Azure Virtual WAN and supporting remote work


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.

Are you scrambling to provide connectivity for remote users? Do you suddenly see a need to support a surge of users beyond what you had planned for? Do you need the user to connect from home and not only access the cloud but also be able to reach on-premises? Do you need your remote users to be able to reach resources behind a private WAN? Do you have a need for users to access intra cloud resources without having the need to set up connectivity between regions? As this global pandemic creates unprecedented changes around us, the Azure Virtual WAN team is here for you to cater to your connectivity needs.

Azure Virtual WAN is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface. These functionalities include Branch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE), Site-to-site VPN connectivity, Remote User VPN (Point-to-site) connectivity, Private (ExpressRoute) connectivity, Intra cloud connectivity (Transitive connectivity for Virtual Networks), VPN ExpressRoute Interconnectivity, Routing, Azure firewall, Encryption for private connectivity etc. You don't have to have all of these use cases to start using Virtual WAN. You can get started with just one use case and adjust your network as it evolves.

Virtual WAN diagram

Now talking about remote users, lets look at what you need to get your network up and running:

Set up remote user connectivity

You can connect to your resources in Azure over an IPsec/IKE (IKEv2) or OpenVPN connection. This type of connection requires a VPN client to be configured for the remote user. This client can be the Azure VPN client or OpenVPN Client or any client that supports IKEv2. For more information, see Create a point-to-site connection.

Connectivity from the remote user to on-premises

You have two options here:

  • Set up Site-to-site connectivity with any existing VPN device. When you connect the IPsec VPN device to Azure Virtual WAN hub, interconnectivity between the Point-to-site User VPN (Remote user) and Site-to-site VPN is automatic. For more information on how to set up Site-to-site VPN from your on-premise VPN device to Azure Virtual WAN, see Create a site-to-site connection using Virtual WAN.

  • Connect your ExpressRoute circuit to the Virtual WAN hub. Connecting an ExpressRoute circuit requires deploying an ExpressRoute gateway in Virtual WAN. As soon as you have deployed one, interconnectivity between the Point-to-site User VPN and ExpressRoute user is automatic. To create the ExpressRoute connection, see Create an ExpressRoute connection using Virtual WAN. You can use an existing ExpressRoute circuit to connect to Azure Virtual WAN.

Existing basic Virtual WAN customer

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

Additional information

Virtual WAN supports one hub per region/location. For location information, see the Virtual WAN partners and locations article. Each hub supports up to 10,000 remote user connections, 1,000 branch connection, four ExpressRoute circuits and up to 500 Virtual Network connections. As you scale up the remote users, if you have any questions, don't hesitate to seek help by sending an email to If you require technical support, be sure to open a support ticket from the Azure portal and help will be on the way.


Does the user need to have hub and spoke with SD-WAN/VPN devices to use Azure Virtual WAN?

Virtual WAN provides many functionalities built into a single pane of glass such as Site/Site-to-site VPN connectivity, User/P2S connectivity, ExpressRoute connectivity, Virtual Network connectivity, VPN ExpressRoute Interconnectivity, VNET to VNET transitive connectivity, Centralized Routing, Azure firewall and firewall manager security, Monitoring, ExpressRoute Encryption and many other capabilities. You do not have to have all of these use cases to start using Virtual WAN. You can simply get started with just one use case. The Virtual WAN architecture is a hub and spoke architecture with scale and performance built-in where branches (VPN/SD-WAN devices), users (Azure VPN Clients, openVPN or IKEv2 Clients), ExpressRoute circuits, Virtual Networks serve as spokes to Virtual Hub(s). All hubs are connected in full mesh in a Standard Virtual WAN making it easy for the user to use the Microsoft backbone for any-to-any (any spoke) connectivity. For hub and spoke with SD-WAN/VPN devices, users can either manually set it up in the Azure Virtual WAN portal or use the Virtual WAN Partner CPE (SD-WAN/VPN) to set up connectivity to Azure. Virtual WAN partners provide automation for connectivity which is the ability to export the device info into Azure, download the Azure configuration and establish connectivity to the Azure Virtual WAN hub. For Point-to-site/User VPN connectivity, we support Azure VPN client, OpenVPN or IKEv2 client.

What client does the Azure Virtual WAN User VPN (Point-to-site) support?

Virtual WAN supports Azure VPN client, OpenVPN Client, or any IKEv2 client. Azure AD authentication is supported with Azure VPN Client.A minimum of Windows 10 client OS version 17763.0 or higher is required. OpenVPN client(s) can support certificate based authentication. Once cert-based auth is selected on the gateway, you will see the .ovpn file to download to your device. Both certificate and RADIUS auth is supported with IKEv2.

For User VPN (Point-to-site)- Why is the P2S client pool split into two routes?

Each gateway has two instances, the split happens so that each gateway instance can independently allocate client IPs for connected clients and traffic from the virtual network is routed back to the correct gateway instance to avoid inter-gateway instance hop.

How do I add DNS servers for P2S clients?

There are two options to add DNS servers for the P2S clients.

  1. Open a support ticket with Microsoft and have them add your DNS servers to the hub
  2. Or, if you are using the Azure VPN Client for Windows 10, you can modify the downloaded profile XML file and add the <dnsservers><dnsserver> </dnsserver></dnsservers> tags before importing it.


For User VPN (Point-to-site)- how many clients are supported?

Each User VPN P2S gateway has two instances and each instance supports upto certain users as the scale unit changes. Scale unit 1-3 supports 500 connections, Scale unit 4-6 supports 1000 connections, Scale unit 7-12 supports 5000 connections and Scale unit 13-20 supports upto 10,000 connections. As an example, lets say the user chooses 1 scale unit. Each scale unit would imply an active-active gateway deployed and each of the instances (in this case 2) would support upto 500 connections. Since you can get 500 connections * 2 per gateway, it does not mean you plan for 1000 instead of the 500 for this scale unit as instances may need to be serviced during which connectivity for the extra 500 may be interrupted if you surpass the recommended connection count. Also, be sure to plan for downtime in case you decide to scale up or down on the scale unit or change the point-to-site configuration on the VPN gateway.

What is the difference between an Azure virtual network gateway (VPN Gateway) and an Azure Virtual WAN VPN gateway?

Virtual WAN provides large-scale site-to-site connectivity and is built for throughput, scalability, and ease of use. When you connect a site to a Virtual WAN VPN gateway, it is different from a regular virtual network gateway that uses a gateway type 'VPN'. Similarly, when you connect an ExpressRoute circuit to a Virtual WAN hub, it uses a different resource for the ExpressRoute gateway than the regular virtual network gateway that uses gateway type 'ExpressRoute'. Virtual WAN supports up to 20 Gbps aggregate throughput both for VPN and ExpressRoute. Virtual WAN also has automation for connectivity with an ecosystem of CPE branch device partners. CPE branch devices have built-in automation that auto-provisions and connects into Azure Virtual WAN. These devices are available from a growing ecosystem of SD-WAN and VPN partners. See the Preferred Partner List.

How is Virtual WAN different from an Azure virtual network gateway?

A virtual network gateway VPN is limited to 30 tunnels. For connections, you should use Virtual WAN for large-scale VPN. You can connect up to 1,000 branch connections per region (virtual hub) with aggregate of 20 Gbps per hub. A connection is an active-active tunnel from the on-premises VPN device to the virtual hub. You can have one hub per region, which means you can connect more than 1,000 branches across hubs.

What is a Virtual WAN Gateway Scale Unit

A scale unit is an unit defined to pick an aggregate throughput of a gateway in Virtual hub. 1 scale unit of VPN = 500 Mbps . 1 scale unit of ExpressRoute = 2 Gbps. Example : 10 scale unit of VPN would imply 500 Mbps * 10 = 5 Gbps

Which device providers (Virtual WAN partners) are supported?

At this time, many partners support the fully automated Virtual WAN experience. For more information, see Virtual WAN partners.

What are the Virtual WAN partner automation steps?

For partner automation steps, see Virtual WAN partner automation.

Am I required to use a preferred partner device?

No. You can use any VPN-capable device that adheres to the Azure requirements for IKEv2/IKEv1 IPsec support.

How do Virtual WAN partners automate connectivity with Azure Virtual WAN?

Software-defined connectivity solutions typically manage their branch devices using a controller, or a device provisioning center. The controller can use Azure APIs to automate connectivity to the Azure Virtual WAN. The automation includes uploading branch information, downloading the Azure configuration, setting up IPSec tunnels into Azure Virtual hubs, and automatically setting up connectivity form the branch device to Azure Virtual WAN. When you have hundreds of branches, connecting using Virtual WAN CPE Partners is easy because the onboarding experience takes away the need to set up, configure, and manage large-scale IPsec connectivity. For more information, see Virtual WAN partner automation.

How is Virtual WAN supporting SD-WAN devices?

Virtual WAN partners automate IPsec connectivity to Azure VPN end points. If the Virtual WAN partner is an SD-WAN provider, then it is implied that the SD-WAN controller manages automation and IPsec connectivity to Azure VPN end points. If the SD-WAN device requires its own end point instead of Azure VPN for any proprietary SD-WAN functionality, you can deploy the SD-WAN end point in an Azure VNet and coexist with Azure Virtual WAN.

Does Virtual WAN change any existing connectivity features?

There are no changes to existing Azure connectivity features.

Are there new Resource Manager resources available for Virtual WAN?

Yes, Virtual WAN introduces new Resource Manager resources. For more information, please see the Overview.

How many VPN devices can connect to a single hub?

Up to 1,000 connections are supported per virtual hub. Each connection consists of four links and each link connection supports two tunnels that are in an active-active configuration. The tunnels terminate in an Azure virtual hub vpngateway.

Can the on-premises VPN device connect to multiple Hubs?

Yes. Traffic flow, when commencing, is from the on-premises device to the closest Microsoft network edge, and then to the virtual hub.

Can I deploy and use my favorite network virtual appliance (in an NVA VNet) with Azure Virtual WAN?

Yes, you can connect your favorite network virtual appliance (NVA) VNet to the Azure Virtual WAN. First, connect the network virtual appliance VNet to the hub with a Hub Virtual Network connection. Then, create a virtual hub route with a next hop pointing to the Virtual Appliance. You can apply multiple routes to the virtual hub Route Table. Any spokes connected to the NVA VNet must additionally be connected to the virtual hub to ensure that the spoke VNet routes are propagated to on-premises systems.

Can I create a Network Virtual Appliance inside the virtual hub?

A Network Virtual Appliance (NVA) cannot be deployed inside a virtual hub. However, you can create it in a spoke VNet that is connected to the virtual hub and enable a route in the hub to direct traffic for destination VNet via the NVA IP address (of the NIC).

Can a spoke VNet have a virtual network gateway?

No. The spoke VNet cannot have a virtual network gateway if it is connected to the virtual hub.

Is there support for BGP?

Yes, BGP is supported. When you create a VPN site, you can provide the BGP parameters in it. This will imply that any connections created in Azure for that site will be enabled for BGP. Additionally, if you had a VNet with an NVA, and if this NVA VNet was attached to a Virtual WAN hub, in order to ensure that routes from an NVA VNet are advertised appropriately, spokes that are attached to NVA VNet must disable BGP. Additionally, connect these spoke VNets to the virtual hub VNet to ensure spoke VNet routes are propagated to on-premises systems.

Can I direct traffic using UDR in the virtual hub?

Yes, you can direct traffic to a VNet using a virtual hub route table. This allows you to set routes for destination VNets in Azure via a specific IP address (typically of the NVA NIC).

Is there any licensing or pricing information for Virtual WAN?

Yes. See the Pricing page.

How do I calculate price of a hub?

  • You would pay for the services in the hub. For example, lets say you have 10 branches or on-premises devices requiring to connect to Azure Virtual WAN would imply connecting to VPN end points in the hub. Lets say this is VPN of 1 scale unit = 500 Mbps, this is charged at $0.361/hr. Each connection is charged at $0.05/hr. For 10 connections, the total charge of service/hr would be $0.361 + $.5/hr. Data charges for traffic leaving Azure apply.

  • There is additional hub charge. See the Pricing page.

  • If you had ExpressRoute gateway due to ExpressRoute circuits connecting to a virtual hub, then you would pay for the scale unit price. Each scale unit in ER is 2 Gbps and each connection unit is charged at the same rate as the VPN Connection unit.

  • If you had Spoke VNETs connected to the hub, peering charges at the Spoke VNETs still apply.

How do new partners that are not listed in your launch partner list get onboarded?

All virtual WAN APIs are open API. You can go over the documentation to assess technical feasibility. If you have any question, send an email to An ideal partner is one that has a device that can be provisioned for IKEv1 or IKEv2 IPsec connectivity.

What if a device I am using is not in the Virtual WAN partner list? Can I still use it to connect to Azure Virtual WAN VPN?

Yes as long as the device supports IPsec IKEv1 or IKEv2. Virtual WAN partners automate connectivity from the device to Azure VPN end points. This implies automating steps such as 'branch information upload', 'IPsec and configuration' and 'connectivity'.Since your device is not from a Virtual WAN partner ecosystem, you will need to do the heavy lifting of manually taking the Azure configuration and updating your device to set up IPsec connectivity.

Is it possible to construct Azure Virtual WAN with a Resource Manager template?

A simple configuration of one Virtual WAN with one hub and one vpnsite can be created using an quickstart template. Virtual WAN is primarily a REST or portal driven service.

Is Global VNet peering supported with Azure Virtual WAN?

You can connect a VNet in a different region than your virtual WAN.

Can spoke VNets connected to a virtual hub communicate with each other (V2V Transit)?

Yes. Standard Virtual WAN supports Vnet to Vnet transitive connectivity via the Virtual WAN hub that the Vnets are connected to. In Virtual WAN terminology, we refer to these paths as “local Virtual WAN VNet transit” for VNets connected to a Virtual Wan Hub within a single region, and “global Virtual WAN VNet transit” for VNets connected through multiple Virtual WAN Hubs across two or more regions. VNet transit supports up to 3 Gbps of throughput during public preview. Throughput will expanded when global transit goes GA.

NOTE: Currently V2V transit preview requires a VPN GW to be deployed in a Virtual Hub to trigger the routing elements to be launched. This VPN GW is not used for the V2V transit path. This is a known limitation and will be removed at the time of V2V GA. You can delete the VPN Gateway in the hub(s) after it is fully launched as it is not needed for V2V transit functionality.

For some scenarios, spoke Vnets can also be directly peered with each other using Virtual Network Peering in addition to local or global Virtual WAN VNet transit. In this case, Vnet Peering takes precedence over the transitive connection via the Virtual WAN hub.

What is a branch connection to Azure Virtual WAN?

A connection from a branch device into Azure Virtual WAN supports up to four links. A link is the physical connectivity link at the branch location (for example: ATT, Verizon etc.). Each link connection is composed of two active/active IPsec tunnels.

Is branch-to-branch connectivity allowed in Virtual WAN?

Yes, branch-to-branch connectivity is available in Virtual WAN for VPN and VPN to ExpressRoute.

Does branch-to-branch traffic traverse through the Azure Virtual WAN?


Does Virtual WAN require ExpressRoute from each site?

No, the Virtual WAN does not require ExpressRoute from each site. It uses standard IPsec site-to-site connectivity via internet links from the device to an Azure Virtual WAN hub. Your sites may be connected to a provider network using an ExpressRoute circuit. For Sites that are connected using ExpressRoute in a virtual hub, sites can have branch to branch traffic flow between VPN and ExpressRoute.

Is there a network throughput limit when using Azure Virtual WAN?

Number of branches is limited to 1000 connections per hub/region and a total of 20 Gbps in the hub. You can have 1 hub per region.

How many VPN connections does a Virtual WAN hub support?

An Azure Virtual WAN hub can support up to 1,000 S2S connections, 10,000 P2S connections, and 4 ExpressRoute connections simultaneously.

What is the total VPN throughput of a VPN tunnel and a connection?

The total VPN throughput of a hub is up to 20 Gbps based on the chosen scale unit. Throughput is shared by all existing connections. Each tunnel in a connection can support up to 1 Gbps.

I don't see the 20 Gbps setting for the virtual hub in the portal. How do I configure that?

Navigate to the VPN gateway inside a hub on the portal and click on the scale unit to change it to the appropriate setting.

Does Virtual WAN allow the on-premises device to utilize multiple ISPs in parallel, or is it always a single VPN tunnel?

On-premises device solutions can apply traffic policies to steer traffic across multiple tunnels into Azure.

What is global transit architecture?

For information about global transit architecture, see Global transit network architecture and Virtual WAN.

How is traffic routed on the Azure backbone?

The traffic follows the pattern: branch device ->ISP->Microsoft network edge->Microsoft DC (hub VNet)->Microsoft network edge->ISP->branch device

In this model, what do you need at each site? Just an internet connection?

Yes. An internet connection and physical device that supports IPsec, preferably from our integrated Virtual WAN partners. Optionally, you can manually manage the configuration and connectivity to Azure from your preferred device.

How do I enable default route ( in a connection (VPN, ExpressRoute, or Virtual Network):

A virtual hub can propagate a learned default route to a virtual network/site-to-site VPN/ExpressRoute connection if the flag is 'Enabled' on the connection. This flag is visible when the user edits a virtual network connection, a VPN connection, or an ExpressRoute connection. By default, this flag is disabled when a site or an ExpressRoute circuit is connected to a hub. It is enabled by default when a virtual network connection is added to connect a VNet to a virtual hub. The default route does not originate in the Virtual WAN hub; the default route is propagated if it is already learned by the Virtual WAN hub as a result of deploying a firewall in the hub, or if another connected site has forced-tunneling enabled.

How does the virtual hub in a Virtual WAN select the best path for a route from multiple hubs

If a Virtual Hub learns the same route from multiple remote hubs, the order in which it decides is as follows

  1. Route Origin a) Network routes – VNET prefixes directly learnt by the Virtual Hub gateways b) Hub RouteTable (statically configured routes) c) BGP d) InterHub routes
  2. Route metric : Virtual WAN prefers ExpressRoute over VPN. ExpressRoute peer have a higher weightage compared to the VPN peer
  3. AS path length

Is there support for IPv6 in Virtual WAN?

IPv6 is not supported in Virtual WAN hub and its gateways.If you have a VNET that has IPv6 support and you would like to connect the VNET to Virtual WAN, this scenario is also not supported.

What are the differences between the Virtual WAN types (Basic and Standard)?

The 'Basic' WAN type lets you create a basic hub (SKU = Basic). A 'Standard' WAN type lets you create standard hub (SKU = Standard). Basic hubs are limited to site-to-site VPN functionality. Standard hubs let you have ExpressRoute, User VPN (P2S), full mesh hub, and VNet-to-VNet transit through the hubs. You pay a base charge of $0.25/hr for standard hubs and a data processing fee for transiting through the hubs during VNet-to-VNet connectivity, as well as data processing for hub to hub traffic. For more information, see Basic and Standard virtual WANs. For pricing, see the Pricing page.

Next Steps

For more information about Virtual WAN, see Virtual WAN overview