Merge pull request #268987 from greg-lindsay/appgw-freshness

add app gw caveat

Author: prmerger-automator[bot]

articles/virtual-network/virtual-network-manage-peering.md

@@ -4,7 +4,7 @@ description: Learn how to create, change, or delete a virtual network peering. W
 author: asudbring
 ms.service: virtual-network
 ms.topic: how-to
-ms.date: 08/24/2023
+ms.date: 03/13/2024
 ms.author: allensu
 ms.custom: template-how-to, engagement-fy23, devx-track-azurepowershell, devx-track-azurecli
 ---
@@ -69,7 +69,7 @@ Before creating a peering, familiarize yourself with the [requirements and const
     | Subscription | Select the [subscription](../azure-glossary-cloud-terminology.md#subscription) of the virtual network you want to peer with. One or more subscriptions are listed, depending on how many subscriptions your account has read access to. If you checked the **I know my resource ID** checkbox, this setting isn't available. |
     | Virtual network | Select the virtual network you want to peer with. You can select a virtual network created through either Azure deployment model. If you want to select a virtual network in a different region, you must select a virtual network in a [supported region](#cross-region). You must have read access to the virtual network for it to be visible in the list. If a virtual network is listed, but grayed out, it may be because the address space for the virtual network overlaps with the address space for this virtual network. If virtual network address spaces overlap, they can't be peered. If you checked the **I know my resource ID** checkbox, this setting isn't available. |
     | Allow 'vnet-2' to access 'vnet-1' | By **default**, this option is selected. </br></br>  - Select **Allow 'vnet-2' to access 'vnet-1'** if you want to enable communication between the two virtual networks through the default `VirtualNetwork` flow. Enabling communication between virtual networks allows resources that are connected to either virtual network to communicate with each other over the Azure private network. The **VirtualNetwork** service tag for network security groups encompasses the virtual network and peered virtual network when this setting is set to **Selected**. To learn more about service tags, see [Azure service tags](./service-tags-overview.md). |
-    | Allow 'vnet-2' to receive forwarded traffic from 'vnet-1' | This option **isn't selected by default**. </br></br> -To allow forwarded traffic from the peered virtual network, select **Allow 'vnet-2' to receive forwarded traffic from 'vnet-1'**. This setting can be selected if you want to allow traffic that doesn't originated from **vnet-1** to reach **vnet-2**. For example, if **vnet-1** has an NVA that receives traffic from outside of **vnet-1** that gets forwards to **vnet-2**, you can select this setting to allow that traffic to reach **vnet-2** from **vnet-1**. While enabling this capability allows the forwarded traffic through the peering, it doesn't create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Learn about [user-defined routes](virtual-networks-udr-overview.md#user-defined). </br></br> **NOTE:** *Not selecting the **Allow 'vnet-1' to receive forwarded traffic from 'vnet-2'** setting only changes the definition of the **VirtualNetwork** service tag. It *doesn't* fully prevent traffic flow across the peer connection, as explained in this setting description.*  |
+    | Allow 'vnet-2' to receive forwarded traffic from 'vnet-1' | This option **isn't selected by default**. </br></br> -To allow forwarded traffic from the peered virtual network, select **Allow 'vnet-2' to receive forwarded traffic from 'vnet-1'**. This setting can be selected if you want to allow traffic that doesn't originate from **vnet-1** to reach **vnet-2**. For example, if **vnet-1** has an NVA that receives traffic from outside of **vnet-1** that gets forwards to **vnet-2**, you can select this setting to allow that traffic to reach **vnet-2** from **vnet-1**. While enabling this capability allows the forwarded traffic through the peering, it doesn't create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. Learn about [user-defined routes](virtual-networks-udr-overview.md#user-defined). </br></br> **NOTE:** *Not selecting the **Allow 'vnet-1' to receive forwarded traffic from 'vnet-2'** setting only changes the definition of the **VirtualNetwork** service tag. It *doesn't* fully prevent traffic flow across the peer connection, as explained in this setting description.*  |
     | Allow gateway in 'vnet-2' to forward traffic to 'vnet-1' | This option **isn't selected by default**. </br></br> - Select **Allow gateway in 'vnet-2' to forward traffic to 'vnet-1'** if you want **vnet-1** to receive traffic from **vnet-2**'s gateway/Route Server. **vnet-2** must contain a gateway in order for this option to be enabled. |
     | Enable 'vnet-2' to use 'vnet-1's' remote gateway |  This option **isn't selected by default.**  </br></br> - Select **Enable 'vnet-2' to use 'vnet-1' remote gateway** if you want **vnet-2** to use **vnet-1**'s gateway or Route Server. **vnet-2** can only use a remote gateway or Route Server from one peering connection. **vnet-1** has to have a gateway or Route Server in order for you to select this option. For example, the virtual network you're peering with has a VPN gateway that enables communication to an on-premises network. Selecting this setting allows traffic from this virtual network to flow through the VPN gateway in the peered virtual network. </br></br> You can also select this option, if you want this virtual network to use the remote Route Server to exchange routes, see [Azure Route Server](../route-server/overview.md). </br></br> This scenario requires implementing user-defined routes that specify the virtual network gateway as the next hop type. Learn about [user-defined routes](virtual-networks-udr-overview.md#user-defined). You can only specify a VPN gateway as a next hop type in a user-defined route, you can't specify an ExpressRoute gateway as the next hop type in a user-defined route. </br></br> **NOTE:** *You can't use remote gateways if you already have a gateway configured in your virtual network. To learn more about using a gateway for transit, see [Configure a VPN gateway for transit in a virtual network peering](../vpn-gateway/vpn-gateway-peering-gateway-transit.md)*. |
 
@@ -337,6 +337,8 @@ az network vnet peering delete \
 
 - There's a nominal charge for ingress and egress traffic that utilizes a virtual network peering. For more information, see the [pricing page](https://azure.microsoft.com/pricing/details/virtual-network).
 
+- Application Gateways that do not have [Network Isolation](../application-gateway/application-gateway-private-deployment.md?tabs=portal) enabled don't allow traffic to be sent between peered VNETs when **Allow traffic to remote virtual network** is disabled.
+
 ## Permissions
 
 The accounts you use to work with virtual network peering must be assigned to the following roles: