Merge pull request #308900 from wtnlee/ft-post-release

test

Author: prmerger-automator[bot]

articles/virtual-wan/about-internet-routing.md

@@ -59,7 +59,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.
-    * Virtual Network connection **bypass next hop setting** is ignored for deployments using static routes on Virtual Network connections with **propagate static route** enabled. Traffic destined for the Virtual Network connection will be inspected by the security appliance in the hub and  routed directly to the destination IP in the spoke Virtual Network, bypassing the next hop IP configured in the static route.  
+    * 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.
   * 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.
 

articles/virtual-wan/howto-connect-vnet-hub-powershell.md

@@ -18,7 +18,7 @@ Before you create a connection, be aware of the following:
 * A virtual network can only be connected to one virtual hub at a time.
 * In order to connect it to a virtual hub, the remote virtual network can't have a gateway (ExpressRoute or VPN) or RouteServer.
 * To connect a cross-tenant remote virtual network to the virtual hub, refer to [Connect cross-tenant virtual networks to a Virtual WAN hub](cross-tenant-vnet.md).
-* Make sure to check if you'd like to enable [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#understanding-bypass-next-hop-ip-for-workloads-within-this-vnet) for your connection.
+* Make sure to check if you'd like to enable [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#bypassexplained) for your connection.
 
 * Some configuration settings, such as **Propagate static route**, can only be configured in the Azure portal at this time. See the [Azure portal](howto-connect-vnet-hub.md) version of this article for steps.
 

articles/virtual-wan/howto-connect-vnet-hub.md

@@ -30,7 +30,7 @@ Before you create a connection, be aware of the following:
 >
 > * To delete a virtual network connected to the virtual hub, you must delete both the virtual network connection and virtual network resource. 
 
-## Understanding Bypass Next Hop IP for workloads within this VNet
+## <a name="bypassexplained"> </a> Understanding Bypass Next Hop IP for workloads within this VNet
 [!INCLUDE [Bypass Next Hop IP](../../includes/virtual-wan-bypass-next-hop-ip-include.md)]
 
 ## Next steps

articles/virtual-wan/scenario-route-through-nva.md

@@ -102,7 +102,7 @@ In **Figure 2**, there are two hubs; **Hub1** and **Hub2**.
 
 * This scenario doesn't support Secure Hubs with Routing Intent due to the [routing policies limitations](how-to-routing-policies.md#knownlimitations) regarding static routes. However, you can use the [BGP peering feature](scenario-bgp-peering-hub.md) to use indirect spokes together with Secure Hubs with Routing Intent.
 
-* Make sure to review the static routes placed on your VNet Connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#understanding-bypass-next-hop-ip-for-workloads-within-this-vnet) is enabled for your connection.
+* Make sure to review the static routes placed on your VNet Connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#bypassexplained) is enabled for your connection.
 
 ## <a name="workflow"></a>Scenario workflow
 

articles/virtual-wan/scenario-route-through-nvas-custom.md

@@ -177,7 +177,7 @@ To set up routing via NVA, consider the following steps:
 * Portal users must enable 'Propagate to default route' on connections (VPN/ER/P2S/VNet) for the 0.0.0.0/0 route to take effect.
 * PS/CLI/REST users must set flag 'enableinternetsecurity' to true for the 0.0.0.0/0 route to take effect.
 * Virtual network connection doesn't support 'multiple/unique' next hop IP to the 'same' network virtual appliance in a spoke VNet 'if' one of the routes with next hop IP is indicated to be public IP address or 0.0.0.0/0 (internet).
-* Make sure to review the static routes placed on your VNet connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#understanding-bypass-next-hop-ip-for-workloads-within-this-vnet) is enabled for your connection.
+* Make sure to review the static routes placed on your VNet connections and check if [bypass next hop IP for workloads within this VNet](howto-connect-vnet-hub.md#bypassexplained) is enabled for your connection.
 * When 0.0.0.0/0 is configured as a static route on a virtual network connection, that route is applied to all traffic, including the resources within the spoke itself. This means all traffic will be forwarded to the next hop IP address of the static route (NVA Private IP). Thus, in deployments with a 0.0.0.0/0 route with next hop NVA IP address configured on a spoke virtual network connection, to access workloads in the same virtual network as the NVA directly (i.e. so that traffic doesn't pass through the NVA), specify a /32 route on the spoke virtual network connection. For instance, if you want to access 10.1.3.1 directly, specify 10.1.3.1/32 next hop 10.1.3.1 on the spoke virtual network connection.
 * To simplify routing and to reduce the changes in the Virtual WAN hub route tables, we encourage using the new "BGP peering with Virtual WAN hub" option.