Merge pull request #306978 from MicrosoftDocs/repo_sync_working_branch

Taojunshen · web-flow · commit 856d018fd7fd · 2025-10-16T05:53:00.000+08:00
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
diff --git a/articles/application-gateway/tcp-tls-proxy-overview.md b/articles/application-gateway/tcp-tls-proxy-overview.md
@@ -5,7 +5,7 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 05/21/2025
+ms.date: 10/14/2025
 ms.author: mbender
 # Customer intent: As a network architect, I want to implement TCP/TLS proxy capabilities on an application gateway, so that I can efficiently manage both HTTP and non-HTTP workloads while ensuring secure connections to backend servers.
 ---
@@ -33,6 +33,21 @@ Process flow:
 | [**Azure Load Balancer**](../load-balancer/load-balancer-overview.md) | A pass-through load balancer where a client directly establishes a connection with a backend server selected by the Load Balancer's distribution algorithm. |
 | **Azure Application Gateway** | Terminating load balancer where a client directly establishes a connection with Application Gateway and a separate connection is initiated with a backend server selected by Application Gateway's distribution algorithm. |
 
+#### Azure Application Gateway (TLS/TCP proxy)
+- **Type** – Layer-4 terminating proxy.
+- **Protocols** – Supports TCP or TLS protocols.
+- **Versatility** – Use a single endpoint (frontend IP) to serve HTTP and non-HTTP workloads.
+- **Scaling** – Configure autoscaling (up to 125 instances) to serve your TCP and TLS traffic.
+- **Security through TLS termination** – Simplify security with centralized TLS termination and certificate management ensuring consistent compliance across all applications, including non-HTTP workloads. Seamlessly integrates with Azure Key Vault for secure certificate management.
+- **Backend types** – Flexibly connect your applications to backends anywhere; within the same Virtual Network, across peered VNets, through remote FQDNs or IPs, or even via hybrid connectivity to your on-premises servers.
+
+#### Azure Load Balancer
+- **Type** – Layer-4 pass-through network device.
+- **Protocols** – Supports TCP or UDP protocols.
+- **Performance** – Provides low latency and high throughput. Built for millions of simultaneous connections with microsecond-level latency.
+- **Scaling** – Handles long-lived connections and scales up to millions of flows for all TCP and UDP applications.
+- **Inbound and outbound** – Azure Load Balancer delivers complete traffic control with both inbound and outbound capabilities. Seamlessly connect external clients to your applications, while enabling your backend instances to securely reach the internet and other services.
+- **Direct server return** - For the return traffic, the backend instance sends the response packet directly back to the client's IP address, reducing latency and improving performance.
 
 ## Features
 
diff --git a/articles/virtual-wan/about-virtual-hub-routing.md b/articles/virtual-wan/about-virtual-hub-routing.md
@@ -96,6 +96,10 @@ Route tables now have features for association and propagation. A pre-existing r
 
 Virtual hub **Reset** is available only in the Azure portal. Resetting provides you with a way to bring any failed resources such as route tables, hub router, or the virtual hub resource itself back to its rightful provisioning state. Consider resetting the hub before contacting Microsoft for support. This operation doesn't reset any of the gateways in a virtual hub.
 
+## <a name="reset"></a>Router reset
+
+If your Virtual Hub Router enters a failed state, you may be unable to update routes, even though network connectivity might still work. In this scenario, use the **Reset router** option in the vHub settings to restore normal operation. This process typically takes less than 10 minutes and rarely disrupts network traffic. Use this option if the Hub status is in a succeeded state while the routing status is in a failed state.
+
 ## <a name="considerations"></a>Additional considerations
 
 Consider the following items when configuring Virtual WAN routing:
diff --git a/articles/virtual-wan/nat-rules-vpn-gateway.md b/articles/virtual-wan/nat-rules-vpn-gateway.md
@@ -99,7 +99,7 @@ The following diagram shows the projected result:
    For instance, if the on-premises BGP IP address is 10.30.0.133 and there is an **Ingress NAT Rule** that translates 10.30.0.0/24 to 172.30.0.0/24, the VPN site's **Link Connection BGP Address** must be configured to be the translated address (172.30.0.133).
 * In Dynamic NAT, on-premises BGP peer IP can't be part of the pre-NAT address range (**Internal Mapping**) as IP and port translations aren't fixed. If there is a need to translate the on-premises BGP peering IP, please create a separate **Static NAT Rule** that translates BGP Peering IP address only.
 
-   For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premises BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/32, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.168.0.02/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).
+   For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premises BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/24, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.168.0.1/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).
 
 ### Ingress SNAT (VPN site with statically configured routes)
 
diff --git a/articles/vpn-gateway/basic-public-ip-migrate-howto.md b/articles/vpn-gateway/basic-public-ip-migrate-howto.md
@@ -20,7 +20,7 @@ This article helps you migrate a Basic SKU public IP address to a Standard SKU f
 
 During the public IP address SKU migration process, your Basic SKU public IP address resource is migrated to a Standard SKU public IP address resource. The IP address assigned to your gateway doesn't change.
 
-Additionally, if your VPN Gateway gateway SKU is VpnGw 1-5, your gateway SKU is migrated to a VPN Gateway AZ SKU (VpnGw 1-5 AZ). For more information, see [About VPN Gateway SKU consolidation and migration](gateway-sku-consolidation.md).
+Additionally, if your VPN Gateway gateway SKU is VpnGw 1-5, your gateway SKU might be migrated to a VPN Gateway AZ SKU (VpnGw 1-5 AZ). For more information, see [About VPN Gateway SKU consolidation and migration](gateway-sku-consolidation.md).
 
 > [!NOTE]
 > Migration functionality is rolling out to regions. If you don't see the **Migrate** tab in the Azure portal, it means that the migration process isn't available yet in your region. For more information, see the [VPN Gateway - What's New](whats-new.md#upcoming-projected-changes) article.
diff --git a/articles/vpn-gateway/packet-capture.md b/articles/vpn-gateway/packet-capture.md
@@ -29,10 +29,12 @@ The following examples of JSON and a JSON schema provide explanations of each pr
 - You can't run multiple gateway-wide packet captures at the same time.
 - You can't run multiple packet captures on a single connection at the same time. You can run multiple packet captures on different connections at the same time.
 - A maximum of five packet captures can be run in parallel per gateway. These packet captures can be a combination of gateway-wide packet captures and per-connection packet captures.
-- The unit for MaxPacketBufferSize is bytes and MaxFileSize is megabytes
+- The unit for MaxPacketBufferSize is bytes.
+- The unit for MaxFileSize is megabytes.
 
 > [!NOTE]  
 > Set the **CaptureSingleDirectionTrafficOnly** option to **false** if you want to capture both inner and outer packets.
+> When analyzing pcap files containing packets that got truncated due to the **MaxPacketBufferSize** setting, this may result in unexpected warnings like "TCP Previous segment not captured" and "TCP ACKed unseen segment".
 
 **Example JSON**
 
diff --git a/articles/vpn-gateway/vpn-gateway-vpn-faq.md b/articles/vpn-gateway/vpn-gateway-vpn-faq.md
@@ -4,7 +4,7 @@ description: Get answers to frequently asked questions about VPN Gateway connect
 author: cherylmc
 ms.service: azure-vpn-gateway
 ms.topic: concept-article
-ms.date: 05/09/2025
+ms.date: 09/09/2025
 ms.author: cherylmc
 # Customer intent: As a network administrator, I want to understand the configuration options and limitations of Azure VPN Gateway, so that I can effectively manage cross-premises connections and optimize my organization’s hybrid network architecture.
 ---
@@ -155,6 +155,10 @@ We're taking action to ensure the continued operation of deployed VPN gateways t
 
 However, Basic SKU public IP addresses are being phased out. Going forward, when you create a VPN gateway, you must use the Standard SKU public IP address. You can find details on the retirement of Basic SKU public IP addresses in the [Azure Updates announcement](https://azure.microsoft.com/updates/upgrade-to-standard-sku-public-ip-addresses-in-azure-by-30-september-2025-basic-sku-will-be-retired).
 
+> [!NOTE]
+> The timeline for the VPN Gateway using Azure Basic IP is subject to frequent updates.
+> For the latest migration timeline, please see [this page](/azure/vpn-gateway/whats-new#upcoming-projected-changes). 
+
 ### How is my VPN tunnel authenticated?
 
 Azure VPN Gateway uses preshared key (PSK) authentication. We generate a PSK when we create the VPN tunnel. You can change the automatically generated PSK to your own by using the Set Pre-Shared Key REST API or PowerShell cmdlet.
@@ -211,7 +215,7 @@ See the following articles:
 
 The Standard and High Performance SKUs will be deprecated on September 30, 2025. You can view the announcement on the [Azure Updates site](https://go.microsoft.com/fwlink/?linkid=2255127). The product team will make a migration path available for these SKUs by November 30, 2024. For more information, see the [VPN Gateway legacy SKUs](vpn-gateway-about-skus-legacy.md#sku-deprecation) article.
 
-*At this time, there's no action that you need to take.*
+ For the latest migration timeline, please see [Upcoming projected changes](/azure/vpn-gateway/whats-new#upcoming-projected-changes). 
 
 
 [!INCLUDE [legacy SKU deprecation](../../includes/vpn-gateway-deprecate-sku-faq.md)]
@@ -226,14 +230,20 @@ The expected customer impact includes new [pricing](https://azure.microsoft.com/
  
 ### What is the anticipated timeline for the migration?
 
-These timelines may be subject to change. Please revisit this for the most updated timeline. Here's the anticipated timeline for the migration tool availability.
+Here is the anticipated timeline for the migration tool availability and Basic SKU Public IP deprecation.
+
+| Date                          | Event                                                                                              |
+|-------------------------------|----------------------------------------------------------------------------------------------------|
+| Aug 4, 2025                   | Migration tooling for Basic SKU Public IP to Standard SKU becomes available (Public Preview) for **Active-Passive VPN Gateways** in Public Cloud. |
+| Sep 2025 (tentative GA)       | Temporary GA timeline for Public and Sovereign Cloud support.                                      |
+| End of Sep 2025 (tentative GA)| Migration tooling GA for **Active-Active VPN Gateways** (Basic → Standard SKU Public IP).          |
+| Oct 2025 (planned)            | Automated capability becomes available to remove the Basic public IP from **Basic SKU Gateways**. Existing IP addresses remain unchanged and connectivity is not interrupted. |
+| Aug 4, 2025 – End of Jan 2026 | Customer-controlled migrations can be initiated after tool availability (approx. 6 months window). |
+| End of Jan 2026               | Overall migration timeline for all VPN Gateways with Basic IP is extended until this date.         |
+| Feb 2026                      | Basic SKU Public IP addresses are fully deprecated.                                                |
+
+
 
-  | Date                | Event                                                      |
-  |---------------------|------------------------------------------------------------|
-  | Apr/May 2025        | Migration tooling availability for Active-Passive Gateways. |
-  | Jul/Aug 2025        | Migration tooling availability for Active-Active Gateways.  |
-  | May 2025 to Sep 2025| Customer-controlled migration can be initiated after tool availability. |
-  | Sep 2025            | Basic SKU IP addresses are deprecated.                     |
 
 
 ### What are the required customer actions?
diff --git a/includes/bastion-native-connect-tunnel.md b/includes/bastion-native-connect-tunnel.md
@@ -21,7 +21,7 @@ Steps:
 
 1. Sign in to your Azure account using `az login`. If you have more than one subscription, you can view them using `az account list` and select the subscription containing your Bastion resource using `az account set --subscription "<subscription ID>"`.
 
-1. Open the tunnel to your target VM.
+1. Open the tunnel to your target VM. Without root privileges use local port 1024 or above as ports below that are privileged ports only accessible by root.
 
    ```azurecli
    az network bastion tunnel --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId or VMSSInstanceResourceId>" --resource-port "<TargetVMPort>" --port "<LocalMachinePort>"
diff --git a/includes/vpn-gateway-p2s-clientcert-include.md b/includes/vpn-gateway-p2s-clientcert-include.md
@@ -14,7 +14,7 @@ You can generate client certificates by using the following methods:
 
 * **Enterprise certificate:**
 
-  * If you're using an enterprise certificate solution, generate a client certificate with the common name value format *name\@yourdomain.com*. Use this format instead of the *domain name\username* format.
+  * If you're using an enterprise certificate solution, generate a client certificate with the common name value format *name\@contoso.com*. Use this format instead of the *domain name\username* format.
 
   * Make sure the client certificate is based on a user certificate template that has *Client Authentication* listed as the first item in the user list. Check the certificate by double-clicking it and viewing **Enhanced Key Usage** in the **Details** tab.
 
@@ -28,4 +28,4 @@ You can generate client certificates by using the following methods:
 
   * [MakeCert instructions](../articles/vpn-gateway/vpn-gateway-certificates-point-to-site-makecert.md): Use MakeCert if you don't have access to a Windows 10 or later computer for generating certificates. Although MakeCert is deprecated, you can still use it to generate certificates. You can install the generated certificates on any supported P2S client.
 
-  * Linux: See [strongSwan](../articles/vpn-gateway/vpn-gateway-certificates-point-to-site-linux.md) or [OpenSSL](../articles/vpn-gateway/point-to-site-certificates-linux-openssl.md) instructions.
+  * Linux: See [strongSwan](../articles/vpn-gateway/vpn-gateway-certificates-point-to-site-linux.md) or [OpenSSL](../articles/vpn-gateway/point-to-site-certificates-linux-openssl.md) instructions.
