Merge pull request #310073 from wtnlee/ft-ga

prmerger-automator[bot] · web-flow · commit 84f848701483 · 2026-01-05T20:30:15.000Z
ft-ga
diff --git a/articles/virtual-wan/about-internet-routing.md b/articles/virtual-wan/about-internet-routing.md
@@ -35,22 +35,21 @@ The following table shows the availability status of securing Internet access wi
 | Security solution |Status|
 |--|--|
 |Azure Firewall |Generally Available in Azure Public and Azure Government Clouds.|
-|Firewall NVA in the Virtual WAN hub| Generally Available in Azure Public Cloud |
-| Software-as-a-service in the Virtual WAN Hub| Generally Available in Azure Public Cloud|
+|Firewall NVA in the Virtual WAN hub| Generally Available in regions where [Network Virtual Appliances](about-nva-hub.md#regions) are available. |
+| Software-as-a-service in the Virtual WAN Hub|  Generally Avaialble in regions where [Palo Alto Cloud NGFW is available](https://docs.paloaltonetworks.com/cloud-ngfw-azure/reference/cloud-ngfw-for-azure-supported-regions-and-zones).|
 
 ### Forced tunnel
 
 The following table shows the availability status of securing Internet access with **forced tunneling** by configuring private routing policy.
 
-
 >[!IMPORTANT]
-> Configuring Virtual WAN hubs in forced tunnel mode is being progressively deployed to all Azure regions. The current list of available regions are: Australia Central, Brazil South, Central India, East Asia, East US, India West, Korea Central, Malaysia South, Malaysia West, Qatar Central, UK South, and West Central US. If you have any questions regarding region availability, contact virtual-wan-forced-tunnel@microsoft.com or your Microsoft account team. 
+> Configuring Virtual WAN hubs in forced tunnel mode is deployed to Azure Public. Deployment is underway for Azure Government. If you have any questions regarding region availability, contact virtual-wan-forced-tunnel@microsoft.com or your Microsoft account team.
 
  Security solution |Status|
 |--|--|
-|Azure Firewall |Generally Available in select Azure regions (see note above).|
-|Firewall NVA in the Virtual WAN hub| Public Preview in select Azure regions (see note above). |
-| Software-as-a-service in the Virtual WAN Hub| Public Preview in select Azure regions (see note above).|
+|Azure Firewall |Generally Available in Azure Public.|
+|Firewall NVA in the Virtual WAN hub| Public Preview in regions where [Network Virtual Appliances](about-nva-hub.md#regions) are available.|
+| Software-as-a-service in the Virtual WAN Hub| Public Preview in regions where [Palo Alto Cloud NGFW is available](https://docs.paloaltonetworks.com/cloud-ngfw-azure/reference/cloud-ngfw-for-azure-supported-regions-and-zones).|
 
 ### Known Limitations
 
@@ -59,7 +58,7 @@ The following table shows the availability status of securing Internet access wi
     * Destination-NAT (DNAT) for security solutions deployed in the Virtual WAN hub is **not supported** for Virtual WAN hubs that are configured with Forced Tunnel internet routing mode. The incoming connection for DNAT traffic originates from the Internet. However, forced tunnel mode forces return traffic via on-premises or an NVA. This routing pattern results in asymmetric routing. 
     * Traffic from on-premises destined for the public IP address of an Azure storage account deployed in the same Azure region as the Virtual WAN hub bypasses security solution in the hub. For more details on issue, see [Virtual WAN known issues](whats-new.md#knownissues).
     * On-premises **can't** advertise forced tunnel routes more specific that 0.0.0.0/0. Advertising more specific routes like 0.0.0.0/1 and 128.0.0.0/1 from on-premises may blackhole in management traffic for Azure Firewall or NVAs integrated in the Virtual Hub.
-    * When a 0.0.0.0/0 route is configured as a static route on a Virtual Network connection, the **bypass next hop setting** that is configured on the Virtual Network connection is ignored and is will be considered by Virtual WAN as **bypass/equals**. This means that that traffic destined for IP addresses within  Virtual Network connection with the configured 0.0.0.0/0 static route will be inspected by the security appliance in the Virtual Hub and routed directly to the destination IP in the spoke Virtual Network. Traffic will **bypass** the next hop IP configured in the static route. For a detaield example of this routing behavior, see **traffic behavior With Bypass Next Hop IP Enabled** in the [bypass next hop IP](howto-connect-vnet-hub.md#bypassexplained) document.
+    * When a 0.0.0.0/0 route is configured as a static route on a Virtual Network connection, the **bypass next hop setting** that is configured on the Virtual Network connection is ignored and considered to be set to **bypass/equals**. This means that that traffic destined for IP addresses within  Virtual Network connection with the configured 0.0.0.0/0 static route will be inspected by the security appliance in the Virtual Hub and routed directly to the destination IP in the spoke Virtual Network. Traffic will **bypass** the next hop IP configured in the static route. For a detailed example of this routing behavior, see **traffic behavior with Bypass Next Hop IP enabled** in the [bypass next hop IP](howto-connect-vnet-hub.md#bypassexplained) document.
   * The default route learned from ExpressRoute can't be advertised to another ExpressRoute circuit. This means you can't configure Virtual WAN to route Internet traffic from one ExpressRoute circuit to another ExpressRoute circuit for egress. 
   * If there is no 0.0.0.0/0 route learnt from on-premises or a static route configured to point to a NVA in a spoke Network, the effective routes on the security solution incorrectly displays 0.0.0.0/0 with next hop Internet. As Internet-traffic is not forwarded to the security solution in the hub when forced tunnel mode is configured without an explicit 0.0.0.0/0 learnt from on-premises or configured as a static route, effective routes should **not** contain a  0.0.0.0/0 route.
   
diff --git a/articles/virtual-wan/how-to-routing-policies.md b/articles/virtual-wan/how-to-routing-policies.md
@@ -107,9 +107,9 @@ Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) ar
     
 * Routing Intent simplifies routing by managing route table associations and propagations for all connections (Virtual Network, Site-to-site VPN, Point-to-site VPN, and ExpressRoute). Virtual WANs with custom route tables and customized policies therefore can't be used with the Routing Intent constructs.
 * Encrypted ExpressRoute (Site-to-site VPN tunnels running over ExpressRoute circuits) is supported in hubs where routing intent is configured if Azure Firewall is configured to allow traffic between VPN tunnel endpoints (Site-to-site VPN Gateway private IP and on-premises VPN device private IP). For more information on the required configurations, see [Encrypted ExpressRoute with routing intent](#encryptedER).
+* For deployments where static routes are specified on a Virtual Network connection with **proagate static routes enabled**, the **bypass next hop setting** that is configured on the Virtual Network connection is ignored and is considered to be set to **bypass/equals**. This means that if the connected Virtual Network address space (corresponding to the connection with the configured static route) is a subnet within the configured static route on the Virtual Network connection, traffic destined for the Virtual Network will be inspected by the security appliance in the Virtual Hub and routed **directly** to the destination IP in the spoke Virtual Network. Traffic will **bypass** the next hop IP configured in the static route. For a detailed example of this routing behavior, see **traffic behavior with Bypass Next Hop IP enabled** in the [bypass next hop IP](howto-connect-vnet-hub.md#bypassexplained) document.
 * The following connectivity use cases are **not** supported with Routing Intent:
-  * Static routes in the defaultRouteTable that point to a Virtual Network connection can't be used in conjunction with routing intent. However, you can use the [BGP peering feature](scenario-bgp-peering-hub.md).
-  * Static routes on the Virtual Network connection with "static route propagation" aren't applied to the next-hop resource specified in private routing policies. Support for applying static routes on Virtual Network connections to private routing policy next-hop is on the roadmap.
+  * Static routes in the defaultRouteTable that point to a Virtual Network connection can't be used in conjunction with routing intent. Instead of using static routes on the defaultRouteTable, you  you can use the [BGP peering feature](scenario-bgp-peering-hub.md) or apply static routes on the Virtual Network connection with "static route propagation" enabled. Routes learnt via BGP or specified as a static route on a Virtual Network connection **are applied** to the next-hop resource specified in private routing policies.
   * The ability to deploy both an SD-WAN connectivity NVA and a separate Firewall NVA or SaaS solution in the **same** Virtual WAN hub is currently in the road-map. Once routing intent is configured with next hop SaaS solution or Firewall NVA, connectivity between the SD-WAN NVA and Azure is impacted. Instead, deploy the SD-WAN NVA and Firewall NVA or SaaS solution in different Virtual Hubs. Alternatively, you can also deploy the SD-WAN NVA in a spoke Virtual Network connected to the hub and leverage the virtual hub [BGP peering](scenario-bgp-peering-hub.md) capability.
   * Network Virtual Appliances (NVAs) can only be specified as the next hop resource for routing intent if they're Next-Generation Firewall or dual-role Next-Generation Firewall and SD-WAN NVAs. Currently, **checkpoint**, **fortinet-ngfw**, **fortinet-ngfw-and-sdwan** and **cisco-tdv-vwan-nva**  are the only NVAs eligible to be configured to be the next hop for routing intent. If you attempt to specify another NVA, Routing Intent creation fails. You can check the type of the NVA by navigating to your Virtual Hub -> Network Virtual Appliances and then looking at the **Vendor** field. [**Palo Alto Networks Cloud NGFW**](how-to-palo-alto-cloud-ngfw.md) is also supported as the next hop for Routing Intent, but is considered a next hop of type **SaaS solution**. 
   * Routing Intent users who want to connect multiple ExpressRoute circuits to Virtual WAN and want to send traffic between them via a security solution deployed in the hub can enable open up a support case to enable this use case. Reference [enabling connectivity across ExpressRoute circuits](#expressroute) for more information.
diff --git a/articles/virtual-wan/whats-new.md b/articles/virtual-wan/whats-new.md
@@ -27,7 +27,7 @@ You can also find the latest Azure Virtual WAN updates and subscribe to the RSS
 
 | Type |Area |Name |Description | Date added | Limitations |
 | --- |---|---|---|---|---|
-| Feature| Routing| Forced tunnel| November 2025| Forced tunnel gives additional flexibility when routing internet traffic via security solutions deployed in the Virtual WAN hub. Forced tunnel mode allows customers who use routing intent to first inspect internet-bound traffic via a security solution deployed in the hub and then forward inspected traffic via a dynamically learnt 0.0.0.0/0 route learnt from on-premises or Network Virtual Appliance, or a static route configured on a  Virtual WAN spoke Virtual Network connection. For more information on supported internet access patterns in Virtual WAN, see [about internet routing in Virtual WAN](about-internet-routing.md)| See [internet routing in Virtual WAN](about-internet-routing.md) for limitations as well as region restrictions. |
+| Feature| Routing| Forced tunnel| November 2025| Forced tunnel gives additional flexibility when routing internet traffic via security solutions deployed in the Virtual WAN hub. Forced tunnel mode allows customers who use routing intent to first inspect internet-bound traffic via a security solution deployed in the hub and then forward inspected traffic via a dynamically learnt 0.0.0.0/0 route learnt from on-premises or Network Virtual Appliance, or a static route configured on a  Virtual WAN spoke Virtual Network connection. For more information on supported internet access patterns in Virtual WAN, see [about internet routing in Virtual WAN](about-internet-routing.md)| See [internet routing in Virtual WAN](about-internet-routing.md) for more information regarding limitation and availability. |
 | Feature | Routing | Route-maps | General Availability of Route-maps. Route-maps is a feature that gives you the ability to control route advertisements and routing for Virtual WAN virtual hubs. | April 2025|[Known limitations](route-maps-about.md#considerations-and-limitations)| 
 | Metric| Routing | [New Virtual hub metrics](monitor-virtual-wan-reference.md#hub-router-metrics)| There are now two new  Virtual WAN hub metrics that display the virtual hub's capacity and spoke Virtual Machine (VM) utilization: **Routing Infrastructure Units** and **Spoke VM Utilization**.| August 2024 | The **Spoke VM Utilization** metric represents an approximate number of deployed spoke VMs as a percentage of the total number of spoke VMs that the hub's routing infrastructure units can support. 
 | Feature| Routing | [Routing intent](how-to-routing-policies.md)| Routing intent is the mechanism through which you can configure Virtual WAN to send private or internet traffic via a security solution deployed in the hub.|May 2023|Routing Intent is Generally Available  in Azure public cloud. See documentation for [other limitations](how-to-routing-policies.md#knownlimitations).|
