freshness review

cherylmc · cherylmc · commit 1ff7bb95b5cb · 2025-03-26T12:42:24.000-04:00
diff --git a/articles/virtual-wan/connect-virtual-network-gateway-vwan.md b/articles/virtual-wan/connect-virtual-network-gateway-vwan.md
@@ -4,7 +4,7 @@ description: Learn how to connect an Azure VPN gateway (virtual network gateway)
 author: cherylmc
 ms.service: azure-virtual-wan
 ms.topic: how-to
-ms.date: 07/28/2023
+ms.date: 03/26/2025
 ms.author: cherylmc
 
 ---
@@ -29,7 +29,6 @@ Virtual Network (for virtual network gateway)
 
 * [Create a virtual network](../virtual-network/quick-create-portal.md) without any virtual network gateways. This virtual network will be configured with an active/active virtual network gateway in later steps. Verify that none of the subnets of your on-premises networks overlap with the virtual networks that you want to connect to.
 
-
 ## <a name="vnetgw"></a>1. Configure VPN Gateway virtual network gateway
 
 In this section you create a VPN Gateway virtual network gateway in active-active mode for your virtual network. When you create the gateway, you can either use existing public IP addresses for the two instances of the gateway, or you can create new public IPs. You'll use these public IPs when setting up the Virtual WAN sites. 
diff --git a/articles/virtual-wan/gateway-settings.md b/articles/virtual-wan/gateway-settings.md
@@ -5,7 +5,7 @@ description: This article answers common questions about Virtual WAN gateway set
 author: cherylmc
 ms.service: azure-virtual-wan
 ms.topic: concept-article
-ms.date: 07/28/2023
+ms.date: 03/26/2025
 ms.author: cherylmc
 
 ---
diff --git a/articles/virtual-wan/how-to-forced-tunnel.md b/articles/virtual-wan/how-to-forced-tunnel.md
@@ -5,7 +5,7 @@ description: Learn to configure forced tunneling for P2S VPN in Virtual WAN.
 author: wtnlee
 ms.service: azure-virtual-wan
 ms.topic: how-to
-ms.date: 08/24/2023
+ms.date: 03/26/2025
 ms.author: wellee
 
 ---
diff --git a/articles/virtual-wan/howto-connect-vnet-hub.md b/articles/virtual-wan/howto-connect-vnet-hub.md
@@ -5,7 +5,7 @@ description: Learn how to connect a VNet to a Virtual WAN hub using the portal.
 author: cherylmc
 ms.service: azure-virtual-wan
 ms.topic: how-to
-ms.date: 06/14/2023
+ms.date: 03/26/2025
 ms.author: cherylmc
 
 ---
diff --git a/articles/virtual-wan/routing-deep-dive.md b/articles/virtual-wan/routing-deep-dive.md
@@ -6,7 +6,7 @@ services: virtual-wan
 author: erjosito
 ms.service: azure-virtual-wan
 ms.topic: concept-article
-ms.date: 08/24/2023
+ms.date: 03/26/2025
 ms.author: jomore
 ---
 
@@ -27,7 +27,7 @@ All VNet and branch connections are associated and propagating to the default ro
 :::image type="content" source="./media/routing-deep-dive/virtual-wan-routing-deep-dive-scenario-1.png" alt-text="Diagram that shows a Virtual WAN design with two ExpressRoute circuits and two V P N branches." :::
 
 > [!IMPORTANT]
-> The previous diagram shows two secured virtual hubs, this topology is supported with Routing Intent. For more information see [How to configure Virtual WAN Hub routing intent and routing policies][virtual-wan-intent].
+> The previous diagram shows two secured virtual hubs. This topology is supported with Routing Intent. For more information, see [How to configure Virtual WAN Hub routing intent and routing policies][virtual-wan-intent].
 
 Out of the box, the Virtual WAN hubs exchange information between each other so that communication across regions is enabled. You can inspect the effective routes in Virtual WAN route tables: for example, the following picture shows  the effective routes in hub 1:
 
diff --git a/articles/virtual-wan/sd-wan-connectivity-architecture.md b/articles/virtual-wan/sd-wan-connectivity-architecture.md
@@ -7,7 +7,7 @@ author: skishen525
 
 ms.service: azure-virtual-wan
 ms.topic: concept-article
-ms.date: 08/24/2023
+ms.date: 03/26/2025
 ms.author: sukishen
 
 ---
diff --git a/articles/virtual-wan/virtual-wan-expressroute-about.md b/articles/virtual-wan/virtual-wan-expressroute-about.md
@@ -4,7 +4,7 @@ description: Learn about using ExpressRoute in Azure Virtual WAN to connect your
 author: cherylmc
 ms.service: azure-virtual-wan
 ms.topic: conceptual
-ms.date: 11/21/2023
+ms.date: 03/26/2025
 ms.author: cherylmc
 ---
 # About ExpressRoute connections in Azure Virtual WAN
diff --git a/articles/virtual-wan/virtual-wan-faq.md b/articles/virtual-wan/virtual-wan-faq.md
@@ -5,7 +5,7 @@ author: cherylmc
 ms.service: azure-virtual-wan
 ms.custom: devx-track-azurepowershell
 ms.topic: faq
-ms.date: 03/27/2024
+ms.date: 03/26/2025
 ms.author: cherylmc
 # Customer intent: As someone with a networking background, I want to read more details about Virtual WAN in a FAQ format.
 ---
@@ -219,7 +219,7 @@ A connection from a branch or VPN device into Azure Virtual WAN is a VPN connect
 
 ### What happens if the on-premises VPN device only has 1 tunnel to an Azure Virtual WAN VPN gateway?
 
-An Azure Virtual WAN connection is composed of 2 tunnels. A Virtual WAN VPN gateway is deployed in a virtual hub in active-active mode, which implies that there are separate tunnels from on-premises devices terminating on separate instances. This is the recommendation for all users. However, if the user chooses to only have 1 tunnel to one of the Virtual WAN VPN gateway instances, if for any reason (maintenance, patches etc.) the gateway instance is taken offline, the tunnel will be moved to the secondary active instance and the user might experience a reconnect. BGP sessions won't move across instances.
+An Azure Virtual WAN connection is composed of 2 tunnels. A Virtual WAN VPN gateway is deployed in a virtual hub in active-active mode, which implies that there are separate tunnels from on-premises devices terminating on separate instances. This is the recommendation for all users. However, if the user chooses to only have 1 tunnel to one of the Virtual WAN VPN gateway instances, if for any reason (maintenance, patches, etc.) the gateway instance is taken offline, the tunnel will be moved to the secondary active instance and the user might experience a reconnect. BGP sessions won't move across instances.
 
 ### What happens during a gateway reset in a Virtual WAN VPN gateway?
 
diff --git a/articles/virtual-wan/virtual-wan-global-transit-network-architecture.md b/articles/virtual-wan/virtual-wan-global-transit-network-architecture.md
@@ -6,7 +6,7 @@ author: cherylmc
 
 ms.service: azure-virtual-wan
 ms.topic: conceptual
-ms.date: 09/25/2023
+ms.date: 03/26/2025
 ms.author: cherylmc
 
 ---
@@ -51,7 +51,7 @@ An Enterprise cloud footprint can span multiple cloud regions and it's optimal (
 
 **Figure 3: Virtual WAN cross-region connectivity**
 
-When multiple hubs are enabled in a single virtual WAN, the hubs are automatically interconnected via hub-to-hub links, thus enabling global connectivity between branches and Vnets that are distributed across multiple regions. 
+When multiple hubs are enabled in a single virtual WAN, the hubs are automatically interconnected via hub-to-hub links, thus enabling global connectivity between branches and VNets that are distributed across multiple regions. 
 
 Additionally, hubs that are all part of the same virtual WAN, can be associated with different regional access and security policies. For more information, see [Security and policy control](#security) later in this article.
 
@@ -87,7 +87,7 @@ ExpressRoute is a private and resilient way to connect your on-premises networks
 
 There are two options to enable ExpressRoute to ExpressRoute transit connectivity when using Azure Virtual WAN:
 
-* You can enable ExpressRoute to ExpressRoute transit connectivity by enabling ExpressRoute Global Reach on your ExpressRoute circuits. [Global Reach](../expressroute/expressroute-global-reach.md) is an ExpressRoute add-on feature that allows you to link ExpressRoute circuits in different peering locations together to make a private network. ExpressRoute to ExpressRoute transit connectivity between circuits with the Global Reach add-on will not transit the Virtual WAN hub because Global Reach enables a more optimal path over the global backbone.
+* You can enable ExpressRoute to ExpressRoute transit connectivity by enabling ExpressRoute Global Reach on your ExpressRoute circuits. [Global Reach](../expressroute/expressroute-global-reach.md) is an ExpressRoute add-on feature that allows you to link ExpressRoute circuits in different peering locations together to make a private network. ExpressRoute to ExpressRoute transit connectivity between circuits with the Global Reach add-on won't transit the Virtual WAN hub because Global Reach enables a more optimal path over the global backbone.
 
 * You can use the Routing Intent feature with private traffic routing policies to enable ExpressRoute transit connectivity via a security appliance deployed in the Virtual WAN Hub. This option doesn't require Global Reach. For more information, see the [ExpressRoute section](how-to-routing-policies.md#expressroute) in routing intent documentation.
 
@@ -99,7 +99,7 @@ This option lets enterprises leverage the Azure backbone to connect branches. Ho
 
 > [!NOTE]
 > Disabling Branch-to-Branch Connectivity in Virtual WAN -
-> Virtual WAN can be configured to disable Branch-to-Branch connectivity. This configuration will block route propagation between VPN (S2S and P2S) and Express Route connected sites. This configuration will not affect branch-to-Vnet and Vnet-to-Vnet route propagation and connectivity. To configure this setting using Azure Portal: Under Virtual WAN Configuration menu, Choose Setting: Branch-to-Branch - Disabled. 
+> Virtual WAN can be configured to disable Branch-to-Branch connectivity. This configuration will block route propagation between VPN (S2S and P2S) and Express Route connected sites. This configuration won't affect branch-to-VNet and VNet-to-VNet route propagation and connectivity. To configure this setting using the Azure portal: Under the Virtual WAN Configuration menu, choose setting: Branch-to-Branch - Disabled.
 
 ### Remote User-to-VNet (c)
 
@@ -111,7 +111,7 @@ The Remote User-to-branch path lets remote users who are using a point-to-site c
 
 ### VNet-to-VNet transit (e) and VNet-to-VNet cross-region (h)
 
-The VNet-to-VNet transit enables VNets to connect to each other in order to interconnect multi-tier applications that are implemented across multiple VNets. Optionally, you can connect VNets to each other through VNet Peering and this may be suitable for some scenarios where transit via the VWAN hub isn't necessary.
+The VNet-to-VNet transit enables VNets to connect to each other in order to interconnect multi-tier applications that are implemented across multiple VNets. Optionally, you can connect VNets to each other through VNet Peering and this might be suitable for some scenarios where transit via the VWAN hub isn't necessary.
 
 
 ## <a name="DefaultRoute"></a>Forced tunneling and default route
@@ -152,7 +152,7 @@ The VNet-to-VNet secured transit enables VNets to connect to each other via secu
 
 ### VNet-to-Internet or third-party Security Service (i)
 
-The VNet-to-Internet enables VNets to connect to the internet via the security appliances (Azure Firewall, select NVA and SaaS) in the virtual WAN hub. Traffic to internet via supported third-party security services doesn't flow through a security appliance and is routed straight to the third-party security service. You can configure Vnet-to-Internet path via supported third-party security service using Azure Firewall Manager.  
+The VNet-to-Internet enables VNets to connect to the internet via the security appliances (Azure Firewall, select NVA and SaaS) in the virtual WAN hub. Traffic to internet via supported third-party security services doesn't flow through a security appliance and is routed straight to the third-party security service. You can configure VNet-to-Internet path via supported third-party security service using Azure Firewall Manager.  
 
 ### Branch-to-Internet or third-party Security Service (j)
 
@@ -172,21 +172,21 @@ The Branch-to-VNet secured transit enables branches to communicate with virtual
 
 ### How do I enable default route (0.0.0.0/0) in a Secured Virtual Hub
 
-Azure Firewall deployed in a Virtual WAN hub (Secure Virtual Hub) can be configured as default router to the Internet or Trusted Security Provider for all branches (connected by VPN or Express Route), spoke Vnets and Users (connected via P2S VPN). 
-This configuration must be done using Azure Firewall Manager.  See Route Traffic to your hub to configure all traffic from branches (including Users) as well as Vnets to Internet via the Azure Firewall. 
+Azure Firewall deployed in a Virtual WAN hub (Secure Virtual Hub) can be configured as default router to the Internet or Trusted Security Provider for all branches (connected by VPN or Express Route), spoke VNets and Users (connected via P2S VPN). 
+This configuration must be done using Azure Firewall Manager.  See Route Traffic to your hub to configure all traffic from branches (including Users) as well as VNets to Internet via the Azure Firewall. 
 
 This is a two step configuration:
 
-1. Configure Internet traffic routing using Secure Virtual Hub Route Setting menu. Configure Vnets and Branches that can send traffic to the internet via the Firewall.
+1. Configure Internet traffic routing using Secure Virtual Hub Route Setting menu. Configure VNets and Branches that can send traffic to the internet via the Firewall.
 
-2. Configure which Connections (Vnet and Branch) can route traffic to the internet (0.0.0.0/0) via the Azure FW in the hub or Trusted Security Provider. This step ensures that the default route is propagated to selected branches and Vnets that are attached to the Virtual WAN hub via the Connections. 
+2. Configure which Connections (VNet and Branch) can route traffic to the internet (0.0.0.0/0) via the Azure FW in the hub or Trusted Security Provider. This step ensures that the default route is propagated to selected branches and VNets that are attached to the Virtual WAN hub via the Connections. 
 
 ### Force tunneling traffic to on-premises firewall in a Secured Virtual Hub
 
-If there is already a default route learned (via BGP) by the Virtual Hub from one of the Branches (VPN or ER sites), this default route is overridden by the default route learned from Azure Firewall Manager setting. In this case, all traffic that is entering the hub from Vnets and branches destined to internet, will be routed to the Azure Firewall or Trusted Security Provider.
+If there is already a default route learned (via BGP) by the Virtual Hub from one of the Branches (VPN or ER sites), this default route is overridden by the default route learned from Azure Firewall Manager setting. In this case, all traffic that is entering the hub from VNets and branches destined to internet, will be routed to the Azure Firewall or Trusted Security Provider.
 
 > [!NOTE]
-> Currently there is no option to select on-premises firewall or Azure Firewall (and Trusted Security Provider) for internet bound traffic originating from Vnets, Branches or Users. The default route learned from the Azure Firewall Manager setting is always preferred over the default route learned from one of the branches.
+> Currently there is no option to select on-premises firewall or Azure Firewall (and Trusted Security Provider) for internet bound traffic originating from VNets, Branches or Users. The default route learned from the Azure Firewall Manager setting is always preferred over the default route learned from one of the branches.
 
 
 ## Next steps
