Skip to content

Commit 7da9952

Browse files
Merge pull request #297125 from cherylmc/vwan-fresh4
freshness review vwan
2 parents 5c685b1 + 5de08cd commit 7da9952

File tree

2 files changed

+17
-19
lines changed

2 files changed

+17
-19
lines changed

articles/virtual-wan/whats-new.md

Lines changed: 12 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ description: Learn what's new with Azure Virtual WAN such as the latest release
44
author: cherylmc
55
ms.service: azure-virtual-wan
66
ms.topic: concept-article
7-
ms.date: 03/04/2024
7+
ms.date: 03/27/2025
88
ms.author: cherylmc
99
---
1010

@@ -25,7 +25,7 @@ You can also find the latest Azure Virtual WAN updates and subscribe to the RSS
2525

2626
| Type |Area |Name |Description | Date added | Limitations |
2727
| --- |---|---|---|---|---|
28-
| 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.
28+
| 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.
2929
| 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).|
3030
|Feature| Routing |[Virtual hub routing preference](about-virtual-hub-routing-preference.md)|Hub routing preference gives you more control over your infrastructure by allowing you to select how your traffic is routed when a virtual hub router learns multiple routes across S2S VPN, ER, and SD-WAN NVA connections. |October 2022| |
3131
|Feature| Routing|[Bypass next hop IP for workloads within a spoke VNet connected to the virtual WAN hub generally available](how-to-virtual-hub-routing.md)|Bypassing next hop IP for workloads within a spoke VNet connected to the virtual WAN hub lets you deploy and access other resources in the VNet with your NVA without any additional configuration.|October 2022| |
@@ -66,15 +66,15 @@ You can also find the latest Azure Virtual WAN updates and subscribe to the RSS
6666
| Type |Area |Name |Description | Date added | Limitations |
6767
| --- |---|---|---|---|---|
6868
|Feature|Remote User connectivity/Point-to-site VPN |[User Groups and IP address pools for P2S User VPNs](user-groups-about.md) |Ability to configure P2S User VPNs to assign users IP addresses from specific address pools based on their identity or authentication credentials.|May 2023| |
69-
|Feature|Remote User connectivity/Point-to-site VPN|[Global profile include/exclude](global-hub-profile.md#include-or-exclude-a-hub-from-a-global-profile)|Ability to mark a point-to-site gateway as "excluded", meaning users who connect to global profile will not be load-balanced to that gateway.|February 2022| |
69+
|Feature|Remote User connectivity/Point-to-site VPN|[Global profile include/exclude](global-hub-profile.md#include-or-exclude-a-hub-from-a-global-profile)|Ability to mark a point-to-site gateway as "excluded", meaning users who connect to global profile won't be load-balanced to that gateway.|February 2022| |
7070
|Feature|Remote User connectivity/Point-to-site VPN|[Forced tunneling for P2S VPN](how-to-forced-tunnel.md)|Ability to force all traffic to Azure Virtual WAN for egress.|October 2021|Only available for Azure VPN Client version 2:1900:39.0 or newer.|
7171
|Feature|Remote User connectivity/Point-to-site VPN|[macOS Azure VPN client](openvpn-azure-ad-client-mac.md)|General Availability of Azure VPN Client for macOS.|August 2021| |
7272
|Feature|Branch connectivity/Site-to-site VPN<br><br>Remote User connectivity/Point-to-site VPN|[Hot-potato vs cold-potato routing for VPN traffic](virtual-wan-site-to-site-portal.md)|Ability to specify Microsoft or ISP POP preference for Azure VPN egress traffic. For more information, see [Routing preference in Azure](../virtual-network/ip-services/routing-preference-overview.md).|June 2021|This parameter can only be specified at gateway creation time and can't be modified after the fact.|
7373
|Feature|Remote User connectivity/Point-to-site VPN|[Remote RADIUS server](virtual-wan-point-to-site-portal.md)|Ability for a P2S VPN gateway to forward authentication traffic to a RADIUS server in a virtual network connected to a different hub, or a RADIUS server hosted on-premises.|April 2021| |
7474
|Feature|Remote User connectivity/Point-to-site VPN|[Dual-RADIUS server](virtual-wan-point-to-site-portal.md)|Ability to specify primary and backup RADIUS servers to service authentication traffic.|March 2021| |
7575
|Feature|Remote User connectivity/Point-to-site VPN|[Custom IPsec policies](point-to-site-ipsec.md)|Ability to specify connection/encryption parameters for IKEv2 point-to-site connections.|March 2021|Only supported for IKEv2- based connections.<br><br>View the [list of available parameters](point-to-site-ipsec.md). |
7676
|SKU|Remote User connectivity/Point-to-site VPN|[Support up to 100K users connected to a single hub](about-client-address-pools.md)|Increased maximum number of concurrent users connected to a single gateway to 100,000.|March 2021| |
77-
|Feature|Remote User connectivity/Point-to-site VPN|Multiple-authentication methods|Ability for a single gateway to use multiple authentication mechanisms.|June 2023|Supported for gateways running all protocol combinations. Note that Azure AD authentication still requires the use of OpenVPN|
77+
|Feature|Remote User connectivity/Point-to-site VPN|Multiple-authentication methods|Ability for a single gateway to use multiple authentication mechanisms.|June 2023|Supported for gateways running all protocol combinations. Azure AD authentication still requires the use of OpenVPN|
7878

7979
## Preview
8080

@@ -92,17 +92,16 @@ The following features are currently in gated public preview. After working with
9292
|1|ExpressRoute connectivity with Azure Storage and the 0.0.0.0/0 route|If you configured a 0.0.0.0/0 route statically in a virtual hub route table or dynamically via a network virtual appliance for traffic inspection, that traffic bypasses inspection when destined for Azure Storage and is in the same region as the ExpressRoute gateway in the virtual hub. | | As a workaround, you can either use [Private Link](../private-link/private-link-overview.md) to access Azure Storage or put the Azure Storage service in a different region than the virtual hub.|
9393
|2| Default routes (0/0) won't propagate inter-hub |0/0 routes won't propagate between two virtual WAN hubs. | June 2020 | None. Note: While the Virtual WAN team has fixed the issue, wherein static routes defined in the static route section of the VNet peering page propagate to route tables listed in "propagate to route tables" or the labels listed in "propagate to route tables" on the VNet connection page, default routes (0/0) won't propagate inter-hub. |
9494
|3| Two ExpressRoute circuits in the same peering location connected to multiple hubs |If you have two ExpressRoute circuits in the same peering location, and both of these circuits are connected to multiple virtual hubs in the same Virtual WAN, then connectivity to your Azure resources might be impacted. | July 2023 | Make sure each virtual hub has at least 1 virtual network connected to it. This ensures connectivity to your Azure resources. The Virtual WAN team is also working on a fix for this issue. |
95-
|4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP is not enabled by default for virtual hub deployments. When multiple ExpressRoute circuits are connected to a Virtual WAN hub, ECMP enables traffic from spoke virtual networks to on-premises over ExpressRoute to be distributed across all ExpressRoute circuits advertising the same on-premises routes. | | To enable ECMP for your Virtual WAN hub, please reach out to [email protected] after January 1, 2025. |
96-
| 5| Virtual WAN hub address prefixes are not advertised to other Virtual WAN hubs in the same Virtual WAN.| You can't leverage Virtual WAN hub-to-hub full mesh routing capabilities to provide connectivity between NVA orchestration software deployed in a VNET or on-premises connected to a Virtual WAN hub to an Integrated NVA or SaaS solution deployed in a different Virtual WAN hub. | | If your NVA or SaaS orchestrator is deployed on-premises, connect that on-premises site to all Virtual WAN hubs with NVAs or SaaS solutions deployed in them. If your orchestrator is in an Azure VNET, manage NVAs or SaaS solutions using public IP. Support for Azure VNET orchestrators is on the roadmap.|
97-
|6| Configuring routing intent to route between connectivity and firewall NVAs in the same Virtual WAN Hub| Virtual WAN routing intent private routing policy does not support routing between an SD-WAN NVA and a Firewall NVA (or SaaS solution) deployed in the same Virtual hub.| | Deploy the connectivity and firewall integrated NVAs in two different hubs in the same Azure region. Alternatively, deploy the connectivity NVA to a spoke Virtual Network connected to your Virtual WAN Hub and leverage the [BGP peering](scenario-bgp-peering-hub.md).|
98-
| 7| BGP between the Virtual WAN hub router and NVAs deployed in the Virtual WAN hub does not come up if the ASN used for BGP peering is updated post-deployment.|Virtual Hub router expects NVA in the hub to use the ASN that was configured on the router when the NVA was first deployed. Updating the ASN associated with the NVA on the NVA resource does not properly register the new ASN with the Virtual Hub router so the router rejects BGP sessions from the NVA if the NVA OS is configured to use the new ASN. | |Delete and recreate the NVA in the Virtual WAN hub with the correct ASN.|
99-
|8| Advertising default route (0.0.0.0/0) from on-premises (VPN, ExpressRoute, BGP endpoint) or statically configured on a Virtual Network connection is not supported for forced tunneling use cases.| The 0.0.0.0/0 route advertised from on-premises (or statically configured on a Virtual Network connection) is not applied to the Azure Firewall or other security solutions deployed in the Virtual WAN hub. Packets inspected by the security solution in the hub are routed directly to the internet, bypassing the route learnt from on-premises||Publish the default route from on-premises only in non-secure hub scenarios.|
95+
|4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP isn't enabled by default for virtual hub deployments. When multiple ExpressRoute circuits are connected to a Virtual WAN hub, ECMP enables traffic from spoke virtual networks to on-premises over ExpressRoute to be distributed across all ExpressRoute circuits advertising the same on-premises routes. | | To enable ECMP for your Virtual WAN hub, reach out to [email protected] after January 1, 2025. |
96+
| 5| Virtual WAN hub address prefixes aren't advertised to other Virtual WAN hubs in the same Virtual WAN.| You can't leverage Virtual WAN hub-to-hub full mesh routing capabilities to provide connectivity between NVA orchestration software deployed in a virtual network or on-premises connected to a Virtual WAN hub to an Integrated NVA or SaaS solution deployed in a different Virtual WAN hub. | | If your NVA or SaaS orchestrator is deployed on-premises, connect that on-premises site to all Virtual WAN hubs with NVAs or SaaS solutions deployed in them. If your orchestrator is in an Azure virtual network, manage NVAs or SaaS solutions using public IP. Support for Azure virtual network orchestrators is on the roadmap.|
97+
|6| Configuring routing intent to route between connectivity and firewall NVAs in the same Virtual WAN hub| Virtual WAN routing intent private routing policy doesn't support routing between an SD-WAN NVA and a Firewall NVA (or SaaS solution) deployed in the same Virtual hub.| | Deploy the connectivity and firewall integrated NVAs in two different hubs in the same Azure region. Alternatively, deploy the connectivity NVA to a spoke Virtual Network connected to your Virtual WAN hub and leverage the [BGP peering](scenario-bgp-peering-hub.md).|
98+
| 7| BGP between the Virtual WAN hub router and NVAs deployed in the Virtual WAN hub doesn't come up if the ASN used for BGP peering is updated post-deployment.|Virtual hub router expects NVA in the hub to use the ASN that was configured on the router when the NVA was first deployed. Updating the ASN associated with the NVA on the NVA resource doesn't properly register the new ASN with the Virtual hub router so the router rejects BGP sessions from the NVA if the NVA OS is configured to use the new ASN. | |Delete and recreate the NVA in the Virtual WAN hub with the correct ASN.|
99+
|8| Advertising default route (0.0.0.0/0) from on-premises (VPN, ExpressRoute, BGP endpoint) or statically configured on a Virtual Network connection isn't supported for forced tunneling use cases.| The 0.0.0.0/0 route advertised from on-premises (or statically configured on a Virtual Network connection) isn't applied to the Azure Firewall or other security solutions deployed in the Virtual WAN hub. Packets inspected by the security solution in the hub are routed directly to the internet, bypassing the route learnt from on-premises||Publish the default route from on-premises only in non-secure hub scenarios.|
100100
|9| Routing intent update operations fail in deployments where private routing policy next hop resource is an NVA or SaaS solution.| In deployments where private routing policy is configured with next hop NVA or SaaS solutions alongside additional private prefixes, modifying routing intent fails. Examples of operations that fail are adding or removing internet or private routing policies. This known issue doesn't impact deployments with no additional private prefixes configured. | |Remove any additional private prefixes, update routing intent and then reconfigure additional private prefixes.|
101-
|10| DNAT traffic is not forwarded to the NVA after associating an additional IP address.|After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic is not forwarded properly to the NVA due to a code defect. | November 2024 | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity.|
102-
|11| Spoke Virtual Network address space updates not picked up by Virtual WAN | Multiple concurrent updates on spoke Virtual Network address spaces are not properly synced with the Virtual Hub. | November 2024 | Ensure address space updates in a single Virtual Network are done serially. Wait until the first address update is properly reflected in the Virtual Hub's effective routes before updating the address space of the spoke Virtual Network again. If this issue has already occurred, make sure to update the address space of the affected Virtual Network with a nonimpacting address space (wait about 20 minutes before attempting again). Once this is reflected in the Virtual Network AND in the Virtual Hub, update the Virtual Network address space to the preferred Virtual Network address space.|
101+
|10| DNAT traffic isn't forwarded to the NVA after associating an additional IP address.|After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic isn't forwarded properly to the NVA due to a code defect. | November 2024 | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity.|
102+
|11| Spoke Virtual Network address space updates not picked up by Virtual WAN | Multiple concurrent updates on spoke Virtual Network address spaces aren't properly synced with the Virtual hub. | November 2024 | Ensure address space updates in a single Virtual Network are done serially. Wait until the first address update is properly reflected in the Virtual hub's effective routes before updating the address space of the spoke Virtual Network again. If this issue has already occurred, make sure to update the address space of the affected Virtual Network with a nonimpacting address space (wait about 20 minutes before attempting again). Once this is reflected in the Virtual Network AND in the Virtual hub, update the Virtual Network address space to the preferred Virtual Network address space.|
103103
|12 |Unable to update route tables and routing configuration (propagated route table and label) for on-premises (VPN, ExpressRoute, NVA) connections. | When a Virtual WAN hub and its gateway(s) are in different Azure resource groups, updating routing configuration results in a "resource not found" error. | March 2025| This issue is caused by a code defect in Azure portal. Use Terraform, PowerShell, CLI or REST API to manage your Virtual WAN deployment.|
104-
|13| Hub will not advertise routes to VPN sites | When a customer uses Route-Maps for the first time it triggers an upgrade. After the upgrade is complete, If VPN sites are not advertising routes to the hub, the hub will not advertise routes to the VPN sites. | December 2024 | If the VPN sites start adverting any routes to the hub, the hub will start adverting routes again.
105-
104+
|13| Hub won't advertise routes to VPN sites | When a customer uses Route-Maps for the first time it triggers an upgrade. After the upgrade is complete, If VPN sites aren't advertising routes to the hub, the hub won't advertise routes to the VPN sites. | December 2024 | If the VPN sites start adverting any routes to the hub, the hub will start adverting routes again.
106105

107106
## Next steps
108107

articles/virtual-wan/work-remotely-support.md

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,22 +1,21 @@
11
---
22
title: 'Azure Virtual WAN and working remotely'
3-
description: Learn how you can leverage Azure Virtual WAN to enable working remotely due to the COVID-19 pandemic.
3+
description: Learn how you can leverage Azure Virtual WAN to enable working remotely.
44
services: virtual-wan
55
author: cherylmc
66

77
ms.service: azure-virtual-wan
88
ms.topic: concept-article
9-
ms.date: 02/03/2023
9+
ms.date: 03/27/2025
1010
ms.author: cherylmc
1111

1212

1313
---
1414

1515
# Azure Virtual WAN and supporting remote work
1616

17-
>[!NOTE]
18-
>This article describes how you can leverage Azure Virtual WAN, Azure, Microsoft network, and the Azure partner ecosystem to work remotely and mitigate network issues that you are facing because of COVID-19 crisis.
19-
>
17+
> [!NOTE]
18+
> This article describes how you can leverage Azure Virtual WAN, Azure, Microsoft network, and the Azure partner ecosystem to work remotely and mitigate network issues.
2019
2120
Are you scrambling to provide connectivity for remote users?
2221
Do you suddenly see a need to support a surge of users beyond what you had planned for?
@@ -45,7 +44,7 @@ You have two options here:
4544

4645
## <a name="basic vWAN"></a>Existing basic Virtual WAN customer
4746

48-
Basic Virtual WAN provides Site-to-site VPN only. In order for remote users to connect, you will need to upgrade the virtual WAN to Standard Virtual WAN. For steps to upgrade a virtual WAN, see [Upgrade a virtual WAN from Basic to Standard](upgrade-virtual-wan.md)
47+
Basic Virtual WAN provides Site-to-site VPN only. In order for remote users to connect, you'll need to upgrade the virtual WAN to Standard Virtual WAN. For steps to upgrade a virtual WAN, see [Upgrade a virtual WAN from Basic to Standard](upgrade-virtual-wan.md)
4948

5049
## <a name="other considerations"></a>Additional information
5150

0 commit comments

Comments
 (0)