Virtual WAN Documentation

Contents
Virtual WAN documentation

Overview
What is Virtual WAN?
Quickstarts
ARM templates
Any-to-any routing
Route to shared services VNets
Tutorials
Create a site-to-site connection
Create User VPN (point-to-site) connections
Create an ExpressRoute connection
Concepts
Work remotely
Support for working remotely
Leverage Virtual WAN
Virtual WAN FAQ
NVA in the Virtual WAN Hub
Locations and Partners
Hub locations and partners
Automation guidelines for partners
Architecture
Migrate to Virtual WAN
Global transit network architecture
SD-WAN connectivity architecture
Interconnect with China
Routing
About virtual hub routing
Routing scenarios
Any-to-any
Isolating VNets
Isolating VNets - custom
Isolating virtual networks and branches
Shared services VNets
Route through an NVA
Route through an NVA - custom
BGP peering with virtual hub
Azure Firewall - custom
Application Gateway and backend pools
Site-to-site
About S2S IPsec policies
Multiple ISP links - Azure path selection
Point-to-site
About P2S IPsec policies
About P2S client address pools
About P2S global and hub-based profiles
Security
Security baseline
Pricing explained
About secured virtual hubs
How-to guides
Upgrade a virtual WAN SKU
Create an NVA in a virtual hub
Connect a VNet to a virtual hub
Create a cross-tenant VNet connection
ExpressRoute
Create an ExpressRoute connection
Configure ExpressRoute encryption
Site-to-site
Create a site-to-site connection
Azure portal
Azure PowerShell
Connect virtual network gateway to Virtual WAN
Configure custom IPsec policy
Configure NAT rules
Azure portal
Azure PowerShell
User VPN (point-to-site)
Create User VPN
Azure portal
Azure PowerShell
Create User VPN - Azure AD authentication
Generate certificates
Configure Azure AD tenant
Client profiles
Download global and hub-based profiles
Extract and view profile information
Deploy profiles using Intune
VPN clients
OpenVPN
Azure AD authentication
Windows 10
macOS
Configure Always-On tunnels
User tunnel
Device tunnel
Authentication
Multi-Factor Authentication(MFA)
Azure AD authentication
Multi-application Azure AD authentication
Routing
Configure virtual hub routing
View virtual hub effective routes
How to configure routing intent and policies
Route traffic from a virtual hub to an NVA (legacy)
Azure portal
Azure PowerShell
Configure BGP peering with virtual hub
Security
Install Azure Firewall in a hub
Inter-hub and branch-to-branch via Azure Firewall
Configure Private Link connectivity
Manage access to resources - Spoke VNet P2S
Monitoring
Monitoring Virtual WAN
Azure Monitor Insights
Configure S2S VPN packet captures
Azure portal
PowerShell
Advanced Monitoring for P2S VPN
Reference
Azure PowerShell
REST
Azure CLI
Python SDK
Resources
Pricing
Subscription and service limits
Networking Roadmap
Networking blog
Networking update announcements
Pricing calculator
SLA
What is Azure Virtual WAN?
3/15/2022 • 9 minutes to read • Edit Online
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 inter-connectivity, routing, Azure
Firewall, and encryption for private connectivity. 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, and then adjust your network as it evolves.
The Virtual WAN architecture is a hub and spoke architecture with scale and performance built in for branches
(VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2 clients), ExpressRoute circuits, and virtual networks.
It enables a global transit network architecture, where the cloud hosted network 'hub' enables transitive
connectivity between endpoints that may be distributed across different types of 'spokes'.
Azure regions serve as hubs that you can choose to connect to. 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 spoke connectivity with SD-WAN/VPN devices, users can either manually set it up in Azure Virtual WAN, or
use the Virtual WAN CPE (SD-WAN/VPN) partner solution to set up connectivity to Azure. We have a list of
partners that support connectivity automation (ability to export the device info into Azure, download the Azure
configuration and establish connectivity) with Azure Virtual WAN. For more information, see the Virtual WAN
partners and locations article.
This article provides a quick view into the network connectivity in Azure Virtual WAN. Virtual WAN offers the
following advantages:
Integrated connectivity solutions in hub and spoke: Automate site-to-site configuration and
connectivity between on-premises sites and an Azure hub.
Automated spoke setup and configuration: Connect your virtual networks and workloads to the Azure
hub seamlessly.
Intuitive troubleshooting: You can see the end-to-end flow within Azure, and then use this information to
take required actions.
Basic and Standard virtual WANs

There are two types of virtual WANs: Basic and Standard. The following table shows the available configurations
for each type.
VIRT UA L WA N T Y P E H UB T Y P E AVA IL A B L E C O N F IGURAT IO N S
Basic Basic Site-to-site VPN only
Standard Standard ExpressRoute

User VPN (P2S)
VPN (site-to-site)
Inter-hub and VNet-to-VNet transiting
through the virtual hub
Azure Firewall
NVA in a virtual WAN
NOTE
You can upgrade from Basic to Standard, but cannot revert from Standard back to Basic.
For steps to upgrade a virtual WAN, see Upgrade a virtual WAN from Basic to Standard.
Architecture
For information about Virtual WAN architecture and how to migrate to Virtual WAN, see the following articles:
Virtual WAN architecture
Global transit network architecture
Virtual WAN resources

To configure an end-to-end virtual WAN, you create the following resources:
vir tualWAN: The virtualWAN resource represents a virtual overlay of your Azure network and is a
collection of multiple resources. It contains links to all your virtual hubs that you would like to have
within the virtual WAN. Virtual WAN resources are isolated from each other and cannot contain a
common hub. Virtual hubs across Virtual WAN do not communicate with each other.
Hub: A virtual hub is a Microsoft-managed virtual network. The hub contains various service endpoints
to enable connectivity. From your on-premises network (vpnsite), you can connect to a VPN Gateway
inside the virtual hub, connect ExpressRoute circuits to a virtual hub, or even connect mobile users to a
Point-to-site gateway in the virtual hub. The hub is the core of your network in a region. Multiple virtual
hubs can be created in the same region.
A hub gateway is not the same as a virtual network gateway that you use for ExpressRoute and VPN
Gateway. For example, when using Virtual WAN, you don't create a site-to-site connection from your on-
premises site directly to your VNet. Instead, you create a site-to-site connection to the hub. The traffic
always goes through the hub gateway. This means that your VNets do not need their own virtual network
gateway. Virtual WAN lets your VNets take advantage of scaling easily through the virtual hub and the
virtual hub gateway.
Hub vir tual network connection: The Hub virtual network connection resource is used to connect the
hub seamlessly to your virtual network. One virtual network can be connected to only one virtual hub.
Hub-to-Hub connection: Hubs are all connected to each other in a virtual WAN. This implies that a
branch, user, or VNet connected to a local hub can communicate with another branch or VNet using the
full mesh architecture of the connected hubs. You can also connect VNets within a hub transiting through
the virtual hub, as well as VNets across hub, using the hub-to-hub connected framework.
Hub route table: You can create a virtual hub route and apply the route to the virtual hub route table.
You can apply multiple routes to the virtual hub route table.
Additional Vir tual WAN resources
Site: This resource is used for site-to-site connections only. The site resource is vpnsite . It represents your
on-premises VPN device and its settings. By working with a Virtual WAN partner, you have a built-in solution
to automatically export this information to Azure.
Connectivity
Site -to -site VPN connections
You can connect to your resources in Azure over a Site-to-site IPsec/IKE (IKEv2) connection. For more
information, see Create a site-to-site connection using Virtual WAN.
This type of connection requires a VPN device or a Virtual WAN Partner device. 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 a list of the available partners and
locations, see the Virtual WAN partners and locations article. If your VPN/SD-WAN device provider is not listed
in the mentioned link, then you can simply use the step-by-step instruction Create a site-to-site connection
using Virtual WAN to set up the connection.
User VPN (point-to -site ) connections
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 on the client computer. For more information, see Create a
point-to-site connection.
ExpressRoute connections
ExpressRoute lets you connect on-premises network to Azure over a private connection. To create the
connection, see Create an ExpressRoute connection using Virtual WAN.
Hub-to -VNet connections
You can connect an Azure virtual network to a virtual hub. For more information, see Connect your VNet to a
hub.
Transit connectivity
Transit connectivity between VNets
Virtual WAN allows transit connectivity between VNets. VNets connect to a virtual hub via a virtual network
connection. Transit connectivity between the VNets in Standard Vir tual WAN is enabled due to the presence
of a router in every virtual hub. This router is instantiated when the virtual hub is first created.
The router can have four routing statuses: Provisioned, Provisioning, Failed, or None. The Routing status is
located in the Azure portal by navigating to the Virtual Hub page.
A None status indicates that the Virtual hub did not provision the router. This can happen if the Virtual WAN
is of type Basic, or if the virtual hub was deployed prior to the service being made available.
A Failed status indicates failure during instantiation. In order to instantiate or reset the router, you can locate
the Reset Router option by navigating to the virtual hub Overview page in the Azure portal.
Every virtual hub router supports an aggregate throughput up to 50 Gbps.
Connectivity between the virtual network connections assumes, by default, a maximum total of 2000 VM
workload across all VNets connected to a single virtual Hub. This limit can be increased opening an online
customer support request. For cost implication, see Routing Infrastructure Unit cost in the Azure Virtual WAN
Pricing page.
Transit connectivity between VPN and ExpressRoute
Virtual WAN allows transit connectivity between VPN and ExpressRoute. This implies that VPN-connected sites
or remote users can communicate with ExpressRoute-connected sites. There is also an implicit assumption that
the Branch-to-branch flag is enabled and BGP is supported in VPN and ExpressRoute connections. This flag
can be located in the Azure Virtual WAN settings in Azure portal. All route management is provided by the
virtual hub router, which also enables transit connectivity between virtual networks.
Custom Routing
Virtual WAN provides advanced routing enhancements. Ability to set up custom route tables, optimize virtual
network routing with route association and propagation, logically group route tables with labels and simplify
numerous network virtual appliance (NVA) or shared services routing scenarios.
Global VNet peering
Global VNet Peering provides a mechanism to connect two VNets in different regions. In Virtual WAN, virtual
network connections connect VNets to virtual hubs. The user does not need to set up global VNet peering
explicitly. VNets connected to virtual hub in same region incur VNet peering charges. VNets connected to virtual
hub in a different region incur Global VNet peering charges.
ExpressRoute traffic encryption
Azure Virtual WAN provides ability to encrypt your ExpressRoute traffic. The technique provides an encrypted
transit between the on-premises networks and Azure virtual networks over ExpressRoute, without going over
the public internet or using public IP addresses. For more information, see IPsec over ExpressRoute for Virtual
WAN.
Locations
For location information, see the Virtual WAN partners and locations article.
Route tables for Basic and Standard virtual WANs

Route tables now have features for association and propagation. A pre-existing route table is a route table that
does not have these features. If you have pre-existing routes in hub routing and would like to use the new
capabilities, consider the following:
Standard Vir tual WAN Customers with pre-existing routes in vir tual hub : If you have pre-
existing routes in the Routing section for the hub in the Azure portal, you will need to first delete them
and then attempt creating new route tables (available in the Route Tables section for the hub in Azure
portal). It is highly encouraged to do the delete step for all hubs in a Virtual WAN.
Basic Vir tual WAN Customers with pre-existing routes in vir tual hub : If you have pre-existing
routes in Routing section for the hub in the Azure portal, you will need to first delete them, then upgrade
your Basic Virtual WAN to Standard Virtual WAN. See Upgrade a virtual WAN from Basic to Standard. It is
highly encouraged to do the delete step for all hubs in a Virtual WAN.
Gated public preview

The below features are currently in gated public preview.
F EAT URE DESC RIP T IO N
Routing Intent and Policies Enabling Inter-hub security This feature allows customers to configure internet-bound,
private or inter-hub traffic flow through the Azure Firewall.
Please review Routing Intent and Policies to learn more.
Hub to Hub over ER preview link This feature allows traffic between 2 hubs traverse through
the Azure Virtual WAN router in each hub and uses a hub-
to-hub path instead of the ExpressRoute path (which
traverses through the Microsoft edge routers/MSEE). Please
review Hub to Hub over ER preview link
BGP peering with a virtual hub This feature provides the ability for the virtual hub to pair
with and directly exchange routing information through
Border Gateway Protocol (BGP) routing protocol. Please
review the concept BGP peering with a virtual hub and the
guide How to peer BGP with a virtual hub
FAQ
For frequently asked questions, see the Virtual WAN FAQ.
What's new?
Subscribe to the RSS feed and view the latest Virtual WAN feature updates on the Azure Updates page.
Next steps
Tutorial: Create a site-to-site connection using Virtual WAN
Learn module: Introduction to Azure Virtual WAN
Quickstart: Create an any-to-any configuration
using an ARM template
This quickstart describes how to use an Azure Resource Manager template (ARM template) to create an any-to-
any scenario where any spoke can reach another spoke.
An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for
your project. The template uses declarative syntax. In declarative syntax, you describe your intended deployment
without writing the sequence of programming commands to create the deployment.
If your environment meets the prerequisites and you're familiar with using ARM templates, select the Deploy to
Azure button. The template will open in the Azure portal.
Prerequisites
If you don't have an Azure subscription, create a free account before you begin.
Public key certificate data is required for this configuration. See Generate and export certificates for steps to
generate and export the required certificates. Sample certificate data is provided in the article only to satisfy
the template requirements in order to create a P2S gateway.
Review the template

The template used in this quickstart is from Azure Quickstart Templates. The template for this article is too long
to show here. To view the template, see azuredeploy.json.
In this quickstart, you'll create an Azure Virtual WAN multi-hub deployment, including all gateways and VNet
connections. The list of input parameters has been purposely kept at a minimum. The IP addressing scheme can
be changed by modifying the variables inside of the template. The scenario is explained further in the Any-to-
any scenario article.
This template creates a fully functional Azure Virtual WAN environment with the following resources:
Two distinct hubs in different regions
Four Azure virtual networks (VNet)
Two VNet connections for each VWAN hub
One Point-to-Site (P2S) VPN gateway in each hub
One Site-to-Site (S2S) VPN gateway in each hub
One ExpressRoute gateway in each hub
Multiple Azure resources are defined in the template:
Microsoft.Network/vir tualwans
Microsoft.Network/vir tualhubs
Microsoft.Network/vir tualnetworks
Microsoft.Network/hubvir tualnetworkconnections
Microsoft.Network/p2svpngateways
Microsoft.Network/vpngateways
Microsoft.Network/expressroutegateways
Microsoft.Network/vpnser verconfigurations
NOTE
This ARM template doesn't create the customer-side resources required for hybrid connectivity. After you deploy the
template, you still need to create and configure the P2S VPN clients, the VPN branches (Local Sites), and connect the
ExpressRoute circuits.
To find more templates, see Azure Quickstart Templates.
Deploy the template

To deploy this template properly, you must use Deploy to Azure button in the Azure portal, rather than other
methods, for the following reasons:
In order to create the P2S configuration, you need to upload the root certificate data. The data field does not
accept the certificate data when using PowerShell or CLI.
This template does not work properly using Cloud Shell due to the certificate data upload.
Additionally, you can easily modify the template and parameters in the portal to accommodate IP address
ranges and other values.
1. Click Deploy to Azure .
2. To view the template, click Edit template . On this page, you can adjust some of the values such as
address space or the name of certain resources. Save to save your changes, or Discard .
3. On the template page, enter the values. For the Hub_Public Cer tificate Data for P2S fields, you need
to input the public key certificate data from the root certificate that you want to use (as mentioned in the
prerequisites). If you haven't generated a root certificate and you are using these steps as only an exercise
to run the template and observe the results, you can use the following example certificate data for both
hubs. If you choose to use this example data and later want P2S clients to connect, you must replace this
information with the certificate data from your own environment.
NOTE
This certificate data is supplied for example purposes only. Replace this example data with the public key certificate
data from your own certificate if you want P2S clients to connect.
MIIC9zCCAd+gAwIBAgIQOn0lVXm3E5hH/A7CdSuPyDANBgkqhkiG9w0BAQsFADAe
MRwwGgYDVQQDDBNEZW1vUm9vdENlcnRpZmljYXRlMB4XDTIyMDExMTE5NDgwOFoX
DTMyMDExMTE5NTgwOVowHjEcMBoGA1UEAwwTRGVtb1Jvb3RDZXJ0aWZpY2F0ZTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM3m0yqbpV46r6D8pOjODw1E
O5QBf9kynypwRy0yrgj+6j1YzVogYQgBFHGgg1OszoAWorvN1KmuqOvdqR5Jtiuv
A3p8dfsWVZlkthTX9MaWQfskCThE+NucphalFgEOcpdJpN9kt+n1IMgbqI0metcW
lCyOkUke13jcNkYEd5oRi053yEWUOSfNoDvxmbwrGdtpPo8VH+7bZaNB8mUfxUjO
Hg6cv+BV910q0c+O6QWj5B5W+tJGDTxwuokyI94Fsb9FG6wxyZGSGX0uTBiuUC7V
Uf9FZur9HTfofkiy6QX2+6j0iQfqv7jM9NOnAzhUT+l+2l+6glEbkA2R3vH5wZ0C
AwEAAaMxMC8wDgYDVR0PAQH/BAQDAgIEMB0GA1UdDgQWBBQhyYPrM242o1FzArus
77YlfhwkUzANBgkqhkiG9w0BAQsFAAOCAQEAL0wMThonNJ6dPRlbopqbuGLttDnX
OnpKLrv6d8kl6y8z4orYUi1T7Q3wjlMwVoHgqc8r7DMWroWG8mFlCyVdUYH9oYQS
m60v1fltvRxtFZiB3jzAMOcQsqr+v6QlAkr4RF7f7JtuLxwUCvVlF+rrQOAu9pu7
Kh180o9a79CgrA67DTSYP4wI1YRKglWK8eAxEkAfHTXwC/MJmf3XMMyb3cBWiirl
FLlDgEi4Jb14vd3diBg51df8WbW/+jmoNIbrWkpLhL27sSx6rgN/2NUYzdA4MWqp
Odrcs3wQsYovibqHiQUFHc24bvlcKiEpL535nHrSJR6PITm3Wh83yQ02mQ==
4. When you have finished entering values, select Review + create .

5. On the Review + create page, after validation passes, select Create .
6. It takes about 75 minutes for the deployment to complete. You can view the progress on the template
Over view page. If you close the portal, deployment will continue.
Validate the deployment

1. Sign in to the Azure portal.
2. Select Resource groups from the left pane.
3. Select the resource group that you created in the previous section. On the Over view page, you will see
something similar to this example:
4. Click the virtual WAN to view the hubs. On the virtual WAN page, click each hub to view connections and
other hub information.
Complete the hybrid configuration

The template does not configure all of the settings necessary for a hybrid network. Complete the following
configurations and settings, depending on your requirements:
Configure the VPN branches - local sites
Complete the P2S VPN configuration
Connect the ExpressRoute circuits
Clean up resources
When you no longer need the resources that you created, delete them. Some of the Virtual WAN resources must
be deleted in a certain order due to dependencies. Deleting can take about 30 minutes to complete.
1. Open the virtual WAN that you created.
2. Select a virtual hub associated to the virtual WAN to open the hub page.
3. Delete all gateway entities following the below order for the gateway type. This can take 30 minutes to
complete.
VPN:
a. Disconnect VPN Sites
b. Delete VPN connections
c. Delete VPN Gateways
ExpressRoute:
a. Delete ExpressRoute Connections
b. Delete ExpressRoute Gateways
4. You can either delete the hub at this point, or delete it later when you delete the resource group.
5. Repeat for all hubs associated to the virtual WAN.
6. Navigate to the resource group in the Azure portal.
7. Select Delete resource group . This deletes everything in the resource group, including the hubs and
the virtual WAN.
Next steps
Quickstart: Route to shared services VNets using an
ARM template
This quickstart describes how to use an Azure Resource Manager template (ARM template) to set up routes to
access a shared service VNet with workloads that you want every VNet and Branch (VPN/ER/P2S) to access.
Examples of these shared workloads might include virtual machines with services like domain controllers or file
shares, or Azure services exposed internally through Azure Private Endpoint.
An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for
your project. The template uses declarative syntax. In declarative syntax, you describe your intended deployment
without writing the sequence of programming commands to create the deployment.
If your environment meets the prerequisites and you're familiar with using ARM templates, select the Deploy to
Azure button. The template will open in the Azure portal.
Prerequisites
Public key certificate data is required for this configuration. Sample data is provided in the article. However,
the sample data is provided only to satisfy the template requirements in order to create a P2S gateway. After
the template completes and the resources are deployed, you must update this field with your own certificate
data in order for the configuration to work. See User VPN certificates.
Review the template

The template used in this quickstart is from Azure Quickstart Templates. The template for this article is too long
to show here. To view the template, see azuredeploy.json.
In this quickstart, you'll create an Azure Virtual WAN multi-hub deployment, including all gateways and VNet
connections. The list of input parameters has been purposely kept at a minimum. The IP addressing scheme can
be changed by modifying the variables inside of the template. The scenario is explained further in the Scenario:
Shared services VNet article.
This template creates a fully functional Azure Virtual WAN environment with the following resources:
2 distinct hubs in different regions.
4 Azure Virtual Networks (VNet).
2 VNet connections for each VWan hub.
1 Point-to-Site (P2S) VPN gateway in each hub.
1 Site-to-Site (S2S) VPN gateway in each hub.
1 ExpressRoute gateway in each hub.
Custom Route Tables RT_SHARED in each hub.
A label LBL_RT_SHARED to group RT_SHARED route tables.
Multiple Azure resources are defined in the template:
Microsoft.Network/vir tualwans
Microsoft.Network/vir tualhubs
Microsoft.Network/vir tualnetworks
Microsoft.Network/hubvir tualnetworkconnections
Microsoft.Network/hubroutetables
Microsoft.Network/p2svpngateways
Microsoft.Network/vpngateways
Microsoft.Network/expressroutegateways
Microsoft.Network/vpnser verconfigurations
NOTE
This ARM template doesn't create the customer-side resources required for hybrid connectivity. After you deploy the
template, you still need to create and configure the P2S VPN clients, VPN branches (Local Sites), and connect
ExpressRoute circuits.
To find more templates, see Azure Quickstart Templates.
Deploy the template

To deploy this template properly, you must use the button to Deploy to Azure button and the Azure portal,
rather than other methods, for the following reasons:
In order to create the P2S configuration, you need to upload the root certificate data. The data field does not
accept the certificate data when using PowerShell or CLI.
This template does not work properly using Cloud Shell due to the certificate data upload.
Additionally, you can easily modify the template and parameters in the portal to accommodate IP address
ranges and other values.
1. Click Deploy to Azure .
2. To view the template, click Edit template . On this page, you can adjust some of the values such as
address space or the name of certain resources. Save to save your changes, or Discard .
3. On the template page, enter the values. For this template, the P2S public certificate data is required. If you
are using this article as an exercise, you can use the following data from this .cer file as sample data for
both hubs. Once the template runs and deployment is complete, in order to use the P2S configuration,
you must replace this information with the public key certificate data for your own deployment.
MIIC5zCCAc+gAwIBAgIQGxd3Av1q6LJDZ71e3TzqcTANBgkqhkiG9w0BAQsFADAW
MRQwEgYDVQQDDAtQMlNSb290Q2VydDAeFw0yMDExMDkyMjMxNTVaFw0yMTExMDky
MjUxNTVaMBYxFDASBgNVBAMMC1AyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA33fFra/E0YmGuXLKmYcdvjsYpKwQmw8DjjDkbwhE9jcc
Dp50e7F1P6Rxo1T6Hm3dIhEji+0QkP4Ie0XPpw0eW77+RWUiG9XJxGqtJ3Q4tyRy
vBfsHORcqMlpV3VZOXIxrk+L/1sSm2xAc2QGuOqKaDNNoKmjrSGNVAeQHigxbTQg
zCcyeuhFxHxAaxpW0bslK2hEZ9PhuAe22c2SHht6fOIDeXkadzqTFeV8wEZdltLr
6Per0krxf7N2hFo5Cfz0KgWlvgdKLL7dUc9cjHo6b6BL2pNbLh8YofwHQOQbwt6H
miAkEnx1EJ5N8AWuruUTByR2jcWyCnEAUSH41+nk4QIDAQABozEwLzAOBgNVHQ8B
Af8EBAMCAgQwHQYDVR0OBBYEFJMgnJSYHH5AJ+9XB11usKRwjbjNMA0GCSqGSIb3
DQEBCwUAA4IBAQBOy8Z5FBd/nvgDcjvAwNCw9h5RHzgtgQqDP0qUjEqeQv3ALeC+
k/F2Tz0OWiPEzX5N+MMrf/jiYsL2exXuaPWCF5U9fu8bvs89GabHma8MGU3Qua2x
Imvt0whWExQMjoyU8SNUi2S13fnRie9ZlSwNh8B/OIUUEtVhQsd4OfuZZFVH4xGp
ibJMSMe5JBbZJC2tCdSdTLYfYJqrLkVuTjynXOjmz2JXfwnDNqEMdIMMjXzlNavR
J8SNtAoptMOK5vAvlySg4LYtFyXkl0W0vLKIbbHf+2UszuSCijTUa3o/Y1FoYSfi
eJH431YTnVLuwdd6fXkXFBrXDhjNsU866+hE
4. When you have finished entering values, select Review + create .

5. On the Review + create page, after validation passes, select Create .
6. It takes about 75 minutes for the deployment to complete. You can view the progress on the template
Over view page. If you close the portal, deployment will continue.
Validate the deployment

2. Select Resource groups from the left pane.
3. Select the resource group that you created in the previous section. On the Over view page, you will see
something similar to this example:
4. Click the virtual WAN to view the hubs. On the virtual WAN page, click each hub to view connections and
other hub information.
Complete the hybrid configuration

The template does not configure all of the settings necessary for a hybrid network. You need to complete the
following configurations and settings, depending on your requirements.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Tutorial: Create a Site-to-Site connection using
Azure Virtual WAN
This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an IPsec/IKE (IKEv1
and IKEv2) VPN connection. This type of connection requires a VPN device located on-premises that has an
externally facing public IP address assigned to it. For more information about Virtual WAN, see the Virtual WAN
Overview.
In this tutorial you learn how to:
Create a virtual WAN
Configure hub Basic settings
Configure site-to-site VPN gateway settings
Create a site
Connect a site to a hub
Connect a VPN site to a hub
Connect a VNet to a hub
Download a configuration file
View or edit your VPN gateway
NOTE
If you have many sites, you typically would use a Virtual WAN partner to create this configuration. However, you can
create this configuration yourself if you are comfortable with networking and proficient at configuring your own VPN
device.
Prerequisites
Verify that you have met the following criteria before beginning your configuration:
You have an Azure subscription. If you don't have an Azure subscription, create a free account.
You have a virtual network that you want to connect to.
Verify that none of the subnets of your on-premises networks overlap with the virtual networks that
you want to connect to.
To create a virtual network in the Azure portal, see the Quickstart article.
Your virtual network must not have any existing virtual network gateways.
If your virtual network already has gateways (VPN or ExpressRoute), you must remove all of the
gateways before proceeding.
This configuration requires that virtual networks connect to the Virtual WAN hub gateway only.
Decide the IP address range that you want to use for your virtual hub private address space. This
information is used when configuring your virtual hub. A virtual hub is a virtual network that is created
and used by Virtual WAN. It's the core of your Virtual WAN network in a region. The address space range
must conform the certain rules:
The address range that you specify for the hub can't overlap with any of the existing virtual networks
that you connect to.
The address range can't overlap with the on-premises address ranges that you connect to.
If you are unfamiliar with the IP address ranges located in your on-premises network configuration,
coordinate with someone who can provide those details for you.

1. In the portal, in the Search resources bar, type Vir tual WAN in the search box and select Enter .
2. Select Vir tual WANs from the results. On the Virtual WANs page, select + Create to open the Create
WAN page.
3. On the Create WAN page, on the Basics tab, fill in the fields. Modify the example values to apply to your
environment.
Subscription : Select the subscription that you want to use.

Resource group : Create new or use existing.
Resource group location : Choose a resource location from the dropdown. A WAN is a global
resource and does not live in a particular region. However, you must select a region in order to
manage and locate the WAN resource that you create.
Name : Type the Name that you want to call your virtual WAN.
Type : Basic or Standard. Select Standard . If you select Basic, understand that Basic virtual WANs can
only contain Basic hubs. Basic hubs can only be used for site-to-site connections.
4. After you finish filling out the fields, at the bottom of the page, select Review +Create .
5. Once validation passes, click Create to create the virtual WAN.
Configure hub settings

A hub is a virtual network that can contain gateways for site-to-site, ExpressRoute, or point-to-site functionality.
For this tutorial, you begin by filling out the Basics tab for the virtual hub and then continue on to fill out the
site-to-site tab in the next section. Note that it is possible to create an empty hub (a hub that does not contain
any gateways) and then add gateways (S2S, P2S, ExpressRoute, etc.) later. Once a hub is created, you'll be
charged for the hub, even if you don't attach any sites or create any gateways within the hub.
1. Locate the virtual WAN that you created. On the virtual WAN page, under the Connectivity section,
select Hubs .
2. On the Hubs page, select +New Hub to open the Create vir tual hub page.
3. On the Create vir tual hub page Basics tab, complete the following fields:
Region : This setting was previously referred to as location. It is the region in which you want to create
your virtual hub.
Name : The name by which you want the virtual hub to be known.
Hub private address space : The minimum address space is /24 to create a hub.
Configure a site-to-site gateway
In this section, you configure site-to-site connectivity settings, and then proceed to create the hub and site-to-
site VPN gateway. A hub and gateway can take about 30 minutes to create.
1. On the Create vir tual hub page, click Site to site to open the Site to site tab.
2. On the Site to site tab, complete the following fields:

Select Yes to create a Site-to-site VPN.
AS Number : The AS Number field cannot be edited.
Gateway scale units : Select the Gateway scale units value from the dropdown. The scale unit
lets you pick the aggregate throughput of the VPN gateway being created in the virtual hub to
connect sites to.
If you pick 1 scale unit = 500 Mbps, it implies that two instances for redundancy will be created,
each having a maximum throughput of 500 Mbps. For example, if you had five branches, each
doing 10 Mbps at the branch, you will need an aggregate of 50 Mbps at the head end. Planning for
aggregate capacity of the Azure VPN gateway should be done after assessing the capacity needed
to support the number of branches to the hub.
Routing preference : Azure routing preference lets you to choose how your traffic routes
between Azure and the internet. You can choose to route traffic either via the Microsoft network, or
via the ISP network (public internet). These options are also referred to as cold potato routing and
hot potato routing, respectively.
The public IP address in Virtual WAN is assigned by the service, based on the routing option
selected. For more information about routing preference via Microsoft network or ISP, see the
Routing preference article.
3. Select Review + Create to validate.
4. Select Create to create the hub and gateway. This can take up to 30 minutes. After 30 minutes, Refresh
to view the hub on the Hubs page. Select Go to resource to navigate to the resource.
Create a site
In this section, you create site. Sites correspond to your physical locations. Create as many sites as you need. For
example, if you have a branch office in NY, a branch office in London, and a branch office and LA, you'd create
three separate sites. These sites contain your on-premises VPN device endpoints. You can create up to 1000 sites
per virtual hub in a virtual WAN. If you had multiple hubs, you can create 1000 per each of those hubs. If you
have Virtual WAN partner CPE device, check with them to learn about their automation to Azure. Typically,
automation implies a simple click experience to export large-scale branch information into Azure, and setting up
connectivity from the CPE to Azure Virtual WAN VPN gateway. For more information, see Automation guidance
from Azure to CPE partners.
1. Navigate to your Vir tual WAN -> VPN sites to open the VPN sites page.
2. On the VPN sites page, click +Create site .
3. On the Create VPN Site page, on the Basics tab, complete the following fields:
Region : Previously referred to as location. This is the location you want to create this site resource
in.
Name : The name by which you want to refer to your on-premises site.
Device vendor : The name of the VPN device vendor (for example: Citrix, Cisco, Barracuda).
Adding the device vendor can help the Azure Team better understand your environment in order
to add additional optimization possibilities in the future, or to help you troubleshoot.
Private address space : The IP address space that is located on your on-premises site. Traffic
destined for this address space is routed to your local site. This is required when BGP is not
enabled for the site.
NOTE
If you edit the address space after creating the site (for example, add an additional address space) it can
take 8-10 minutes to update the effective routes while the components are recreated.
4. Select Links to add information about the physical links at the branch. If you have a Virtual WAN partner
CPE device, check with them to see if this information is exchanged with Azure as a part of the branch
information upload set up from their systems.
Link Name : A name you want to provide for the physical link at the VPN Site. Example: mylink1.
Link speed : This is the speed of the VPN device at the branch location. Example: 50, which means
50 Mbps is the speed of the VPN device at the branch site.
Link provider name : The name of the physical link at the VPN Site. Example: ATT, Verizon.
Link IP address/FQDN : Public IP address of the on-premises device using this link. Optionally,
you can provide the private IP address of your on-premises VPN device that is behind
ExpressRoute. You can also include a fully qualified domain name. For example,
something.contoso.com. The FQDN should be resolvable from the VPN gateway. This is possible if
the DNS server hosting this FQDN is reachable over internet. IP address takes precedence when
both IP address and FQDN are specified.
NOTE
Supports one IPv4 address per FQDN. If the FQDN were to be resolved to multiple IP addresses,
then the VPN gateway picks up the first IP4 address from the list. IPv6 addresses are not
supported at this time.
VPN gateway maintains a DNS cache which is refreshed every 5 minutes. The gateway tries to
resolve FQDNs for disconnected tunnels only. A gateway reset or configuration change can also
trigger FQDN resolution.
Link Border Gateway Protocol : Configuring BGP on a virtual WAN link is equivalent to
configuring BGP on an Azure virtual network gateway VPN. Your on-premises BGP peer address
must not be the same as the public IP address of your VPN to device or the VNet address space of
the VPN site. Use a different IP address on the VPN device for your BGP peer IP. It can be an
address assigned to the loopback interface on the device. Specify this address in the
corresponding VPN site representing the location. For BGP prerequisites, see About BGP with
Azure VPN Gateway. You can always edit a VPN link connection to update its BGP parameters
(Peering IP on the link and the AS #).
5. You can add or delete more links. Four links per VPN Site are supported. For example, if you have four
ISPs (Internet service provider) at the branch location, you can create four links, one per each ISP, and
provide the information for each link.
6. Once you have finished filling out the fields, select Review + create to verify. Click Create to create the
site.
7. On the VPN sites page, click Hub association: Connected to this hub to clear the filter.
8. Once the filter has cleared, you can view your site.
Connect the VPN site to a hub

In this section, you connect your VPN site to the hub.
1. Navigate to your Vir tual HUB -> VPN (Site to site) .
2. You may need to click Hub association: Connected to this hub in order to clear the filters and view
your sites.
3. Select the checkbox for the site that you want to connect, then click Connect VPN sites .
4. On the Connect sites page, configure the required settings.

Pre-shared key (PSK) : Enter the pre-shared key used by your VPN device. If you don't enter a
key, Azure autogenerates one for you. You would then use that key when configuring your VPN
device.
Protocol and IPsec : You can either leave the default settings for Protocol (IKEv2) and IPsec
(Default), or you can configure custom settings. For more information, see default/custom IPsec.
Propagate Default Route : Only change this setting to Enable if you know you want to
propagate the default route. Otherwise, leave it as Disable . You can always modify this setting
later.
The Enable option allows the virtual hub to propagate a learned default route to this connection.
This flag enables default route propagation to a connection only if the default route 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. The default route does not originate in the Virtual
WAN hub.
Use policy based traffic selector : Leave this setting as Disable unless you are configuring a
connection to a device that uses this setting.
5. At the bottom of the page, click Connect .
6. Once you click Connect , the connectivity status shows Updating . After updating completes, the site will
show the connection and connectivity status.
Connection Provisioning status : This is the status of the Azure resource for the connection that
connects the VPN site to the Azure hub’s VPN gateway. Once this control plane operation is successful,
Azure VPN gateway and the on-premises VPN device will proceed to establish connectivity.
Connectivity status : This is the actual connectivity (data path) status between Azure’s VPN gateway in
the hub and VPN site. After updating is completed, it can show any of the following states:
Unknown : This state is typically seen if the backend systems are working to transition to another
status.
Connecting : The VPN gateway is trying to reach out to the actual on-premises VPN site.
Connected : Connectivity is established between VPN gateway and the on-premises VPN site.
Not connected : Connectivity is not established.
Disconnected : This status is seen if, for any reason (on-premises or in Azure), the connection was
disconnected.
7. If you want to make changes to your site, select your site, then click the ... context menu.
From this page, you can do the following:

Edit or delete the VPN Connection.
Delete the VPN connection to this hub.
Download a branch-specific configuration for details about the Azure site. If you want to download the
configuration file that pertains to all connected sites in your hub, select Download VPN Config from
the menu at the top of the page instead.
Connect a VNet to the hub

In this section, you create a connection between the hub and your VNet.
1. Navigate to your Vir tual WAN .
2. Select Vir tual network connections .
3. On the virtual network connection page, select +Add connection .
4. On the Add connection page, configure the required settings. For more information about routing
settings, see About routing.
Connection name : Name your connection.
Hubs : Select the hub you want to associate with this connection.
Subscription : Verify the subscription.
Resource group : The resource group that contains the VNet.
Vir tual network : Select the virtual network you want to connect to this hub. The virtual network you
select can't have an already existing virtual network gateway.
Propagate to none : This is set to No by default. Changing the switch to Yes makes the configuration
options for Propagate to Route Tables and Propagate to labels unavailable for configuration.
Associate Route Table : You can select the route table that you want to associate.
Static routes : You can use this setting to specify next hop.
5. Once you have completed the settings you want to configure, select Create to create the connection.
Download VPN configuration

Use the VPN device configuration file to configure your on-premises VPN device. The basic steps are listed
below. The information about what the configuration file contains and how to configure your VPN device are
1. Navigate to your Vir tual HUB -> VPN (Site to site) page.
2. At the top of the VPN (Site to site) page, click Download VPN Config . You will see a series of
messages as Azure creates a storage account in the resource group 'microsoft-network-[location]', where
location is the location of the WAN.
3. Once the file has finished creating, click the link to download the file. To learn about the contents of the
file, see About the VPN device configuration file in this section.
4. Apply the configuration to your on-premises VPN device. For more information, see VPN device
configuration in this section.
5. After you have applied the configuration to your VPN devices, it isn't necessary to keep the storage
account that Azure created. You can delete it.
About the VPN device configuration file
The device configuration file contains the settings to use when configuring your on-premises VPN device. When
you view this file, notice the following information:
vpnSiteConfiguration - This section denotes the device details set up as a site connecting to the virtual
WAN. It includes the name and public ip address of the branch device.
vpnSiteConnections - This section provides information about the following settings:
Address space of the virtual hub(s) VNet.
Example:
"AddressSpace":"10.1.0.0/24"
Address space of the VNets that are connected to the hub.

Example:
"ConnectedSubnets":["10.2.0.0/16","10.3.0.0/16"]
IP addresses of the virtual hub vpngateway. Because each connection of the vpngateway is
composed of two tunnels in active-active configuration, you'll see both IP addresses listed in this
file. In this example, you see "Instance0" and "Instance1" for each site.
Example:
"Instance0":"104.45.18.186"
"Instance1":"104.45.13.195"
Vpngateway connection configuration details such as BGP, pre-shared key etc. The PSK is the
pre-shared key that is automatically generated for you. You can always edit the connection in the
Overview page for a custom PSK.
Example device configuration file
{
"configurationVersion":{
"LastUpdatedTime":"2018-07-03T18:29:49.8405161Z",
"Version":"r403583d-9c82-4cb8-8570-1cbbcd9983b5"
},
"vpnSiteConfiguration":{
"Name":"testsite1",
"IPAddress":"73.239.3.208"
},
"vpnSiteConnections":[
{
"hubConfiguration":{
"AddressSpace":"10.1.0.0/24",
"Region":"West Europe",
"ConnectedSubnets":[
"10.2.0.0/16",
"10.3.0.0/16"
]
]
},
"gatewayConfiguration":{
"IpAddresses":{
"Instance0":"104.45.18.186",
"Instance1":"104.45.13.195"
}
},
"connectionConfiguration":{
"IsBgpEnabled":false,
"PSK":"bkOWe5dPPqkx0DfFE3tyuP7y3oYqAEbI",
"IPsecParameters":{
"SADataSizeInKilobytes":102400000,
"SALifeTimeInSeconds":3600
}
}
}
]
},
{
"Version":"1f33f891-e1ab-42b8-8d8c-c024d337bcac"
},
"Name":" testsite2",
"IPAddress":"66.193.205.122"
},
{
"Region":"West Europe"
},
"IpAddresses":{
"Instance0":"104.45.18.187",
"Instance1":"104.45.13.195"
}
},
"PSK":"XzODPyAYQqFs4ai9WzrJour0qLzeg7Qg",
"IPsecParameters":{
}
}
}
]
},
{
"Version":"cd1e4a23-96bd-43a9-93b5-b51c2a945c7"
},
"IPAddress":"182.71.123.228"
},
{
},
"IpAddresses":{
"Instance0":"104.45.18.187",
"Instance1":"104.45.13.195"
}
},
"PSK":"YLkSdSYd4wjjEThR3aIxaXaqNdxUwSo9",
"IPsecParameters":{
}
}
}
]
}
Configuring your VPN device
NOTE
If you are working with a Virtual WAN partner solution, VPN device configuration automatically happens. The device
controller obtains the configuration file from Azure and applies to the device to set up connection to Azure. This means
you don't need to know how to manually configure your VPN device.
If you need instructions to configure your device, you can use the instructions on the VPN device configuration
scripts page with the following caveats:
The instructions on the VPN devices page are not written for Virtual WAN, but you can use the Virtual
WAN values from the configuration file to manually configure your VPN device.
The downloadable device configuration scripts that are for VPN Gateway do not work for Virtual WAN, as
the configuration is different.
A new Virtual WAN can support both IKEv1 and IKEv2.
Virtual WAN can use both policy based and route-based VPN devices and device instructions.
View or edit gateway settings

You can view and edit your VPN gateway settings at any time by navigating to Vir tual HUB -> VPN (Site to
site) and selecting View/Configure .
On the Edit VPN Gateway page, you can see the following settings:
Public IP Address : Assigned by Azure.
Private IP Address : Assigned by Azure.
Default BGP IP Address : Assigned by Azure.
Custom BGP IP Address : This field is reserved for APIPA (Automatic Private IP Addressing). Azure
supports BGP IP in the ranges 169.254.21.* and 169.254.22.*. Azure accepts BGP connections in these
ranges but will dial connection with the default BGP IP.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Next, to learn more about Virtual WAN, see:
Virtual WAN FAQ
Tutorial: Create a User VPN connection using Azure
Virtual WAN
This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an OpenVPN or
IPsec/IKE (IKEv2) VPN connection using a User VPN (P2S) configuration. This type of connection requires the
native VPN client to be configured on each connecting client computer.
If you want to create a User VPN connection using Azure AD authentication, use the Configure a User VPN
connection - Azure Active Directory authentication article instead.
For more information about Virtual WAN, see the Virtual WAN Overview.
In this tutorial, you learn how to:
Create the User VPN configuration
Create the virtual hub and gateway
Generate client configuration files
Configure VPN clients
Connect to a VNet
View your virtual WAN
Modify settings
Prerequisites

WAN page.
environment.

Create a User VPN configuration

The User VPN (P2S) configuration defines the parameters for remote clients to connect. The instructions you
follow depend on the authentication method you want to use.
In the following steps, when selecting the authentication method, you have three choices. Each method has
specific requirements. Select one of the following methods, and then complete the steps.
Azure cer tificates: For this configuration, certificates are required. You need to either generate or
obtain certificates. A client certificate is required for each client. Additionally, the root certificate
information (public key) needs to be uploaded. For more information about the required certificates, see
Generate and export certificates.
Azure Active Director y authentication: Use the Configure a User VPN connection - Azure Active
Directory authentication article, which contains the specific steps necessary for this configuration.
Radius-based authentication: Obtain the Radius server IP, Radius server secret, and certificate
information.
Configuration steps
1. Navigate to the virtual WAN that you created.
2. Select User VPN configurations from the menu on the left.
3. On the User VPN configurations page, select +Create user VPN config .
4. On the Create new User VPN configuration page Basics tab, under Instance details , enter the
Name you want to assign to your VPN configuration.
5. For Tunnel type , select the tunnel type that you want from the dropdown. The tunnel type options are:
IKEv2 VPN, OpenVPN, and OpenVpn and IKEv2 . Each tunnel type has different required settings.
Requirements and parameters :
IKEv2 VPN
Requirements: When you select the IKEv2 tunnel type, you see a message directing you to select
an authentication method. For IKEv2, you may specify only one authentication method. You can
choose Azure Certificate, Azure Active Directory, or RADIUS-based authentication.
IPSec custom parameters: To customize the parameters for IKE Phase 1 and IKE Phase 2, toggle
the IPsec switch to Custom and select the parameter values. For more information about
customizable parameters, see the Custom IPsec article.
OpenVPN
Requirements: When you select the OpenVPN tunnel type, you see a message directing you to
select an authentication mechanism. If OpenVPN is selected as the tunnel type, you may specify
multiple authentication methods. You can choose any subset of Azure Certificate, Azure Active
Directory, or RADIUS-based authentication. For RADIUS-based authentication, you can provide a
secondary RADIUS server IP address and server secret.
6. Configure the Authentication methods you want to use. Each authentication method is in a separate
tab: Azure cer tificate , RADIUS authentication , and Azure Active Director y . Some authentication
methods are only available on certain tunnel types.
On the tab for the authentication method you want to configure, select Yes to reveal the available
configuration settings.
Example - Cer tificate authentication
Example - RADIUS authentication
Example - Azure Active Director y authentication

7. When you have finished configuring the settings, click Review + create at the bottom of the page.
8. Click Create to create the User VPN configuration.
Create a virtual hub and gateway

1. On the page for your vir tual WAN , on the left pane, select Hubs . On the Hubs page, select +New Hub .
2. On the Create vir tual hub page, view the Basics tab.
3. On the Basics tab, configure the following settings:
Region : Select the region in which you want to deploy the virtual hub.
Hub private address space : The hub's address range in CIDR notation.
4. Click the Point to site tab to open the configuration page for point-to-site. To view the point to site
settings, click Yes .
5. Configure the following settings:
Gateway scale units - This represents the aggregate capacity of the User VPN gateway. If you
select 40 or more gateway scale units, plan your client address pool accordingly. For information
about how this setting impacts the client address pool, see About client address pools. For
information about gateway scale units, see the FAQ.
Point to site configuration - Select the User VPN configuration that you created in a previous
step.
Routing preference - Azure routing preference enables you to choose how your traffic routes
between Azure and the Internet. You can choose to route traffic either via the Microsoft network,
or, via the ISP network (public internet). These options are also referred to as cold potato routing
and hot potato routing, respectively. The public IP address in Virtual WAN is assigned by the
service based on the routing option selected. For more information about routing preference via
Microsoft network or ISP, see the Routing preference article.
Use Remote/On-premises RADIUS ser ver -
NOTE
The Remote/On-premises RADIUS server setting and related proxy IPs are only used if the Gateway is
configured to use RADIUS-based authentication. If the Gateway is not configured to use RADIUS-based
authentication, this setting will be ignored.
When a Virtual WAN User VPN gateway is configured to use RADIUS-based authentication, the
User VPN gateway acts as a proxy and sends RADIUS access requests to your RADIUS server. The
"Use Remote/On-premises RADIUS server" setting is disabled by default, meaning the User VPN
gateway will only be able to forward authentication requests to RADIUS servers in virtual
networks connected to the gateway's hub. Enabling the setting will enable the User VPN gateway
to authenticate with RADIUS servers connected to remote hubs or deployed on-premises.
After updating the setting, navigate to the User VPN gateway and note the RADIUS proxy IPs field.
The RADIUS proxy IPs are the source IPs of the RADIUS packets the User VPN gateway sends to
your RADIUS server. Therefore, your RADIUS server needs to be configured to accept
authentication requests from the RADIUS proxy IPs. If the RADIUS proxy IPs field is blank or none,
configure the RADIUS server to accept authentication requests from the hub's address space.
Client address pool - The address pool from which IP addresses will be automatically assigned
to VPN clients. For more information, see About client address pools.
Custom DNS Ser vers - The IP address of the DNS server(s) the clients will use. You can specify
up to 5.
6. Select Review + create to validate your settings.
7. When validation passes, select Create . Creating a hub can take 30 minutes or more to complete.

When you connect to VNet using User VPN (P2S), you use the VPN client that is natively installed on the
operating system from which you are connecting. All of the necessary configuration settings for the VPN clients
are contained in a VPN client configuration zip file. The settings in the zip file help you easily configure the VPN
clients. The VPN client configuration files that you generate are specific to the User VPN configuration for your
gateway. In this section, you generate and download the files used to configure your VPN clients.
1. On the page for your vir tual WAN , select User VPN configurations .
2. On the User VPN configurations page, select a configuration, then select Download vir tual WAN
user VPN profile .
When you download the WAN-level configuration, you get a built-in Traffic Manager-based User
VPN profile.
For information about Global profiles and hub-based profiles, see Hub profiles. Failover scenarios
are simplified with global profile.
If for some reason a hub is unavailable, the built-in traffic management provided by the service
ensures connectivity (via a different hub) to Azure resources for point-to-site users. You can always
download a hub-specific VPN configuration by navigating to the hub. Under User VPN (point to
site) , download the virtual hub User VPN profile.
3. On the Download vir tual WAN user VPN profile page, select the Authentication type you want,
then click Generate and download profile .
A profile package (zip file) containing the client configuration settings is generated and downloads to
your computer.

Use the downloaded profile package to configure the remote access VPN clients. The procedure for each
operating system is different. Follow the instructions that apply to your system. Once you have finished
configuring your client, you can connect.
OpenVPN
Configure an OpenVPN client for Azure Virtual WAN
Azure AD authentication - Windows 10
Azure AD authentication - macOS
IKEv2
1. Select the VPN client configuration files that correspond to the architecture of the Windows computer. For
a 64-bit processor architecture, choose the 'VpnClientSetupAmd64' installer package. For a 32-bit
processor architecture, choose the 'VpnClientSetupX86' installer package.
2. Double-click the package to install it. If you see a SmartScreen popup, select More info , then Run
anyway .
3. On the client computer, navigate to Network Settings and select VPN . The VPN connection shows the
name of the virtual network that it connects to.
4. Before you attempt to connect, verify that you have installed a client certificate on the client computer. A
client certificate is required for authentication when using the native Azure certificate authentication type.
For more information about generating certificates, see Generate Certificates. For information about how
to install a client certificate, see Install a client certificate.
Connect VNet to hub

In this section, you create a connection between your virtual hub and your VNet. For this tutorial, you do not
need to configure the routing settings.
View a virtual WAN

1. Navigate to your vir tual WAN .
2. On the Over view page, each point on the map represents a hub.
3. In the Hubs and connections section, you can view hub status, site, region, VPN connection status, and
bytes in and out.
Modify settings
Modify client address pool
1. Navigate to your Vir tual HUB -> User VPN (Point to site) .
2. Click the value next to Gateway scale units to open the Edit User VPN gateway page.
3. On the Edit User VPN gateway page, edit the settings.
4. Click Edit at the bottom of the page to validate your settings.
5. Click Confirm to save your settings. Any changes on this page could take up to 30 minutes to complete.
Modify DNS servers
2. Click the value next to Custom DNS Ser vers to open the Edit User VPN gateway page.
3. On the Edit User VPN gateway page, edit the Custom DNS Ser vers field. Enter the DNS server IP
addresses in the Custom DNS Ser vers text boxes. You can specify up to five DNS Servers.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Manage secure access to resources in spoke VNets
Tutorial: Create an ExpressRoute association using
Azure Virtual WAN
This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an ExpressRoute
circuit. For more information about Virtual WAN and Virtual WAN resources, see the Virtual WAN Overview.
Create a hub and a gateway
Connect a circuit to a hub gateway
Test connectivity
Change a gateway size
Advertise a default route
Prerequisites
You have a virtual network that you want to connect to. Verify that none of the subnets of your on-
premises networks overlap with the virtual networks that you want to connect to. To create a virtual
network in the Azure portal, see the Quickstart.
Your virtual network does not have any virtual network gateways. If your virtual network has a gateway
(either VPN or ExpressRoute), you must remove all gateways. This configuration requires that virtual
networks are connected instead, to the Virtual WAN hub gateway.
Obtain an IP address range for your hub region. The hub is a virtual network that is created and used by
Virtual WAN. The address range that you specify for the hub cannot overlap with any of your existing
virtual networks that you connect to. It also cannot overlap with your address ranges that you connect to
on-premises. If you are unfamiliar with the IP address ranges located in your on-premises network
configuration, coordinate with someone who can provide those details for you.
The ExpressRoute circuit must be a Premium or Standard circuit in order to connect to the hub gateway.
If you don't have an Azure subscription, create a free account.

From a browser, navigate to the Azure portal and sign in with your Azure account.
1. Navigate to the Virtual WAN page. In the portal, click +Create a resource . Type Vir tual WAN into the
search box and select Enter.
2. Select Vir tual WAN from the results. On the Virtual WAN page, click Create to open the Create WAN
page.
3. On the Create WAN page, on the Basics tab, fill in the following fields:
Subscription - Select the subscription that you want to use.
Resource Group - Create new or use existing.
Resource group location - Choose a resource location from the dropdown. A WAN is a global
resource and does not live in a particular region. However, you must select a region in order to more
easily manage and locate the WAN resource that you create.
Name - Type the name that you want to call your WAN.
Type - Select Standard . You can't create an ExpressRoute gateway using the Basic SKU.
4. After you finish filling out the fields, select Review +Create .
5. Once validation passes, select Create to create the virtual WAN.

A virtual hub is a virtual network that is created and used by Virtual WAN. It can contain various gateways, such
as VPN and ExpressRoute. In this section, you will create an ExpressRoute gateway for your virtual hub. You can
either create the gateway when you create a new virtual hub, or you can create the gateway in an existing hub
by editing it.
ExpressRoute gateways are provisioned in units of 2 Gbps. 1 scale unit = 2 Gbps with support up to 10 scale
units = 20 Gbps. It takes about 30 minutes for a virtual hub and gateway to fully create.
To create a new virtual hub and a gateway
Create a new virtual hub. Once a hub is created, you'll be charged for the hub, even if you don't attach any sites.
1. Locate the Virtual WAN that you created. On the Virtual WAN page, under the Connectivity section,
select Hubs . Click New Hub to open the Create vir tual hub page.
2. On the Create vir tual hub page, fill in the fields.
3. Select the ExpressRoute tab . Click Yes to reveal settings and fill out the field. For information about
gateway scale units, see the FAQ.
5. Select Create to create the hub with an ExpressRoute gateway. A hub can take about 30 minutes to
complete. After 30 minutes, Refresh to view the hub on the Hubs page. Select Go to resource to
navigate to the resource.
To create a gateway in an existing hub
You can also create a gateway in an existing hub by editing it.
1. Navigate to the virtual hub that you want to edit and select it.
2. On the Edit vir tual hub page, select the checkbox Include ExpressRoute gateway .
3. Select Confirm to confirm your changes. It takes about 30 minutes for the hub and hub resources to
fully create.
To view a gateway
Once you have created an ExpressRoute gateway, you can view gateway details. Navigate to the hub, select
ExpressRoute , and view the gateway.
Connect your VNet to the hub

In this section, you create the peering connection between your hub and a VNet. Repeat these steps for each
VNet that you want to connect.
1. On the page for your virtual WAN, click Vir tual network connection .
2. On the virtual network connection page, click +Add connection .
3. On the Add connection page, fill in the following fields:
Connection name - Name your connection.
Hubs - Select the hub you want to associate with this connection.
Subscription - Verify the subscription.
Vir tual network - Select the virtual network you want to connect to this hub. The virtual network
cannot have an already existing virtual network gateway (neither VPN, nor ExpressRoute).
Connect your circuit to the hub gateway

Once the gateway is created, you can connect an ExpressRoute circuit to it. ExpressRoute Standard or Premium
circuits that are in ExpressRoute Global Reach-supported locations can connect to a Virtual WAN ExpressRoute
gateway and enjoy all Virtual WAN transit capabilities (VPN-to-VPN, VPN, and ExpressRoute transit).
ExpressRoute Standard and Premium circuits that are in non-Global Reach locations can connect to Azure
resources, but will not be able to use Virtual WAN transit capabilities. ExpressRoute Local is also supported with
Azure Virtual WAN hubs.
To connect the circuit to the hub gateway
In the portal, go to the Vir tual hub -> Connectivity -> ExpressRoute page. If you have access in your
subscription to an ExpressRoute circuit, you will see the circuit you want to use in the list of circuits. If you don’t
see any circuits, but have been provided with an authorization key and peer circuit URI, you can redeem and
connect a circuit. See To connect by redeeming an authorization key.
1. Select the circuit.
2. Select Connect circuit(s) .
To connect by redeeming an authorization key

Use the authorization key and circuit URI you were provided in order to connect.
1. On the ExpressRoute page, click +Redeem authorization key
2. On the Redeem authorization key page, fill in the values.
3. Select Add to add the key.

4. View the circuit. A redeemed circuit only shows the name (without the type, provider and other
information) because it is in a different subscription than that of the user.
To test connectivity
After the circuit connection is established, the hub connection status will indicate 'this hub', implying the
connection is established to the hub ExpressRoute gateway. Wait approximately 5 minutes before you test
connectivity from a client behind your ExpressRoute circuit, for example, a VM in the VNet that you created
earlier.
If you have sites connected to a Virtual WAN VPN gateway in the same hub as the ExpressRoute gateway, you
can have bidirectional connectivity between VPN and ExpressRoute end points. Dynamic routing (BGP) is
supported. The ASN of the gateways in the hub is fixed and cannot be edited at this time.
To change the size of a gateway

If you want to change the size of your ExpressRoute gateway, locate the ExpressRoute gateway inside the hub,
and select the scale units from the dropdown. Save your change. It will take approximately 30 minutes to update
the hub gateway.
To advertise default route 0.0.0.0/0 to endpoints

If you would like the Azure virtual hub to advertise the default route 0.0.0.0/0 to your ExpressRoute end points,
you will need to enable 'Propagate default route'.
1. Select your Circuit ->…-> Edit connection .
2. Select Enable to propagate the default route.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Virtual WAN FAQ
Working remotely using Azure networking services
NOTE
This article describes how you can leverage Azure networking services, Microsoft network, and the Azure partner
ecosystem to work remotely and mitigate network issues that you might be facing because of the COVID-19 crisis.
This article describes the options that are available to organizations to set up remote access for their users or to
supplement their existing solutions with additional capacity during periods of peak utilization. Network
architects are faced with the following challenges:
Address an increase in network utilization.
Provide reliable-secure connectivity to more employees of their company and customers.
Provide connectivity to remote locations across the globe.
Not all networks (for example, private WAN and corporate core networks) experience congestion from peak
remote worker load. The bottlenecks are commonly reported only in home broadband networks and VPN
gateways of on-premises networks of corporations.
Network planners can help ease the bottlenecks and alleviate the network congestion by keeping in mind that
different traffic types need different network treatment priorities and by some smart load
redirection/distribution. For example, real-time tele-medecine traffic of doctor-patient interaction is of high
importance and delay/jitter sensitive. Whereas, replication of the same traffic between storages is not delay
sensitive. The former traffic must be routed via the most optimal network path with higher quality of service;
whereas it is acceptable to route the later traffic via sub-optimal route.
Sharing our best practices - Azure network is designed for elasticity

and high-availability
Azure is designed to withstand sudden changes in the utilization of the resources and can greatly help during
periods of peak utilization. Also, Microsoft maintains and operates one of the worlds' largest networks.
Microsoft's network has been designed for high availability that can withstand different types of failure: from a
single network element failure to failure of an entire region.
The Microsoft network is designed to meet the requirements and provide optimal performance for different
types of network traffic including delay sensitive multimedia traffic for Skype and Teams, CDN, real-time big
data analysis, Azure storage, Bing, and Xbox. To provide optimal performance for different types of traffic, the
Microsoft network attracts all the traffic that is destined to- or wanting to transit through- its resources as close
as possible to the origin of the traffic.
NOTE
Using the Azure networking features described below leverages the traffic attraction behavior of the Microsoft global
network to provide a better customer networking experience. The traffic attraction behavior of the Microsoft network
helps off loading traffic as soon as possible from the first/last mile networks that may experience congestion during
periods of peak utilization.
Enable employees to work remotely
Azure VPN gateway supports both Point-to-Site (P2S) and Site-to-Site (S2S) VPN connections. Using the Azure
VPN gateway you can scale your employee's connections to securely access both your Azure deployed resources
and your on-premises resources. For more information, see How to enable users to work remotely.
If you are using Secure Sockets Tunneling Protocol (SSTP), the number of concurrent connections is limited to
128. To get a higher number of connections, we suggest transitioning to OpenVPN or IKEv2. For more
information, see Transition to OpenVPN protocol or IKEv2 from SSTP.
To access your resources deployed in Azure, remote developers could use Azure Bastion solution, instead of VPN
connection to get secure shell access (RDP or SSH) without requiring public IPs on the VMs being accessed. For
more information, see Work remotely using Azure Bastion.
For aggregating large-scale VPN connection, to support any-to-any connections between resources in different
on-premises global locations, in different regional hub and spoke virtual networks, and to optimize utilization of
multiple home broadband networks you can use Azure Virtual WAN. For more information, see Struggling to
cater to work from home needs? Here is where Azure Virtual WAN can help.
Another way to support a remote workforce is to deploy a Virtual Desktop Infrastructure (VDI) hosted in your
Azure virtual network, secured with an Azure Firewall. For example, Azure Virtual Desktop (AVD) is a desktop
and app virtualization service that runs in Azure. With Azure Virtual Desktop, you can set up a scalable and
flexible environment in your Azure subscription without the need to run any additional gateway servers. You are
only responsible for the AVD virtual machines in your virtual network. For more information, see Azure Firewall
remote work support.
Azure also has a rich set of eco system partners. Our partners Network Virtual Appliances on Azure can also
help scale VPN connectivity. For more information, see Network Virtual Appliance (NVA) considerations for
remote work.
Extend employees' connection to access globally distributed

resources
The following Azure services can help enable employees to access your globally distributed resources. Your
resources could be in any of the Azure regions, on-premises networks, or even in other public or private clouds.
Azure vir tual network peering : If you deploy your resources in more than one Azure regions and/or if
you aggregate the connectivity of remotely working employees using multiple virtual networks, you can
establish connectivity between the multiple Azure virtual networks using virtual network peering. For
more information, see Virtual network peering.
Azure VPN-based solution : For your remote employees connected to Azure via P2S or S2S VPN, you
can enable access to on-premises networks by configuring S2S VPN between your on-premises networks
and Azure VPN gateway. For more information, see Create a Site-to-Site connection.
ExpressRoute : Using ExpressRoute private peering you can enable private connectivity between your
Azure deployments and on-premises infrastructure or your infrastructure in a co-location facility.
ExpressRoute, via Microsoft peering, also permits accessing public endpoints in Microsoft from your on-
premises network. ExpressRoute connections do not go over the public Internet. They offer secure
connectivity, reliability, higher throughput, with lower and consistent latencies than typical connections
over the Internet. For more information, see ExpressRoute overview. Leveraging your existing network
provider that is already part of our ExpressRoute partner ecosystem can help reduce the time to get large
bandwidth connections to Microsoft. Using ExpressRoute Direct you can directly connect your on-
premises network to the Microsoft backbone. ExpressRoute Direct offers two different line-rate options of
dual 10 Gbps or 100 Gbps.
Azure Vir tual WAN : Azure Virtual WAN allows seamless interoperability between your VPN
connections and ExpressRoute circuits. As mentioned earlier, Azure Virtual WAN also support any-to-any
connections between resources in different on-prem global locations, in different regional hub and spoke
virtual networks
Scale customer connectivity to frontend resources

During times when more people go online, many corporate websites experience increased customer traffic.
Azure Application Gateway can help manage this increased frontend workload. For more information, see
Application Gateway high traffic support.
Microsoft support for multi-cloud traffic

For your deployments in other public clouds, Microsoft can provide global connectivity. Azure Virtual WAN, VPN
or ExpressRoute can help in this regard. To extend connectivity from Azure to other clouds, you can configure
S2S VPN between the two clouds. You can also establish connectivity from Azure to other public clouds using
ExpressRoute. Oracle cloud is part of ExpressRoute partner ecosystem. You can set up a direct interconnection
between Azure and Oracle Cloud Infrastructure. Most service providers that are part of the ExpressRoute
partner ecosystem also offer private connectivity to other public clouds. Leveraging these service providers, you
can establish private connectivity between your deployments in Azure and other clouds via ExpressRoute.
Next steps
The following articles discuss how different Azure networking features can be used to scale users to work
remotely:
A RT IC L E DESC RIP T IO N
How to enable users to work remotely Review available options to set up remote access for users or
to supplement their existing solutions with additional
capacity for your organization.
Struggling to cater to work from home needs? Here is where Use Azure Virtual WAN to address the remote connectivity
Azure Virtual WAN can help needs of your organization.
Application Gateway high traffic support Use Application Gateway with Web Application Firewall
(WAF) for a scalable and secure way to manage traffic to
your web applications.
Network Virtual Appliance (NVA) considerations for remote Review guidance about leveraging NVAs in Azure to provide
work remote access solutions.
Transition to OpenVPN protocol or IKEv2 from SSTP Overcome the 128 concurrent connection limit of SSTP by
transitioning to OpenVPN protocol or IKEv2.
Working remotely using Azure Bastion Provide secure and seamless RDP/SSH connectivity to virtual
machines within the Azure virtual network, directly in the
Azure portal, without the use of a public IP address.
Using Azure ExpressRoute to create hybrid connectivity to Use ExpressRoute for hybrid connectivity to enable users in
support remote users your organization to work remotely.
Azure Firewall remote work support Protect your Azure virtual network resources using Azure
Firewall.
Azure Virtual WAN and supporting remote work
NOTE
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.
together to provide a single operational interface. These functionalities include Branch connectivity (via
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.
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 multiple hubs per region/location. For location information, see the Virtual WAN partners
and locations article. Each hub supports up to 100,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 azurevirtualwan@microsoft.com. If you require
technical support, be sure to open a support ticket from the Azure portal and help will be on the way.
FAQ
See the Virtual WAN FAQ.
Next Steps
For more information about Virtual WAN, see Virtual WAN overview
Virtual WAN FAQ
Is Azure Virtual WAN in GA?

Yes, Azure Virtual WAN is Generally Available (GA). However, Virtual WAN consists of several features and
scenarios. There are feature or scenarios within Virtual WAN where Microsoft applies the Preview tag. In those
cases, the specific feature, or the scenario itself, is in Preview. If you do not use a specific preview feature, regular
GA support applies. For more information about Preview support, see Supplemental Terms of Use for Microsoft
Azure Previews.
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 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.
Can you disable fully meshed hubs in a Virtual WAN?
Virtual WAN comes in two flavors: Basic and Standard. In Basic Virtual WAN, hubs are not meshed. In a Standard
Virtual WAN, hubs are meshed and automatically connected when the virtual WAN is first set up. The user does
not need to do anything specific. The user also does not have to disable or enable the functionality to obtain
meshed hubs. Virtual WAN provides you many routing options to steer traffic between any spoke (VNet, VPN,
or ExpressRoute). It provides the ease of fully meshed hubs, and also the flexibility of routing traffic per your
needs.
How are Availability Zones and resiliency handled in Virtual WAN?
Virtual WAN is a collection of hubs and services made available inside the hub. The user can have as many
Virtual WAN per their need. In a Virtual WAN hub, there are multiple services like VPN, ExpressRoute etc. Each of
these services is automatically deployed across Availability Zones (except Azure Firewall), if the region supports
Availability Zones. If a region becomes an Availability Zone after the initial deployment in the hub, the user can
recreate the gateways, which will trigger an Availability Zone deployment. All gateways are provisioned in a hub
as active-active, implying there is resiliency built in within a hub. Users can connect to multiple hubs if they want
resiliency across regions.
Currently, Azure Firewall can be deployed to support Availability Zones using Azure Firewall Manager Portal,
PowerShell or CLI. There is currently no way to configure an existing Firewall to be deployed across availability
zones. You will need to delete and redeploy your Azure Firewall.
While the concept of Virtual WAN is global, the actual Virtual WAN resource is Resource Manager-based and
deployed regionally. If the virtual WAN region itself were to have an issue, all hubs in that virtual WAN will
continue to function as is, but the user will not be able to create new hubs until the virtual WAN region is
available.
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. IKEv2 supports both certificate and RADIUS
authentication.
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. The first method is preferred as it adds the custom
DNS servers to the gateway instead of the client.
1. Use the following PowerShell script to add the custom DNS servers. Replace the values for your
environment.
// Define variables
$rgName = "testRG1"
$virtualHubName = "virtualHub1"
$P2SvpnGatewayName = "testP2SVpnGateway1"
$vpnClientAddressSpaces =
$vpnServerConfiguration1Name = "vpnServerConfig1"
$vpnClientAddressSpaces = New-Object string[] 2
$vpnClientAddressSpaces[0] = "192.168.2.0/24"
$customDnsServers = New-Object string[] 2
$customDnsServers[0] = "7.7.7.7"
$customDnsServers[1] = "8.8.8.8"
$virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
$vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name
$vpnServerConfiguration1Name
// Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -
VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -
VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers
// Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
$P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
$updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -
CustomDnsServer $customDnsServers
// Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns servers
2. Or, if you are using the Azure VPN Client for Windows 10, you can modify the downloaded profile XML
file and add the <dnsser vers><dnsser ver> </dnsser ver></dnsser vers> tags before importing it.
<azvpnprofile>
<clientconfig>
<dnsservers>
<dnsserver>x.x.x.x</dnsserver>
<dnsserver>y.y.y.y</dnsserver>
</dnsservers>
</clientconfig>
</azvpnprofile>
For User VPN (Point-to -site )- how many clients are supported?
Each User VPN P2S gateway has two instances. Each instance supports up to a certain number of connections as
the scale units change. 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-18 supports up to 10,000 connections.
For example, let's 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 up to 500 connections. Since you can get 500
connections * 2 per gateway, it does not mean that you plan for 1000 instead of the 500 for this scale unit.
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 are Virtual WAN gateway scale units?
A scale unit is a 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
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 'Site-to-site VPN'. When you want to connect remote users to Virtual WAN, you use a
gateway type 'Point-to-site VPN'. The Point-to-site and Site-to-site VPN Gateways are separate entities in the
Virtual WAN hub and must be individually deployed. 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 autoprovisions 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 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 also have
multiple virtual hubs per region, which means you can connect more than 1,000 branches to a single Azure
Region by deploying multiple Virtual WAN hubs in that Azure Region, each with its own Site-to-site VPN
gateway.
What is the recommended algorithm and Packets per second per Site -to -site instance in Virtual WAN hub?
How many tunnels is support per instance? What is the max throughput supported in a single tunnel?
Virtual WAN supports 2 active Site-to-Site VPN Gateway instances in a virtual hub. This means there are 2
active-active set of VPN gateway instances in a virtual hub. During maintenance operations, each instance is
upgraded one by one due to which a user may experience brief decrease in aggregate throughput of a VPN
gateway.
While Virtual WAN VPN supports many algorithms, our recommendation is GCMAES256 for both IPSEC
Encryption and Integrity for optimal performance. AES256 and SHA256 are considered less performant and
therefore performance degradation such as latency and packet drops can be expected for similar algorithm
types.
Packets per second or PPS is a factor of the total # of packets and the throughput supported per instance. This is
best understood with an example. Lets say a 1 scale unit 500-Mbps site-to-site VPN gateway instance is
deployed in a virtual WAN hub. Assuming a packet size of 1480, expected PPS for that vpn gateway instance at a
minimum = [(500 Mbps * 1024 * 1024) /8/1480] ~ 43690.
Virtual WAN has concepts of VPN connection, link connection and tunnels. A single VPN connection consists of
link connections. Virtual WAN supports up to 4 link connections in a VPN connection. Each link connection
consists of two IPsec tunnels that terminate in two instances of an active-active VPN gateway deployed in a
virtual hub. The total number of tunnels that can terminate in a single active instance is 1000, which also implies
that throughput for 1 instance will be available aggregated across all the tunnels connecting to that instance.
Each tunnel also has certain throughput values. For GCM algorithm, a tunnel can support up to a maximum 1.25
Gbps. In cases of multiple tunnels connected to a lower value scale unit gateway, it is best to evaluate the need
per tunnel and plan for a VPN gateway that is an aggregate value for throughput across all tunnels terminating
in the VPN instance.
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.
Virtual WAN also has CPE partner solutions that automate connectivity to Azure Virtual WAN making it easier to
set up IPsec VPN connections at scale.
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.
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'. Because 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.
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 Virtual WAN partner automation to
assess technical feasibility. An ideal partner is one that has a device that can be provisioned for IKEv1 or IKEv2
IPsec connectivity. Once the company has completed the automation work for their CPE device based on the
automation guidelines provided above, you can reach out to azurevirtualwan@microsoft.com to be listed here
Connectivity through partners. If you are a customer that would like a certain company solution to be listed as a
Virtual WAN partner, have the company contact the Virtual WAN by sending an email to
azurevirtualwan@microsoft.com.
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.
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 VPN gateway. Links represent the physical ISP link at the branch/VPN device.
What is a branch connection to Azure Virtual WAN?
A connection from a branch or VPN device into Azure Virtual WAN is a VPN connection that connects virtually
the VPN Site and the Azure VPN Gateway in a virtual hub.
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
may experience a reconnect. BGP sessions will not move across instances.
What happens during a Gateway Reset in a Virtual WAN VPN Gateway?
The Gateway Reset button should be used if your on-premises devices are all working as expected but Site to
Site VPN connections in Azure are in a Disconnected state. Virtual WAN VPN Gateways are always deployed in
an Active-Active state for high availability. This means there is always more than one instance deployed in a VPN
Gateway at any point of time. When the Gateway Reset button is used, it reboots the instances in the VPN
Gateway in a sequential manner, so your connections are not disrupted. There will be a brief gap as connections
move from one instance to the other, but this gap should be less than a minute. Additionally, please note that
resetting the gateways will not change your Public IPs.
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.
Are there new Resource Manager resources available for Virtual WAN?
Yes, Virtual WAN has new Resource Manager resources. For more information, please see the Overview.
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.
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 appropriate routing to direct traffic per your needs.
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 in VPN connectivity?
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.
Is there any licensing or pricing information for Virtual WAN?
Yes. See the Pricing page.
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.
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.
In 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.
Is branch-to -branch connectivity allowed in Virtual WAN?
Yes, branch-to-branch connectivity is available in Virtual WAN. Branch is conceptually applicable to VPN Site,
ExpressRoute circuits, or Point-to-Site/User VPN users. Enabling branch-to-branch is enabled by default and can
be located in WAN Configuration settings. This lets VPN branches/users connect to other VPN branches and
transit connectivity is also enabled between VPN and ExpressRoute users.
Does branch-to -branch traffic traverse through the Azure Virtual WAN?
Yes. Branch-to-branch traffic traverses through Azure Virtual WAN.
Does Virtual WAN require ExpressRoute from each site?
No. Virtual WAN does not require ExpressRoute from each site. Your sites may be connected to a provider
network using an ExpressRoute circuit. For sites that are connected using ExpressRoute to a virtual hub and
IPsec VPN into the same hub, virtual hub provides transit connectivity between the VPN and ExpressRoute user.
Is there a network throughput or connection limit when using Azure Virtual WAN?
Network throughput is per service in a virtual WAN hub. In each hub, the VPN aggregate throughput is up to 20
Gbps, the ExpressRoute aggregate throughput is up to 20 Gbps, and the User VPN/Point-to-site VPN aggregate
throughput is up to 20 Gbps. The router in virtual hub supports up to 50 Gbps for VNet-to-VNet traffic flows
and assumes a total of 2000 VM workload across all VNets connected to a single virtual hub. This limit can be
increased opening an online customer support request. For cost implication, see Routing Infrastructure Unit cost
in the Azure Virtual WAN Pricing page.
When VPN sites connect into a hub, they do so with connections. Virtual WAN supports up to 1000 connections
or 2000 IPsec tunnels per virtual hub. When remote users connect into virtual hub, they connect to the P2S VPN
gateway, which supports up to 100,000 users depending on the scale unit(bandwidth) chosen for the P2S VPN
gateway in the virtual hub.
Can I use NAT -T on my VPN connections?
Yes, NAT traversal (NAT-T) is supported. The Virtual WAN VPN gateway will NOT perform any NAT-like
functionality on the inner packets to/from the IPsec tunnels. In this configuration, ensure the on-premises device
initiates the IPsec tunnel.
I don't see the 20-Gbps setting for the virtual hub in portal. How do I configure that?
Navigate to the VPN gateway inside a hub on the portal, then 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 the Azure
Virtual WAN hub (VPN gateway in the virtual hub).
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 (0.0.0.0/0) for 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. A default route does not propagate between hubs (inter-hub).
Is it possible to create multiple virtual WAN hubs in the same region?
Yes. Customers can now create more than one hub in the same region for the same Azure Virtual WAN.
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. Longest prefix match.
2. Local routes over interhub.
3. Static routes over BGP: This is in context to the decision being made by the virtual hub router. However, if the
decision maker is the VPN gateway where a site advertises routes via BGP or provides static address prefixes,
static routes may be preferred over BGP routes.
4. ExpressRoute (ER) over VPN: ER is preferred over VPN when the context is a local hub. Transit connectivity
between ExpressRoute circuits is only available through Global Reach. Therefore, in scenarios where
ExpressRoute circuit is connected to one hub and there is another ExpressRoute circuit connected to a
different hub with VPN connection, VPN may be preferred for inter-hub scenarios.
5. AS path length (Virtual hubs prepend routes with the AS path 65520-65520 when advertising routes to each
other).
Does the Virtual WAN hub allow connectivity between ExpressRoute circuits?
Transit between ER-to-ER is always via Global reach. Virtual hub gateways are deployed in DC or Azure regions.
When two ExpressRoute circuits connect via Global reach, there is no need for the traffic to come all the way
from the edge routers to the virtual hub DC.
Is there a concept of weight in Azure Virtual WAN ExpressRoute circuits or VPN connections
When multiple ExpressRoute circuits are connected to a virtual hub, routing weight on the connection provides a
mechanism for the ExpressRoute in the virtual hub to prefer one circuit over the other. There is no mechanism to
set a weight on a VPN connection. Azure always prefers an ExpressRoute connection over a VPN connection
within a single hub.
Does Virtual WAN prefer ExpressRoute over VPN for traffic egressing Azure
Yes. Virtual WAN prefers ExpressRoute over VPN for traffic egressing Azure.
When a Virtual WAN hub has an ExpressRoute circuit and a VPN Site connected to it, what would cause a
VPN connection route to be preferred over ExpressRoute?
When an ExpressRoute circuit is connected to virtual hub, the Microsoft edge routers are the first node for
communication between on-premises and Azure. These edge routers communicate with the Virtual WAN
ExpressRoute gateways that, in turn, learn routes from the virtual hub router that controls all routes between
any gateways in Virtual WAN. The Microsoft edge routers process virtual hub ExpressRoute routes with higher
preference over routes learned from on-premises.
For any reason, if the VPN connection becomes the primary medium for the virtual hub to learn routes from
(e.g failover scenarios between ExpressRoute and VPN), unless the VPN Site has a longer AS Path length, the
virtual hub will continue to share VPN learned routes with the ExpressRoute gateway. This causes the Microsoft
edge routers to prefer VPN routes over on-premises routes.
When two hubs (hub 1 and 2) are connected and there is an ExpressRoute circuit connected as a bow-tie to
both the hubs, what is the path for a VNet connected to hub 1 to reach a VNet connected in hub 2?
The current behavior is to prefer the ExpressRoute circuit path over hub-to-hub for VNet-to-VNet connectivity.
However, this is not encouraged in a Virtual WAN setup. To resolve this, you can do one of two things:
Configure multiple ExpressRoute circuits (different providers) to connect to one hub and use the hub-to-
hub connectivity provided by Virtual WAN for inter-region traffic flows.
Contact the product team to take part in the gated public preview. In this preview, traffic between the 2
hubs traverses through the Azure Virtual WAN router in each hub and uses a hub-to-hub path instead of
the ExpressRoute path (which traverses through the Microsoft edge routers/MSEE). To use this feature
during preview, email previewpreferh2h@microsoft.com with the Virtual WAN IDs, Subscription ID,
and the Azure region. Expect a response within 48 business hours (Monday-Friday) with confirmation
that the feature is enabled.
Can hubs be created in different resource group in Virtual WAN?
Yes. This option is currently available via PowerShell only. The Virtual WAN portal requires that the hubs are in
the same resource group as the Virtual WAN resource itself.
What is the recommended hub address space during hub creation?
The recommended Virtual WAN hub address space is /23. Virtual WAN hub assigns subnets to various
gateways (ExpressRoute, Site-to-site VPN, Point-to-site VPN, Azure Firewall, Virtual hub Router). For scenarios
where NVAs are deployed inside a virtual hub, a /28 is typically carved out for the NVA instances. However if the
user were to provision multiple NVAs, a /27 subnet may be assigned. Therefore keeping a future architecture in
mind, while Virtual WAN hubs are deployed with a minimum size of /24, the recommended hub address space
at creation time for user to input is /23.
Can you resize or change the address prefixes of a spoke Virtual Network connected to the Virtual WAN
Hub?
No. This is currently not possible. To change the address prefixes of a spoke Virtual Network, please remove the
connection between the spoke Virtual Network and the Virtual WAN hub, modify the address spaces of the
spoke Virtual Network, and then re-create the connection between the spoke Virtual Network and the Virtual
WAN Hub.
Is there support for IPv6 in Virtual WAN?
IPv6 is not supported in the Virtual WAN hub and its gateways. If you have a VNet that has IPv4 and IPv6
support and you would like to connect the VNet to Virtual WAN, this scenario not currently supported.
For the point-to-site User VPN scenario with internet breakout via Azure Firewall, you will likely have to turn off
IPv6 connectivity on your client device to force traffic to the Virtual WAN hub. This is because modern devices,
by default, use IPv6 addresses.
What is the recommended API version to be used by scripts automating various Virtual WAN functionalities?
A minimum version of 05-01-2020 (May 1 2020) is required.
Are there any Virtual WAN limits?
See the Virtual WAN limits section on the Subscription and service limits page.
What are the differences between the Virtual WAN types (Basic and Standard)?
See Basic and Standard Virtual WANs. For pricing, see the Pricing page.
Does Virtual WAN store customer data?
No. Virtual WAN does not store any customer data.
Are there any Managed Service Providers that can manage Virtual WAN for users as a service?
Yes. For a list of Managed Service Provider (MSP) solutions enabled via Azure Marketplace, see Azure
Marketplace offers by Azure Networking MSP partners.
How does Virtual WAN Hub routing differ from Azure Route Server in a VNet?
Both Azure Virtual WAN hub and Azure Route Server provide Border Gateway Protocol (BGP) peering
capabilities that can be utilized by NVAs (Network Virtual Appliance) to advertise IP addresses from the NVA to
the user’s Azure virtual networks. The deployment options differ in the sense that Azure Route Server is typically
deployed by a self-managed customer hub VNet whereas Azure Virtual WAN provides a zero-touch fully
meshed hub service to which customers connect their various spokes end points (Azure VNET, on-premise
branches with Site-to-site VPN or SDWAN, remote users with Point-to-site/Remote User VPN and Private
connections with ExpressRoute) and enjoy BGP Peering for NVAs deployed in spoke VNET along with other
vWAN capabilities such as transit connectivity for VNet-to-VNet , transit connectivity between VPN and
ExpressRoute , custom/advanced routing, custom route association and propagation, routing intent/policies for
no hassle inter-region security, Secure Hub/Azure firewall etc. For more details about Virtual WAN BGP Peering,
please see How to peer BGP with a virtual hub.
If I am using a third-party security provider (Zscaler, iBoss or Checkpoint) to secure my internet traffic, why
don't I see the VPN site associated to the third-party security provider in the Azure portal?
When you choose to deploy a security partner provider to protect Internet access for your users, the third-party
security provider creates a VPN site on your behalf. Because the third-party security provider is created
automatically by the provider and is not a user-created VPN site, this VPN site will not show up in the Azure
portal.
For more information regarding the available options third-party security providers and how to set this up, see
Deploy a security partner provider.
Will BGP communities generated by on-premises be preserved in Virtual WAN?
Yes, BGP communities generated by on-premises will be preserved in Virtual WAN. You can use your own public
ASNs or private ASNs for your on-premises networks. You can't use the ranges reserved by Azure or IANA:
ASNs reserved by Azure:
Public ASNs: 8074, 8075, 12076
Private ASNs: 65515, 65517, 65518, 65519, 65520
ASNs reserved by IANA: 23456, 64496-64511, 65535-65551
In Virtual WAN, what are the estimated performances by ExpressRoute gateway SKU?
C O N N EC T IO N S P ER
SC A L E UN IT SEC O N D M EGA - B IT S P ER SEC O N D PA C K ET S P ER SEC O N D
1 scale unit 14,000 2,000 200,000

(2 instances)
2 scale units 28,000 4,000 400,000

(4 instances)
3 scale units 42,000 6,000 600,000

(6 instances)
4 scale units 56,000 8,000 800,000

(8 instances)
5 scale units 70,000 10,000 1,000,000

(10 instances)
6 scale units 84,000 12,000 1,200,000

(12 instances)
7 scale units 98,000 14,000 1,400,000

(14 instances)
8 scale units 112,000 16,000 1,600,000

(16 instances)
9 scale units 126,000 18,000 1,800,000

(18 instances)
10 scale units 140,000 20,000 2,000,000

(20 instances)
NOTE
*Scale units 2-10, during maintenance operations, maintain aggregate throughput. However, scale unit 1, during a
maintenance operation, may see a slight variation in throughput numbers.
Why am I seeing a message and button called "Update router to latest software version" in portal?
The Virtual WAN team has been working on upgrading virtual routers from their current Cloud Services
infrastructure to Virtual Machine Scale Sets (VMSS) based deployments. This will enable the virtual hub router
to now be availability zone aware and have enhanced scaling out capabilities during high CPU usage. If you
navigate to your Virtual WAN hub resource and see this message and button, then you can upgrade your router
to the lastest version by clicking on the button. The Cloud Services infrastructure will be deprecated soon, so
please migrate by May 31, 2022.
Note that you’ll only be able to update your virtual hub router if all the resources (gateways/route tables/VNET
connections) in your hub are in a succeeded state. Additionally, as this operation requires deployment of new
VMSS based virtual hub routers, you’ll face an expected downtime of 30 minutes per hub. Within a single
Virtual WAN resource, hubs should be updated one at a time instead of updating multiple at the same time.
When the Router Version says “Latest”, then the hub is done updating.
Next steps
For more information about Virtual WAN, see About Virtual WAN.
Network Virtual Appliances in the Virtual WAN hub
Customers can deploy select Network Virtual Appliances directly into the Virtual WAN hub in a solution that is
jointly managed by Microsoft Azure and third-party Network Virtual Appliance vendors. Not all Network Virtual
Appliances in Azure Marketplace can be deployed into the Virtual WAN hub. For a full list of available partners,
please reference the Partners section.
Key benefits
When a Network Virtual Appliance is deployed into the Virtual WAN hub, it can serve as a third-party gateway
with various functionalities. It could serve as an SD-WAN gateway, Firewall or a combination of both.
Deploying Network Virtual Appliances into the Virtual WAN Hub allows customers to enjoy the following
benefits:
Pre-defined and pre-tested selection of infrastructure choices ( NVA Infrastructure Units ) :
Microsoft and the partner work together to validate throughput and bandwidth limits prior to solution being
made available to customers.
Built-in availability and resiliency : Virtual WAN Network Virtual Appliance deployments are Availability
Zone (AZ) aware and are automatically configured to be highly available.
No-hassle provisioning and boot-strapping : A Managed Application is pre-qualified for provisioning
and boot-strapping for the Virtual WAN platform. This Managed Application is available through the Azure
Marketplace link.
Simplified routing : Leverage Virtual WAN's intelligent routing systems. NVA solutions peer with the Virtual
WAN Hub router and participate in the Virtual WAN routing decision process similarly to Microsoft
Gateways.
Integrated suppor t : Partners have a special support agreement with Microsoft Azure Virtual WAN to
quickly diagnose and resolve any customer problems.
Platform-provided lifecycle management : Upgrades and patches are a part of the Azure Virtual WAN
service. This takes away the complexity of lifecycle management from a customer deploying Virtual
Appliance solutions.
Integrated with platform features : Transit connectivity with Microsoft gateways and Virtual Networks,
Encrypted ExpressRoute (SD-WAN overlay running over an ExpressRoute circuit) and Virtual Hub route
tables interact seamlessly.
Partners
The following SD-WAN connectivity Network Virtual Appliances can be deployed in the Virtual WAN hub.
C O N F IGURAT IO N / H O W -
PA RT N ERS TO / DEP LO Y M EN T GUIDE DEDIC AT ED SUP P O RT M O DEL
Barracuda Networks Barracuda CloudGen WAN Yes

Deployment Guide
Cisco Cloud Service Router(CSR) The integration of the Cisco SD-WAN Yes
VWAN solution with Azure virtual WAN
enhances Cloud OnRamp for Multi-
Cloud deployments and enables
configuring Cisco Catalyst 8000V Edge
Software (Cisco Catalyst 8000V) as a
network virtual appliance (NVA) in
Azure Virtual WAN Hubs. View Cisco
SD-WAN Cloud OnRamp, Cisco IOS XE
Release 17.x Configuration Guide
VMware SD-WAN VMware SD-WAN in Virtual WAN Hub Yes

Deployment Guide. The managed
application for deployment can be
found at this Azure Marketplace link.
Versa Networks If you are an existing Versa Networks Yes

customer, log on to your Versa
account and access the deployment
guide using the following link Versa
Deployment Guide. If you are a new
Versa customer, sign-up using the
Versa preview sign-up link.
The following dual-role SD-WAN connectivity and security (Next-Generation Firewall) Network Virtual
Appliances can be deployed in the Virtual WAN hub. These Virtual Appliances can be used to inspect all North-
South, East-West, and Internet-bound traffic.
Fortinet Next-Generation Firewall To access the preview of Fortinet No

(NGFW) NGFW deployed in the Virtual WAN
hub, reach out to
azurevwan@fortinet.com with your
subscription ID. For more information
about the offering, please see the
following Fortinet blog post.
Basic use cases

Any-to -any connectivity
Customers can deploy a Network Virtual Appliance in every Azure region where they have a footprint. Branch
sites are connected to Azure via SD-WAN tunnels terminating on the closest Network Virtual Appliance
deployed in an Azure Virtual WAN Hub.
Branch sites can then access workloads in Azure deployed in Virtual Networks in the same region or other
regions through the Microsoft global-backbone. SD-WAN connected sites can also communicate with other
branches that are connected to Azure via ExpressRoute, Site-to-site VPN or Remote User Connectivity.
Security provided by Azure Firewall along with Connectivity NVA
Customers can deploy a Azure Firewall along side their connectivity-based Network Virtual Appliances. Virtual
WAN routing can be configured to send all traffic to Azure Firewall for inspection. You may also configure
Virtual WAN to send all internet-bound traffic to Azure Firewall for inspection.
Security provided by Network Virtual Appliance Firewalls
Customers can also deploy Network Virtual Appliances into the Virtual WAN Hub that perform both SD-WAN
connectivity and Next-Generation Firewall capabilities. Customers can connect on-premises devices to the
Network Virtual Appliance in the hub and also use the same appliance to inspect all North-South, East-West and
Internet-bound traffic. Routing to enable these scenarios can be configured via Routing Intent and Routing
Policies.
Partners that support these traffic flows are listed as dual-role SD-WAN connectivity and security (Next-
Generation Firewall) Network Vir tual Appliances in the Partners section.
How does it work?
The NVAs that are available to be deployed directly into the Azure Virtual WAN hub are engineered specifically
to be used in the Virtual WAN Hub. The NVA offer is published to Azure Marketplace as a Managed Application,
and customers can deploy the offer directly from Azure Marketplace.
Each partner's NVA offering will have a slightly different experience and functionality based on their deployment
requirements.
Managed Application
All NVA offerings that are available to be deployed into the Virtual WAN hub will have a Managed Application
that is available in Azure Marketplace. Managed Applications allow partners to do the following:
Build a custom deployment experience for their NVA.
Provide a specialized Resource Manager template that allows them to create the NVA directly in the Virtual
WAN hub.
Bill software licensing costs directly, or through Azure Marketplace.
Expose custom properties and resource meters.
NVA Partners may create different resources depending on their appliance deployment, configuration licensing,
and management needs. When a customer creates an NVA in the Virtual WAN hub, like all Managed
Applications, there will be two Resource Groups created in their subscription.
Customer Resource Group - This will contain an application placeholder for the Managed Application.
Partners can use this to expose whatever customer properties they choose here.
Managed Resource Group - Customers cannot configure or change resources in this resource group
directly, as this is controlled by the publisher of the Managed Application. This Resource Group will contain
the NetworkVir tualAppliances resource.
NVA Infrastructure Units

When you create an NVA in the Virtual WAN hub, you must choose the number of NVA Infrastructure Units you
want to deploy it with. An NVA Infrastructure Unit is a unit of aggregate bandwidth capacity for an NVA in
the Virtual WAN hub. An NVA Infrastructure Unit is similar to a VPN Scale Unit in terms of the way you think
about capacity and sizing.
1 NVA Infrastructure Unit represents 500 Mbps of aggregate bandwidth for all branch site connections
coming into this NVA, at a cost of $0.25/hour.
Azure supports from 1-80 NVA Infrastructure Units for a given NVA virtual hub deployment.
Each partner may offer different NVA Infrastructure Unit bundles that are a subset of all supported NVA
Infrastructure Unit configurations.
Similar to VPN Scale Units, if you pick 1 NVA Infrastructure Unit = 500 Mbps, it implies that two instances for
redundancy will be created, each having a maximum throughput of 500 Mbps. For example, if you had five
branches, each doing 10 Mbps at the branch, you will need an aggregate of 50 Mbps at the head end. Planning
for aggregate capacity of the NVA should be done after assessing the capacity needed to support the number of
branches to the hub.
Network Virtual Appliance configuration process

Partners have worked to provide an experience that configures the NVA automatically as part of the deployment
process. Once the NVA has been provisioned into the virtual hub, any additional configuration that may be
required for the NVA must be done via the NVA partners portal or management application. Direct access to the
NVA is not available.
Site and Connection resources with NVAs

Unlike Virtual WAN Site-to-site VPN Gateway configurations, you do not need to create Site resources, Site-to-
Site connection resources, or point-to-site connection resources to connect your branch sites to your NVA
in the Virtual WAN hub.
You still need to create Hub-to-VNet connections to connect your Virtual WAN hub to your Azure virtual
networks as well as connect ExpressRoute, Site-to-site VPN or Remote User VPN connections.
Supported regions
NVA in the virtual hub is available in the following regions:
GEO P O L IT IC A L REGIO N A Z URE REGIO N S
North America Canada Central, Canada East, Central US, East US, East US 2,
South Central US, North Central US, West Central US, West
US, West US 2
South America Brazil South, Brazil Southeast
Europe France Central, France South, Germany North, Germany

West Central, North Europe, Norway East, Norway West,
Switzerland North, Switzerland West, UK South, UK West,
West Europe
Middle East UAE North
Asia East Asia, Japan East, Japan West, Korea Central, Korea
South, Southeast Asia
Australia Australia South East, Australia East, Australia Central,

Australia Central 2
Africa South Africa North
India South India, West India, Central India
NVA FAQ
I am a network appliance partner and want to get our NVA in the hub. Can I join this partner program?
Unfortunately, we do not have capacity to on-board any new partner offers at this time. Check back with us at a
later date!
Can I deploy any NVA from Azure Marketplace into the Virtual WAN hub?
At this time, only Barracuda CloudGen WAN, Cisco Cloud vWAN Application, and VMware Sd-WAN are available
to be deployed into the Virtual WAN hub.
What is the cost of the NVA?
You must purchase a license for the NVA from the NVA vendor. For your Barracuda CloudGen WAN NVA from
Barracuda license, see Barracuda's CloudGen WAN page. Cisco currently only offers BYOL (Bring Your Own
License) licensing model that needs to be procured directly from Cisco. In addition, you will also incur charges
from Microsoft for the NVA Infrastructure Units you consume, and any other resources you use. For more
information, see Pricing Concepts.
Can I deploy an NVA to a Basic hub?
No. You must use a Standard hub if you want to deploy an NVA.
Can I deploy an NVA into a Secure hub?
Yes. Partner NVAs can be deployed into a hub with Azure Firewall.
Can I connect any CPE device in my branch office to Barracuda CloudGen WAN NVA in the hub?
No. Barracuda CloudGen WAN is only compatible with Barracuda CPE devices. To learn more about CloudGen
WAN requirements, see Barracuda's CloudGen WAN page. For Cisco, there are several SD-WAN CPE devices that
are compatible. See Cisco Cloud OnRamp for Multi-Cloud documentation for compatible CPEs.
What routing scenarios are supported with NVA in the hub?
All routing scenarios supported by Virtual WAN are supported with NVAs in the hub.
Next steps
To learn more about Virtual WAN, see the Virtual WAN Overview article.
Virtual WAN partners and virtual hub locations
This article provides information on Virtual WAN supported regions and partners for connectivity into the
Virtual WAN Hub.
There are two types of offerings that make connecting to Azure easier for customers:
Network Vir tual Appliances (NVAs) deployed in the Vir tual WAN Hub : Customers can deploy
Network Virtual Appliances directly into the Virtual WAN hub. This solution is jointly managed by Microsoft
Azure and third-party Network Virtual Appliance solution providers. To learn more about NVAs deployed in
the Virtual WAN Hub reference About NVA in the Virtual WAN Hub.
Branch IPsec connectivity automation : Customers can automatically configure and connect their branch
devices to the Azure Virtual WAN Site-to-site VPN Gateway using IPsec tunnels. These configurations are
typically set up in the device-management UI (or equivalent).
Partners with integrated Virtual Hub offerings

Some partners offer Network Virtual Appliances (NVAs) that can be deployed directly into the Azure Virtual
WAN hub through a solution that is jointly managed by Microsoft Azure and third-party Network Virtual
Appliance solution providers.
When a Network Virtual Appliance is deployed into the Virtual WAN hub, it can serve as a third-party gateway
with various functionalities. It could serve as an SD-WAN gateway, Firewall or a combination of both. For more
information about the benefits of deploying a NVA into the Virtual WAN hub, reference this About NVA in the
Virtual WAN Hub.
The following SD-WAN connectivity Network Virtual Appliances can be deployed in the Virtual WAN hub.
Barracuda Networks Barracuda CloudGen WAN Yes

Deployment Guide
Cisco Cloud Service Router(CSR) The integration of the Cisco SD-WAN Yes
VWAN solution with Azure virtual WAN
enhances Cloud OnRamp for Multi-
Cloud deployments and enables
configuring Cisco Catalyst 8000V Edge
Software (Cisco Catalyst 8000V) as a
network virtual appliance (NVA) in
Azure Virtual WAN Hubs. View Cisco
SD-WAN Cloud OnRamp, Cisco IOS XE
Release 17.x Configuration Guide
VMware SD-WAN VMware SD-WAN in Virtual WAN Hub Yes

Deployment Guide. The managed
application for deployment can be
found at this Azure Marketplace link.
Versa Networks If you are an existing Versa Networks Yes

customer, log on to your Versa
account and access the deployment
guide using the following link Versa
Deployment Guide. If you are a new
Versa customer, sign-up using the
Versa preview sign-up link.
The following dual-role SD-WAN connectivity and security (Next-Generation Firewall) Network Virtual
Appliances can be deployed in the Virtual WAN hub. These Virtual Appliances can be used to inspect all North-
South, East-West, and Internet-bound traffic.
Fortinet Next-Generation Firewall To access the preview of Fortinet No

(NGFW) NGFW deployed in the Virtual WAN
hub, reach out to
azurevwan@fortinet.com with your
subscription ID. For more information
about the offering, please see the
following Fortinet blog post.
Branch IPsec connectivity automation from partners

Devices that connect to Azure Virtual WAN have built-in automation to connect. This is typically set up in the
device-management UI (or equivalent), which sets up the connectivity and configuration management between
the VPN branch device to an Azure Virtual Hub VPN endpoint (VPN gateway).
The following high-level automation is set up in the device console/management center:
Appropriate permissions for the device to access Azure Virtual WAN Resource Group
Uploading of Branch Device into Azure Virtual WAN
Automatic download of Azure connectivity information
Configuration of on-premises branch device
Some connectivity partners may extend the automation to include creating the Azure Virtual Hub VNet and VPN
Gateway. If you want to know more about automation, see Automation guidelines for Virtual WAN partners.
Branch IPsec Connectivity partners

You can check the links in this section for more information about services offered by partners. If your branch
device partner is not listed in the section below, have your branch device provider contact us. They can contact
us by sending an email to azurevirtualwan@microsoft.com.
PA RT N ERS C O N F IGURAT IO N / H O W - TO / DEP LO Y M EN T GUIDE
Barracuda Networks Barracuda CloudGen Firewall: Azure Virtual WAN
Check Point Check Point for the Microsoft Azure Virtual WAN Quick Start
Guide
Cisco Meraki Azure Virtual WAN Cisco Meraki Deployment Guide

PA RT N ERS C O N F IGURAT IO N / H O W - TO / DEP LO Y M EN T GUIDE
Citrix Using Citrix SD-WAN to connect to Microsoft Azure Virtual

WAN
Cloudgenix CloudGenix Azure Virtual WAN CloudBlade Deployment

Guide
Fortinet FortiGate and Microsoft Azure Virtual WAN Integration

deployment guide,Routing Scenario Blog
HPE Aruba Aruba SD-WAN and Microsoft Azure Virtual WAN

Deployment Guide
NetFoundry Netfoundry Support Hub: Azure Virtual WAN
Nuage/Nokia Nuage and Azure Virtual WAN Deployment Guide
Open Systems Open Systems and Azure Virtual WAN Deployment Guide
Palo Alto Networks Palo Alto Networks Azure Virtual WAN Deployment Guide
Riverbed Technology Azure Virtual WAN & SteelConnect EX
Silver-Peak EdgeConnect and Microsoft Azure Virtual WAN Integration

Guide
VMware SD-WAN Azure Virtual WAN VMware SD-WAN Deployment Guide
Versa Configuring Versa SD-WAN and Microsoft Azure vWAN

(Available for registered customers)
* Direct link unavailable. Please contact partner company for support.

The following partners are slated on our roadmap based on a terms sheet signed between the companies
indicating the scope of work to automate IPsec connectivity between the partner device and Azure Virtual WAN
VPN Gateways: 128 Technologies, Arista, F5 Networks, Oracle SD-WAN (Talari), and SharpLink.
Locations
Azure regions within a geopolitical region
Virtual WAN is available for the following regions:
Australia Government Australia Central, Australia Central 2
Europe France Central, France South, Germany North, Germany

West Central, North Europe, Norway East, Switzerland
North, Switzerland West, West Europe, UK West, UK South
North America East US, West US, East US 2, West US 2, Central US, South
Central US, North Central US, West Central US, Canada
Central, Canada East
Asia East Asia, Southeast Asia
India India West, India Central, India South
Japan Japan West, Japan East
Oceania Australia Southeast, Australia East
South Africa South Africa North, South Africa West
South America Brazil South
South Korea Korea Central, Korea South
UAE UAE North, UAE Central
Azure regions and geopolitical boundaries for national clouds

Virtual WAN is available for the following regions:
US Government cloud US Gov Arizona, US Gov Iowa, US Gov Texas, US Gov

Virginia, US DoD Central, US DoD East
China East China East2
China North China North2
Next steps
For more information about Virtual WAN, see the Virtual WAN FAQ.
For more information about how to automate connectivity to Azure Virtual WAN, see Automation
guidelines for Virtual WAN partners.
Automation guidelines for Virtual WAN partners
This article helps you understand how to set up the automation environment to connect and configure a branch
device (a customer on-premises VPN device or SDWAN CPE) for Azure Virtual WAN. If you are a provider that
provides branch devices that can accommodate VPN connectivity over IPsec/IKEv2 or IPsec/IKEv1, this article is
for you.
A branch device (a customer on-premises VPN device or SDWAN CPE) typically uses a controller/device
dashboard to be provisioned. SD-WAN solution administrators can often use a management console to pre-
provision a device before it gets plugged into the network. This VPN capable device gets its control plane logic
from a controller. The VPN Device or SD-WAN controller can use Azure APIs to automate connectivity to Azure
Virtual WAN. This type of connection requires the on-premises device to have an externally facing public IP
address assigned to it.
Before you begin automating

Verify that your device supports IPsec IKEv1/IKEv2. See default policies.
View the REST APIs that you use to automate connectivity to Azure Virtual WAN.
Test out the portal experience of Azure Virtual WAN.
Then, decide which part of the connectivity steps you would like to automate. At a minimum, we
recommend automating:
Access Control
Upload of branch device information into Azure Virtual WAN
Downloading Azure configuration and setting up connectivity from branch device into Azure Virtual
WAN
REST API to automate Virtual Hub creation
REST API to automate Azure VPN gateway for Virtual WAN
REST API to connect a VPNSite to an Azure VPN Hub
Default IPsec policies
Customer experience
Understand the expected customer experience in conjunction with Azure Virtual WAN.
1. Typically, a virtual WAN user will start the process by creating a Virtual WAN resource.
2. The user will set up a service principal-based resource group access for the on-premises system (your
branch controller or VPN device provisioning software) to write branch info into Azure Virtual WAN.
3. The user may decide at this time to log into your UI and set up the service principal credentials. Once that is
complete, your controller should be able to upload branch information with the automation you will provide.
The manual equivalent of this on the Azure side is 'Create Site'.
4. Once the Site (branch device) information is available in Azure, the user will connect the site to a hub. A
virtual hub is a Microsoft-managed virtual network. The hub contains various service endpoints to enable
connectivity from your on-premises network (vpnsite). The hub is the core of your network in a region. There
can only be one hub per Azure region and the vpn endpoint (vpngateway) inside it is created during this
process. The VPN gateway is a scalable gateway which sizes appropriately based on bandwidth and
connection needs. You may choose to automate virtual hub and vpngateway creation from your branch
device controller dashboard.
5. Once the virtual Hub is associated to the site, a configuration file is generated for the user to manually
download. This is where your automation comes in and makes the user experience seamless. Instead of the
user having to manually download and configure the branch device, you can set the automation and provide
minimal click-through experience on your UI, thereby alleviating typical connectivity issues such as shared
key mismatch, IPSec parameter mismatch, configuration file readability etc.
6. At the end of this step in your solution, the user will have a seamless site-to-site connection between the
branch device and virtual hub. You can also set up additional connections across other hubs. Each connection
is an active-active tunnel. Your customer may choose to use a different ISP for each of the links for the tunnel.
7. Consider providing troubleshooting and monitoring capabilities in the CPE management interface. Typical
scenarios include "Customer not able to access Azure resources due to a CPE issue", "Show IPsec parameters
at the CPE side" etc.
Automation details
Access control
Customers must be able to set up appropriate access control for Virtual WAN in the device UI. This is
recommended using an Azure Service Principal. Service principal-based access provides the device controller
appropriate authentication to upload branch information. For more information, see Create service principal.
While this functionality is outside of the Azure Virtual WAN offering, we list below the typical steps taken to set
up access in Azure after which the relevant details are inputted into the device management dashboard
Create an Azure Active Directory application for your on-premises device controller.
Get application ID and authentication key
Get tenant ID
Assign application to role "Contributor"
Upload branch device information
You should design the user experience to upload branch (on-premises site) information to Azure. You can use
REST APIs for VPNSite to create the site information in Virtual WAN. You can provide all branch SDWAN/VPN
devices or select device customizations as appropriate.
Device configuration download and connectivity
This step involves downloading Azure configuration and setting up connectivity from the branch device into
Azure Virtual WAN. In this step, a customer that is not using a provider would manually download the Azure
configuration and apply it to their on-premises SDWAN/VPN device. As a provider, you should automate this
step. View the download REST APIs for additional information. The device controller can call
'GetVpnConfiguration' REST API to download the Azure configuration.
Configuration notes
If Azure VNets are attached to the virtual hub, they will appear as ConnectedSubnets.
VPN connectivity uses route-based configuration and supports both IKEv1, and IKEv2 protocols.
Device configuration file

vpnSiteConnections - This section provides information about the following:
Example:

Example:
IP addresses of the virtual hub vpngateway. Because the vpngateway has each connection
comprising of 2 tunnels in active-active configuration, you will see both IP addresses listed in this
Example:
"Instance0":"104.45.18.186"
"Instance1":"104.45.13.195"
{
},
"Name":"testsite1",
"IPAddress":"73.239.3.208"
},
{
"10.2.0.0/16",
"10.3.0.0/16"
]
},
"IpAddresses":{
"Instance0":"104.45.18.186",
"Instance1":"104.45.13.195"
}
},
"IPsecParameters":{
}
}
}
]
},
{
},
"IPAddress":"66.193.205.122"
},
{
},
"IpAddresses":{
"Instance0":"104.45.18.187",
"Instance1":"104.45.13.195"
}
},
"IPsecParameters":{
}
}
}
]
},
{
},
"IPAddress":"182.71.123.228"
},
{
},
"IpAddresses":{
"Instance0":"104.45.18.187",
"Instance1":"104.45.13.195"
}
},
"IPsecParameters":{
}
}
}
]
}
Connectivity details
Your on-premises SDWAN/VPN device or SD-WAN configuration must match or contain the following
algorithms and parameters, which you specify in the Azure IPsec/IKE policy.
IKE encryption algorithm
IKE integrity algorithm
DH Group
IPsec encryption algorithm
IPsec integrity algorithm
PFS Group
Default policies for IPsec connectivity
NOTE
When working with Default policies, Azure can act as both initiator and responder during an IPsec tunnel setup. While
Virtual WAN VPN supports many algorithm combinations, our recommendation is GCMAES256 for both IPSEC
Encryption and Integrity for optimal performance. AES256 and SHA256 are considered less performant and therefore
performance degradation such as latency and packet drops can be expected for similar algorithm types. For more
information about Virtual WAN, see the Azure Virtual WAN FAQ.
Initiator
The following sections list the supported policy combinations when Azure is the initiator for the tunnel.
Phase-1
AES_256, SHA1, DH_GROUP_2
AES_256, SHA_256, DH_GROUP_2
Phase-2
GCM_AES_256, GCM_AES_256, PFS_NONE
AES_256, SHA_1, PFS_NONE
Responder
The following sections list the supported policy combinations when Azure is the responder for the tunnel.
Phase-1
Phase-2
AES_256, SHA_1, PFS_1
AES_256, SHA_256, PFS_1
AES_256, SHA_256, PFS_2
AES_256, SHA_256, PFS_14
AES_256, SHA_256, PFS_24
AES_128, SHA_256, PFS_1
AES_128, SHA_256, PFS_2
AES_128, SHA_256, PFS_14
Custom policies for IPsec connectivity
When working with custom IPsec policies, keep in mind the following requirements:
IKE - For IKE, you can select any parameter from IKE Encryption, plus any parameter from IKE Integrity, plus
any parameter from DH Group.
IPsec - For IPsec, you can select any parameter from IPsec Encryption, plus any parameter from IPsec
Integrity, plus PFS. If any of the parameters for IPsec Encryption or IPsec Integrity is GCM, then the
parameters for both settings must be GCM.
NOTE
With Custom IPsec policies, there is no concept of responder and initiator (unlike Default IPsec policies). Both sides (on-
premises and Azure VPN gateway) will use the same settings for IKE Phase 1 and IKE Phase 2. Both IKEv1 and IKEv2
protocols are supported.
Available settings and parameters
SET T IN G PA RA M ET ERS
IKE Encryption GCMAES256, GCMAES128, AES256, AES128
IKE Integrity SHA384, SHA256
DH Group ECP384, ECP256, DHGroup24, DHGroup14
IPsec Encryption GCMAES256, GCMAES128, AES256, AES128, None
IPsec Integrity GCMAES256, GCMAES128, SHA256
PFS Group ECP384, ECP256, PFS24, PFS14, None
SA Lifetime integer; min. 300/ default 3600 seconds
Next steps
For more information about Virtual WAN, see About Azure Virtual WAN and the Azure Virtual WAN FAQ.
For any additional information, please send an email to azurevirtualwan@microsoft.com. Include your company
name in “[ ]” in the subject line.
Migrate to Azure Virtual WAN
Azure Virtual WAN lets companies simplify their global connectivity in order to benefit from the scale of the
Microsoft global network. This article provides technical details for companies that want to migrate from an
existing customer-managed hub-and-spoke topology, to a design that leverages Microsoft-managed Virtual
WAN hubs.
For information about the benefits that Azure Virtual WAN enables for enterprises adopting a cloud-centric
modern enterprise global network, see Global transit network architecture and Virtual WAN.
Figure: Azure Vir tual WAN

The Azure hub-and-spoke connectivity model has been adopted by thousands of our customers to leverage the
default transitive routing behavior of Azure Networking in order to build simple and scalable cloud networks.
Azure Virtual WAN builds on these concepts and introduces new capabilities that allow global connectivity
topologies, not only between on-premises locations and Azure, but also allowing customers to leverage the
scale of the Microsoft network to augment their existing global networks.
This article shows how to migrate an existing customer-managed hub-and-spoke environment, to a topology
that is based on Azure Virtual WAN.
Scenario
Contoso is a global financial organization with offices in both Europe and Asia. They are planning to move their
existing applications from an on-premises data center in to Azure and have built out a foundation design based
on the customer-managed hub-and-spoke architecture, including regional hub virtual networks for hybrid
connectivity. As part of the move to cloud-based technologies, the network team have been tasked with
ensuring that their connectivity is optimized for the business moving forward.
The following figure shows a high-level view of the existing global network including connectivity to multiple
Azure regions.
Figure: Contoso existing network topology
The following points can be understood from the existing network topology:
A hub-and-spoke topology is used in multiple regions including ExpressRoute circuits for connectivity
back to a common private Wide Area Network (WAN).
Some of these sites also have VPN tunnels directly in to Azure to reach applications hosted within the
cloud.
Requirements
The networking team have been tasked with delivering a global network model that can support the Contoso
migration to the cloud and must optimize in the areas of cost, scale, and performance. In summary, the
following requirements are to be met:
Provide both head quarter (HQ) and branch offices with optimized path to cloud hosted applications.
Remove the reliance on existing on-premises data centers (DC) for VPN termination while retaining the
following connectivity paths:
Branch-to-VNet : VPN connected offices must be able to access applications migrated to the cloud in
the local Azure region.
Branch-to-Hub to Hub-to-VNet : VPN connected offices must be able to access applications
migrated to the cloud in the remote Azure region.
Branch-to-branch : Regional VPN connected offices must be able to communicate with each other
and ExpressRoute connected HQ/DC sites.
Branch-to-Hub to Hub-to-branch : Globally separated VPN connected offices must be able to
communicate with each other and any ExpressRoute connected HQ/DC sites.
Branch-to-Internet : Connected sites must be able to communicate with the Internet. This traffic
must be filtered and logged.
VNet-to-VNet : Spoke virtual networks in the same region must be able to communicate with each
other.
VNet-to-Hub to Hub-to-VNet : Spoke virtual networks in the different regions must be able to
communicate with each other.
Provide the ability for Contoso roaming users (laptop and phone) to access company resources while not on
the corporate network.
Azure Virtual WAN architecture

The following figure shows a high-level view of the updated target topology using Azure Virtual WAN to meet
the requirements detailed in the previous section.
Figure: Azure Vir tual WAN architecture

Summary:
HQ in Europe remains ExpressRoute connected, Europe on-premises DC are fully migrated to Azure and now
decommissioned.
Asia DC and HQ remain connected to Private WAN. Azure Virtual WAN now used to augment the local carrier
network and provide global connectivity.
Azure Virtual WAN hubs deployed in both West Europe and South East Asia Azure regions to provide
connectivity hub for ExpressRoute and VPN connected devices.
Hubs also provide VPN termination for roaming users across multiple client types using OpenVPN
connectivity to the global mesh network, allowing access to not only applications migrated to Azure, but also
any resources remaining on-premises.
Internet connectivity for resources within a virtual network provided by Azure Virtual WAN.
Internet connectivity for remote sites also provided by Azure Virtual WAN. Local internet breakout supported via
partner integration for optimized access to SaaS services such as Microsoft 365.
Migrate to Virtual WAN

This section shows the various steps for migrating to Azure Virtual WAN.
Step 1: Single region customer-managed hub-and-spoke
The following figure shows a single region topology for Contoso prior to the rollout of Azure Virtual WAN:
Figure 1: Single region manual hub-and-spoke
In keeping with the hub-and-spoke approach, the customer-managed hub virtual network contains several
function blocks:
Shared services (any common function required by multiple spokes). Example: Contoso uses Windows
Server domain controllers on Infrastructure-as-a-service (IaaS) virtual machines.
IP/Routing firewall services are provided by a third-party network virtual appliance, enabling spoke-to-spoke
layer-3 IP routing.
Internet ingress/egress services including Azure Application Gateway for inbound HTTPS requests and third-
party proxy services running on virtual machines for filtered outbound access to internet resources.
ExpressRoute and VPN virtual network gateway for connectivity to on-premises networks.
Step 2: Deploy Virtual WAN hubs
Deploy a Virtual WAN hub in each region. Set up the Virtual WAN hub with VPN and ExpressRoute functionality
as described in the following articles:
Tutorial: Create a Site-to-Site connection using Azure Virtual WAN
Tutorial: Create an ExpressRoute association using Azure Virtual WAN
NOTE
Azure Virtual WAN must be using the Standard SKU to enable some of the traffic paths shown in this article.
Figure 2: Customer-managed hub-and-spoke to Vir tual WAN migration
Step 3: Connect remote sites (ExpressRoute and VPN ) to Virtual WAN
Connect the Virtual WAN hub to the existing ExpressRoute circuits and set up Site-to-site VPNs over the Internet
to any remote branches.

At this point, on-premises network equipment will begin to receive routes reflecting the IP address space
assigned to the Virtual WAN-managed hub VNet. Remote VPN-connected branches at this stage will see two
paths to any existing applications in the spoke virtual networks. These devices should be configured to continue
to use the tunnel to the customer-managed hub to ensure symmetrical routing during the transition phase.
Step 4: Test hybrid connectivity via Virtual WAN
Prior to using the managed Virtual WAN hub for production connectivity, we recommend that you set up a test
spoke virtual network and Virtual WAN VNet connection. Validate that connections to this test environment
work via ExpressRoute and Site to Site VPN before continuing with the next steps.
At this stage, it is important to recognize that both the original customer-managed hub virtual network and the
new Virtual WAN Hub are both connected to the same ExpressRoute circuit. Due to this, we have a traffic path
that can be used to enable spokes in both environments to communicate. For example, traffic from a spoke that
is attached to the customer-managed hub virtual network will traverse the MSEE devices used for the
ExpressRoute circuit to reach any spoke connected via a VNet connection to the new Virtual WAN hub. This
allows a staged migration of spokes in Step 5.
Step 5: Transition connectivity to virtual WAN hub

a . Delete the existing peering connections from Spoke virtual networks to the old customer-managed hub.
Access to applications in spoke virtual networks is unavailable until steps a-c are complete.
b . Connect the spoke virtual networks to the Virtual WAN hub via VNet connections.
c . Remove any user-defined routes (UDR) previously used within spoke virtual networks for spoke-to-spoke
communications. This path is now enabled by dynamic routing available within the Virtual WAN hub.
d . Existing ExpressRoute and VPN Gateways in the customer-managed hub are now decommissioned to permit
the next step (e).
e . Connect the old customer-managed hub (hub virtual network) to the Virtual WAN hub via a new VNet
connection.
Step 6: Old hub becomes shared services spoke
We have now redesigned our Azure network to make the Virtual WAN hub the central point in our new
topology.

Because the Virtual WAN hub is a managed entity and does not allow deployment of custom resources such as
virtual machines, the shared services block now exists as a spoke virtual network and hosts functions such as
internet ingress via Azure Application Gateway or network virtualized appliance. Traffic between the shared
services environment and backend virtual machines now transits the Virtual WAN-managed hub.
Step 7: Optimize on-premises connectivity to fully utilize Virtual WAN
At this stage, Contoso has mostly completed their migrations of business applications in into the Microsoft
Cloud, with only a few legacy applications remaining within the on-premises DC.

To leverage the full functionality of Azure Virtual WAN, Contoso decides to decommission their legacy on-
premises VPN connections. Any branches continuing to access HQ or DC networks are able to transit the
Microsoft global network using the built-in transit routing of Azure Virtual WAN.
NOTE
ExpressRoute Global Reach is required for customers that want to leverage the Microsoft backbone to provide
ExpressRoute to ExpressRoute transit (not shown Figure 7.).
End-state architecture and traffic paths
Figure: Dual region Vir tual WAN

This section provides a summary of how this topology meets the original requirements by looking at some
example traffic flows.
Path 1
Path 1 shows traffic flow from a S2S VPN connected branch in Asia to an Azure VNet in the South East Asia
region.
The traffic is routed as follows:
Asia branch is connected via resilient S2S BGP enabled tunnels into South East Asia Virtual WAN hub.
Asia Virtual WAN hub routes traffic locally to connected VNet.
Path 2
Path 2 shows traffic flow from the ExpressRoute connected European HQ to an Azure VNet in the South East
Asia region.
European HQ is connected via ExpressRoute circuit into West Europe Virtual WAN hub.
Virtual WAN hub-to-hub global connectivity enables transit of traffic to VNet connected in remote region.
Path 3
Path 3 shows traffic flow from the Asia on-premises DC connected to Private WAN to a European S2S connected
Branch.
Asia DC is connected to local Private WAN carrier.
ExpressRoute circuit locally terminates in Private WAN connects to the South East Asia Virtual WAN hub.
Virtual WAN hub-to-hub global connectivity enables transit of traffic.
Path 4
Path 4 shows traffic flow from an Azure VNet in South East Asia region to an Azure VNet in West Europe region.
Virtual WAN hub-to-hub global connectivity enables native transit of all connected Azure VNets without
further user config.
Path 5
Path 5 shows traffic flow from roaming VPN (P2S) users to an Azure VNet in the West Europe region.
Laptop and mobile device users use the OpenVPN client for transparent connectivity in to the P2S VPN
gateway in West Europe.
West Europe Virtual WAN hub routes traffic locally to connected VNet.
Security and policy control via Azure Firewall
Contoso has now validated connectivity between all branches and VNets in line with the requirements discussed
earlier in this article. To meet their requirements for security control and network isolation, they need to
continue to separate and log traffic via the hub network. Previously this function was performed by a network
virtual appliance (NVA). Contoso also wants to decommission their existing proxy services and utilize native
Azure services for outbound Internet filtering.
Figure: Azure Firewall in Vir tual WAN (Secured Vir tual hub)
The following high-level steps are required to introduce Azure Firewall into the Virtual WAN hubs to enable a
unified point of policy control. For more information about this process and the concept of Secure Virtual Hubs,
see Azure Firewall Manager.
1. Create Azure Firewall policy.
2. Link firewall policy to Azure Virtual WAN hub. This step allows the existing Virtual WAN hub to function as a
secured virtual hub, and deploys the required Azure Firewall resources.
NOTE
There are constraints relating to use of secured virtual hubs, including inter-region traffic. For more information, see
Firewall Manager - known issues.
The following paths show the connectivity paths enabled by using Azure secured virtual hubs:
Path 6
Path 6 shows secure traffic flow between VNets within the same region.
Virtual Networks connected to the same Secured Virtual Hub now route traffic to via the Azure Firewall.
Azure Firewall can apply policy to these flows.
Path 7
Path 7 shows traffic flow from an Azure VNet to the Internet or third-party Security Service.
Virtual Networks connected to the Secure Virtual Hub can send traffic to public, destinations on the
Internet, using the Secure Hub as a central point of Internet access.
This traffic can be filtered locally using Azure Firewall FQDN rules, or sent to a third-party security service
for inspection.
Path 8
Path 8 shows traffic flow from branch-to-Internet or third-party Security Service.
Branches connected to the Secure Virtual Hub can send traffic to public destinations on the Internet by
using the Secure Hub as a central point of Internet access.
This traffic can be filtered locally using Azure Firewall FQDN rules, or sent to a third-party security service
for inspection.
Next steps
Learn more about Azure Virtual WAN.
Global transit network architecture and Virtual WAN
Modern enterprises require ubiquitous connectivity between hyper-distributed applications, data, and users
across the cloud and on-premises. Global transit network architecture is being adopted by enterprises to
consolidate, connect, and control the cloud-centric modern, global enterprise IT footprint.
The global transit network architecture is based on a classic hub-and-spoke connectivity model where the cloud
hosted network 'hub' enables transitive connectivity between endpoints that may be distributed across different
types of 'spokes'.
In this model, a spoke can be:
Virtual network (VNets)
Physical branch site
Remote user
Internet
Figure 1: Global transit hub-and-spoke network

Figure 1 shows the logical view of the global transit network where geographically distributed users, physical
sites, and VNets are interconnected via a networking hub hosted in the cloud. This architecture enables logical
one-hop transit connectivity between the networking endpoints.
Global transit network with Virtual WAN

Azure Virtual WAN is a Microsoft-managed cloud networking service. All the networking components that this
service is composed of are hosted and managed by Microsoft. For more information about Virtual WAN, see the
Virtual WAN Overview article.
Azure Virtual WAN allows a global transit network architecture by enabling ubiquitous, any-to-any connectivity
between globally distributed sets of cloud workloads in VNets, branch sites, SaaS and PaaS applications, and
users.
Figure 2: Global transit network and Vir tual WAN

In the Azure Virtual WAN architecture, virtual WAN hubs are provisioned in Azure regions, to which you can
choose to connect your branches, VNets, and remote users. The physical branch sites are connected to the hub
by Premium or Standard ExpressRoute or site-to site-VPNs, VNets are connected to the hub by VNet
connections, and remote users can directly connect to the hub using User VPN (point-to-site VPNs). Virtual WAN
also supports cross-region VNet connection where a VNet in one region can be connected to a virtual WAN hub
in a different region.
You can establish a virtual WAN by creating a single virtual WAN hub in the region that has the largest number
of spokes (branches, VNets, users), and then connecting the spokes that are in other regions to the hub. This is a
good option when an enterprise footprint is mostly in one region with a few remote spokes.
Hub-to-hub connectivity
An Enterprise cloud footprint can span multiple cloud regions and it is optimal (latency-wise) to access the cloud
from a region closest to their physical site and users. One of the key principles of global transit network
architecture is to enable cross-region connectivity between all cloud and on-premises network endpoints. This
means that traffic from a branch that is connected to the cloud in one region can reach another branch or a
VNet in a different region using hub-to-hub connectivity enabled by Azure Global Network.
Figure 3: Vir tual 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.
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 later in this article.
Any-to-any connectivity
Global transit network architecture enables any-to-any connectivity via virtual WAN hubs. This architecture
eliminates or reduces the need for full mesh or partial mesh connectivity between spokes, that are more
complex to build and maintain. In addition, routing control in hub-and-spoke vs. mesh networks is easier to
configure and maintain.
Any-to-any connectivity (in the context of a global architecture) allows an enterprise with globally distributed
users, branches, datacenters, VNets, and applications to connect to each other through the “transit” hub(s). Azure
Virtual WAN acts as the global transit system.
Figure 4: Vir tual WAN traffic paths
Azure Virtual WAN supports the following global transit connectivity paths. The letters in parentheses map to
Figure 4.
Branch-to-VNet (a)
Branch-to-branch (b)
ExpressRoute Global Reach and Virtual WAN
Remote User-to-VNet (c)
Remote User-to-branch (d)
VNet-to-VNet (e)
Branch-to-hub-hub-to-Branch (f)
Branch-to-hub-hub-to-VNet (g)
VNet-to-hub-hub-to-VNet (h)
Branch-to -VNet (a) and Branch-to -VNet Cross-region (g)
Branch-to-VNet is the primary path supported by Azure Virtual WAN. This path allows you to connect branches
to Azure IAAS enterprise workloads that are deployed in Azure VNets. Branches can be connected to the virtual
WAN via ExpressRoute or site-to-site VPN. The traffic transits to VNets that are connected to the virtual WAN
hubs via VNet Connections. Explicit gateway transit is not required for Virtual WAN because Virtual WAN
automatically enables gateway transit to branch site. See Virtual WAN Partners article on how to connect an SD-
WAN CPE to Virtual WAN.
ExpressRoute Global Reach and Virtual WAN
ExpressRoute is a private and resilient way to connect your on-premises networks to the Microsoft Cloud.
Virtual WAN supports Express Route circuit connections. Connecting a branch site to Virtual WAN with Express
Route requires 1) Premium or Standard Circuit 2) Circuit to be in a Global Reach enabled location.
ExpressRoute Global Reach is an add-on feature for ExpressRoute. With Global Reach, you can link ExpressRoute
circuits together to make a private network between your on-premises networks. Branches that are connected to
Azure Virtual WAN using ExpressRoute require the ExpressRoute Global Reach to communicate with each other.
In this model, each branch that is connected to the virtual WAN hub using ExpressRoute can connect to VNets
using the branch-to-VNet path. Branch-to-branch traffic won't transit the hub because ExpressRoute Global
Reach enables a more optimal path over Azure WAN.
Branch-to -branch (b) and Branch-to -Branch cross-region (f )
Branches can be connected to an Azure virtual WAN hub using ExpressRoute circuits and/or site-to-site VPN
connections. You can connect the branches to the virtual WAN hub that is in the region closest to the branch.
This option lets enterprises leverage the Azure backbone to connect branches. However, even though this
capability is available, you should weigh the benefits of connecting branches over Azure Virtual WAN vs. using a
private WAN.
NOTE
Disabling Branch-to-Branch Connectivity in Virtual WAN - Virtual WAN can be configured to disable Branch-to-Branch
connectivity. This configuation 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 propogation and connectivity. To configure
this setting using Azure Portal: Under Virtual WAN Configuration menu, Choose Setting: Branch-to-Branch - Disabled.
Remote User-to -VNet (c)

You can enable direct, secure remote access to Azure using point-to-site connection from a remote user client to
a virtual WAN. Enterprise remote users no longer have to hairpin to the cloud using a corporate VPN.
Remote User-to -branch (d)
The Remote User-to-branch path lets remote users who are using a point-to-site connection to Azure access on-
premises workloads and applications by transiting through the cloud. This path gives remote users the flexibility
to access workloads that are both deployed in Azure and on-premises. Enterprises can enable central cloud-
based secure remote access service in Azure Virtual WAN.
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 is not necessary.
Force tunneling and default route

Force Tunneling can be enabled by configuring the enable default route on a VPN, ExpressRoute, or Virtual
Network connection in Virtual WAN.
A virtual hub propagates a learned default route to a virtual network/site-to-site VPN/ExpressRoute connection
if enable default 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.
Security and policy control

The Azure Virtual WAN hubs interconnect all the networking end points across the hybrid network and
potentially see all transit network traffic. Virtual WAN hubs can be converted to Secured Virtual Hubs by
deploying the Azure Firewall inside VWAN hubs to enable cloud-based security, access, and policy control.
Orchestration of Azure Firewalls in virtual WAN hubs can be performed by Azure Firewall Manager.
Azure Firewall Manager provides the capabilities to manage and scale security for global transit networks. Azure
Firewall Manager provides ability to centrally manage routing, global policy management, advanced Internet
security services via third-party along with the Azure Firewall.
Figure 5: Secured vir tual hub with Azure Firewall

Azure Firewall to the virtual WAN supports the following global secured transit connectivity paths. The letters in
parentheses map to Figure 5.
VNet-to-VNet secure transit (e)
VNet-to-Internet or third-party Security Service (i)
Branch-to-Internet or third-party Security Service ( j)
VNet-to -VNet secured transit (e )
The VNet-to-VNet secured transit enables VNets to connect to each other via the Azure Firewall in the virtual
WAN hub.
VNet-to -Internet or third-party Security Service (i)
The VNet-to-Internet enables VNets to connect to the internet via the Azure Firewall in the virtual WAN hub.
Traffic to internet via supported third-party security services does not flow through the Azure Firewall. 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)
The Branch-to-Internet enables branches to connect to the internet via the Azure Firewall in the virtual WAN
hub. Traffic to internet via supported third-party security services does not flow through the Azure Firewall. You
can configure Branch-to-Internet path via supported third-party security service using Azure Firewall Manager.
Branch-to -branch secured transit cross-region (f )
Branches can be connected to a secured virtual hub with Azure Firewall using ExpressRoute circuits and/or site-
to-site VPN connections. You can connect the branches to the virtual WAN hub that is in the region closest to the
branch.
This option lets enterprises leverage the Azure backbone to connect branches. However, even though this
capability is available, you should weigh the benefits of connecting branches over Azure Virtual WAN vs. using a
private WAN.
NOTE
Inter-hub processing of traffic via firewall is currently not supported. Traffic between hubs will be routed to the proper
branch within the secured virtual hub, however traffic will bypass the Azure Firewall in each hub.
Branch-to -VNet secured transit (g)

The Branch-to-VNet secured transit enables branches to communicate with virtual networks in the same region
as the virtual WAN hub as well as another virtual network connected to another virtual WAN hub in another
region.
NOTE
Inter-hub with firewall is currently not supported. Traffic between hubs will move directly bypassing the Azure Firewall in
each hub. Traffic via a connection destined to a virtual network in the same region will be processed by the Azure Firewall
in the secured hub.
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.
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.
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.
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.
Next steps
Create a connection using Virtual WAN and Deploy Azure Firewall in VWAN hub(s).
Site-to-site connections using Virtual WAN
ExpressRoute connections using Virtual WAN
Azure Firewall Manager to Deploy Azure FW in VWAN
SD-WAN connectivity architecture with Azure
Virtual WAN
Azure Virtual WAN is a networking service that brings together many cloud connectivity and security services
with a single operational interface. These services include branch (via Site-to-site VPN), remote user (Point-to-
site VPN), private (ExpressRoute) connectivity, intra-cloud transitive connectivity for VNets, VPN and
ExpressRoute interconnectivity, routing, Azure Firewall, and encryption for private connectivity.
Although Azure Virtual WAN is a cloud-based SD-WAN that provides a rich suite of Azure first-party
connectivity, routing, and security services, Azure Virtual WAN also is designed to enable seamless
interconnection with premises-based SD-WAN and SASE technologies and services. Many such services are
offered by our Virtual WAN ecosystem and Azure Networking Managed Services partners (MSPs). Enterprises
that are transforming their private WAN to SD-WAN have options when interconnecting their private SD-WAN
with Azure Virtual WAN. Enterprises can choose from these options:
Direct Interconnect model
Direct Interconnect model with NVA-in-VWAN-hub
Indirect Interconnect model
Managed Hybrid WAN model using their favorite managed service provider MSP
In all of these cases, the interconnection of Virtual WAN with SD-WAN is similar from the connectivity side, but
may vary on the orchestration and operational side.
Direct Interconnect model
In this architecture model, the SD-WAN branch customer-premises equipment (CPE) is directly connected to
Virtual WAN hubs via IPsec connections. The branch CPE may also be connected to other branches via the
private SD-WAN, or use Virtual WAN for branch to branch connectivity. Branches that need to access their
workloads in Azure will be able to directly and securely access Azure via the IPsec tunnel(s) that are terminated
in the Virtual WAN hub(s).
SD-WAN CPE partners can enable automation in order to automate the normally tedious and error-prone IPsec
connectivity from their respective CPE devices. Automation allows the SD-WAN controller to talk to Azure via
the Virtual WAN API to configure the Virtual WAN sites, and push necessary IPsec tunnel configuration to the
branch CPEs. See Automation guidelines for the description of Virtual WAN interconnection automation by
various SD-WAN partners.
The SD-WAN CPE continues to be the place where traffic optimization and path selection is implemented and
enforced.
In this model, some vendor proprietary traffic optimization based on real-time traffic characteristics may not be
supported because the connectivity to Virtual WAN is over IPsec and the IPsec VPN is terminated on the Virtual
WAN VPN gateway. For example, dynamic path selection at the branch CPE is feasible due to the branch device
exchanging various network packet information with another SD-WAN node, hence identifying the best link to
use for various prioritized traffic dynamically at the branch. This feature may be useful in areas where last mile
optimization (branch to the closest Microsoft POP) is required.
With Virtual WAN, users can get Azure Path Selection, which is policy-based path selection across multiple ISP
links from the branch CPE to Virtual WAN VPN gateways. Virtual WAN allows for the setup of multiple links
(paths) from the same SD-WAN branch CPE; each link represents a dual tunnel connection from a unique public
IP of the SD-WAN CPE to two different instances of Azure Virtual WAN VPN gateway. SD-WAN vendors can
implement the most optimal path to Azure, based on traffic policies set by their policy engine on the CPE links.
On the Azure end, all connections coming in are treated equally.
Direct Interconnect model with NVA-in-VWAN-hub
This architecture model supports the deployment of a third-party Network Virtual Appliance (NVA) directly into
the virtual hub. This allows customers who want to connect their branch CPE to the same brand NVA in the
virtual hub so that they can take advantage of proprietary end-to-end SD-WAN capabilities when connecting to
Azure workloads.
Several Virtual WAN Partners have worked to provide an experience that configures the NVA automatically as
part of the deployment process. Once the NVA has been provisioned into the virtual hub, any additional
configuration that may be required for the NVA must be done via the NVA partners portal or management
application. Direct access to the NVA isn't available. The NVAs that are available to be deployed directly into the
Azure Virtual WAN hub are engineered specifically to be used in the virtual hub. For partners that support NVA
in VWAN hub and their deployment guides, please see the Virtual WAN Partners article.
The SD-WAN CPE continues to be the place where traffic optimization and path selection is implemented and
enforced. In this model, vendor proprietary traffic optimization based on real-time traffic characteristics is
supported because the connectivity to Virtual WAN is via the SD-WAN NVA in the hub.
Indirect Interconnect model
In this architecture model, SD-WAN branch CPEs are indirectly connected to Virtual WAN hubs. As the figure
shows, an SD-WAN virtual CPE is deployed in an enterprise VNet. This virtual CPE is, in turn, connected to the
Virtual WAN hub(s) using IPsec. The virtual CPE serves as an SD-WAN gateway into Azure. Branches that need
to access their workloads in Azure will be able access them via the v-CPE gateway.
Since the connectivity to Azure is via the v-CPE gateway (NVA), all traffic to and from Azure workload VNets to
other SD-WAN branches go via the NVA. In this model, the user is responsible for managing and operating the
SD-WAN NVA including high availability, scalability, and routing.
Managed Hybrid WAN model

In this architecture model, enterprises can leverage a managed SD-WAN service offered by a Managed Service
Provider (MSP) partner. This model is similar to the direct or indirect models described above. However, in this
model, the SD-WAN design, orchestration, and operations are delivered by the SD-WAN Provider.
Azure Networking MSP partners can use Azure Lighthouse to implement the SD-WAN and Virtual WAN service
in the enterprise customer’s Azure subscription, as well as operate the end-to-end hybrid WAN on behalf of the
customer. These MSPs may also be able to implement Azure ExpressRoute into the Virtual WAN and operate it
as an end-to-end managed service.
Azure Virtual WAN FAQ
Solving Remote Connectivity
Interconnect with China using Azure Virtual WAN
and Secure Hub
When looking at common automotive, manufacturing, logistics industries, or other institutes like embassies,
there is often the question about how to improve interconnection with China. Those improvements are mostly
relevant for using Cloud Services like Microsoft 365, Azure Global Services, or interconnect branches inside of
China with a customer backbone.
In most of the cases, customers are struggling with high latencies, low bandwidth, unstable connection, and high
costs connecting to outside of China (for example, Europe or the United States).
A reason for these struggles is the "Great Firewall of China", which protects the Chinese part of the Internet and
filters traffic to China. Nearly all traffic running from People's Republic of China to outside of China, except the
special administration zones like Hong Kong and Macau, passes the Great Firewall. The traffic running through
Hong Kong and Macau does not hit the Great Firewall in full force, it is handled by a subset of the Great Firewall.
Using Virtual WAN, a customer can establish a more performant and stable connection to Microsoft Cloud
Services and a connection to their enterprise network without breaking the Chinese cybersecurity law.
Requirements and workflow
If you want to stay compliant to the Chinese cybersecurity law, you need to meet a set of certain conditions.
First, you need to work together with a network and ISP who owns an ICP (Internet Content Provider) license for
China. In most cases, you'll end up with one of the following providers:
China Telecom Global Ltd.
China Mobile Ltd.
China Unicom Ltd.
PCCW Global Ltd.
Hong Kong Telecom Ltd.
Depending on the provider and your needs, you now need to purchase one of the following network
connectivity services to interconnect your branches within China.
A MPLS/IPVPN Network
A Software Defined WAN (SDWAN)
Dedicated Internet Access
Next, you need to agree with that provider to give a breakout to the Microsoft Global Network and its Edge
Network in Hong Kong, not in Beijing or Shanghai. In this case, Hong Kong is very important because of its
physical connection and location to China.
While most customers think using Singapore for interconnect is the best case because it looks nearer to China
when looking on the map, this is not true. When you follow network fiber maps, nearly all network connects go
through Beijing, Shanghai, and Hong Kong. This makes Hong Kong a better location choice to interconnect to
China.
Depending on the provider, you may get different service offerings. The table below shows an example of
providers and the service they offer, based on information at the time this article was written.
SERVIC E P RO VIDER EXA M P L ES
MPLS/IPVPN Network PCCW, China Telecom Global
SDWAN PCCW, China Telecom Global
Dedicated Internet Access PCCW, Hong Kong Telecom, China Mobil
With your provider, you can agree on which of the following two solutions to use to reach the Microsoft global
backbone:
Getting a Microsoft Azure ExpressRoute terminated in Hong Kong. That would be the case for the use of
MPLS/IPVPN. Currently, only the only ICP license provider with ExpressRoute to Hong Kong is China
Telecom Global. However, they can also talk to the other providers if they leverage Cloud Exchange
Providers like Megaport or InterCloud. For more information, see ExpressRoute connectivity providers.
Using a Dedicated Internet Access directly at one of the following Internet Exchange Points, or using a
private network interconnect.
The following list shows Internet Exchanges possible in Hong Kong:
AMS-IX Hong Kong
BBIX Hong Kong
Equinix Hong Kong
HKIX
When using this connect, your next BGP hop for Microsoft Services must be Microsoft Autonomous System
Number (AS#) 8075. If you use a single location or SDWAN solution, that would be the choice of connection.
With the current changes regarding interconnects between China and Hong Kong SAR, most of these network
providers build an MPLS bridge between China and Hong Kong SAR.
You can see that site-to-site VPN connections inside China are allowed and are mostly stable. The same applies
for the site-to-site connections between branches in the rest of the world. Providers now create a VPN/SDWAN
Aggregation on both sides and bridge via MPLS between them.
Either way, we still recommend that you have a second and regular internet breakout into China. This is to split
the traffic between enterprise traffic to cloud services like Microsoft 365 and Azure, and by-law regulated
internet traffic.
A compliant network architecture within China could look like the following example:
In this example, having an interconnect with the Microsoft Global Network in Hong Kong, you can now start to
leverage the Azure Virtual WAN Global Transit Architecture and additional services, like Azure secure Virtual
WAN hub, in order to consume services and interconnect to your branches and datacenter outside China.
Hub-to-hub communication
In this section, we use Virtual WAN hub-to-hub communication to interconnect. In this scenario, you create a
new Virtual WAN hub resource to connect to a Virtual WAN hub in Hong Kong, other regions you prefer, a
region where you already have Azure resources, or where want to connect.
A sample architecture could look like following example:
In this example, the China branches connect to Azure Cloud China and each other by using VPN or MPLS
connections. Branches that need to be connected to Global Services use MPLS or Internet-based services that
are connected directly to Hong Kong. If you want to use ExpressRoute in Hong Kong as well as in the other
region, you need to configure ExpressRoute Global Reach to interconnect both ExpressRoute Circuits.
ExpressRoute Global Reach is not available in some regions. If you need to interconnect with Brazil or India, for
example, you need to leverage Cloud Exchange Providers to provide the routing services.
The figure below shows both examples for this scenario.
Secure Internet breakout for Microsoft 365
Another consideration is network security as well as logging for the entry point between China and the Virtual
WAN established backbone component, and the customer backbone. In most cases, there is a need to breakout
to the Internet in Hong Kong to directly reach the Microsoft Edge Network and, with that, the Azure Front Door
Servers used for Microsoft 365 Services.
For both scenarios with Virtual WAN, you would leverage the Azure Virtual WAN secured hub. Using Azure
Firewall Manager, you can change a regular Virtual WAN hub to a secured hub, and then deploy and manage an
Azure Firewall within that hub.
The following figure shows an example of this scenario:
Architecture and traffic flows
Depending on your choice regarding the connection to Hong Kong, the overall architecture may change slightly.
This section shows three available architectures in different combination with VPN or SDWAN and/or
ExpressRoute.
All of these options make use of Azure Virtual WAN secured hub for direct Microsoft 365 connectivity in Hong
Kong. These architectures also support the compliance requirements for Microsoft 365 Multi-Geo and keep that
traffic near the next Azure Front Door location. As a result, it's also an improvement for the usage of Microsoft
365 out of China.
When using Azure Virtual WAN together with Internet connections, every connection can benefit from
additional services like Microsoft Azure Peering Services (MAPS). MAPS was built to optimize traffic coming to
the Microsoft Global Network from 3rd Party Internet Service Providers.
Option 1: SDWAN or VPN
This section discusses a design that uses SDWAN or VPN to Hong Kong and to other branches. This option
shows the use and traffic flow when using pure Internet connection on both sites of the Virtual WAN backbone.
In this case, the connection is brought to Hong Kong using dedicated Internet access, or an ICP provider SDWAN
solution. Other branches are using pure Internet or SDWAN Solutions as well.
In this architecture, every site is connected to the Microsoft Global Network by using VPN and Azure Virtual
WAN. The traffic between the sites and Hong Kong is transmitted trough the Microsoft Network and only uses
regular Internet connection on the last mile.
Option 2: ExpressRoute and SDWAN or VPN
This section discusses a design that uses ExpressRoute in Hong Kong and other Branches with VPN/SDWAN
Branches. This option shows the use of and ExpressRoute terminated in Hong Kong and other branches
connected via SDWAN or VPN. ExpressRoute in Hong Kong is currently limited to a short list of Providers, which
you can find in the list of Express Route Partners.
There are also options to terminate ExpressRoute from China, for example, in South Korea or Japan. But, given
compliance, regulation, and latency, Hong Kong is currently the best choice.
Option 3: ExpressRoute only
This section discusses a design that where ExpressRoute is used for Hong Kong and other Branches. This option
shows the interconnect using ExpressRoute on both ends. Here you have a different traffic flow than the other.
The Microsoft 365 traffic will flow to the Azure virtual WAN secured hub and from there to the Microsoft Edge
Network and the Internet.
The traffic that goes to the interconnected branches or from them to the locations in China will follow a different
approach within that architecture. Currently virtual WAN does not support ExpressRoute to ExpressRoute transit.
The traffic will leverage ExpressRoute Global Reach or the 3rd Party interconnect without passing the virtual
WAN Hub. It will directly flow from one Microsoft Enterprise Edge (MSEE) to another.
Currently ExpressRoute Global Reach is not available in every country/region, but you can configure a solution
using Azure Virtual WAN.
You can, for example, configure an ExpressRoute with Microsoft Peering and connect a VPN tunnel through that
peering to Azure Virtual WAN. Now you have enabled, again, the transit between VPN and ExpressRoute without
Global Reach and 3rd party provider and service, such as Megaport Cloud.
Next steps
See the following articles for more information:
Global Transit network architecture with Azure Virtual WAN
Create a Virtual WAN hub
Configure a Virtual WAN secured hub
Azure Peering Service Preview Overview
About virtual hub routing
The routing capabilities in a virtual hub are provided by a router that manages all routing between gateways
using Border Gateway Protocol (BGP). A virtual hub can contain multiple gateways such as a Site-to-site VPN
gateway, ExpressRoute gateway, Point-to-site gateway, Azure Firewall. This router also provides transit
connectivity between virtual networks that connect to a virtual hub and can support up to an aggregate
throughput of 50 Gbps. These routing capabilities apply to Standard Virtual WAN customers.
To configure routing, see How to configure virtual hub routing.
Routing concepts
The following sections describe the key concepts in virtual hub routing.
Hub route table
A virtual hub route table can contain one or more routes. A route includes its name, a label, a destination type, a
list of destination prefixes, and next hop information for a packet to be routed. A Connection typically will have
a routing configuration that associates or propagates to a route table.
Hub routing intent and policies
NOTE
Hub Routing Policies are currently in Managed Preview.
To obtain access to this preview, please reach out to previewinterhub@microsoft.com with the Virtual WAN ID,
Subscription ID and Azure Region you wish to configure Routing Policies in. Please expect a response within 24-48 hours
with confirmation of feature enablement.
For more information on how to configure Routing Intent and Policies please view the following document.
Customers using Azure Firewall manager to set up policies for public and private traffic now can set up their
networks in a much simpler manner using Routing Intent and Routing Policies.
Routing Intent and Routing policies allow you to specify how the Virtual WAN hub forwards Internet-bound and
Private (Point-to-site, Site-to-site, ExpressRoute, Network Virtual Appliances inside the Virtual WAN Hub and
Virtual Network) Traffic. There are two types of Routing Policies: Internet Traffic and Private Traffic Routing
Policies. Each Virtual WAN Hub may have at most one Internet Traffic Routing Policy and one Private Traffic
Routing Policy, each with a Next Hop resource.
While Private Traffic includes both branch and Virtual Network address prefixes, Routing Policies considers them
as one entity within the Routing Intent Concept.
Internet Traffic Routing Policy : When an Internet Traffic Routing Policy is configured on a Virtual WAN
hub, all branch (User VPN (Point-to-site VPN), Site-to-site VPN and ExpressRoute) and Virtual Network
connections to that Virtual WAN Hub will forward Internet-bound traffic to the Azure Firewall resource or
Third-Party Security provider specified as part of the Routing Policy.
Private Traffic Routing Policy : When a Private Traffic Routing Policy is configured on a Virtual WAN
hub, all branch and Virtual Network traffic in and out of the Virtual WAN Hub including inter-hub traffic
will be forwarded to the Next Hop Azure Firewall resource that was specified in the Private Traffic Routing
Policy.
For more information on how to configure Routing Intent and Policies please view the following document.
Connections
Connections are Resource Manager resources that have a routing configuration. The four types of connections
are:
VPN connection : Connects a VPN site to a virtual hub VPN gateway.
ExpressRoute connection : Connects an ExpressRoute circuit to a virtual hub ExpressRoute gateway.
P2S configuration connection : Connects a User VPN (Point-to-site) configuration to a virtual hub User
VPN (Point-to-site) gateway.
Hub vir tual network connection : Connects virtual networks to a virtual hub.
You can set up the routing configuration for a virtual network connection during setup. By default, all
connections associate and propagate to the Default route table.
Association
Each connection is associated to one route table. Associating a connection to a route table allows the traffic to be
sent to the destination indicated as routes in the route table. The routing configuration of the connection will
show the associated route table. Multiple connections can be associated to the same route table. All VPN,
ExpressRoute, and User VPN connections are associated to the same (default) route table.
By default, all connections are associated to a Default route table in a virtual hub. Each virtual hub has its own
Default route table, which can be edited to add a static route(s). Routes added statically take precedence over
dynamically learned routes for the same prefixes.
Propagation
Connections dynamically propagate routes to a route table. With a VPN connection, ExpressRoute connection, or
P2S configuration connection, routes are propagated from the virtual hub to the on-premises router using BGP.
Routes can be propagated to one or multiple route tables.
A None route table is also available for each virtual hub. Propagating to the None route table implies that no
routes are required to be propagated from the connection. VPN, ExpressRoute, and User VPN connections
propagate routes to the same set of route tables.
Labels
Labels provide a mechanism to logically group route tables. This is especially helpful during propagation of
routes from connections to multiple route tables. For example, the Default Route Table has a built-in label
called 'Default'. When users propagate connection routes to 'Default' label, it automatically applies to all the
Default Route Tables across every hub in the Virtual WAN.
Configuring static routes in a virtual network connection
Configuring static routes provides a mechanism to steer traffic through a next hop IP, which could be of a
Network Virtual Appliance (NVA) provisioned in a Spoke VNet attached to a virtual hub. The static route is
composed of a route name, list of destination prefixes, and a next hop IP.
Route tables for pre-existing routes

Route tables now have features for association and propagation. A pre-existing route table is a route table that
does not have these features. If you have pre-existing routes in hub routing and would like to use the new
capabilities, consider the following:
Standard Vir tual WAN Customers with pre-existing routes in vir tual hub :
If you have pre-existing routes in Routing section for the hub in Azure portal, you will need to first delete
them and then attempt creating new route tables (available in the Route Tables section for the hub in
Azure portal).
Basic Vir tual WAN Customers with pre-existing routes in vir tual hub :
If you have pre-existing routes in Routing section for the hub in Azure portal, you will need to first delete
them, then upgrade your Basic Virtual WAN to Standard Virtual WAN. See Upgrade a virtual WAN from
Basic to Standard.
Hub reset
Virtual hub Reset is available only in the Azure portal. Resetting provides you a way to bring any failed
resources such as route tables, hub router, or the virtual hub resource itself back to its rightful provisioning
state. Consider resetting the hub prior to contacting Microsoft for support. This operation does not reset any of
the gateways in a virtual hub.
Additional considerations
Consider the following when configuring Virtual WAN routing:
All branch connections (Point-to-site, Site-to-site, and ExpressRoute) need to be associated to the Default
route table. That way, all branches will learn the same prefixes.
All branch connections need to propagate their routes to the same set of route tables. For example, if you
decide that branches should propagate to the Default route table, this configuration should be consistent
across all branches. As a result, all connections associated to the Default route table will be able to reach all of
the branches.
Branch-to-branch via Azure Firewall is currently not supported.
When using Azure Firewall in multiple regions, all spoke virtual networks must be associated to the same
route table. For example, having a subset of the VNets going through the Azure Firewall while other VNets
bypass the Azure Firewall in the same virtual hub is not possible.
You may specify multiple next hop IP addresses on a single Virtual Network connection. However, Virtual
Network Connection does not support ‘multiple/unique’ next hop IP to the ‘same’ network virtual appliance
in a SPOKE Virtual Network 'if' one of the routes with next hop IP is indicated to be public IP address or
0.0.0.0/0 (internet)
All information pertaining to 0.0.0.0/0 route is confined to a local hub's route table. This route does not
propagate across hubs.
You can only use Virtual WAN to program routes in a spoke if the prefix is shorter (less specific) than the
virtual network prefix. For example, in the diagram above the spoke VNET1 has the prefix 10.1.0.0/16: in this
case, Virtual WAN would not be able to inject a route that matches the virtual network prefix (10.1.0.0/16) or
any of the subnets (10.1.0.0/24, 10.1.1.0/24). In other words, Virtual WAN cannot attract traffic between two
subnets that are in the same virtual network.
Next steps
To configure routing, see How to configure virtual hub routing.
For more information about Virtual WAN, see the FAQ.
Scenario: Any-to-any
When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. In an Any-to-any
scenario, any spoke can reach another spoke. When multiple hubs exist, hub-to-hub routing (also known as
inter-hub) is enabled by default in Standard Virtual WAN. You can create this configuration using various
methods, such as the Azure portal, or an Azure Quickstart Template. For more information about virtual hub
routing, see About virtual hub routing.
Design
In order to figure out how many route tables will be needed in a Virtual WAN scenario, you can build a
connectivity matrix, where each cell represents whether a source (row) can communicate to a destination
(column).
F RO M TO VN ET S B RA N C H ES
VNets → Direct Direct
Branches → Direct Direct
Each of the cells in the previous table describes whether a Virtual WAN connection (the "From" side of the flow,
the row headers) communicates with a destination prefix (the "To" side of the flow, the column headers in italics).
In this scenario there are no firewalls or Network Virtual Appliances, so communication flows directly over
Virtual WAN (hence the word "Direct" in the table).
Since all connections from both VNets and branches (VPN, ExpressRoute, and User VPN) have the same
connectivity requirements, a single route table is required. As a result, all connections will be associated and
propagate to the same route table, the Default route table:
Virtual networks:
Associated route table: Default
Propagating to route tables: Default
Branches:
For more information about virtual hub routing, see About virtual hub routing.
Architecture
In Figure 1 , all VNets and Branches (VPN, ExpressRoute, P2S) can reach each other. In a virtual hub, connections
work as follows:
A VPN connection connects a VPN site to a VPN gateway.
A virtual network connection connects a virtual network to a virtual hub. The virtual hub's router provides
the transit functionality between VNets.
An ExpressRoute connection connects an ExpressRoute circuit to an ExpressRoute gateway.
These connections (by default at creation) are associated to the Default route table, unless you set up the routing
configuration of the connection to either None , or a custom route table. These connections also propagate
routes, by default to the Default route table. This is what enables an any-to-any scenario where any spoke (VNet,
VPN, ER, P2S) can reach each other.
Figure 1
Workflow
This scenario is enabled by default for Standard Virtual WAN. If the settings for branch-to-branch are disabled in
WAN configuration, that will disallow connectivity between branch spokes. VPN/ExpressRoute/User VPN are
considered as branch spokes in Virtual WAN
Next steps
Scenario: Isolating VNets
When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. In this scenario,
the goal is to prevent VNets from being able to reach other. This is known as isolating VNets. For information
about virtual hub routing, see About virtual hub routing.
Design
In this scenario, the workload within a certain VNet remains isolated and is not able to communicate with other
VNets. However, the VNets are required to reach all branches (VPN, ER, and User VPN). In order to figure out
how many route tables will be needed, you can build a connectivity matrix. For this scenario it will look like the
following table, where each cell represents whether a source (row) can communicate to a destination (column):
F RO M TO VN ET S B RA N C H ES
VNets → Direct Direct
Branches → Direct Direct
the row headers) communicates with a destination prefix (the "To" side of the flow, the column headers in italics).
In this scenario there are no firewalls or Network Virtual Appliances, so communications flows directly over
Virtual WAN (hence the word "Direct" in the table).
This connectivity matrix gives us two different row patterns, which translate to two route tables. Virtual WAN
already has a Default route table, so we will need another route table. For this example, we will name the route
table RT_VNET .
VNets will be associated to this RT_VNET route table. Because they need connectivity to branches, branches will
need to propagate to RT_VNET (otherwise the VNets would not learn the branch prefixes). Since the branches
are always associated to the Default route table, VNets will need to propagate to the Default route table. As a
result, this is the final design:
Virtual networks:
Associated route table: RT_VNET
Branches:
Propagating to route tables: RT_VNET and Default
Notice that since only branches propagate to the route table RT_VNET , those will be the only prefixes that
VNets will learn, and not those of other VNets.
For information about virtual hub routing, see About virtual hub routing.
Workflow
In order to configure this scenario, take the following steps into consideration:
1. Create a custom route table in each hub. In the example, the route table is RT_VNet . To create a route
table, see How to configure virtual hub routing. For more information about route tables, see About
virtual hub routing.
2. When you create the RT_VNet route table, configure the following settings:
Association : Select the VNets you want to isolate.
Propagation : Select the option for branches, implying branch(VPN/ER/P2S) connections will
propagate routes to this route table.
Next steps
Scenario: Custom isolation for VNets
When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. In a custom
isolation scenario for VNets, the goal is to prevent a specific set of VNets from being able to reach other specific
set of VNets. However, the VNets are required to reach all branches (VPN/ER/User VPN). For more information
about virtual hub routing, see About virtual hub routing.
Design
In order to figure out how many route tables will be needed, you can build a connectivity matrix. For this
scenario it will look like the following, where each cell represents whether a source (row) can communicate to a
destination (column):
F RO M TO : B L UE VN ET S RED VN ET S B RA N C H ES
Blue VNets → Direct Direct
Red VNets → Direct Direct
Branches → Direct Direct Direct
the row headers) communicates with a destination (the "To" side of the flow, the column headers in italics). In
this scenario there are no firewalls or Network Virtual Appliances, so communications flows directly over Virtual
WAN (hence the word "Direct" in the table).
The number of different row patterns will be the number of route tables we will need in this scenario. In this
case, three route route tables that we will call RT_BLUE and RT_RED for the virtual networks, and Default for
the branches. Remember, the branches always have to be associated to the Default routing table.
The branches will need to learn the prefixes from both Red and Blue VNets, so all VNets will need to propagate
to Default (additionally to either RT_BLUE or RT_RED ). Blue and Red VNets will need to learn the branches
prefixes, so branches will propagate to both route tables RT_BLUE and RT_RED too. As a result, this is the final
design:
Blue virtual networks:
Associated route table: RT_BLUE
Propagating to route tables: RT_BLUE and Default
Red virtual networks:
Associated route table: RT_RED
Propagating to route tables: RT_RED and Default
Branches:
Propagating to route tables: RT_BLUE , RT_RED and Default
NOTE
Since all branches need to be associated to the Default route table, as well as to propagate to the same set of routing
tables, all branches will have the same connectivity profile. In other words, the Red/Blue concept for VNets cannot be
applied to branches.
NOTE
If your Virtual WAN is deployed over multiple regions, you will need to create the RT_BLUE and RT_RED route tables in
every hub, and routes from each VNet connection need to be propagated to the route tables in every virtual hub using
propagation labels.
Workflow
In Figure 1 , there are Blue and Red VNet connections.
Blue-connected VNets can reach each other, as well as reach all branches (VPN/ER/P2S) connections.
Red VNets can reach each other, as well as reach all branches (VPN/ER/P2S) connections.
Consider the following steps when setting up routing.
1. Create two custom route tables in the Azure portal, RT_BLUE and RT_RED .
2. For route table RT_BLUE , for the following settings:
Association : Select all Blue VNets.
Propagation : For Branches, select the option for branches, implying branch(VPN/ER/P2S)
connections will propagate routes to this route table.
3. Repeat the same steps for RT_RED route table for Red VNets and branches (VPN/ER/P2S).
This will result in the routing configuration changes as seen the figure below
Figure 1
Next steps
Scenario: Custom Isolation for Virtual Networks and
Branches
When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. In a custom
isolation scenario for both Virtual Networks (VNets) and branches, the goal is to prevent a specific set of VNets
from reaching another set of VNets. Likewise, branches (VPN/ER/User VPN) are only allowed to reach certain
sets of VNets.
We also introduce the additional requirement that Azure Firewall should inspect branch-to-VNet and VNet-to-
branch, but not VNet-to VNet-traffic.
Design
In order to figure out how many route tables will be needed, you can build a connectivity matrix. For this
scenario it will look like the following, where each cell represents whether a source (row) can communicate to a
destination (column):
F RO M TO : B L UE VN ET S RED VN ET S RED B RA N C H ES B L UE B RA N C H ES
Blue VNets → Direct AzFW
Red VNets → Direct AzFW
Red Branches → AzFW Direct Direct
Blue Branches → AzFW Direct Direct
the row headers) communicates with a destination (the "To" side of the flow, the column headers in italics).
Direct implies the traffic flows directly through Virtual WAN while AzFW implies that the traffic is inspected by
Azure Firewall before being forwarded to the destination. A blank entry means that flow is blocked in the setup.
In this case, the two route tables for the VNets are required to achieve the goal of VNet isolation without Azure
Firewall in the path. We will call these routes tables RT_BLUE and RT_RED .
In addition, branches must always be associated to the Default Route Table. To ensure that traffic to and from
the branches is inspected by Azure Firewall, we add static routes in the Default , RT_RED and RT_BLUE route
tables pointing traffic to Azure Firewall and set up Network Rules to allow desired traffic. We also ensure that
the branches do not propagate to RT_BLUE and RT_RED .
As a result, this is the final design:
Blue virtual networks:
Associated route table: RT_BLUE
Propagating to route tables: RT_BLUE
Red virtual networks:
Associated route table: RT_RED
Propagating to route tables: RT_RED
Branches:
Static Routes:
Default Route Table : Virtual Network Address Spaces with next hop Azure Firewall
RT_RED : 0.0.0.0/0 with next hop Azure Firewall
RT_BLUE : 0.0.0.0/0 with next hop Azure Firewall
Firewall Network Rules:
ALLOW RULE Source Prefix : Blue Branch Address Prefixes Destination Prefix : Blue VNet Prefixes
ALLOW RULE Source Prefix : Red Branch Address Prefixes Destination Prefix : Red VNet Prefixes
NOTE
Since all branches need to be associated to the Default route table, as well as to propagate to the same set of routing
tables, all branches will have the same connectivity profile. In other words, the Red/Blue concept for VNets cannot be
applied to branches. However, to achieve custom routing for branches, we can forward traffic from the branches to Azure
Firewall.
NOTE
Azure Firewall by default denies traffic in a zero-trust model. If there is no explicit ALLOW rule that matches the inspected
packet, Azure Firewall will drop the packet.
Workflow
In Figure 1 , there are Blue and Red VNets, as well as branches that can access either Blue or Red VNets.
Blue-connected VNets can reach each other and can reach all blue branches (VPN/ER/P2S) connections. In
the diagram, the blue branch is the Site-to-site VPN site.
Red-connected VNets can reach each other and can reach all red branches (VPN/ER/P2S) connections. In the
diagram, the red branch is the Point-to-site VPN users.
Consider the following steps when setting up routing.
1. Create two custom route tables in the Azure portal, RT_BLUE and RT_RED in order to customize traffic
to these VNets.
2. For route table RT_BLUE , apply the following settings to ensure Blue VNets learn the address prefixes of
all other Blue VNets.:
Association : Select all Blue VNets.
Propagation : Select all Blue VNets.
3. Repeat the same steps for RT_RED route table for Red VNets.
4. Provision an Azure Firewall in Virtual WAN. For more information about Azure Firewall in the Virtual
WAN hub, see Configuring Azure Firewall in Virtual WAN hub.
5. Add a static route to the Default Route Table of the Virtual Hub directing all traffic destined for the VNet
address spaces (both blue and red) to Azure Firewall. This step ensures any packets from your branches
will be sent to Azure Firewall for inspection.
Example: Destination Prefix : 10.0.0.0/8 Next Hop : Azure Firewall
NOTE
This step can also be done via Firewall Manager by selecting the "Secure Private Traffic" option. This will add a
route for all RFC1918 private IP addresses applicable to VNets and branches. You will need to manually add in any
branches or virtual networks that are not compliant with RFC1918.
6. Add a static route to RT_RED and RT_BLUE directing all traffic to Azure Firewall. This step ensures VNets
will not be able to access branches directly. This step cannot be done via Firewall Manager because these
Virtual Networks are not associated with the Default Route Table.
Example: Destination Prefix : 0.0.0.0/0 Next Hop : Azure Firewall
NOTE
Routing is performed using Longest Prefix Match (LPM). As a result, the 0.0.0.0/0 static routes will NOT be
preferred over the exact prefixes that exist in BLUE_RT and RED_RT . As a result, intra-VNet traffic will not be
inspected by Azure Firewall.
This will result in the routing configuration changes as seen in the figure below.
Figure 1
Next steps
Scenario: Route to shared services VNets
the goal is to set up routes to access a Shared Ser vice VNet with workloads that you want every VNet and
Branch (VPN/ER/P2S) to access. Examples of these shared workloads might include Virtual Machines with
services like Domain Controllers or File Shares, or Azure services exposed internally through Azure Private
Endpoints.
Design
We can use a connectivity matrix to summarize the requirements of this scenario:
Connectivity matrix
F RO M TO : ISO L AT ED VN ET S SH A RED VN ET B RA N C H ES
Isolated VNets -> Direct Direct
Shared VNets -> Direct Direct Direct
Branches -> Direct Direct Direct
the row headers) communicates with a destination (the "To" side of the flow, the column headers in italics). In
this scenario there are no firewalls or Network Virtual Appliances, so communication flows directly over Virtual
WAN (hence the word "Direct" in the table).
Similarly to the Isolated VNet scenario, this connectivity matrix gives us two different row patterns, which
translate to two route tables (the shared services VNets and the branches have the same connectivity
requirements). Virtual WAN already has a Default route table, so we will need another custom route table, which
we will call RT_SHARED in this example.
VNets will be associated to the RT_SHARED route table. Because they need connectivity to branches and to the
shared service VNets, the shared service VNet and branches will need to propagate to RT_SHARED (otherwise
the VNets would not learn the branch and shared VNet prefixes). Because the branches are always associated to
the Default route table, and the connectivity requirements are the same for shared services VNets, we will
associate the shared service VNets to the Default route table too.
As a result, this is the final design:
Isolated virtual networks:
Associated route table: RT_SHARED
Shared services virtual networks:
Propagating to route tables: RT_SHARED and Default
Branches:
NOTE
If your Virtual WAN is deployed over multiple regions, you will need to create the RT_SHARED route table in every hub,
and routes from each shared services VNet and branch connection need to be propagated to the route tables in every
virtual hub using propagation labels.
Workflow
To configure the scenario, consider the following steps:
1. Identify the shared ser vices VNet.
2. Create a custom route table. In the example, we refer to the route table as RT_SHARED . For steps to
create a route table, see How to configure virtual hub routing. Use the following values as a guideline:
Association
For VNets except the shared ser vices VNet , select the VNets to isolate. This will imply that
all these VNets (except the shared services VNet) will be able to reach destination based on the
routes of RT_SHARED route table.
Propagation
For Branches , propagate routes to this route table, in addition to any other route tables you
may have already selected. Because of this step, the RT_SHARED route table will learn routes
from all branch connections (VPN/ER/User VPN).
For VNets , select the shared ser vices VNet . Because of this step, RT_SHARED route table will
learn routes from the shared services VNet connection.
This will result in the routing configuration shown in the following figure:
Next steps
To configure using an ARM template, see Quickstart: Route to shared services VNets using an ARM template.
Scenario: Route traffic through an NVA
When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. In this NVA
scenario, the goal is to route traffic through an NVA (Network Virtual Appliance) for branch to VNet and VNet to
branch. For information about virtual hub routing, see About virtual hub routing.
NOTE
If you already have a set up with routes that are prior to the new capabilities How to configure virtual hub routing
becoming available, please use the steps in these versions of the articles:
Azure portal article
PowerShell article
Design
In this scenario we will use the naming convention:
"NVA VNets" for virtual networks where users have deployed an NVA and have connected other virtual
networks as spokes (VNet 2 and VNet 4 in the Figure 2 further down in the article).
"NVA Spokes" for virtual networks connected to an NVA VNet (VNet 5, VNet 6, VNet 7, and VNet 8 in the
Figure 2 further down in the article).
"Non-NVA VNets" for virtual networks connected to Virtual WAN that do not have an NVA or other VNets
peered with them (VNet 1 and VNet 3 in the Figure 2 further down in the article).
"Hubs" for Microsoft-managed Virtual WAN Hubs, where NVA VNets are connected to. NVA spoke VNets
don't need to be connected to Virtual WAN hubs, only to NVA VNets.
The following connectivity matrix, summarizes the flows supported in this scenario:
Connectivity matrix
F RO M TO : N VA SP O KES N VA VN ET S N O N -N VA VN ET S B RA N C H ES
NVA Spokes → Over NVA VNet Peering Over NVA VNet Over NVA VNet
NVA VNets → Peering Direct Direct Direct
Non-NVA → Over NVA VNet Direct Direct Direct

VNets
Branches → Over NVA VNet Direct Direct Direct
Each of the cells in the connectivity matrix describes how a VNet or branch (the "From" side of the flow, the row
headers in the table) communicates with a destination VNet or branch (the "To" side of the flow, the column
headers in italics in the table). "Direct" means that connectivity is provided natively by Virtual WAN, "Peering"
means that connectivity is provided by a User-Defined Route in the VNet, "Over NVA VNet" means that the
connectivity traverses the NVA deployed in the NVA VNet. Consider the following:
NVA Spokes are not managed by Virtual WAN. As a result, the mechanisms with which they will
communicate to other VNets or branches are maintained by the user. Connectivity to the NVA VNet is
provided by a VNet peering, and a Default route to 0.0.0.0/0 pointing to the NVA as next hop should cover
connectivity to the Internet, to other spokes, and to branches
NVA VNets will know about their own NVA spokes, but not about NVA spokes connected to other NVA
VNets. For example, in the Figure 2 further down in this article, VNet 2 knows about VNet 5 and VNet 6, but
not about other spokes such as VNet 7 and VNet 8. A static route is required to inject other spokes' prefixes
into NVA VNets
Similarly, branches and non-NVA VNets will not know about any NVA spoke, since NVA spokes are not
connected to Virtual WAN hubs. As a result, static routes will be needed here as well.
Taking into account that the NVA spokes are not managed by Virtual WAN, all other rows show the same
connectivity pattern. As a result, a single route table (the Default one) will do:
Virtual networks (non-hub VNets and user-hub VNets):
Branches:
However, in this scenario we need to think about which static routes to configure. Each static route will have two
components, one part in the Virtual WAN hub telling the Virtual WAN components which connection to use for
each spoke, and another one in that specific connection pointing to the concrete IP address assigned to the NVA
(or to a load balancer in front of multiple NVAs), as Figure 1 shows:
Figure 1
With that, the static routes that we need in the Default table to send traffic to the NVA spokes behind the NVA
VNet are as follows:
DESC RIP T IO N RO UT E TA B L E STAT IC RO UT E
VNet 2 Default 10.2.0.0/16 -> eastusconn
VNet 4 Default 10.4.0.0/16 -> weconn
Now virtual WAN knows which connection to send the packets to, but the connection needs to know what to do
when receiving those packets: This is where the connection route tables are used. Here we will use the shorter
prefixes (/24 instead of the longer /16), to make sure that these routes have preference over routes that are
imported from the NVA VNets (VNet 2 and VNet 4):
DESC RIP T IO N C O N N EC T IO N STAT IC RO UT E
VNet 5 eastusconn 10.2.1.0/24 -> 10.2.0.5
VNet 6 eastusconn 10.2.2.0/24 -> 10.2.0.5
VNet 7 weconn 10.4.1.0/24 -> 10.4.0.5
VNet 8 weconn 10.4.2.0/24 -> 10.4.0.5
Now NVA VNets, non-NVA VNets, and branches know how to reach all NVA spokes. For more information about
virtual hub routing, see About virtual hub routing.
Architecture
In Figure 2 , there are two hubs; Hub1 and Hub2 .
Hub1 and Hub2 are directly connected to NVA VNets VNet 2 and VNet 4 .
VNet 5 and VNet 6 are peered with VNet 2 .
VNet 7 and VNet 8 are peered with VNet 4 .
VNets 5,6,7,8 are indirect spokes, not directly connected to a virtual hub.
Figure 2
Scenario workflow
To set up routing via NVA, here are the steps to consider:
1. Identify the NVA spoke VNet connection. In Figure 2 , they are VNet 2 Connection (eastusconn) and
VNet 4 Connection (weconn) .
Ensure there are UDRs set up:
From VNet 5 and VNet 6 to VNet 2 NVA IP
From VNet 7 and VNet 8 to VNet 4 NVA IP
You do not need to connect VNets 5,6,7,8 to the virtual hubs directly. Ensure that NSGs in VNets 5,6,7,8
allow traffic for branch (VPN/ER/P2S) or VNets connected to their remote VNets. For example, VNets 5,6
must ensure NSGs allow traffic for on-premises address prefixes and VNets 7,8 that are connected to the
remote Hub 2.
Virtual WAN does not support a scenario where VNets 5,6 connect to virtual hub and communicate via VNet 2
NVA IP; therefore the need to connect VNets 5,6 to VNet2 and similarly VNet 7,8 to VNet 4.
2. Add an aggregated static route entry for VNets 2,5,6 to Hub 1’s Default route table.
NOTE
To simplify the routing and to reduce the changes in the Virtual WAN hub route tables, we recommend the new
BGP peering with Virtual WAN hub (preview). For more information, see the following articles:
Scenario: BGP peering with a virtual hub (preview)
How to create BGP peering with virtual hub (preview) - Azure portal
3. Configure a static route for VNets 5,6 in VNet 2’s virtual network connection. To set up routing
configuration for a virtual network connection, see virtual hub routing.
4. Add an aggregated static route entry for VNets 4,7,8 to Hub 1’s Default route table.
5. Repeat steps 2, 3 and 4 for Hub 2’s Default route table.
This will result in the routing configuration changes, as shown in Figure 3 , below.
Figure 3
Next steps
Scenario: Route traffic through NVAs by using
custom settings
When you're working with Azure Virtual WAN virtual hub routing, you have many options available to you. The
focus of this article is when you want to route traffic through a network virtual appliance (NVA) for
communication between virtual networks and branches, and use a different NVA for internet-bound traffic. For
more information, see About virtual hub routing.
NOTE
Please note that for the routing scenarios below, the Virtual WAN hub and Spoke Virtual Network containing the NVA
must be in the same Azure Region.
Design
Spokes for virtual networks connected to the virtual hub. (For example, VNet 1, VNet 2, and VNet 3 in the
diagram later in this article.)
Ser vice VNet for virtual networks where users have deployed an NVA to inspect non-internet traffic, and
possibly with common services accessed by spokes. (For example, VNet 4 in the diagram later in this article.)
Perimeter VNet for virtual networks where users have deployed an NVA to be used to inspect internet-
bound traffic. (For example, VNet 5 in the diagram later in this article.)
Hubs for Virtual WAN hubs managed by Microsoft.
The following table summarizes the connections supported in this scenario:
F RO M TO SP O K ES SERVIC E VN ET B RA N C H ES IN T ERN ET
Spokes -> directly directly through Service through

VNet Perimeter VNet
Ser vice VNet -> directly n/a directly
Branches -> through Service directly directly

VNet
Each of the cells in the connectivity matrix describes whether connectivity flows directly over Virtual WAN or
over one of the virtual networks with an NVA.
Note the following details:
Spokes:
Spokes will reach other spokes directly over Virtual WAN hubs.
Spokes will get connectivity to branches via a static route pointing to the Service VNet. They don't
learn specific prefixes from the branches, because those prefixes are more specific and override the
summary.
Spokes will send internet traffic to the Perimeter VNet through a direct VNet peering.
Branches will get to spokes via a static routing pointing to the Service VNet. They don't learn specific prefixes
from the virtual networks that override the summarized static route.
The Service VNet will be similar to a Shared Services VNet that needs to be reachable from every virtual
network and every branch.
The Perimeter VNet doesn't need to have connectivity over Virtual WAN, because the only traffic it will
support comes over direct virtual network peerings. To simplify configuration, however, use the same
connectivity model as for the Perimeter VNet.
There are three distinct connectivity patterns, which translate to three route tables. The associations to the
different virtual networks are:
Spokes:
Associated route table: RT_V2B
Propagating to route tables: RT_V2B and RT_SHARED
NVA VNets (Service VNet and DMZ VNet):
Associated route table: RT_SHARED
Propagating to route tables: RT_SHARED
Branches:
NOTE
Please make sure that the spoke VNets are not propagating to the Default label. This ensures traffic from branches to
spoke VNets is forwarded to the NVAs.
These static routes ensure that traffic to and from the virtual network and branch goes through the NVA in the
Service VNet (VNet 4):
DESC RIP T IO N RO UT E TA B L E STAT IC RO UT E
Branches RT_V2B 10.2.0.0/16 -> vnet4conn
NVA spokes Default 10.1.0.0/16 -> vnet4conn
Now you can use Virtual WAN to select the correct connection to send the packets to. You also need to use
Virtual WAN to select the correct action to take when receiving those packets. You use the connection route
tables for this, as follows:
DESC RIP T IO N C O N N EC T IO N STAT IC RO UT E
VNet2Branch vnet4conn 10.2.0.0/16 -> 10.4.0.5
Branch2VNet vnet4conn 10.1.0.0/16 -> 10.4.0.5
For more information, see About virtual hub routing.
Architecture
The following diagram shows the architecture described earlier in the article.
In the diagram, there is one hub; Hub 1 .
Hub 1 is directly connected to NVA VNets VNet 4 and VNet 5 .
Traffic between VNets 1, 2, 3 and the branches is expected to go via VNet 4 NVA 10.4.0.5.
All internet bound traffic from VNets 1, 2, and 3 is expected to go via VNet 5 NVA 10.5.0.5.
Workflow
To set up routing via NVA, consider the following steps:

1. For internet-bound traffic to go via VNet 5, you need VNets 1, 2, and 3 to directly connect via virtual
network peering to VNet 5. You also need a user-defined route set up in the virtual networks for 0.0.0.0/0
and next hop 10.5.0.5.
If you do not want to connect VNets 1, 2, and 3 to VNet 5 and instead just use the NVA in VNet 4 to route
0.0.0.0/0 traffic from branches (on-premises VPN or ExpressRoute connections), go to the alternate
workflow.
However, if you want VNet-to-VNet traffic to transit through the NVA, you would need to disconnect VNet
1,2,3 from the virtual hub and connect it or stack it above the NVA Spoke VNet4. In Virtual WAN, VNet-
to-VNet traffic transits through the Virtual WAN hub or a Virtual WAN hub’s Azure Firewall (Secure hub).
If VNets peer directly using VNet peering, then they can communicate directly bypassing the transit
through the virtual hub.
2. In the Azure portal, go to your virtual hub and create a custom route table called RT_Shared . This table
learns routes via propagation from all virtual networks and branch connections. You can see this empty
table in the following diagram.
Routes: You don't need to add any static routes.
Association: Select VNets 4 and 5, which means that the connections of these virtual networks
associate to the route table RT_Shared .
Propagation: Because you want all branches and virtual network connections to propagate their
routes dynamically to this route table, select branches and all virtual networks.
3. Create a custom route table called RT_V2B for directing traffic from VNets 1, 2, and 3 to branches.
Routes: Add an aggregated static route entry for branches, with next hop as the VNet 4
connection. Configure a static route in VNet 4’s connection for branch prefixes. Indicate the next
hop as the specific IP of the NVA in VNet 4.
Association: Select all VNets 1, 2, and 3 . This implies that VNet connections 1, 2, and 3 will
associate to this route table and be able to learn routes (static and dynamic via propagation) in this
route table.
Propagation: Connections propagate routes to route tables. Selecting VNets 1, 2, and 3 enables
propagating routes from VNets 1, 2, and 3 to this route table. There's no need to propagate routes
from branch connections to RT_V2B , because branch virtual network traffic goes via the NVA in
VNet 4.
4. Edit the default route table, DefaultRouteTable .
All VPN, Azure ExpressRoute, and user VPN connections are associated to the default route table. All VPN,
ExpressRoute, and user VPN connections propagate routes to the same set of route tables.
Routes: Add an aggregated static route entry for VNets 1, 2, and 3, with next hop as the VNet 4
connection. Configure a static route in VNet 4’s connection for VNet 1, 2, and 3 aggregated
prefixes. Indicate the next hop as the specific IP of the NVA in VNet 4.
Association: Make sure the option for branches (VPN/ER/P2S) is selected, ensuring that on-
premises branch connections are associated to the default route table.
Propagation from: Make sure the option for branches (VPN/ER/P2S) is selected, ensuring that
on-premises connections are propagating routes to the default route table.
Alternate workflow
In this workflow, you don't connect VNets 1, 2, and 3 to VNet 5. Instead, you use the NVA in VNet 4 to route
0.0.0.0/0 traffic from branches (on-premises VPN or ExpressRoute connections).
To set up routing via NVA, consider the following steps:
1. In the Azure portal, go to your virtual hub and create a custom route table calledRT_NVA for directing
traffic via the NVA 10.4.0.5
Routes:No action required.
Association:Select VNet4 . This implies that VNet connection 4 will associate to this route table
and is able to learn routes (static and dynamic via propagation) in this route table.
Propagation:Connections propagate routes to route tables. Selecting VNets 1, 2, and 3 enables
propagating routes from VNets 1, 2, and 3 to this route table. Selecting branches (VPN/ER/P2S)
enables propagating routes from branches/on-premises connections to this route table. All VPN,
2. Create a custom route table calledRT_VNET for directing traffic from VNets 1, 2, and 3 to branches or the
internet (0.0.0.0/0) via the VNet4 NVA. VNet-to-VNet traffic will be direct, and not through VNet 4’s NVA.
If you want traffic to go via the NVA, disconnect VNet 1, 2, and 3 and connect them using VNet peering to
VNet4.
Routes:
Add an aggregated route '10.2.0.0/16' with next hop as the VNet 4 connection for traffic
going from VNets 1, 2, and 3 towards branches. In the VNet4 connection, configure a route
for '10.2.0.0/16' and indicate the next hop to be the specific IP of the NVA in VNet 4.
Add a route '0.0.0.0/0' with next hop as the VNet 4 connection. '0.0.0.0/0' is added to imply
sending traffic to internet. It does not imply specific address prefixes pertaining to VNets or
branches. In the VNet4 connection, configure a route for '0.0.0.0/0', and indicate the next
hop to be the specific IP of the NVA in VNet 4.
Association:Select all VNets 1, 2, and 3 . This implies that VNet connections 1, 2, and 3 will
associate to this route table and be able to learn routes (static and dynamic via propagation) in this
route table.
Propagation:Connections propagate routes to route tables. Selecting VNets 1, 2, and 3 enable
propagating routes from VNets 1, 2, and 3 to this route table. Make sure the option for branches
(VPN/ER/P2S) is not selected. This ensures that on-premises connections cannot get to the VNets
1, 2, and 3 directly.
3. Edit the default route table,DefaultRouteTable .
All VPN, Azure ExpressRoute, and user VPN connections are associated to the default route table. All VPN,
Routes:
Add an aggregated route '10.1.0.0/16' for VNets 1, 2, and 3 with next hop as the VNet 4
connection .
Add a route '0.0.0.0/0' with next hop as the VNet 4 connection . '0.0.0.0/0' is added to
imply sending traffic to internet. It does not imply specific address prefixes pertaining to
VNets or branches. In the prior step for the VNet4 connection, you would already have
configured a route for '0.0.0.0/0', with next hop to be the specific IP of the NVA in VNet 4.
Association:Make sure the option for branches (VPN/ER/P2S) is selected. This ensures that on-
premises branch connections are associated to the default route table. All VPN, Azure
ExpressRoute, and user VPN connections are associated only to the default route table.
Propagation from:Make sure the option for branches (VPN/ER/P2S) is selected. This ensures
that on-premises connections are propagating routes to the default route table. All VPN,
ExpressRoute, and user VPN connections propagate routes to the 'same set of route tables'.
Considerations
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 does not 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).
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 does not 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.
Scenario: BGP peering with a virtual hub
How to create BGP peering with virtual hub - Azure portal
Next steps
Scenario: BGP peering with a virtual hub (Preview)
IMPORTANT
The BGP peering with Virtual WAN hub feature is currently in gated public preview. If you are interested in trying this
feature, please email previewbgpwithvhub@microsoft.com along with the Resource ID of your Virtual WAN resource.
After receiving confirmation of feature enablement, please follow the following doucmentation page for key considerations
and a detailed configuration guide.
To locate the Resource ID, open the Azure portal, navigate to your Virtual WAN resource, and click Settings >
Proper ties > Resource ID.
Example:
/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualWans/<virtualWANname>
Azure Virtual WAN hub router, also called as virtual hub router, acts as a route manager and provides
simplification in routing operation within and across virtual hubs. In other words, a virtual hub router does the
following:
Simplifies routing management by being the central routing engine talking to gateways such as VPN,
ExpressRoute, P2S, and Network Virtual Appliances (NVA).
Enables advance routing scenarios of custom route tables, association, and propagation of routes.
Acts as the router for traffic transiting between/to virtual networks connected to a virtual hub.
The virtual hub router now also exposes the ability to peer with it, thereby exchanging routing information
directly through Border Gateway Protocol (BGP) routing protocol. NVA or a BGP end point provisioned in a
virtual network connected to a virtual hub, can directly peer with the virtual hub router if it supports the BGP
routing protocol and ensures that ASN on the NVA is set up to be different from the virtual hub ASN.
Benefits and considerations

Key benefits
You no longer need to manually update the routing table on your NVA whenever your virtual network
addresses are updated.
You no longer need to update user-defined routes manually whenever your NVA announces new routes or
withdraws old ones.
NVA in virtual networks connected to a virtual hub can learn virtual hub gateway (VPN, ExpressRoute, or
Managed NVA) routes.
You can peer multiple instances of your NVA with a virtual hub router. You can configure BGP attributes in
your NVA and, depending on your design (active-active or active-passive), let the virtual hub router know
which NVA instance is active or passive.
Considerations
You can't peer a virtual hub router with Azure Route Server provisioned in a virtual network.
The virtual hub router only supports 16-bit (2 bytes) ASN.
The virtual network connection that has the NVA BGP connection endpoint must always be associated
and propagating to defaultRouteTable. Custom route tables are not supported at this time.
The virtual hub router supports transit connectivity between virtual networks connected to virtual hubs.
This has nothing to do with this feature for BGP peering capability as Virtual WAN already supports
transit connectivity. Examples:
VNET1: NVA1 connected to Virtual Hub 1 -> (transit connectivity) -> VNET2: NVA2 connected to
Virtual Hub 1.
VNET1: NVA1 connected to Virtual Hub 1 -> (transit connectivity) -> VNET2: NVA2 connected to
Virtual Hub 2.
You can use your own public ASNs or private ASNs in your network virtual appliance. You can't use the
ranges reserved by Azure or IANA. The following ASNs are reserved by Azure or IANA:
ASNs reserved by Azure:
Public ASNs: 8074, 8075, 12076
Private ASNs: 65515, 65517, 65518, 65519, 65520
ASNs reserved by IANA: 23456, 64496-64511, 65535-65551
While the virtual hub router exchanges BGP routes with your NVA and propagates them to your virtual
network, it directly facilitates propagating routes from on-premises via the virtual hub hosted gateways
(VPN Gateway/ExpressRoute Gateway/Managed NVA gateways).
The virtual hub router has the following limits:
RESO URC E L IM IT
Number of routes each BGP peer can advertise to the The hub can only accept a maximum number of 10,000
virtual hub. routes (total) from its connected resources. For example,
if a virtual hub has a total of 6000 routes from the
connected virtual networks, branches, virtual hubs etc.,
then when a new BGP peering is configured with an
NVA, the NVA can only advertise up to 4000 routes.
Routes from NVA in a virtual network that are more specific than the virtual network address space,
when advertised to the virtual hub through BGP are not propagated further to on-premises.
Traffic destined for addresses in the virtual network directly connected to the virtual hub cannot be
configured to route through the NVA using BGP peering between the hub and NVA. This is because the
virtual hub automatically learns about system routes associated with addresses in the spoke virtual
network when the spoke virtual network connection is created. These automatically learned system
routes are preferred over routes learned by the hub through BGP.
BGP peering scenarios

This section describes scenarios where BGP peering feature can be utilized to configure routing.
Transit VNet connectivity

In this scenario, the virtual hub named "Hub 1" is connected to several virtual networks. The goal is to establish
routing between virtual networks VNET1 and VNET5.
Configuration steps without BGP peering
The following steps are required when BGP peering is not used on the virtual hub:
Virtual hub configuration
On the Hub 1's defaultRouteTable, configure static route for VNET5 (subnet 10.2.1.0/24) pointing to VNET2
connection.
On Hub 1's virtual network connection for VNET2, configure static route for VNET5 pointing to VNET2 NVA
IP (subnet 10.2.0.5).
On Hub 1, propagate routes from connections for VNET1 and VNET2 to the defaultRouteTable, and associate
them to the defaultRouteTable.
Virtual network configuration
On VNET5, set up a user-defined route (UDR) to point to VNET2 NVA IP.
Configuration steps with BGP peering
In the previous configuration, the maintenance of the static routes and UDR can become complex if the VNET5
configuration changes frequently. To address this challenge, the BGP peering with a virtual hub feature can be
used and the routing configuration must be changed to the following steps:
On Hub 1, configure VNET2 NVA as a BGP peer. Also, configure VNET2 NVA, to have a BGP peering with Hub
1.
On Hub 1, propagate routes from connections for VNET1 and VNET2 to the defaultRouteTable, and associate
On VNET5, set up a user-defined route (UDR) to point to VNET2 NVA IP.
Effective routes
The table below shows few entries from Hub 1's effective routes in the defaultRouteTable. Notice that the route
for VNET5 (subnet 10.2.1.0/24) and this confirms VNET1 and VNET5 will be able to communicate with each
other.
DEST IN AT IO N P REF IX N EXT H O P O RIGIN A SN PAT H
10.2.0.0/24 eastusconn VNet connection ID -
10.2.1.0/24 BGP peer connection ID for BGP peer connection ID for 65510
NVA NVA
10.4.1.0/24 Hub 2 Hub 2 -
Configuring routing in this manner using the feature eliminates the need for static route entries on the virtual
hub. Therefore, the configuration is simpler and route tables are updated dynamically when the configuration in
connected virtual networks (like VNET5) changes.
Branch VNet connectivity
In this scenario, the on-premises site named "NVA Branch 1" has a VPN configured to terminate on the VNET2
NVA. The goal is to configure routing between NVA Branch 1 and virtual network VNET1.
Configuration steps without BGP peering
The following steps are required when BGP peering is not used on the virtual hub:
On the Hub 1's defaultRouteTable, configure static route for NVA Branch 1 pointing to VNET2 connection.
On Hub 1's virtual network connection for VNET2, configure static route for NVA Branch 1 pointing to VNET2
NVA IP (10.2.0.5).
On Hub 1, propagate routes from connections for VNET1 and VNET2 to the defaultRouteTable and associate
BGP peering between VNET2 NVA and NVA Branch 1, and route advertisements for VNET1 from VNET2 NVA
to NVA Branch 1.
Configuration steps with BGP peering
Over time, the destination prefixes in NVA Branch 1 may change, or there may be many sites like NVA Branch 1,
which need connectivity to VNET1. This would result in needing updates to the static routes on the Hub 1 and
the VNET2 connection, which can get cumbersome. In such cases, we can use the BGP peering with a virtual hub
feature and the configuration steps for routing connectivity would be as given below.
On Hub 1, configure VNET2 NVA as a BGP peer. Also, configure VNET2 NVA, to have a BGP peering with Hub
1.
On Hub 1, propagate routes from connections for VNET1 and VNET2 to the defaultRouteTable and associate
BGP peering between VNET2 NVA and NVA Branch 1, and route advertisements for VNET1 from VNET2 NVA
to NVA Branch 1.
Effective routes
The table below shows few entries from Hub 1's effective routes in the defaultRouteTable. Notice that the route
for NVA Branch 1 (subnet 192.168.1.0/24) is learned over the BGP peering with the NVA.
DEST IN AT IO N P REF IX N EXT H O P O RIGIN A SN PAT H
10.2.0.0/24 eastusconn VNet connection ID -
192.168.1.0/24 BGP peer connection ID for BGP peer connection ID for 65510
NVA NVA
To manage network changes in NVA Branch 1 or establish connectivity between new sites like NVA Branch 1,
there is no additional configuration required on Hub 1 because the BGP peering between Hub 1 and NVA will
dynamically update the route tables. The configuration and maintenance are, therefore, simplified.
Next steps
Configure BGP peering with a virtual hub.
Scenario: Azure Firewall - custom
the goal is to route traffic between VNets directly, but use Azure Firewall for VNet-to-Internet/Branch and
Branch-to-VNet traffic flows.
Design
In order to figure out how many route tables will be needed, you can build a connectivity matrix, where each cell
represents whether a source (row) can communicate to a destination (column). The connectivity matrix in this
scenario is trivial, but be consistent with other scenarios, we can still look at it.
Connectivity matrix
F RO M TO : VN ET S B RA N C H ES IN T ERN ET
VNets → Direct AzFW AzFW
Branches → AzFW Direct Direct
In the previous table, an "Direct" represents direct connectivity between two connections without the traffic
traversing the Azure Firewall in Virtual WAN, and "AzFW" indicates that the flow will go through the Azure
Firewall. Since there are two distinct connectivity patterns in the matrix, we will need two route tables that will
be configured as follows:
Virtual networks:
Associated route table: RT_VNet
Propagating to route tables: RT_VNet
Branches:
NOTE
You can create a separate Virtual WAN instance with one single Secure Virtual Hub in each region, and then you can
connect each Virtual WAN to each other via Site-to-Site VPN.
For information about virtual hub routing, see About virtual hub routing.
Workflow
In this scenario, you want to route traffic through the Azure Firewall for VNet-to-Internet, VNet-to-Branch, or
Branch-to-VNet traffic, but would like to go direct for VNet-to-VNet traffic. If you used Azure Firewall Manager,
the route settings are automatically populated into the Default Route Table . Private Traffic applies to VNet and
Branches, Internet traffic applies to 0.0.0.0/0.
VPN, ExpressRoute, and User VPN connections are collectively called Branches and associate to the same
(Default) route table. All VPN, ExpressRoute, and User VPN connections propagate routes to the same set of
route tables. In order to configure this scenario, take the following steps into consideration:
1. Create a custom route table RT_VNet .
2. Create a route to activate VNet-to-Internet and VNet-to-Branch: 0.0.0.0/0 with the next hop pointing to
Azure Firewall. In the Propagation section, you'll make sure that VNets are selected which would ensure
more specific routes, thereby allowing VNet-to-VNet direct traffic flow.
In Association: Select VNets that will imply that VNets will reach destination according to the routes
of this route table.
In Propagation: Select VNets that will imply that the VNets propagate to this route table; in other
words, more specific routes will propagate to this route table, thereby ensuring direct traffic flow
between VNet to VNet.
3. Add an aggregated static route for VNets into the Default Route table to activate the Branch-to-VNet
flow via the Azure Firewall.
Remember, branches are associated and propagating to the default route table.
Branches do not propagate to RT_VNet route table. This ensures the VNet-to-Branch traffic flow via the
Azure Firewall.
This will result in the routing configuration changes as shown in Figure 1 .
Figure 1
Next steps
For more information about how to configure virtual hub routing, see How to configure virtual hub routing.
Scenario: Secure traffic between Application
Gateway and backend pools
When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. In this scenario, a
user’s traffic enters Azure through an application gateway deployed in a spoke VNet that is connected to a
secured Virtual WAN hub (Virtual WAN hub with an Azure Firewall). The goal is to use the Azure Firewall in the
secured virtual hub to inspect traffic between the application gateway and the backend pools.
There are two specific design patterns in this scenario, depending on whether the application gateway and
backend pools are in the same VNet, or different VNets.
Scenario 1: The application gateway and backend pools are in the same virtual network peered to a Virtual
WAN hub (separate subnets).
Scenario 2: The application gateway and backend pools are in different virtual networks peered to a Virtual
WAN hub.
Scenario 1 - Same VNet

In this scenario, the application gateway and backend pools are in the same virtual network peered to a Virtual
WAN hub (separate subnets).
Workflow
Currently, routes that are advertised from the Virtual WAN route table to spoke virtual networks are applied to
the entire virtual network, and not on the subnets of the spoke VNet. As a result, user-defined routes are
necessary to enable this scenario. For information about user-defined routes (UDR), see Virtual Network custom
routes.
1. In Azure Firewall Manager, on the spoke virtual network containing the application gateway and backend
pools, select Enable Secure Internet Traffic and Enable Secure Private Traffic .
2. Configure user-defined routes (UDRs) on the application gateway subnet.
To ensure the application gateway is able to send traffic directly to the Internet, specify the
following UDR:
Address Prefix: 0.0.0.0.0/0
Next Hop: Internet
To ensure the application gateway is able to send traffic to the backend pool via Azure Firewall in
the Virtual WAN hub, specify the following UDR:
Address Prefix: Backend pool subnet (10.2.0.0/24)
Next Hop: Azure Firewall private IP
3. Configure a user-defined route (UDR) on the backend pool subnet.
Address Prefix: Application Gateway subnet
Next Hop: Azure Firewall private IP
Scenario 2 - Different VNets

In this scenario, application gateway and backend pools are in different virtual networks that are peered to a
Virtual WAN hub.
Workflow
Currently, routes that are advertised from the Virtual WAN route table to spoke virtual networks are applied to
the entire virtual network, and not on the subnets of the spoke VNet. As a result, user-defined routes are
necessary to enable this scenario. For information about user-defined routes (UDR), see Virtual Network custom
routes.
1. In Azure Firewall Manager , select Enable Secure Internet Traffic and Enable Secure Private
Traffic on both of the spoke virtual networks.
2. Configure user-defined routes (UDRs) on the application gateway subnet. To ensure the application
gateway is able to send traffic directly to the Internet, specify the following UDR:
Address Prefix: 0.0.0.0.0/0
Next Hop: Internet
Next steps
For more information about user-defined routes, see Virtual Network custom routes.
For information about Virtual WAN secured virtual hubs, see Secured virtual hubs.
Site-to-site IPsec policies
This article shows the supported IPsec policy combinations.

NOTE
When working with Default policies, Azure can act as both initiator and responder during an IPsec tunnel setup. While
Virtual WAN VPN supports many algorithm combinations, our recommendation is GCMAES256 for both IPSEC
Encryption and Integrity for optimal performance. AES256 and SHA256 are considered less performant and therefore
performance degradation such as latency and packet drops can be expected for similar algorithm types. For more
information about Virtual WAN, see the Azure Virtual WAN FAQ.
Initiator
The following sections list the supported policy combinations when Azure is the initiator for the tunnel.
Phase-1
Phase-2
Responder
The following sections list the supported policy combinations when Azure is the responder for the tunnel.
Phase-1
Phase-2
AES_256, SHA_256, PFS_1
AES_256, SHA_256, PFS_2
AES_256, SHA_256, PFS_14
AES_256, SHA_256, PFS_24
AES_128, SHA_256, PFS_1
AES_128, SHA_256, PFS_2
AES_128, SHA_256, PFS_14
Custom IPsec policies

NOTE
Next steps
For steps to configure a custom IPsec policy, see Configure a custom IPsec policy for Virtual WAN.
For more information about Virtual WAN, see About Azure Virtual WAN and the Azure Virtual WAN FAQ.
Azure path selection across multiple ISP links
Azure Virtual WAN provides a user the capability to include link information in a VPN Site, enabling scenarios
where the VPN/SD-WAN device solution can program branch-specific policies to steer traffic across various
links into Azure. This is called Azure path selection .
Architecture
To understand how Azure path selection works, let's use the example of a Virtual WAN VPN site and a site-to-
site connection.
A VPN site represents the on-premises SD-WAN/VPN device with information such as public IP, device model
and name, etc. The actual on-premises VPN site may have multiple ISP links that can also be included in Virtual
WAN VPN site information. This allows you to view the link information in Azure.
A site-to-site IPsec connection coming into a Virtual WAN’s VPN terminates on the VPN gateway instances
inside a virtual hub. A site-to-site connection represents the connectivity between the VPN site and the Azure
VPN gateway. It consists of one or more link connections. Each link connection consists of two tunnels with each
tunnel terminating on a unique instance of the Azure Virtual WAN VPN gateway. Up to four link connections can
be set up in the site-to-site connection, which makes it possible to have up to eight tunnels within a site-to-site
connection. Azure supports up to 2000 tunnels terminating inside a single Virtual WAN VPN gateway.
This figure shows multi-link at a site connecting to Azure Virtual WAN. In this diagram:
There are two ISP links at the on-premises branch (VPN/SD-WAN device). Each ISP link corresponds to a
link connection.
It assumed that the on-premises customer-manager VPN/SD-WAN device supports IKEv1 or IKEv2 IPsec.
Each Azure site-to-site Virtual WAN connection is composed of link connections within itself. A
connection supports up to four link connections. Azure charges a connection unit fee for the Virtual WAN
connection. There is no charge for the link connections.
Each link connection, in turn, consists of two IPsec tunnels that can terminate on two different instances
of the Virtual WAN VPN gateway. The gateways are set up as active-active gateways for resiliency. Each
link connection is required to have a unique IP address and BGP Peering IP. In the diagram, Tunnel 0 can
terminate on instance 0, and Tunnel 1 can terminate on instance 1.
Branch devices that provide path selection can enable appropriate policy in the branch management
solution to steer traffic across multiple links to Azure. For example, the ISP 1 link can be used for higher
priority traffic and the ISP 2 link can be used as backup.
It is important to note that Virtual HUB VPN uses ECMP (equal cost multi-path routing) across all
terminating tunnels.
Next steps
See the Azure FAQ.
Point-to-site IPsec policies
This article shows the supported IPsec policy combinations for Point-to-site VPN connectivity in Azure Virtual
WAN.

The following table shows the default IPsec parameters for Point-to-site VPN connections. These parameters are
automatically chosen by the Virtual WAN Point-to-site VPN gateway when a Point-to-site profile is created.
Phase 1 IKE Encryption AES256
Phase 1 IKE Integrity SHA256
DH Group DHGroup24
Phase 2 IPsec Encryption GCMAES256
Phase 2 IPsec Integrity GCMAES25
PFS Group PFS24
Custom IPsec policies

IKE - For Phase 1 IKE, you can select any parameter from IKE Encryption, plus any parameter from IKE
Integrity, plus any parameter from DH Group.
IPsec - For Phase 2 IPsec, you can select any parameter from IPsec Encryption, plus any parameter from
IPsec Integrity, plus PFS. If any of the parameters for IPsec Encryption or IPsec Integrity is GCM, then both
IPsec Encryption and Integrity must use the same algorithm. For example, if GCMAES128 is chosen for IPsec
Encryption, GCMAES128 must also be chosen for IPsec Integrity.
The following table shows the available IPsec parameters for Point-to-site VPN connections.
Phase 1 IKE Encryption AES128, AES256, GCMAES128, GCMAES256
Phase 1 IKE Integrity SHA256, SHA384
DH Group DHGroup14, DHGroup24, ECP256, ECP384
Phase 2 IPsec Encryption GCMAES128, GCMAES256, SHA256
Phase 2 IPsec Integrity GCMAES128, GCMAES256

PFS Group PFS14, PFS24, ECP256, ECP384
Next steps
See How to create a point-to-site connection
About client address pools for point-to-site
configurations
This article describes Virtual WAN guidelines and requirements for allocating client address spaces when the
virtual hub's point-to-site Gateway scale units are 40 or greater.
Point-to-site VPN gateways in the Virtual WAN hub are deployed with multiple instances. Each instance of a
point-to-site VPN gateway can support up to 10,000 concurrent point-to-site user connections. As a result, for
scale units greater than 40, Virtual WAN needs to deploy extra capacity, which requires a minimum number of
address pools allocated for different scale units.
For instance, if a scale unit of 100 is chosen, 5 instances are deployed for the point-to-site VPN gateway in a
virtual hub. This deployment can support 50,000 concurrent connections and at least 5 distinct address pools.
Available scale units
M IN IM UM N UM B ER O F A DDRESS
SC A L E UN IT M A XIM UM SUP P O RT ED C L IEN T S POOLS
40 20000 2
60 30000 3
80 40000 4
100 50000 5
120 60000 6
140 70000 7
160 80000 8
180 90000 9
200 100000 10
Specifying address pools

Point-to-site VPN address pool assignments are done automatically by Virtual WAN. See the following basic
guidelines for specifying address pools.
One gateway instance allows for a maximum of 10,000 concurrent connections. As such, each address pool
should contain at least 10,000 unique RFC1918 IP addresses.
Multiple address pool ranges are automatically combined and assigned to a single gateway instance. This
process is done in a round-robin manner for any gateway instances that have less than 10,000 IP addresses.
For example, a pool with 5,000 addresses can be combined automatically by Virtual WAN with another pool
that has 8,000 addresses and is assigned to a single gateway instance.
A single address pool is only assigned to a single gateway instance by Virtual WAN.
Address pools must be distinct. There can be no overlap between address pools.
NOTE
If an address pool is associated to a gateway instance that is undergoing maintenance, the address pool cannot be re-
assigned to another instance.
Example
The following example describes a situation where 60 scale units support up to 30,000 connections but the
allocated address pools results in fewer than 30,000 concurrent connections.
The total number of concurrent connections supported in this setup is 28,192. The first gateway instance
supports 10,000 addresses, the second instance 8,192 connections, and the third instance also supports 10,000
addresses.
A DDRESS P O O L N UM B ER A DDRESS P O O L SUP P O RT ED C O N N EC T IO N S
1 10.12.0.0/15 10000
2 10.13.0.0/19 8192
3 10.14.0.0/15 10000
Recommendations
Ensure address pool #2 has at least 10,000 distinct IP addresses. (example: 10.13.0.0/15)
Add one more address pool. (example: Address Pool #4 10.15.0.0/21 with 2048 addresses). Address pools 2
and 4 will be automatically combined and allow that gateway instance to support 10,000 concurrent
connections.
Configure or modify this setting

This setting is configured on the Point to site page when you create your virtual hub. You can later modify it.
To modify this setting:
Next steps
For configuration steps, see Configure P2S User VPN.
Download a global or hub-based profile for User
VPN clients
Azure Virtual WAN offers two types of connectivity for remote users: global and hub-based. Use the following
sections to learn about profile types and how to download them.
IMPORTANT
RADIUS authentication supports only the hub-based profile.
Global profile
The global profile associated with a User VPN configuration points to a load balancer that includes all active
User VPN hubs that are using that User VPN configuration. A user connected to the global profile is directed to
the hub that's closest to the user's geographic location. This type of connectivity is useful when users travel to
different locations frequently.
For example, you can associate a VPN configuration with two Virtual WAN hubs, one in West US and one in
Southeast Asia. If a user connects to the global profile associated with the User VPN configuration, they'll
connect to the closest Virtual WAN hub based on their location.
To download the global profile:
1. Go to the virtual WAN.
2. Select User VPN configurations .
3. Select the configuration for which you want to download the profile.
4. Select Download vir tual WAN user VPN profile .
Include or exclude a hub from a global profile

By default, every hub that uses a specific User VPN configuration is included in the corresponding global VPN
profile. You can choose to exclude a hub from the global VPN profile. If you do, a user won't be load balanced to
connect to that hub's gateway if they're using the global VPN profile.
To check whether or not the hub is included in the global VPN profile:
1. Go to the hub.
2. On the left panel, go to User VPN (Point to site) under Connectivity .
3. See Gateway attachment state to determine if this hub is included in the global VPN profile. If the
state is attached , the hub is included. If the state is detached , the hub is not included.
To include or exclude a specific hub from the global VPN profile:

1. Select Include/Exclude Gateway from Global Profile .
2. Make one of the following choices:

Select Exclude if you want to remove this hub's gateway from the Virtual WAN global User VPN
profile. Users who are using the hub-level User VPN profile will still be able to connect to this
gateway. Users who are using the WAN-level profile will not be able to connect to this gateway.
Select Include if you want to include this hub's gateway in the Virtual WAN global User VPN
profile. Users who are using this WAN-level profile will be able to connect to this gateway.
Hub-based profile
The profile points to a single hub. The user can connect to only the particular hub by using this profile. To
download the hub-based profile:
2. On the Over view page, select the hub.
3. Select User VPN (Point to site) .
4. Select Download vir tual Hub User VPN profile .
5. Select EAPTLS as the authentication type.

6. Select Generate and download profile .
Next steps
To learn more about Virtual WAN, see the Virtual WAN overview article.
About Virtual WAN pricing
together to provide a single operational interface. These functionalities include branch connectivity (via
connectivity, remote user VPN (Point-to-site) connectivity, private (ExpressRoute) connectivity, intra-cloud
connectivity (transitive connectivity for virtual networks), VPN ExpressRoute inter-connectivity, routing, Azure
Firewall, and encryption for private connectivity.
This article discusses three commonly deployed scenarios with Azure Virtual WAN and typical price estimates
for the deployments based on the listed prices. Additionally, there can be many other scenarios where Virtual
WAN may be useful.
IMPORTANT
The pricing shown in this article is intended to be used for example purposes only.
Pricing can change at any point. For current pricing information, see the Virtual WAN pricing page.
Inter-hub (hub-to-hub) charges do not show in the Virtual WAN pricing page because pricing is subject to Inter-
Region (Intra/Inter-continental) charges. For more information, see Azure data transfer charges.
Pricing components
The following diagram shows the typical data routes in a network involving Virtual WAN, and the different
components of pricing per hour and per GB.
VA L UE SC EN A RIO H O URLY C O ST P ER GB C O ST
1 Data transfer from a spoke Deployment hour VNet peering (outbound)

VNet to a VPN Site-to-Site ($0.25/hr) + VPN S2S Scale ($0.01/GB) + Standard
branch via Standard vWAN Unit ($0.261/hr) + VPN S2S Outbound Zone 1
hub in East US Connection Unit ($0.05/hr) ($0.087/GB) = $0.097/GB
= $0.561/hr
1' Data transfer from a VPN Deployment hour VNet peering (inbound)
Site-to-Site branch to a ($0.25/hr) + VPN S2S Scale ($0.01/GB) = $0.01/GB
spoke VNet via Standard Unit ($0.261/hr) + VPN S2S
vWAN hub in East US Connection Unit ($0.05/hr)
= $0.561/hr
2 Data transfer from a VPN Deployment hour Standard Outbound Zone 1

Site-to-Site branch via ($0.25/hr) + VPN S2S Scale ($0.087/GB) = $0.087/GB
Standard vWAN hub to Unit ($0.261/hr) + VPN S2S
another VPN Site-to-Site Connection Unit
branch in East US (2x$0.05/hr) = $0.611/hr
2' Data transfer from a VPN Deployment hour ExpressRoute Metered

Site-to-Site branch via ($0.25/hr) + VPN S2S Scale Outbound Zone 1
Standard vWAN hub to Unit ($0.261/hr) + VPN S2S ($0.025/GB) = $0.025/GB
ExpressRoute connected Connection Unit ($0.05/hr)
Data Center/ HQ in East US + ExpressRoute Scale Unit
($0.42/hr) + ExpressRoute
Connection Unit ($0.05/hr)
= $1.03/hr
3 Data transfer from a VPN Deployment hour ExpressRoute Metered

Site-to-Site branch via ($0.25/hr) + VPN S2S Scale Outbound Zone 1
Standard vWAN hub to Unit ($0.261/hr) + VPN S2S ($0.025/GB) = $0.025/GB
ExpressRoute connected Connection Unit ($0.05/hr)
Data Center/ HQ in East US + ExpressRoute Scale Unit
($0.42/hr) + ExpressRoute
Connection Unit ($0.05/hr)
= $1.03/hr

VNet to ExpressRoute ($0.25/hr) + ExpressRoute ($0.01/GB) + ExpressRoute
connected Data Center/ HQ Scale Unit ($0.42/hr) + Metered Outbound Zone 1
via Standard vWAN hub in ExpressRoute Connection ($0.025/GB) = $0.035/GB
East US Unit ($0.05/hr) = $0.72/hr
4' Data transfer from Deployment hour VNet peering (inbound)

ExpressRoute connected ($0.25/hr) + ExpressRoute ($0.01/GB) = $0.01/GB
Data Center/ HQ to a spoke Scale Unit ($0.42/hr) +
VNet via Standard vWAN ExpressRoute Connection
hub in East US Unit ($0.05/hr) = $0.72/hr
4" Data transfer from Deployment hour VNet peering (inbound)

ExpressRoute connected (2x$0.25/hr) + ($0.01/GB) + hub Data
Data Center/ HQ to a ExpressRoute Scale Unit Processing (Europe)
remote spoke VNet via ($0.42/hr) + ExpressRoute ($0.02/GB) + Inter-Region
Standard vWAN hub in Connection Unit ($0.05/hr) data transfer (East US to
Europe = $0.97/hr Europe) ($0.05/GB) =
$0.08/GB
5 Data transfer from a spoke Deployment hour VNet peering (outbound +

VNet to another spoke ($0.25/hr) = $0.25/hr inbound) (2x$0.01/GB) +
VNet via Standard vWAN hub Data Processing
hub in East US ($0.02/GB) = $0. 04/GB
6 Data transfer from a spoke Deployment hour VNet peering (outbound +

VNet connected to a hub in (2x$0.25/hr) = $0.50/hr inbound) (2x$0.01/GB) +
East US to another spoke hub Data Processing
VNet in Europe (a different (2x$0.02/GB) + Inter-
region) that is connected to Region data transfer (East
a hub in Europe US to Europe) ($0.05/GB) =
$0. 11/GB

VNet to a User VPN (Point- ($0.25/hr) + VPN P2S Scale ($0.01/GB) + Standard
to-Site) via Standard vWAN Unit ($0.261/hr) + VPN P2S Outbound Zone 1
hub in Europe Connection Unit ($0.087/GB) = $0.097/GB
($0.0125/hr) = $0.524/hr
7' Data transfer from a User Deployment hour VNet peering (inbound)
VPN (Point-to-Site) to a ($0.25/hr) + VPN P2S Scale ($0.01/GB) = $0.01/GB
spoke VNet via Standard Unit ($0.261/hr) + VPN P2S
vWAN hub in Europe Connection Unit
($0.0125/hr) = $0.524/hr
8 Data transfer from an SD- Standard vWAN hub Standard Outbound Zone 2
WAN branch via Network Deployment hour ($0.12/GB) = $0.12/GB
Virtual Appliance in hub in ($0.25/hr) + NVA
Singapore to another SD- Infrastructure Unit
WAN branch in the same ($0.25/hr) = $0.50/hr
region *Additional third-party
licensing charges may apply
Common topology scenarios

Microsoft global backbone WAN
In this scenario, you create fully meshed automatic regional hubs globally, which serve as a Microsoft backbone
for traffic connectivity globally. Typical connectivity involves endpoints such as branches (Site-to-Site VPN or
SD-WAN), remote users (Point-to-Site VPN), and private circuits (ExpressRoute). This relies on the Microsoft
backbone to carry traffic globally.
Scenario 1 diagram: Microsoft global backbone WAN
Alternatives
You can also choose to have a secured vWAN hub (includes Firewall) to become a central point of routing
and security needs for each global region.
Software -Defined Wide Area Network (SD-WAN )
In this scenario, stores moving to SD-WAN technology use vWAN hubs for automated store termination to
access resources on Azure and back on-premises (Data Center). The stores are connected via VPN tunnels to
send traffic securely through internet over the hub to the on-premises Data Center or for accessing shared apps
on Azure.
Scenario 2 diagram: Software-Defined Wide Area Network (SD-WAN)
Alternatives
You can choose to use a third-party Network Virtual Appliance in the hub and connect that to the retail
stores and centers.
You can also choose to have a secured vWAN hub (includes Firewall) to become a central point of routing
and security needs.
Remote user connectivity
In this scenario, remote user sessions terminate on vWAN hubs. These could be remote users and/or Azure
Virtual Desktop sessions from virtual networks. Currently, 100k users are supported on each hub.
The following diagram shows Point-to-Site VPN over virtual network connections for encrypted traffic across
tunnels between the spoke VNets and vWAN hub. You can also choose to have virtual network peering
connections among different spoke VNets for direct connectivity. For example, between shared and VDI spoke
VNets.
Scenario 3 diagram: Remote user connectivity
Data flow calculations

IMPORTANT
The pricing shown in this article is for example purposes only and is subject to change. For the latest pricing, see the
Virtual WAN pricing page.
Microsoft global backbone WAN calculation

In this scenario, we assumed a total of 8-TB data flowing through the global network through the vWAN hubs as
shown in the diagram below. The total data transfer costs amount to $600 for this (sum of all the data flow costs
in the diagram below, assuming metered charges for ExpressRoute), and the total hub costs (3 scale units + 3
connection units (ER) + 3 hub deployments) amount to $1534.
Scenario 1 diagram: Microsoft global backbone WAN calculation
VA L UE C A L C UL AT IO N
S2S VPN hub Singapore (1 S2S VPN scale unit ($0.361/hr) + 1 connection unit
($0.05/hr)) x 730 hours = $300 per month
ExpressRoute hub US E (1 ER scale unit ($0.42/hr) + 1 connection unit ($0.05/hr)) x

730 hours = $343 per month
ExpressRoute hub EU (1 ER scale unit ($0.42/hr) + 1 connection unit ($0.05/hr)) x

Standard hub deployment cost 3 hubs x 730 hours x $0.25/hr = $548 per month
Total $1534 per month
Software -Defined Wide Area Network (SD-WAN ) calculation

In this scenario, we assumed a total of 12-TB data flowing through the vWAN hub, as shown in the diagram
below in the US East Region. The total data transfer costs amount to $434 (sum of all the data flow costs shown
below; includes hub processing charges, peering, bandwidth, metered ER data transfer costs), and the total hub
costs (2 scale units + 3 connection units (2 S2S, 1 ER) + 1 hub deployment) amount to $863.
Scenario 2 diagram: Software-Defined Wide Area Network (SD-WAN) calculation
VPN S2S (branches) (1 S2S VPN scale unit ($0.361/hr) + 2 connection units
(2x$0.05/hr) x 730 hours = $337 per month
ExpressRoute hub (HQ) (1 ER scale unit ($0.42/hr) + 1 connection unit ($0.05/hr) x

Standard hub deployment cost 1 hub x 730 hours x $0.25/hr = $183 per month
Remote user connectivity calculation

In this scenario, we assumed a total of 15-TB data flowing through the network in the US East Region. The total
data transfer costs amount to $405 (includes hub processing charges, peering, bandwidth, metered ER data
transfer charges), and the total hub costs (2 scale units + 2 connection units + 2 hub deployments) amount to
$708.
Scenario 3 diagram: Remote user connectivity calculation
ExpressRoute hub (HQ) (1 ER scale unit ($0.42/hr) + 1 connection unit ($0.05/hr)) x

Standard hub deployment cost 2 hubs x 730 hours x $0.25/hr = $365 per month
Pricing FAQ
IMPORTANT
The pricing shown in this article is for example purposes only and is subject to change. For the latest pricing, see the
Virtual WAN pricing page.
What is a scale unit?

A scale unit provides the unit for aggregate capacity of Site-to-site (S2S), Point-to-site (P2S), and ExpressRoute
(ER) in a virtual hub. For example:
1 S2S VPN scale unit implies a total capacity of 500-Mbps VPN gateway (dual instances are deployed
for resiliency) in a virtual hub costing $0.361/hour.
1 ER scale unit implies a total of 2-Gbps ER gateway in virtual hub costing $0.42/hr.
5 ER scale units would imply a total of 10-Gbps ER gateway inside a virtual hub VNet priced at
$0.42*5/hr. ER increments $0.25/hr from the 6th to 10th scale unit.
What is a connection unit?
A connection unit applies to any on-premises/non-Microsoft endpoint connecting to Azure gateways. For Site-
to-site VPN, this value implies branches. For User VPN (Point-to-site), this value implies remote users. For
ExpressRoute, this value implies ExpressRoute circuit connections.
For example:
One branch connection connecting to Azure VPN in a virtual hub costs $0.05/hr. Therefore, 100 branch
connections connecting to an Azure virtual hub would cost $0.05*100/hr.
Two ExpressRoute circuit connections connecting to a virtual hub would cost $0.05*2/hr.
Three remote user connections connecting to the Azure virtual hub P2S gateway would cost $0.01*3/hr.
How are data transfer charges calculated?
Any traffic entering Azure is not charged. Traffic leaving Azure (via VPN, ExpressRoute, or Point-to-site
User VPN connections) is subject to the standard Azure data transfer charges or, in the case of
ExpressRoute, ExpressRoute pricing.
Peering charges are applicable when a VNet connected to a vWAN hub sends or receives data. For more
information, see Virtual Network pricing.
For data transfer charges between a Virtual WAN hub, and a remote Virtual WAN hub or VNet in a
different region than the source hub, data transfer charges apply for traffic leaving a hub. Example: Traffic
leaving an East US hub will be charged $0.02/GB going to a West US hub. There is no charge for traffic
entering the West US hub. All hub to hub traffic is subject to Inter-Region (Intra/Inter-continental) charges
Azure data transfer charges.
What is the difference between a Standard hub fee and a Standard hub processing fee?
Virtual WAN comes in two flavors:
A Basic vir tual WAN , where users can deploy multiple hubs and use VPN Site-to-site connectivity. A
Basic virtual WAN does not have advanced capabilities such as fully meshed hubs, ExpressRoute
connectivity, User VPN/Point-to-site VPN connectivity, VNet-to-VNet transitive connectivity, VPN and
ExpressRoute transit connectivity, or Azure Firewall. There is no base fee or data processing fee for hubs
in a Basic virtual WAN.
A Standard vir tual WAN provides advanced capabilities, such as fully meshed hubs, ExpressRoute
connectivity, User VPN/Point-to-site VPN connectivity, VNet-to-VNet transitive connectivity, VPN and
ExpressRoute transit connectivity, and Azure Firewall, etc. All of the virtual hub routing is provided by a
router that enables multiple services in a virtual hub. There is a base fee for the hub, which is priced at
$0.25/hr. There is also a charge for data processing in the virtual hub router for VNet-to-VNet transit
connectivity. The data processing charge in the virtual hub router is not applicable for branch-to-branch
transfers (Scenario 2, 2', 3), or VNet-to-branch transfers via the same vWAN hub (Scenario 1, 1') as
shown in the Pricing Components.
Next steps
For current pricing, see Virtual WAN pricing.
What is a secured virtual hub?
A virtual hub is a Microsoft-managed virtual network that enables connectivity from other resources. When a
virtual hub is created from a Virtual WAN in the Azure portal, a virtual hub VNet and gateways (optional) are
created as its components.
A secured virtual hub is an Azure Virtual WAN Hub with associated security and routing policies configured by
Azure Firewall Manager. Use secured virtual hubs to easily create hub-and-spoke and transitive architectures
with native security services for traffic governance and protection.
You can use a secured virtual hub to filter traffic between virtual networks (V2V), virtual networks and branch
offices (B2V) and traffic to the Internet (B2I/V2I). A secured virtual hub provides automated routing. There's no
need to configure your own UDRs (user defined routes) to route traffic through your firewall.
You can choose the required security providers to protect and govern your network traffic, including Azure
Firewall, third-party security as a service (SECaaS) providers, or both. Currently, a secured hub doesn’t support
Branch to Branch (B2B) filtering and filtering across multiple hubs. To learn more, see What is Azure Firewall
Manager?.
Create a secured virtual hub

Using Firewall Manager in the Azure portal, you can either create a new secured virtual hub, or convert an
existing virtual hub that you previously created using Azure Virtual WAN.
Gated public preview

The below features are currently in gated public preview.
F EAT URE DESC RIP T IO N
Routing Intent and Policies enabling Inter-hub security This feature allows customers to configure internet-bound,
private or inter-hub traffic flow through the Azure Firewall.
Please review Routing Intent and Policies to learn more.
Next steps
To create a secured virtual hub and use it to secure and govern a hub and spoke network, see Tutorial: Secure
your cloud network with Azure Firewall Manager using the Azure portal.
Upgrade a virtual WAN from Basic to Standard
This article helps you upgrade a Basic WAN to a Standard WAN. A 'Basic' WAN type creates all hubs inside of it
as Basic SKU hubs. In a Basic hub, you are limited to site-to-site VPN functionality only. A 'Standard' WAN type
creates all the hubs inside of it as Standard SKU hubs. When you use Standard hubs, you can enable
ExpressRoute, User (Point-to-site) VPN, a full mesh hub, and VNet-to-VNet transit through the Azure hubs.
The following table shows the configurations available for each WAN type:
VIRT UA L WA N T Y P E H UB T Y P E AVA IL A B L E C O N F IGURAT IO N S
Basic Basic Site-to-site VPN only
Standard Standard ExpressRoute

User VPN (P2S)
VPN (site-to-site)
Inter-hub and VNet-to-VNet transiting
through the virtual hub
Azure Firewall
NVA in a virtual WAN
NOTE
You can upgrade from Basic to Standard, but cannot revert from Standard back to Basic.
To change the virtual WAN type

1. On the page for your virtual WAN, select Configuration to open the Configuration page.
2. For the Virtual WAN type, select Standard from the drop-down.
3. Understand that if you upgrade to a Standard virtual WAN, you cannot revert back to a Basic virtual
WAN. Select Confirm if you want to upgrade.
4. Once the change has been saved, your virtual WAN page looks similar to this example.
Next steps
To learn more about Virtual WAN, see the Virtual WAN Overview page.
How to create a Network Virtual Appliance in an
Azure Virtual WAN hub
This article shows you how to use Virtual WAN to connect to your resources in Azure through a Network
Vir tual Appliance (NVA) in Azure. This type of connection requires a VPN device located on-premises that has
an externally facing public IP address assigned to it. For more information about Virtual WAN, see the What is
Virtual WAN?.
The steps in this article help you create a Barracuda CloudGen WAN Network Virtual Appliance in the Virtual
WAN hub. To complete this exercise, you must have a Barracuda Cloud Premise Device (CPE) and a license for
the Barracuda CloudGen WAN appliance that you deploy into the hub before you begin.
For deployment documentation of Cisco SD-WAN within Azure Virtual WAN, see Cisco Cloud OnRamp for
Multi-Cloud.
For deployment documentation of VMware SD-WAN within Azure Virtual WAN, see Deployment Guide for
VMware SD-WAN in Virtual WAN Hub
Prerequisites
Obtain a license for your Barracuda CloudGen WAN gateway. To learn more about how to do this, see the
Barracuda CloudGen WAN Documentation
your on-premises sites. If you are unfamiliar with the IP address ranges located in your on-premises
network configuration, coordinate with someone who can provide those details for you.

WAN page.
environment.
Create a hub
A hub is a virtual network that can contain gateways for site-to-site, ExpressRoute, point-to-site, or Network
Virtual Appliance functionality. Once the hub is created, you'll be charged for the hub, even if you don't attach
any sites. If you choose to create a site-to-site VPN gateway, it takes 30 minutes to create the site-to-site VPN
gateway in the virtual hub. Unlike site-to-site, ExpressRoute, or point-to-site, the hub must be created first before
you can deploy a Network Virtual Appliance into the hub VNet.
1. Locate the Virtual WAN that you created. On the Vir tual WAN page, under the Connectivity section,
select Hubs .
Project details
Region (previously referred to as Location)
Name
Hub private address space. The minimum address space is /24 to create a hub, which implies anything
range from /25 to /32 will produce an error during creation. Azure Virtual WAN, being a managed
service by Microsoft, creates the appropriate subnets in the virtual hub for the different
gateways/services. (For example: Network Virtual Appliances, VPN gateways, ExpressRoute gateways,
User VPN/Point-to-site gateways, Firewall, Routing, etc.). There is no need for the user to explicitly plan
for subnet address space for the services in the Virtual hub because Microsoft does this as a part of
the service.
5. Select Create to create the hub.
Create the Network Virtual Appliance in the hub

In this step, you will create a Network Virtual Appliance in the hub. The procedure for each NVA will be different
for each NVA partner's product. For this example, we are creating a Barracuda CloudGen WAN Gateway.
1. Locate the Virtual WAN hub you created in the previous step and open it.
2. Find the Network Virtual Appliances tile and select the Create link.
3. On the Network Vir tual Appliance blade, select Barracuda CloudGen WAN , then select the Create
button.
4. This will take you to the Azure Marketplace offer for the Barracuda CloudGen WAN gateway. Read the
terms, then select the Create button when you're ready.
5. On the Basics page you will need to provide the following information:
Subscription - Choose the subscription you used to deploy the Virtual WAN and hub.
Resource Group - Choose the same Resource Group you used to deploy the Virtual WAN and hub.
Region - Choose the same Region in which your Virtual hub resource is located.
Application Name - The Barracuda NextGen WAN is a Managed Application. Choose a name that
makes it easy to identify this resource, as this is what it will be called when it appears in your
subscription.
Managed Resource Group - This is the name of the Managed Resource Group in which Barracuda
will deploy resources that are managed by them. The name should be pre-populated for this.
6. Select the Next: CloudGen WAN gateway button.
7. Provide the following information here:
Vir tual WAN Hub - The Virtual WAN hub you want to deploy this NVA into.
NVA Infrastructure Units - Indicate the number of NVA Infrastructure Units you want to deploy this
NVA with. Choose the amount of aggregate bandwidth capacity you want to provide across all of the
branch sites that will be connecting to this hub through this NVA.
Token - Barracuda requires that you provide an authentication token here in order to identify yourself
as a registered user of this product. You'll need to obtain this from Barracuda.
8. Select the Review and Create button to proceed.
9. On this page, you will be asked to accept the terms of the Co-Admin Access agreement. This is standard
with Managed Applications where the Publisher will have access to some resources in this deployment.
Check the I agree to the terms and conditions above box, and then select Create .
Connect the VNet to the hub

In this section, you create a connection between your hub and VNet.

Next steps
To learn more about Virtual WAN, see the What is Virtual WAN? page.
To learn more about NVAs in a Virtual WAN hub, see About Network Virtual Appliance in the Virtual WAN
hub.
Connect a virtual network to a Virtual WAN hub
This article helps you connect your virtual network to your virtual hub. Repeat these steps for each VNet that
you want to connect.
NOTE
A virtual network can only be connected to one virtual hub at a time.
Add a connection
Next steps
Connect cross-tenant VNets to a Virtual Wan hub
This article helps you use Virtual WAN to connect a VNet to a virtual hub in a different tenant. This architecture
is useful if you have client workloads that must be connected to be the same network, but are on different
tenants. For example, as shown in the following diagram, you can connect a non-Contoso VNet (the Remote
Tenant) to a Contoso virtual hub (the Parent Tenant).
In this article, you learn how to:

Add another tenant as a Contributor on your Azure subscription.
Connect a cross tenant VNet to a virtual hub.
The steps for this configuration are performed using a combination of the Azure portal and PowerShell.
However, the feature itself is available in PowerShell and CLI only.
NOTE
Please note that cross-tenant Virtual Network connections can only be managed through PowerShell or CLI. You cannot
manage cross-tenant Virtual Network Connections in Azure portal.
Before You Begin

Prerequisites
To use the steps in this article, you must have the following configuration already set up in your environment:
A virtual WAN and virtual hub in your parent subscription.
A virtual network configured in a subscription in a different (remote) tenant.
Make sure that the VNet address space in the remote tenant does not overlap with any other address space
within any other VNets already connected to the parent virtual hub.
Working with Azure PowerShell
This article uses PowerShell cmdlets. To run the cmdlets, you can use Azure Cloud Shell. The Azure Cloud Shell is
a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled
and configured to use with your account.
To open the Cloud Shell, just select Tr y it from the upper right corner of a code block. You can also launch Cloud
Shell in a separate browser tab by going to https://shell.azure.com/powershell. Select Copy to copy the blocks
of code, paste it into the Cloud Shell, and press enter to run it.
Assign permissions
In order for the user administering the parent subscription with the virtual hub to be able to modify and access
the virtual networks in the remote tenant, you need to assign Contributor permissions to this user. Assigning
Contributor permissions to this user is done in the subscription of the VNET in the remote tenant.
1. Add the Contributor role assignment to the administrator (the one used to administer the virtual WAN
hub). You can use either PowerShell, or the Azure portal to assign this role. See the following Add or
remove role assignments articles for steps:
PowerShell
Portal
2. Next, add the remote tenant subscription and the parent tenant subscription to the current session of
PowerShell. Run the following command. If you are signed into the parent, you only need to run the
command for the remote tenant.
Connect-AzAccount -SubscriptionId "[subscription ID]" -TenantId "[tenant ID]"
3. Verify that the role assignment is successful by logging into Azure PowerShell using the parent
credentials, and running the following command:
Get-AzSubscription
4. If the permissions have successfully propagated to the parent and have been added to the session, the
subscription owned by the parent and remote tenant will both show up in the output of the command.
Connect VNet to hub

In the following steps, you will switch between the context of the two subscriptions as you link the virtual
network to the virtual hub. Replace the example values to reflect your own environment.
1. Make sure you are in the context of your remote account by running the following command:
Select-AzSubscription -SubscriptionId "[remote ID]"
2. Create a local variable to store the metadata of the virtual network that you want to connect to the hub.
$remote = Get-AzVirtualNetwork -Name "[vnet name]" -ResourceGroupName "[resource group name]"
3. Switch back over to the parent account.
Select-AzSubscription -SubscriptionId "[parent ID]"
4. Connect the VNet to the hub.
New-AzVirtualHubVnetConnection -ResourceGroupName "[parent resource group name]" -VirtualHubName "

[virtual hub name]" -Name "[name of connection]" -RemoteVirtualNetwork $remote
5. You can view the new connection in either PowerShell, or the Azure portal.
PowerShell: The metadata from the newly formed connection will show in the PowerShell console if
the connection was successfully formed.
Azure por tal: Navigate to the virtual hub, Connectivity -> Vir tual Network Connections . You
can view the pointer to the connection. To see the actual resource you will need the proper
permissions.
Troubleshooting
Verify that the metadata in $remote (from the preceding section) matches the information from the Azure
portal.
You can verify permissions using the IAM settings of the remote tenant resource group, or using Azure
PowerShell commands (Get-AzSubscription).
Make sure quotes are included around the names of resource groups or any other environment-specific
variables (eg. "VirtualHub1" or "VirtualNetwork1").
Next steps
For more information about Virtual WAN, see:
The Virtual WAN FAQ
Tutorial: Create an ExpressRoute association using
Azure Virtual WAN
This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an ExpressRoute
circuit. For more information about Virtual WAN and Virtual WAN resources, see the Virtual WAN Overview.
Create a hub and a gateway
Connect a circuit to a hub gateway
Test connectivity
Change a gateway size
Advertise a default route
Prerequisites
on-premises. If you are unfamiliar with the IP address ranges located in your on-premises network
The ExpressRoute circuit must be a Premium or Standard circuit in order to connect to the hub gateway.

2. Select Vir tual WAN from the results. On the Virtual WAN page, click Create to open the Create WAN
page.
3. On the Create WAN page, on the Basics tab, fill in the following fields:
Resource group location - Choose a resource location from the dropdown. A WAN is a global
resource and does not live in a particular region. However, you must select a region in order to more
easily manage and locate the WAN resource that you create.
Name - Type the name that you want to call your WAN.
Type - Select Standard . You can't create an ExpressRoute gateway using the Basic SKU.
4. After you finish filling out the fields, select Review +Create .
5. Once validation passes, select Create to create the virtual WAN.

A virtual hub is a virtual network that is created and used by Virtual WAN. It can contain various gateways, such
as VPN and ExpressRoute. In this section, you will create an ExpressRoute gateway for your virtual hub. You can
either create the gateway when you create a new virtual hub, or you can create the gateway in an existing hub
by editing it.
ExpressRoute gateways are provisioned in units of 2 Gbps. 1 scale unit = 2 Gbps with support up to 10 scale
units = 20 Gbps. It takes about 30 minutes for a virtual hub and gateway to fully create.
To create a new virtual hub and a gateway
Create a new virtual hub. Once a hub is created, you'll be charged for the hub, even if you don't attach any sites.
select Hubs . Click New Hub to open the Create vir tual hub page.
2. On the Create vir tual hub page, fill in the fields.
3. Select the ExpressRoute tab . Click Yes to reveal settings and fill out the field. For information about
gateway scale units, see the FAQ.
5. Select Create to create the hub with an ExpressRoute gateway. A hub can take about 30 minutes to
complete. After 30 minutes, Refresh to view the hub on the Hubs page. Select Go to resource to
navigate to the resource.
To create a gateway in an existing hub
You can also create a gateway in an existing hub by editing it.
1. Navigate to the virtual hub that you want to edit and select it.
2. On the Edit vir tual hub page, select the checkbox Include ExpressRoute gateway .
3. Select Confirm to confirm your changes. It takes about 30 minutes for the hub and hub resources to
fully create.
To view a gateway
Once you have created an ExpressRoute gateway, you can view gateway details. Navigate to the hub, select
ExpressRoute , and view the gateway.
Connect your VNet to the hub

In this section, you create the peering connection between your hub and a VNet. Repeat these steps for each
VNet that you want to connect.
1. On the page for your virtual WAN, click Vir tual network connection .
cannot have an already existing virtual network gateway (neither VPN, nor ExpressRoute).
Connect your circuit to the hub gateway

Once the gateway is created, you can connect an ExpressRoute circuit to it. ExpressRoute Standard or Premium
circuits that are in ExpressRoute Global Reach-supported locations can connect to a Virtual WAN ExpressRoute
gateway and enjoy all Virtual WAN transit capabilities (VPN-to-VPN, VPN, and ExpressRoute transit).
ExpressRoute Standard and Premium circuits that are in non-Global Reach locations can connect to Azure
resources, but will not be able to use Virtual WAN transit capabilities. ExpressRoute Local is also supported with
Azure Virtual WAN hubs.
To connect the circuit to the hub gateway
In the portal, go to the Vir tual hub -> Connectivity -> ExpressRoute page. If you have access in your
subscription to an ExpressRoute circuit, you will see the circuit you want to use in the list of circuits. If you don’t
see any circuits, but have been provided with an authorization key and peer circuit URI, you can redeem and
connect a circuit. See To connect by redeeming an authorization key.
1. Select the circuit.
2. Select Connect circuit(s) .
To connect by redeeming an authorization key

Use the authorization key and circuit URI you were provided in order to connect.
1. On the ExpressRoute page, click +Redeem authorization key
2. On the Redeem authorization key page, fill in the values.
3. Select Add to add the key.

4. View the circuit. A redeemed circuit only shows the name (without the type, provider and other
information) because it is in a different subscription than that of the user.
To test connectivity
After the circuit connection is established, the hub connection status will indicate 'this hub', implying the
connection is established to the hub ExpressRoute gateway. Wait approximately 5 minutes before you test
connectivity from a client behind your ExpressRoute circuit, for example, a VM in the VNet that you created
earlier.
If you have sites connected to a Virtual WAN VPN gateway in the same hub as the ExpressRoute gateway, you
can have bidirectional connectivity between VPN and ExpressRoute end points. Dynamic routing (BGP) is
supported. The ASN of the gateways in the hub is fixed and cannot be edited at this time.
To change the size of a gateway

If you want to change the size of your ExpressRoute gateway, locate the ExpressRoute gateway inside the hub,
and select the scale units from the dropdown. Save your change. It will take approximately 30 minutes to update
the hub gateway.
To advertise default route 0.0.0.0/0 to endpoints

If you would like the Azure virtual hub to advertise the default route 0.0.0.0/0 to your ExpressRoute end points,
you will need to enable 'Propagate default route'.
1. Select your Circuit ->…-> Edit connection .
2. Select Enable to propagate the default route.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Virtual WAN FAQ
ExpressRoute encryption: IPsec over ExpressRoute
for Virtual WAN
This article shows you how to use Azure Virtual WAN to establish an IPsec/IKE VPN connection from your on-
premises network to Azure over the private peering of an Azure ExpressRoute circuit. This technique can provide
an encrypted transit between the on-premises networks and Azure virtual networks over ExpressRoute, without
going over the public internet or using public IP addresses.
Topology and routing

The following diagram shows an example of VPN connectivity over ExpressRoute private peering:
The diagram shows a network within the on-premises network connected to the Azure hub VPN gateway over
ExpressRoute private peering. The connectivity establishment is straightforward:
1. Establish ExpressRoute connectivity with an ExpressRoute circuit and private peering.
2. Establish the VPN connectivity as described in this article.
An important aspect of this configuration is routing between the on-premises networks and Azure over both the
ExpressRoute and VPN paths.
Traffic from on-premises networks to Azure
For traffic from on-premises networks to Azure, the Azure prefixes (including the virtual hub and all the spoke
virtual networks connected to the hub) are advertised via both the ExpressRoute private peering BGP and the
VPN BGP. This results in two network routes (paths) toward Azure from the on-premises networks:
One over the IPsec-protected path
One directly over ExpressRoute without IPsec protection
To apply encryption to the communication, you must make sure that for the VPN-connected network in the
diagram, the Azure routes via on-premises VPN gateway are preferred over the direct ExpressRoute path.
Traffic from Azure to on-premises networks
The same requirement applies to the traffic from Azure to on-premises networks. To ensure that the IPsec path is
preferred over the direct ExpressRoute path (without IPsec), you have two options:
Advertise more specific prefixes on the VPN BGP session for the VPN-connected network. You can
advertise a larger range that encompasses the VPN-connected network over ExpressRoute private
peering, then more specific ranges in the VPN BGP session. For example, advertise 10.0.0.0/16 over
ExpressRoute, and 10.0.1.0/24 over VPN.
Advertise disjoint prefixes for VPN and ExpressRoute. If the VPN-connected network ranges are disjoint
from other ExpressRoute connected networks, you can advertise the prefixes in the VPN and
ExpressRoute BGP sessions respectively. For example, advertise 10.0.0.0/24 over ExpressRoute, and
10.0.1.0/24 over VPN.
In both of these examples, Azure will send traffic to 10.0.1.0/24 over the VPN connection rather than directly
over ExpressRoute without VPN protection.
WARNING
If you advertise the same prefixes over both ExpressRoute and VPN connections, Azure will use the ExpressRoute path
directly without VPN protection.
Before you begin

Before you start your configuration, verify that you meet the following criteria:
If you already have virtual network that you want to connect to, verify that none of the subnets of your on-
premises network overlap with it. Your virtual network doesn't require a gateway subnet and can't have any
virtual network gateways. If you don't have a virtual network, you can create one by using the steps in this
article.
Obtain an IP address range for your hub region. The hub is a virtual network, and the address range that you
specify for the hub region can't overlap with an existing virtual network that you connect to. It also can't
overlap with the address ranges that you connect to on-premises. If you're unfamiliar with the IP address
ranges located in your on-premises network configuration, coordinate with someone who can provide those
details for you.
1. Create a virtual WAN and hub with gateways

The following Azure resources and the corresponding on-premises configurations must be in place before you
proceed:
An Azure virtual WAN
A virtual WAN hub with an ExpressRoute gateway and a VPN gateway
For the steps to create an Azure virtual WAN and a hub with an ExpressRoute association, see Create an
ExpressRoute association using Azure Virtual WAN. For the steps to create a VPN gateway in the virtual WAN,
see Create a site-to-site connection using Azure Virtual WAN.
2. Create a site for the on-premises network

The site resource is the same as the non-ExpressRoute VPN sites for a virtual WAN. The IP address of the on-
premises VPN device can now be either a private IP address, or a public IP address in the on-premises network
reachable via ExpressRoute private peering created in step 1.
NOTE
The IP address for the on-premises VPN device must be part of the address prefixes advertised to the virtual WAN hub
via Azure ExpressRoute private peering.
1. Go to the Azure portal in your browser.

2. Select the hub that you created. On the virtual WAN hub page, under Connectivity , select VPN sites .
3. On the VPN sites page, select +Create site .
4. On the Create site page, fill in the following fields:
Resource Group : Select or create the resource group that you want to use.
Region : Enter the Azure region for the VPN site resource.
Name : Enter the name by which you want to refer to your on-premises site.
Device vendor : Enter the vendor of the on-premises VPN device.
Border Gateway Protocol : Select "Enable" if your on-premises network uses BGP.
Private address space : Enter the IP address space that's located on your on-premises site. Traffic
destined for this address space is routed to the on-premises network via the VPN gateway.
Hubs : Select one or more hubs to connect this VPN site. The selected hubs must have VPN gateways
already created.
5. Select Next: Links > for the VPN link settings:
Link Name : The name by which you want to refer to this connection.
Provider Name : The name of the internet service provider for this site. For an ExpressRoute on-
premises network, it's the name of the ExpressRoute service provider.
Speed : The speed of the internet service link or ExpressRoute circuit.
IP address : The public IP address of the VPN device that resides on your on-premises site. Or, for
ExpressRoute on-premises, it's the private IP address of the VPN device via ExpressRoute.
If BGP is enabled, it will apply to all connections created for this site in Azure. Configuring BGP on a
virtual WAN is equivalent to configuring BGP on an Azure VPN gateway.
Your on-premises BGP peer address must not be the same as the IP address of your VPN to the device or
the virtual network address space of the VPN site. Use a different IP address on the VPN device for your
BGP peer IP. It can be an address assigned to the loopback interface on the device. However, it can't be an
APIPA (169.254.x.x) address. Specify this address in the corresponding VPN site that represents the
location. For BGP prerequisites, see About BGP with Azure VPN Gateway.
6. Select Next: Review + create > to check the setting values and create the VPN site. If you selected
Hubs to connect, the connection will be established between the on-premises network and the hub VPN
gateway.
3. Update the VPN connection setting to use ExpressRoute

After you create the VPN site and connect to the hub, use the following steps to configure the connection to use
ExpressRoute private peering:
1. Go back to the virtual WAN resource page, and select the hub resource. Or navigate from the VPN site to
the connected hub.
2. Under Connectivity , select VPN (Site-to-Site) .
3. Select the ellipsis (...) on the VPN site over ExpressRoute, and select Edit VPN connection to this hub .
4. For Use Azure Private IP Address , select Yes . The setting configures the hub VPN gateway to use
private IP addresses within the hub address range on the gateway for this connection, instead of the
public IP addresses. This will ensure that the traffic from the on-premises network traverses the
ExpressRoute private peering paths rather than using the public internet for this VPN connection. The
following screenshot shows the setting:
5. Select Save .
After you save your changes, the hub VPN gateway will use the private IP addresses on the VPN gateway to
establish the IPsec/IKE connections with the on-premises VPN device over ExpressRoute.
4. Get the private IP addresses for the hub VPN gateway

Download the VPN device configuration to get the private IP addresses of the hub VPN gateway. You need these
addresses to configure the on-premises VPN device.
1. On the page for your hub, select VPN (Site-to-Site) under Connectivity .
2. At the top of the Over view page, select Download VPN Config .
Azure creates a storage account in the resource group "microsoft-network-[location]," where location is
the location of the WAN. After you apply the configuration to your VPN devices, you can delete this
storage account.
3. After the file is created, select the link to download it.
4. Apply the configuration to your VPN device.
VPN device configuration file
The device configuration file contains the settings to use when you're configuring your on-premises VPN device.
When you view this file, notice the following information:
vpnSiteConfiguration : This section denotes the device details set up as a site that's connecting to the
virtual WAN. It includes the name and public IP address of the branch device.
vpnSiteConnections : This section provides information about the following settings:
Address space of the virtual hub's virtual network.
Example: "AddressSpace":"10.51.230.0/24"
Address space of the virtual networks that are connected to the hub.
Example: "ConnectedSubnets":["10.51.231.0/24"]
IP addresses of the virtual hub's VPN gateway. Because each connection of the VPN gateway is
composed of two tunnels in active-active configuration, you'll see both IP addresses listed in this file.
In this example, you see Instance0 and Instance1 for each site, and they're private IP addresses
instead of public IP addresses.
Example: "Instance0":"10.51.230.4" "Instance1":"10.51.230.5"
Configuration details for the VPN gateway connection, such as BGP and pre-shared key. The pre-
shared key is automatically generated for you. You can always edit the connection on the Over view
page for a custom pre-shared key.
[{
"Version":"5b096293-edc3-42f1-8f73-68c14a7c4db3"
},
"Name":"VPN-over-ER-site",
"IPAddress":"172.24.127.211",
"LinkName":"VPN-over-ER"
},
"vpnSiteConnections":[{
"AddressSpace":"10.51.230.0/24",
"Region":"West US 2",
"ConnectedSubnets":["10.51.231.0/24"]
},
"IpAddresses":{
"Instance0":"10.51.230.4",
"Instance1":"10.51.230.5"
}
},
"PSK":"abc123",
"IPsecParameters":{"SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":3600}
}
}]
},
{
"Version":"fbdb34ea-45f8-425b-9bc2-4751c2c4fee0"
},
"Name":"VPN-over-INet-site",
"IPAddress":"13.75.195.234",
"LinkName":"VPN-over-INet"
},
"vpnSiteConnections":[{
"AddressSpace":"10.51.230.0/24",
"Region":"West US 2",
"ConnectedSubnets":["10.51.231.0/24"]
},
"IpAddresses":{
"Instance0":"51.143.63.104",
"Instance1":"52.137.90.89"
}
},
"PSK":"abc123",
"IPsecParameters":{"SADataSizeInKilobytes":102400000,"SALifeTimeInSeconds":3600}
}
}]
}]

The instructions on the VPN device page are not written for a virtual WAN. But you can use the virtual WAN
values from the configuration file to manually configure your VPN device.
The downloadable device configuration scripts that are for the VPN gateway don't work for the virtual WAN,
because the configuration is different.
A new virtual WAN can support both IKEv1 and IKEv2.
A virtual WAN can use only route-based VPN devices and device instructions.
5. View your virtual WAN

3. In the Hubs and connections section, you can view hub, site, region, and VPN connection status. You can
also view bytes in and out.
6. Monitor a connection
Create a connection to monitor communication between an Azure virtual machine (VM) and a remote site. For
information about how to set up a connection monitor, see Monitor network communication. The source field is
the VM IP in Azure, and the destination IP is the site IP.
7. Clean up resources
When you no longer need these resources, you can use Remove-AzResourceGroup to remove the resource
group and all of the resources that it contains. Run the following PowerShell command, and replace
myResourceGroup with the name of your resource group:
Remove-AzResourceGroup -Name myResourceGroup -Force
Next steps
This article helps you create a VPN connection over ExpressRoute private peering by using Virtual WAN. To learn
more about Virtual WAN and related features, see the Virtual WAN overview.
Tutorial: Create a Site-to-Site connection using
Azure Virtual WAN
This tutorial shows you how to use Virtual WAN to connect to your resources in Azure over an IPsec/IKE (IKEv1
and IKEv2) VPN connection. This type of connection requires a VPN device located on-premises that has an
externally facing public IP address assigned to it. For more information about Virtual WAN, see the Virtual WAN
Overview.
In this tutorial you learn how to:
Configure hub Basic settings
Configure site-to-site VPN gateway settings
Create a site
Connect a site to a hub
Connect a VPN site to a hub
Download a configuration file
View or edit your VPN gateway
NOTE
If you have many sites, you typically would use a Virtual WAN partner to create this configuration. However, you can
create this configuration yourself if you are comfortable with networking and proficient at configuring your own VPN
device.
Prerequisites

WAN page.
environment.

Configure hub settings

For this tutorial, you begin by filling out the Basics tab for the virtual hub and then continue on to fill out the
site-to-site tab in the next section. Note that it is possible to create an empty hub (a hub that does not contain
any gateways) and then add gateways (S2S, P2S, ExpressRoute, etc.) later. Once a hub is created, you'll be
charged for the hub, even if you don't attach any sites or create any gateways within the hub.
select Hubs .
your virtual hub.
Configure a site-to-site gateway
In this section, you configure site-to-site connectivity settings, and then proceed to create the hub and site-to-
site VPN gateway. A hub and gateway can take about 30 minutes to create.
1. On the Create vir tual hub page, click Site to site to open the Site to site tab.
2. On the Site to site tab, complete the following fields:

Select Yes to create a Site-to-site VPN.
AS Number : The AS Number field cannot be edited.
Gateway scale units : Select the Gateway scale units value from the dropdown. The scale unit
lets you pick the aggregate throughput of the VPN gateway being created in the virtual hub to
connect sites to.
If you pick 1 scale unit = 500 Mbps, it implies that two instances for redundancy will be created,
each having a maximum throughput of 500 Mbps. For example, if you had five branches, each
doing 10 Mbps at the branch, you will need an aggregate of 50 Mbps at the head end. Planning for
aggregate capacity of the Azure VPN gateway should be done after assessing the capacity needed
to support the number of branches to the hub.
Routing preference : Azure routing preference lets you to choose how your traffic routes
between Azure and the internet. You can choose to route traffic either via the Microsoft network, or
via the ISP network (public internet). These options are also referred to as cold potato routing and
hot potato routing, respectively.
The public IP address in Virtual WAN is assigned by the service, based on the routing option
selected. For more information about routing preference via Microsoft network or ISP, see the
Routing preference article.
4. Select Create to create the hub and gateway. This can take up to 30 minutes. After 30 minutes, Refresh
to view the hub on the Hubs page. Select Go to resource to navigate to the resource.
Create a site
In this section, you create site. Sites correspond to your physical locations. Create as many sites as you need. For
example, if you have a branch office in NY, a branch office in London, and a branch office and LA, you'd create
three separate sites. These sites contain your on-premises VPN device endpoints. You can create up to 1000 sites
per virtual hub in a virtual WAN. If you had multiple hubs, you can create 1000 per each of those hubs. If you
have Virtual WAN partner CPE device, check with them to learn about their automation to Azure. Typically,
automation implies a simple click experience to export large-scale branch information into Azure, and setting up
connectivity from the CPE to Azure Virtual WAN VPN gateway. For more information, see Automation guidance
from Azure to CPE partners.
1. Navigate to your Vir tual WAN -> VPN sites to open the VPN sites page.
2. On the VPN sites page, click +Create site .
3. On the Create VPN Site page, on the Basics tab, complete the following fields:
Region : Previously referred to as location. This is the location you want to create this site resource
in.
Name : The name by which you want to refer to your on-premises site.
Device vendor : The name of the VPN device vendor (for example: Citrix, Cisco, Barracuda).
Adding the device vendor can help the Azure Team better understand your environment in order
to add additional optimization possibilities in the future, or to help you troubleshoot.
Private address space : The IP address space that is located on your on-premises site. Traffic
destined for this address space is routed to your local site. This is required when BGP is not
enabled for the site.
NOTE
If you edit the address space after creating the site (for example, add an additional address space) it can
take 8-10 minutes to update the effective routes while the components are recreated.
4. Select Links to add information about the physical links at the branch. If you have a Virtual WAN partner
CPE device, check with them to see if this information is exchanged with Azure as a part of the branch
information upload set up from their systems.
Link Name : A name you want to provide for the physical link at the VPN Site. Example: mylink1.
Link speed : This is the speed of the VPN device at the branch location. Example: 50, which means
50 Mbps is the speed of the VPN device at the branch site.
Link provider name : The name of the physical link at the VPN Site. Example: ATT, Verizon.
Link IP address/FQDN : Public IP address of the on-premises device using this link. Optionally,
you can provide the private IP address of your on-premises VPN device that is behind
ExpressRoute. You can also include a fully qualified domain name. For example,
something.contoso.com. The FQDN should be resolvable from the VPN gateway. This is possible if
the DNS server hosting this FQDN is reachable over internet. IP address takes precedence when
both IP address and FQDN are specified.
NOTE
Supports one IPv4 address per FQDN. If the FQDN were to be resolved to multiple IP addresses,
then the VPN gateway picks up the first IP4 address from the list. IPv6 addresses are not
supported at this time.
VPN gateway maintains a DNS cache which is refreshed every 5 minutes. The gateway tries to
resolve FQDNs for disconnected tunnels only. A gateway reset or configuration change can also
trigger FQDN resolution.
Link Border Gateway Protocol : Configuring BGP on a virtual WAN link is equivalent to
configuring BGP on an Azure virtual network gateway VPN. Your on-premises BGP peer address
must not be the same as the public IP address of your VPN to device or the VNet address space of
the VPN site. Use a different IP address on the VPN device for your BGP peer IP. It can be an
address assigned to the loopback interface on the device. Specify this address in the
corresponding VPN site representing the location. For BGP prerequisites, see About BGP with
Azure VPN Gateway. You can always edit a VPN link connection to update its BGP parameters
(Peering IP on the link and the AS #).
5. You can add or delete more links. Four links per VPN Site are supported. For example, if you have four
ISPs (Internet service provider) at the branch location, you can create four links, one per each ISP, and
provide the information for each link.
6. Once you have finished filling out the fields, select Review + create to verify. Click Create to create the
site.
7. On the VPN sites page, click Hub association: Connected to this hub to clear the filter.
8. Once the filter has cleared, you can view your site.

In this section, you connect your VPN site to the hub.
1. Navigate to your Vir tual HUB -> VPN (Site to site) .
2. You may need to click Hub association: Connected to this hub in order to clear the filters and view
your sites.
3. Select the checkbox for the site that you want to connect, then click Connect VPN sites .
4. On the Connect sites page, configure the required settings.

Pre-shared key (PSK) : Enter the pre-shared key used by your VPN device. If you don't enter a
key, Azure autogenerates one for you. You would then use that key when configuring your VPN
device.
Protocol and IPsec : You can either leave the default settings for Protocol (IKEv2) and IPsec
(Default), or you can configure custom settings. For more information, see default/custom IPsec.
Propagate Default Route : Only change this setting to Enable if you know you want to
propagate the default route. Otherwise, leave it as Disable . You can always modify this setting
later.
The Enable option allows the virtual hub to propagate a learned default route to this connection.
This flag enables default route propagation to a connection only if the default route 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. The default route does not originate in the Virtual
WAN hub.
Use policy based traffic selector : Leave this setting as Disable unless you are configuring a
connection to a device that uses this setting.
5. At the bottom of the page, click Connect .
6. Once you click Connect , the connectivity status shows Updating . After updating completes, the site will
show the connection and connectivity status.
Connection Provisioning status : This is the status of the Azure resource for the connection that
connects the VPN site to the Azure hub’s VPN gateway. Once this control plane operation is successful,
Azure VPN gateway and the on-premises VPN device will proceed to establish connectivity.
Connectivity status : This is the actual connectivity (data path) status between Azure’s VPN gateway in
the hub and VPN site. After updating is completed, it can show any of the following states:
Unknown : This state is typically seen if the backend systems are working to transition to another
status.
Connecting : The VPN gateway is trying to reach out to the actual on-premises VPN site.
Connected : Connectivity is established between VPN gateway and the on-premises VPN site.
Not connected : Connectivity is not established.
Disconnected : This status is seen if, for any reason (on-premises or in Azure), the connection was
disconnected.
7. If you want to make changes to your site, select your site, then click the ... context menu.
From this page, you can do the following:

Edit or delete the VPN Connection.
Delete the VPN connection to this hub.
Download a branch-specific configuration for details about the Azure site. If you want to download the
configuration file that pertains to all connected sites in your hub, select Download VPN Config from
the menu at the top of the page instead.
Connect a VNet to the hub

In this section, you create a connection between the hub and your VNet.
Download VPN configuration

Use the VPN device configuration file to configure your on-premises VPN device. The basic steps are listed
below. The information about what the configuration file contains and how to configure your VPN device are
1. Navigate to your Vir tual HUB -> VPN (Site to site) page.
2. At the top of the VPN (Site to site) page, click Download VPN Config . You will see a series of
messages as Azure creates a storage account in the resource group 'microsoft-network-[location]', where
location is the location of the WAN.
3. Once the file has finished creating, click the link to download the file. To learn about the contents of the
file, see About the VPN device configuration file in this section.
4. Apply the configuration to your on-premises VPN device. For more information, see VPN device
configuration in this section.
5. After you have applied the configuration to your VPN devices, it isn't necessary to keep the storage
account that Azure created. You can delete it.
About the VPN device configuration file
vpnSiteConnections - This section provides information about the following settings:
Example:

Example:
IP addresses of the virtual hub vpngateway. Because each connection of the vpngateway is
composed of two tunnels in active-active configuration, you'll see both IP addresses listed in this
Example:
"Instance0":"104.45.18.186"
"Instance1":"104.45.13.195"
{
},
"Name":"testsite1",
"IPAddress":"73.239.3.208"
},
{
"10.2.0.0/16",
"10.3.0.0/16"
]
]
},
"IpAddresses":{
"Instance0":"104.45.18.186",
"Instance1":"104.45.13.195"
}
},
"IPsecParameters":{
}
}
}
]
},
{
},
"IPAddress":"66.193.205.122"
},
{
},
"IpAddresses":{
"Instance0":"104.45.18.187",
"Instance1":"104.45.13.195"
}
},
"IPsecParameters":{
}
}
}
]
},
{
},
"IPAddress":"182.71.123.228"
},
{
},
"IpAddresses":{
"Instance0":"104.45.18.187",
"Instance1":"104.45.13.195"
}
},
"IPsecParameters":{
}
}
}
]
}
NOTE
If you are working with a Virtual WAN partner solution, VPN device configuration automatically happens. The device
controller obtains the configuration file from Azure and applies to the device to set up connection to Azure. This means
you don't need to know how to manually configure your VPN device.
The instructions on the VPN devices page are not written for Virtual WAN, but you can use the Virtual
WAN values from the configuration file to manually configure your VPN device.
The downloadable device configuration scripts that are for VPN Gateway do not work for Virtual WAN, as
the configuration is different.
A new Virtual WAN can support both IKEv1 and IKEv2.
Virtual WAN can use both policy based and route-based VPN devices and device instructions.
View or edit gateway settings

You can view and edit your VPN gateway settings at any time by navigating to Vir tual HUB -> VPN (Site to
site) and selecting View/Configure .
On the Edit VPN Gateway page, you can see the following settings:
Public IP Address : Assigned by Azure.
Private IP Address : Assigned by Azure.
Default BGP IP Address : Assigned by Azure.
Custom BGP IP Address : This field is reserved for APIPA (Automatic Private IP Addressing). Azure
supports BGP IP in the ranges 169.254.21.* and 169.254.22.*. Azure accepts BGP connections in these
ranges but will dial connection with the default BGP IP.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Virtual WAN FAQ
Create a Site-to-Site connection to Azure Virtual
WAN using PowerShell
This article shows you how to use Virtual WAN to connect to your resources in Azure over an IPsec/IKE (IKEv1
and IKEv2) VPN connection via PowerShell. This type of connection requires a VPN device located on-premises
that has an externally facing public IP address assigned to it. For more information about Virtual WAN, see the
Virtual WAN Overview.
Prerequisites
Verify that you have an Azure subscription. If you don't already have an Azure subscription, you can
activate your MSDN subscriber benefits or sign up for a free account.
Azure PowerShell
You can also install and run the Azure PowerShell cmdlets locally on your computer. PowerShell cmdlets are
updated frequently. If you have not installed the latest version, the values specified in the instructions may fail.
To find the versions of Azure PowerShell installed on your computer, use the Get-Module -ListAvailable Az
cmdlet. To install or update, see Install the Azure PowerShell module.
Sign in
If you are running PowerShell locally, open the PowerShell console with elevated privileges and connect to your
Azure account. The Connect-AzAccount cmdlet prompts you for credentials. After authenticating, it downloads
your account settings so that they are available to Azure PowerShell.
If you are using Azure Cloud Shell instead of running PowerShell locally, you will notice that you don't need to
run Connect-AzAccount. Azure Cloud Shell connects to your Azure account automatically after you select Tr y It .
1. If you are running PowerShell locally, sign in.
Connect-AzAccount
2. If you have more than one subscription, get a list of your Azure subscriptions.
Get-AzSubscription
3. Specify the subscription that you want to use.
Select-AzSubscription -SubscriptionName "Name of subscription"

Before you can create a virtual wan, you have to create a resource group to host the virtual wan or use an
existing resource group. Create a resource group with New-AzResourceGroup. This example creates a new
resource group named testRG in the West US location:
Create a resource group:
New-AzResourceGroup -Location "West US" -Name "testRG"
Create the virtual wan:
$virtualWan = New-AzVirtualWan -ResourceGroupName testRG -Name myVirtualWAN -Location "West US"
To create the virtual wan in an already existing resource group

Use the steps in this section if you need to create the virtual wan in an already existing resource group.
1. Set the variables for the existing resource group
$resourceGroup = Get-AzResourceGroup -ResourceGroupName "testRG"
2. Create the virtual wan.

Create the hub and configure hub settings
Create a virtual hub with New-AzVirtualHub. This example creates a default virtual hub named westushub with
the specified address prefix and a location for the hub:
$virtualHub = New-AzVirtualHub -VirtualWan $virtualWan -ResourceGroupName "testRG" -Name "westushub" -

AddressPrefix "10.11.0.0/24" -Location "westus"
Create a site-to-site VPN gateway

In this section, you create a site-to-site VPN gateway that will be in the same location as the referenced
VirtualHub. The site-to-site VPN gateway scales based on the scale unit specified and can take about 30 minutes
to create.
New-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw" -VirtualHubId $virtualHub.Id -

VpnGatewayScaleUnit 2
Once your VPNgateway is created, you can view it using the following example.
Get-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw"
Create a site and the connections

In this section, you create sites that correspond to your physical locations and the connections. These sites
contain your on-premises VPN device endpoints, you can create up to 1000 sites per virtual hub in a virtual
WAN. If you have multiple hubs, you can create 1000 per each of those hubs.
Set the variable for the vpnGateway and for the IP address space that is located on your on-premises site, traffic
destined for this address space is routed to your local site. This is required when BGP is not enabled for the site:
$vpnGateway = Get-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw"

$vpnSiteAddressSpaces = New-Object string[] 2
$vpnSiteAddressSpaces[0] = "192.168.2.0/24"
$vpnSiteAddressSpaces[1] = "192.168.3.0/24"
Create Links to add information about the physical links at the branch including metadata about the link speed,
link provider name and add the public IP address of the on-premise device.
$vpnSiteLink1 = New-AzVpnSiteLink -Name "testVpnSiteLink1" -IpAddress "15.25.35.45" -LinkProviderName

"SomeTelecomProvider" -LinkSpeedInMbps "10"
$vpnSiteLink2 = New-AzVpnSiteLink -Name "testVpnSiteLink2" -IpAddress "15.25.35.55" -LinkProviderName
"SomeTelecomProvider2" -LinkSpeedInMbps "100"
Create the vpnSite and reference the variables of the vpnSiteLinks just created:
$vpnSite = New-AzVpnSite -ResourceGroupName "testRG" -Name "testVpnSite" -Location "West US" -VirtualWan
$virtualWan -AddressSpace $vpnSiteAddressSpaces -DeviceModel "SomeDevice" -DeviceVendor "SomeDeviceVendor" -
VpnSiteLink @($vpnSiteLink1, $vpnSiteLink2)
Next is the Vpn Site Link connection which is composed of 2 Active-Active tunnels from a branch/Site known as
VPNSite to the scalable gateway:
$vpnSiteLinkConnection1 = New-AzVpnSiteLinkConnection -Name "testLinkConnection1" -VpnSiteLink

$vpnSite.VpnSiteLinks[0] -ConnectionBandwidth 100
$vpnSiteLinkConnection2 = New-AzVpnSiteLinkConnection -Name "testLinkConnection2" -VpnSiteLink
$vpnSite.VpnSiteLinks[1] -ConnectionBandwidth 10

Finally, you connect your VPN site to the hub Site-to-Site VPN gateway:
New-AzVpnConnection -ResourceGroupName $vpnGateway.ResourceGroupName -ParentResourceName $vpnGateway.Name -

Name "testConnection" -VpnSite $vpnSite -VpnSiteLinkConnection @($vpnSiteLinkConnection1,
$vpnSiteLinkConnection2)
Clean up resources
1. Declare the variables

$virtualWan = Get-AzVirtualWan -ResourceGroupName "testRG" -Name "myVirtualWAN"
$virtualHub = Get-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub"
2. Delete all gateway entities following the below order for the VPN gateway. This can take 30 minutes to
complete.
Delete the VPN Gateway connection to the VPN Sites.
Remove-AzVpnConnection -ResourceGroupName $vpnGateway.ResourceGroupName -ParentResourceName

$vpnGateway.Name -Name "testConnection"
Delete the VPN Gateway. Note that deleting a VPN Gateway will also remove all VPN Express Route
Connections associated with it.
Remove-AzVpnGateway -ResourceGroupName "testRG" -Name "testvpngw"
3. You can delete the Resource Group to delete all the other resources in the resource group, including the
hubs, sites and the virtual WAN.
Remove-AzResourceGroup -Name "testRG"
4. Or you can choose to delete each of the resources in the Resource Group
Delete the VPN site
Remove-AzVpnSite -ResourceGroupName "testRG" -Name "testVpnSite"
Delete the Virtual Hub

Remove-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub"
Delete the Virtual WAN
Remove-AzVirtualWan -Name "MyVirtualWan" -ResourceGroupName "testRG"
Next steps
Virtual WAN FAQ
Connect a VPN Gateway (virtual network gateway)
to Virtual WAN
This article helps you set up connectivity from an Azure VPN Gateway (virtual network gateway) to an Azure
Virtual WAN (VPN gateway). Creating a connection from a VPN Gateway (virtual network gateway) to a Virtual
WAN (VPN gateway) is similar to setting up connectivity to a virtual WAN from branch VPN sites.
In order to minimize possible confusion between two features, we will preface the gateway with the name of the
feature that we are referring to. For example, VPN Gateway virtual network gateway, and Virtual WAN VPN
gateway.
Before you begin

Before you begin, create the following resources:
Azure Virtual WAN
Create a virtual WAN.
Create a hub. The virtual hub contains the Virtual WAN VPN gateway.
Azure Virtual Network
Create a virtual network without any virtual network gateways. Verify that none of the subnets of your on-
premises networks overlap with the virtual networks that you want to connect to. To create a virtual network
in the Azure portal, see the Quickstart.
1. Create a VPN Gateway virtual network gateway

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 will use these public IPs when setting up the Virtual WAN sites. For more
information about active-active VPN gateways and configuration steps, see Configure active-active VPN
gateways.
Active -active mode setting
On the Virtual network gateway Configuration page, enable active-active mode.
BGP setting
On the virtual network gateway Configuration page, you can (optionally) select Configure BGP ASN . If you
configure BGP, change the ASN from the default value shown in the portal. For this configuration, the BGP ASN
cannot be 65515. 65515 will be used by Azure Virtual WAN.
Public IP addresses
When the gateway is created, navigate to the Proper ties page. The properties and configuration settings will be
similar to the following example. Notice the two public IP addresses that are used for the gateway.
2. Create Virtual WAN VPN sites
To create Virtual WAN VPN sites, navigate your to your virtual WAN and, under Connectivity , select VPN sites .
In this section, you will create two Virtual WAN VPN sites that correspond to the virtual network gateways you
created in the previous section.
1. Select +Create site .
2. On the Create VPN sites page, type the following values:
Region - The same region as the Azure VPN Gateway virtual network gateway.
Device vendor - Enter the device vendor (any name).
Private address space - Enter a value, or leave blank when BGP is enabled.
Border Gateway Protocol - Set to Enable if the Azure VPN Gateway virtual network gateway has
BGP enabled.
Connect to Hubs - Select the hub you created in the prerequisites from the dropdown. If you don't
see a hub, verify that you created a site-to-site VPN gateway for your hub.
3. Under Links , enter the following values:
Provider Name - Enter a Link name and a Provider name (any name).
Speed - Speed (any number).
IP Address - Enter IP address (same as the first public IP address shown under the (VPN Gateway)
virtual network gateway properties).
BGP Address and ASN - BGP address and ASN. These must be the same as one of the BGP peer IP
addresses, and ASN from the VPN Gateway virtual network gateway that you configured in Step 1.
4. Review and select Confirm to create the site.
5. Repeat the previous steps to create the second site to match with the second instance of the VPN
Gateway virtual network gateway. You'll keep the same settings, except using second public IP address
and second BGP peer IP address from VPN Gateway configuration.
6. You now have two sites successfully provisioned and can proceed to the next section to download
configuration files.
3. Download the VPN configuration files

In this section, you download the VPN configuration file for each of the sites that you created in the previous
section.
1. At the top of the Virtual WAN VPN sites page, select the Site , then select Download Site-to-site VPN
configuration . Azure creates a configuration file with the settings.
2. Download and open the configuration file.

3. Repeat these steps for the second site. Once you have both configuration files open, you can proceed to
the next section.
4. Create the local network gateways

In this section, you create two Azure VPN Gateway local network gateways. The configuration files from the
previous step contain the gateway configuration settings. Use these settings to create and configure the Azure
VPN Gateway local network gateways.
1. Create the local network gateway using these settings. For information about how to create a VPN
Gateway local network gateway, see the VPN Gateway article Create a local network gateway.
IP address - Use the Instance0 IP Address shown for gatewayconfiguration from the configuration
file.
BGP - If the connection is over BGP, select Configure BGP settings and enter the ASN '65515'. Enter
the BGP peer IP address. Use 'Instance0 BgpPeeringAddresses' for gatewayconfiguration from the
configuration file.
Address Space If the connection isn't over BGP, make sure Configure BGP settings remains
unchecked. Enter the address spaces that you're going to advertise from the virtual network gateway
side. You can add multiple address space ranges. Make sure that the ranges you specify here do not
overlap with ranges of other networks that you want to connect to.
Subscription, Resource Group, and Location are same as for the Virtual WAN hub.
2. Review and create the local network gateway. Your local network gateway should look similar to this
example.
3. Repeat these steps to create another local network gateway, but this time, use the 'Instance1' values
instead of 'Instance0' values from the configuration file.
5. Create connections
In this section, you create a connection between the VPN Gateway local network gateways and virtual network
gateway. For steps on how to create a VPN Gateway connection, see Configure a connection.
1. In the portal, navigate to your virtual network gateway and click Connections . At the top of the
Connections page, click +Add to open the Add connection page.
2. On the Add connection page, configure the following values for your connection:
Name: Name your connection.
Connection type: Select Site-to-site(IPSec)
Vir tual network gateway: The value is fixed because you are connecting from this gateway.
Local network gateway: This connection will connect the virtual network gateway to the local
network gateway. Choose one of the local network gateways that you created earlier.
Shared Key: Enter a shared key.
IKE Protocol: Choose the IKE protocol.
3. Click OK to create your connection.
4. You can view the connection in the Connections page of the virtual network gateway.
5. Repeat the preceding steps to create a second connection. For the second connection, select the other
local network gateway that you created.
6. If the connections are over BGP, after you have created your connections, navigate to a connection and
select Configuration . On the Configuration page, for BGP , select Enabled . Then, click Save . Repeat
for the second connection.
6. Test connections
You can test the connectivity by creating two virtual machines, one on the side of the VPN Gateway virtual
network gateway, and one in a virtual network for the Virtual WAN, and then ping the two virtual machines.
1. Create a virtual machine in the virtual network (Test1-VNet) for Azure VPN Gateway (Test1-VNG). Do not
create the virtual machine in the GatewaySubnet.
2. Create another virtual network to connect to the virtual WAN. Create a virtual machine in a subnet of this
virtual network. This virtual network cannot contain any virtual network gateways. You can quickly create
a virtual network using the PowerShell steps in the site-to-site connection article. Be sure to change the
values before running the cmdlets.
3. Connect the VNet to the Virtual WAN hub. On the page for your virtual WAN, select Vir tual network
connections , then +Add connection . On the Add connection page, fill in the following fields:
cannot have an already existing virtual network gateway.
4. Click OK to create the virtual network connection.
5. Connectivity is now set between the VMs. You should be able to ping one VM from the other, unless there
are any firewalls or other policies blocking the communication.
Next steps
For steps to configure a custom IPsec policy, see Configure a custom IPsec policy for Virtual WAN. For more
information about Virtual WAN, see About Azure Virtual WAN and the Azure Virtual WAN FAQ.
Configure a custom IPsec policy for Virtual WAN
using the portal
You can configure a custom IPsec policy for a Virtual WAN VPN connection in the Azure portal. Custom policies
are helpful when you want both sides (on-premises and Azure VPN gateway) to use the same settings for IKE
Phase 1 and IKE Phase 2.
Working with custom policies

NOTE
Configure a policy
1. Locate the vir tual hub . From a browser, navigate to the Azure portal and sign in with your Azure
account. Navigate to your Virtual WAN resource and locate the virtual hub that your VPN site is
connected to.
2. Select the VPN site . From the hub overview page, click VPN (Site to site) and select the VPN Site for
which you want to set up a custom IPsec policy.
3. Edit the VPN connection . From the Context menu ..., select Edit VPN Connection .
4. Configure the settings . On the Edit VPN connection page, change the IPsec setting from default to
custom and customize the IPsec policy. Select Save to save your settings.
Next steps
Configure NAT Rules for your Virtual WAN VPN
gateway
You can configure your Virtual WAN VPN gateway with static one-to-one NAT rules. A NAT rule provides a
mechanism to set up one-to-one translation of IP addresses. NAT can be used to interconnect two IP networks
that have incompatible or overlapping IP addresses. A typical scenario is branches with overlapping IPs that
want to access Azure VNet resources.
This configuration uses a flow table to route traffic from an external (host) IP Address to an internal IP address
associated with an endpoint inside a virtual network (virtual machine, computer, container, etc.).
In order to use NAT, VPN devices need to use any-to-any (wildcard) traffic selectors. Policy Based (narrow) traffic
selectors are not supported in conjunction with NAT configuration.
Configure NAT rules

You can configure and view NAT rules on your VPN gateway settings at any time.
NAT type: static & dynamic

NAT on a gateway device translates the source and/or destination IP addresses, based on the NAT policies or
rules to avoid address conflict. There are different types of NAT translation rules:
Static NAT : Static rules define a fixed address mapping relationship. For a given IP address, it will be
mapped to the same address from the target pool. The mappings for static rules are stateless because the
mapping is fixed. For example, a NAT rule created to map 10.0.0.0/24 to 192.168.0.0/24 will have a fixed
1-1 mapping. 10.0.0.0 is translated to 192.168.0.0, 10.0.0.1 is translated to 192.168.0.1, and so on.
Dynamic NAT : For dynamic NAT, an IP address can be translated to different target IP addresses and
TCP/UDP port based on availability, or with a different combination of IP address and TCP/UDP port. The
latter is also called NAPT, Network Address and Port Translation. Dynamic rules will result in stateful
translation mappings depending on the traffic flows at any given time. Due to the nature of Dynamic NAT
and the ever changing IP/Port combinations, flows that make use of Dyanmic NAT rules have to be
initiated from the InternalMapping (Pre-NAT) IP Range. The dynamic mapping is released once the flow
is disconnected or gracefully terminated.
Another consideration is the address pool size for translation. If the target address pool size is the same as the
original address pool, use static NAT rule to define a 1:1 mapping in a sequential order. If the target address pool
is smaller than the original address pool, use dynamic NAT rule to accommodate the differences.
NOTE
Site-to-site NAT is not supported with Site-to-site VPN connections where policy based traffic selectors are used.
1. Navigate to your virtual hub.

2. Select VPN (Site to site) .
3. Select NAT rules (Edit) .
4. On the Edit NAT Rule page, you can Add/Edit/Delete a NAT rule using the following values:
Name: A unique name for your NAT rule.
Type: Static or Dynamic. Static one-to-one NAT establishes a one-to-one relationship between an
internal address and an external address while Dynamic NAT assigns an IP and port based on
availability.
IP Configuration ID: A NAT rule must be configured to a specific VPN Gateway instance. This is
applicable to Dynamic NAT only. Static NAT rules are automatically applied to both VPN Gateway
instances.
Mode: IngressSnat or EgressSnat.
IngressSnat mode (also known as Ingress Source NAT) is applicable to traffic entering the Azure
hub’s Site-to-site VPN gateway.
EgressSnat mode (also known as Egress Source NAT) is applicable to traffic leaving the Azure
InternalMapping: An address prefix range of source IPs on the inside network that will be mapped
to a set of external IPs. In other words, your pre-NAT address prefix range.
ExternalMapping: An address prefix range of destination IPs on the outside network that source IPs
will be mapped to. In other words, your post-NAT address prefix range.
Link Connection: Connection resource that virtually connects a VPN site to the Azure Virtual WAN
Hub's Site-to-site VPN gateway.
NOTE
If you want the Site-to-site VPN Gateway to advertise translated (ExternalMapping ) address prefixes via BGP, click the
Enable BGP Translation button, due to which on-premises will automatically learn the post-NAT range of Egress Rules
and Azure (Virtual WAN Hub, connected Virtual Networks, VPN and ExpressRoute branches) will automatically learn the
post-NAT range of Ingress rules. The new POST NAT ranges will be shown in the Effective Routes table in a Virtual Hub.
Please note that the Enable Bgp Translation setting is applied to all NAT rules on the Virtual WAN Hub Site-to-site
VPN Gateway.
Example configurations
Ingress SNAT (BGP-Enabled VPN Site )
Ingress SNAT rules are applied on packets that are entering Azure through the Virtual WAN Site-to-site VPN
gateway. In this scenario, you want to connect two Site-to-site VPN branches to Azure. VPN Site 1 connects via
Link A, and VPN Site 2 connects via Link B. Each site has the same address space 10.30.0.0/24.
In this example, we will NAT site1 to 127.30.0.0.0/24. The Virtual WAN spoke Virtual Networks and branches
other will automatically learn this post-NAT address space.
The following diagram shows the projected end result:
1. Specify a NAT rule.

Specify a NAT rule to ensure the Site-to-site VPN gateway is able to distinguish between the two
branches with overlapping address spaces (such as 10.30.0.0/24). In this example, we focus on Link A for
VPN Site 1.
The following NAT rule can be set up and associated to Link A. Because this is a static NAT rule, the
address spaces of the InternalMapping and ExternalMapping contain the same number of IP
addresses.
Name: ingressRule01
Type: Static
Mode: IngressSnat
InternalMapping: 10.30.0.0/24
ExternalMapping: 172.30.0.0/24
Link Connection: Link A
2. Toggle BGP Route Translation to 'Enable'.
3. Ensure the Site-to-site VPN Gateway is able to peer with the on-premises BGP peer.
In this example, the Ingress NAT Rule will need to translate 10.30.0.132 to 127.30.0.132. In order to do
that, click 'Edit VPN site' to configure VPN site Link A BGP address to reflect this translated BGP peer
address (127.30.0.132).
Considerations if the VPN site connects via BGP

The subnet size for both internal and external mapping must be the same for static one-to-one NAT.
If BGP Translation is enabled, the Site-to-site VPN Gateway will automatically advertise the External
Mapping of Egress NAT rules to on-premises as well as External Mapping of Ingress NAT rules to
Azure (Virtual WAN Hub, connected Spoke Virtual Networks, connected VPN/ExpresRoute). If BGP
Translation is disabled, translated routes are not automatically advertised to the on-premises. As such,
the on-premises BGP speaker must be configured to advertise the post-NAT (ExternalMapping ) range
of Ingress NAT rules associated to that VPN site link connection. Similarly, a route for the post-NAT
(ExternalMapping ) range of Egress NAT Rules must be applied on the on-premises device.
The Site-to-site VPN Gateway automatically translates the on-premises BGP peer IP address if the on-
premises BGP peer IP address is contained within the Internal Mapping of an Ingress NAT Rule . As a
result, the VPN site's Link Connection BGP address must reflect the NAT-translated address (part of
the External Mapping).
For instance, if the on-premises BGP IP address is 10.30.0.133 and there is an Ingress NAT Rule that
translates 10.30.0.0/24 to 127.30.0.0/24, the VPN Site's Link Connection BGP Address must be
configured to be the translated address (127.30.0.133).
In Dynamic NAT, on-premises BGP peer IP cannot be part of the pre-NAT address range (Interal
Mapping ) as IP and port translations are not fixed. If there is a need to translate the on-premises BGP
peering IP, please create a separate Static NAT Rule that translates BGP Peering IP address only.
For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premise BGP
peer IP of 10.0.0.1 and there is an Ingress Dynamic NAT Rule to translate 10.0.0.0/24 to
192.198.0.0/32, a separate Ingress Static NAT Rule translating 10.0.0.1/32 to 192.168.0.02/32 is
required and the corresponding VPN site's Link Connection BGP address must be updated to the
NAT-translated address (part of the External Mapping).
Ingress SNAT (VPN site with statically configured routes)
Ingress SNAT rules are applied on packets that are entering Azure through the Virtual WAN Site-to-site VPN
gateway. In this scenario, you want to connect two Site-to-site VPN branches to Azure. VPN Site 1 connects via
Link A, and VPN Site 2 connects via Link B. Each site has the same address space 10.30.0.0/24.
In this example, we will NAT VPN site 1 to 172.30.0.0.0/24. However, because the VPN Site is not connected to
the Site-to-site VPN Gateway via BGP, the configuration steps are slightly different than the BGP-enabled
example.
1. Specify a NAT rule.

Specify a NAT rule to ensure the Site-to-site VPN gateway is able to distinguish between the two
branches with the same address space 10.30.0.0/24. In this example, we focus on Link A for VPN Site 1.
The following NAT rule can be set up and associated to Link A of one of VPN site 1. Because this is a static
NAT rule, the address spaces of the InternalMapping and ExternalMapping contain the same number
of IP addresses.
Name : IngressRule01
Type : Static
Mode : IngressSnat
InternalMapping : 10.30.0.0/24
ExternalMapping : 172.30.0.0/24
Link Connection : Link A
2. Edit the 'Private Address space' field of VPN Site 1 to ensure the Site-to-site VPN Gateway learns the
post-NAT range (172.30.0.0/24)
Navigate to the Virtual hub resource that contains the Site-to-site VPN gateway. On the virtual hub
page, under Connectivity, select VPN (Site-to-site).
Select the VPN site that is connected to the Virtual WAN hub via Link A. Select Edit Site and input
172.30.0.0/24 as the private address space for the VPN site.
Considerations if VPN sites are statically configured (not connected via BGP)
The subnet size for both internal and external mapping must be the same for static one-to-one NAT.
Edit the VPN site in Azure portal to add the prefixes in the ExternalMapping of Ingress NAT Rules in the
'Private Address Space' field.
For configurations involving Egress NAT Rules , a Route Policy or Static Route with the ExternalMapping
of the Egress NAT rule needs to be applied on the on-premises device.
Packet flow
In the preceding examples, an on-premises device wants to reach a resource in a Spoke Virtual Network. The
packet flow is as follows, with the NAT translations in bold.
1. Traffic from on-premises is initiated.
Source IP Address: 10.30.0.4
Destination IP Address: 10.200.0.4
2. Traffic enters Site-to-site gateway and is translated using the NAT rule and then sent to the Spoke.
3. Reply from Spoke is initiated.
4. Traffic enters the Site-to-site VPN gateway and the translation is reversed and sent to on-premises.
Verification checks
This section shows checks to verify that your configuration is set up properly.
Validate Dynamic NAT Rules
Use Dynamic NAT Rules if the target address pool is smaller than the original address pool.
As IP/Port combinations are not fixed in a Dynamic NAT Rule, the on-premises BGP Peer IP cannot be part
of the pre-NAT (InternalMapping ) addres range. Please create a specific Static NAT Rule that translates
the BGP Peering IP address only.
For example:
On-Premises Address Range: 10.0.0.0/24
On-premises BGP IP: 10.0.0.1
Ingress Dynamic NAT Rule: 192.168.0.1/32
Ingress Static NAT Rule: 10.0.0.1 -> 192.168.0.2
Validate DefaultRouteTable, rules, and routes
Branches in Virtual WAN associate to the DefaultRouteTable , implying all branch connections learn routes that
are populated within the DefaultRouteTable. You will see the NAT rule with the translated prefix in the effective
routes of the DefaultRouteTable.
From the previous example:
Prefix: 172.30.0.0/24
Next Hop Type: VPN_S2S_Gateway
Next Hop: VPN_S2S_Gateway Resource
Validate address prefixes
This example applies to resources in Virtual Networks that are associated to the DefaultRouteTable.
The Effective Routes on the Network Interface Cards (NIC) of any virtual machine that is sitting in a Spoke
Virtual Network connected to the Virtual WAN hub should also contain the address prefixes of the
ExternalMapping specified in the Ingress NAT rule .
The on-premises device should also contain routes for prefixes contained within the External Mapping of
Egress NAT Rules .
Common configuration patterns
NOTE
Site-to-site NAT is not supported with Site-to-site VPN connections where policy based traffic selectors are used.
The following table shows common configuration patterns that arise when configuring different types of NAT
rules on the Site-to-site VPN Gateway.
T Y P E O F VP N SIT E IN GRESS N AT RUL ES EGRESS N AT RUL ES
VPN Site with Statically Configured Edit 'Private Address Space' in the VPN Apply routes for the
Routes Site to contain the ExternalMapping ExternalMapping of the NAT Rule on
of the NAT rule the on-premises device.
VPN Site (BGP Translation Enabled) Put the ExternalMapping address of No special considerations.
the BGP peer in the VPN site Link
Connection's BGP address.
VPN Site (BGP Translation Disabled) Ensure the on-premises BGP Speaker Apply routes for the
advertises the prefixes in the ExternalMapping of the NAT rule on
ExternalMapping of the NAT Rule. the on-premises device.
Also put the ExternalMapping address
of the BGP peer in the VPN site Link
Connection's BGP address.
Next steps
For more information about Site-to-site configurations, see Configure a Virtual WAN Site-to-site connection.
Configure NAT Rules for your Virtual WAN VPN
gateway using PowerShell
You can configure your Virtual WAN VPN gateway with static one-to-one NAT rules. A NAT rule provides a
mechanism to set up one-to-one translation of IP addresses. NAT can be used to interconnect two IP networks
that have incompatible or overlapping IP addresses. A typical scenario is branches with overlapping IPs that
want to access Azure VNet resources.
This configuration uses a flow table to route traffic from an external (host) IP Address to an internal IP address
associated with an endpoint inside a virtual network (virtual machine, computer, container, etc.). In order to use
NAT, VPN devices need to use any-to-any (wildcard) traffic selectors. Policy Based (narrow) traffic selectors are
not supported in conjunction with NAT configuration.
Prerequisites
Verify that you have an Azure subscription. If you don't already have an Azure subscription, you can activate
your MSDN subscriber benefits or sign up for a free account.
This tutorial will create a NAT rule on a VpnGateway which will be associated with a VpnSiteConnection, so
this assumes you have an existing VpnGateway connection to two branches with overlapping address spaces.
Azure PowerShell
Sign in
Connect-AzAccount
Get-AzSubscription
Configure NAT rules

You can configure and view NAT rules on your VPN gateway settings at any time using Azure PowerShell
1. Declare the variables for the existing resources

$virtualWan = Get-AzVirtualWan -ResourceGroupName "testRG" -Name "myVirtualWAN"
$virtualHub = Get-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub"
2. Create the new NAT rule to ensure the Site-to-site VPN gateway is able to distinguish between the two
branches with overlapping address spaces.
You can set the parameters for the following values:
Name: A unique name for your NAT rule.
Type: Static or Dynamic. Static one-to-one NAT establishes a one-to-one relationship between an
internal address and an external address. The subnet size for both internal and external mapping must
be the same for static.
Mode: IngressSnat or EgressSnat.
IngressSnat mode (also known as Ingress Source NAT) is applicable to traffic entering the Azure
EgressSnat mode (also known as Egress Source NAT) is applicable to traffic leaving the Azure
InternalMapping: An address prefix range of source IPs on the inside network that will be mapped
to a set of external IPs. In other words, your pre-NAT address prefix range.
ExternalMapping: An address prefix range of destination IPs on the outside network that source IPs
will be mapped to. In other words, your post-NAT address prefix range.
Link Connection: Connection resource that virtually connects a VPN site to the Azure Virtual WAN
Hub's Site-to-site VPN gateway.
Syntax
New-AzVpnGatewayNatRule
-ResourceGroupName <String>
-ParentResourceName <String>
-Name <String>
[-Type <String>]
[-Mode <String>]
-InternalMapping <String[]>
-ExternalMapping <String[]>
[-InternalPortRange <String[]>]
[-ExternalPortRange <String[]>]
[-IpConfigurationId <String>]
[-AsJob]
[-DefaultProfile <IAzureContextContainer>]
[-WhatIf]
[-Confirm] [<CommonParameters>]
$natrule = New-AzVpnGatewayNatRule -ResourceGroupName "testRG" -ParentResourceName "testvpngw" -Name

"testNatRule" -InternalMapping "10.0.0.0/24" -ExternalMapping "1.2.3.4/32" -IpConfigurationId
"Instance0" -Type Dynamic -Mode EgressSnat
3. Declare the variable to create a new object for the new NAT rule
$newruleobject = New-Object Microsoft.Azure.Commands.Network.Models.PSResourceId

$newruleobject.Id = $natrule.Id
4. Declare the variable to get the existing VPN connection
$conn = Get-AzVpnConnection -Name "Connection-VPNsite1" -ResourceGroupName "testRG" -

ParentResourceName "testvpngw"
5. Set the appropriate index for the NAT rule in the VPN connection
$conn.VpnLinkConnections
$conn.VpnLinkConnections[0].EgressNatRules = $newruleobject
6. Finally, update the existing VPN connection with the new NAT rule
Update-AzVpnConnection -Name "Connection-VPNsite1" -ResourceGroupName "testRG" -ParentResourceName

"testvpngw" -VpnSiteLinkConnection $conn.VpnLinkConnections
Next steps
For more information about Site-to-site configurations, see Configure a Virtual WAN Site-to-site connection.
Tutorial: Create a User VPN connection using Azure
Virtual WAN
IPsec/IKE (IKEv2) VPN connection using a User VPN (P2S) configuration. This type of connection requires the
native VPN client to be configured on each connecting client computer.
If you want to create a User VPN connection using Azure AD authentication, use the Configure a User VPN
connection - Azure Active Directory authentication article instead.
Connect to a VNet
Modify settings
Prerequisites

WAN page.
environment.


The User VPN (P2S) configuration defines the parameters for remote clients to connect. The instructions you
follow depend on the authentication method you want to use.
In the following steps, when selecting the authentication method, you have three choices. Each method has
specific requirements. Select one of the following methods, and then complete the steps.
information.
Configuration steps
IKEv2 VPN
OpenVPN


step.
NOTE
up to 5.

gateway. In this section, you generate and download the files used to configure your VPN clients.
user VPN profile .
VPN profile.
your computer.

OpenVPN
IKEv2
anyway .
Connect VNet to hub

In this section, you create a connection between your virtual hub and your VNet. For this tutorial, you do not
need to configure the routing settings.
View a virtual WAN

1. Navigate to your vir tual WAN .
bytes in and out.
Modify settings
Modify client address pool
Modify DNS servers
2. Click the value next to Custom DNS Ser vers to open the Edit User VPN gateway page.
3. On the Edit User VPN gateway page, edit the Custom DNS Ser vers field. Enter the DNS server IP
addresses in the Custom DNS Ser vers text boxes. You can specify up to five DNS Servers.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Tutorial: Create a User VPN connection to Azure
Virtual WAN using PowerShell
IPsec/IKE (IKEv2) VPN connection using a User VPN (P2S) configuration using PowerShell. This type of
connection requires the native VPN client to be configured on each connecting client computer.
Connect to a VNet
Clean up resources
Prerequisites
Azure PowerShell
Sign in
Connect-AzAccount
Get-AzSubscription

Before you can create a virtual wan, you have to create a resource group to host the virtual wan or use an
existing resource group. Create a resource group with New-AzResourceGroup. This example creates a new
resource group named testRG in the West US location:
Create a resource group:
Create the virtual wan:

The User VPN (P2S) configuration defines the parameters for remote clients to connect depending on the
authentication method you want to use. When selecting the authentication method, there are three methods
available with each method having its specific requirements.
information.
Configuration steps using Azure Certificate authentication
User VPN (point-to-site) connections can use certificates to authenticate. To create a self-signed root certificate
and generate client certificates using PowerShell on Windows 10 or Windows Server 2016, see Generate and
export certificates.
Once you have generated and exported the self-signed root certificate, you need to reference the location of the
stored certificate. If using Cloud Shell on the Azure portal, you would need to upload the certificate first.
$VpnServerConfigCertFilePath = Join-Path -Path /home/name -ChildPath "\P2SRootCert1.cer"

$listOfCerts = New-Object "System.Collections.Generic.List[String]"
$listOfCerts.Add($VpnServerConfigCertFilePath)
Next is to create the User VPN Server Configuration. For the VPN Protocol, you can choose IKEv2 VPN,
OpenVPN, and OpenVpn and IKEv2 depending on your requirements.
New-AzVpnServerConfiguration -Name testconfig -ResourceGroupName testRG -VpnProtocol IkeV2 -

VpnAuthenticationType Certificate -VpnClientRootCertificateFilesList $listOfCerts -
VpnClientRevokedCertificateFilesList $listOfCerts -Location westus
Create the hub and Point-to-Site Gateway

New-AzVirtualHub -VirtualWan $virtualWan -ResourceGroupName "testRG" -Name "westushub" -AddressPrefix
"10.11.0.0/24" -Location "westus"
Next you declare the variables for the existing resources and also specify the Client address pool from which IP
addresses will be automatically assigned to VPN clients.
$virtualHub = Get-AzVirtualHub -ResourceGroupName testRG -Name westushub

$vpnServerConfig = Get-AzVpnServerConfiguration -ResourceGroupName testRG -Name testconfig
$vpnClientAddressSpaces = New-Object string[] 1
For the Point-to-Site Gateway, you need to specify the Gateway scale units and also reference the User VPN
Server Configuration created earlier. Creating a Point-to-Site Gateway can take 30 minutes or more to complete
$P2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName testRG -Name p2svpngw -VirtualHub $virtualHub -

VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig
-EnableInternetSecurityFlag -EnableRoutingPreferenceInternetFlag

gateway. In this section, you run the script to get the profile URL to generate and download the files used to
configure your VPN clients.
Get-AzVirtualWanVpnServerConfigurationVpnProfile -Name myVirtualWAN -ResourceGroupName testRG -

VpnServerConfiguration $vpnServerConfig -AuthenticationMethod EAPTLS

OpenVPN
IKEv2
anyway .
Connect VNet to hub

First the declare a variable to get the already existing Virtual network
$remoteVirtualNetwork = Get-AzVirtualNetwork -Name "testRGvnet" -ResourceGroupName "testRG"
Then you create a connection between your virtual hub and your VNet.
New-AzVirtualHubVnetConnection -ResourceGroupName "testRG" -VirtualHubName "westushub" -Name

"testvnetconnection" -RemoteVirtualNetwork $remoteVirtualNetwork
Clean up resources
1. Delete the gateway entities following the below order for the Point-to-Site VPN configuration. This can
take up to 30 minutes to complete.
Delete the Point-to-Site VPN Gateway
Remove-AzP2sVpnGateway -Name "p2svpngw" -ResourceGroupName "testRG"
Delete the User VPN Server configuration
Remove-AzVpnServerConfiguration -Name "testconfig" -ResourceGroupName "testRG"
2. You can delete the Resource Group to delete all the other resources in the resource group, including the
hubs, sites and the virtual WAN.
Remove-AzResourceGroup -Name "testRG"
3. Or you can choose to delete each of the resources in the Resource Group
Delete the Virtual Hub
Remove-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub"
Delete the Virtual WAN
Remove-AzVirtualWan -Name "MyVirtualWan" -ResourceGroupName "testRG"
Next steps
Virtual WAN FAQ
Configure a Point-to-Site User VPN connection -
Azure Active Directory authentication
This article shows you how to configure Azure AD authentication for User VPN in Virtual WAN to connect to
your resources in Azure over an OpenVPN VPN connection. Azure Active Directory authentication is only
available for gateways using the OpenVPN protocol. For more information about Virtual WAN, see the Virtual
WAN Overview.
NOTE
Azure AD authentication is supported for OpenVPN® protocol connections only and requires the Azure VPN client.

Download a virtual WAN User VPN profile
Create a virtual hub
Edit a hub to add P2S gateway
Download and apply the User VPN client configuration
Before you begin

on premises. If you are unfamiliar with the IP address ranges located in your on-premises network

WAN page.
environment.


A User VPN configuration defines the parameters for connecting remote clients. It is important to create the
User VPN configuration before configuring your virtual hub with P2S settings, as you must specify the User
VPN configuration you want to use.
1. Navigate to your Vir tual WAN ->User VPN configurations page and click +Create user VPN
config .
2. On the Basics page, specify the parameters.

Configuration name - Enter the name you want to call your User VPN Configuration.
Tunnel type - Select OpenVPN from the dropdown menu.
3. Click Azure Active Director y to open the page.
Toggle Azure Active Director y to Yes and supply the following values based on your tenant details. You
can view the necessary values on the Azure Active Directory page for Enterprise applications in the
portal.
Authentication method - Select Azure Active Directory.
Audience - Type in the Application ID of the Azure VPN Enterprise Application registered in your
Azure AD tenant.
Issuer - https://sts.windows.net/<your Directory ID>/
AAD Tenant - https://login.microsoftonline.com/<your Directory ID>
4. Click Create to create the User VPN configuration. You will select this configuration later in the exercise.
Create an empty hub

For this exercise, we create an empty virtual hub. In the next section, you add a gateway to an already existing
hub. However, it is also possible to combine these steps and create the hub with the P2S gateway settings all at
once.
select Hubs .
2. On the Hubs page, click + New Hub to open the Create vir tual hub page.
3. On the Basics tab, fill in the values.
4. Click Review + create .
5. On the Validation passed page, click Create .
Add a P2S gateway to a hub

This section shows you how to add a gateway to an already existing virtual hub. This step can take up to 30
minutes for the hub to complete updating.
1. Navigate to the Hubs page under the virtual WAN.
2. Select the hub to which you want to associate the VPN server configuration and click the ellipsis (...) to
show the menu. Then, click Edit vir tual hub .
3. On the Edit vir tual hub page, check the checkboxes for Include vpn gateway for vpn sites and
Include point-to-site gateway to reveal the settings. Then configure the values.
Gateway scale units : Select the Gateway scale units. Scale units represent the aggregate capacity of
the User VPN gateway. If you select 40 or more gateway scale units, plan your client address pool
accordingly. For information about how this setting impacts the client address pool, see About client
address pools. For information about gateway scale units, see the FAQ.
User VPN configuration : Select the configuration that you created earlier.
Client address pool : Specify the client address pool from which the VPN clients will be assigned IP
addresses. This setting corresponds to the gateway scale units that you
4. Click Confirm . It can take up to 30 minutes to update the hub.
Connect VNet to hub

In this section, you create a connection between your virtual hub and your VNet.
Download User VPN profile

All of the necessary configuration settings for the VPN clients are contained in a VPN client configuration zip file.
The settings in the zip file help you easily configure the VPN clients. The VPN client configuration files that you
generate are specific to the User VPN configuration for your gateway. In this section, you generate and
download the files used to configure your VPN clients.
user VPN profile .
VPN profile.
your computer.
Configure User VPN clients

Each computer that connects must have a client installed. You configure each client by using the VPN User client
profile files that you downloaded in the previous steps. Use the article that pertains to the operating system that
To configure macOS VPN clients (Preview)
For macOS client instructions, see Configure a VPN client - macOS (Preview).
To configure Windows VPN clients
1. Download the Azure VPN Client to each computer.
2. Verify that the Azure VPN Client has permission to run in the background. To check and enable
permissions, navigate to Star t -> Settings -> Privacy -> Background Apps .
Under Background Apps , make sure Let apps run in the background is turned On .
Under Choose which apps can run in the background , turn settings for Azure VPN Client
to On .
To import a VPN client profile (Windows )

1. On the page, select Impor t .
2. Browse to the profile xml file and select it. With the file selected, select Open .
3. Specify the name of the profile and select Save .

4. Select Connect to connect to the VPN.
5. Once connected, the icon will turn green and say Connected .
To delete a client profile - Windows
1. Select the ellipsis (...) next to the client profile that you want to delete. Then, select Remove .
2. Select Remove to delete.

Diagnose connection issues - Windows
1. To diagnose connection issues, you can use the Diagnose tool. Select the ellipsis (...) next to the VPN
connection that you want to diagnose to reveal the menu. Then select Diagnose .
2. On the Connection Proper ties page, select Run Diagnosis .

3. Sign in with your credentials.
4. View the diagnosis results.

1. Navigate to the virtual WAN.
2. On the Overview page, each point on the map represents a hub.
3. In the Hubs and connections section, you can view hub status, site, region, VPN connection status, and bytes
in and out.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Generate and export certificates for User VPN
connections
User VPN (point-to-site) connections use certificates to authenticate. This article shows you how to create a self-
signed root certificate and generate client certificates using PowerShell on Windows 10 or Windows Server
2016.
You must perform the steps in this article on a computer running Windows 10 or Windows Server 2016. The
PowerShell cmdlets that you use to generate certificates are part of the operating system and do not work on
other versions of Windows. The Windows 10 or Windows Server 2016 computer is only needed to generate the
certificates. Once the certificates are generated, you can upload them, or install them on any supported client
operating system.
Create a self-signed root certificate

Use the New-SelfSignedCertificate cmdlet to create a self-signed root certificate. For additional parameter
information, see New-SelfSignedCertificate.
1. From a computer running Windows 10 or Windows Server 2016, open a Windows PowerShell console
with elevated privileges. These examples do not work in the Azure Cloud Shell "Try It". You must run these
examples locally.
2. Use the following example to create the self-signed root certificate. The following example creates a self-
signed root certificate named 'P2SRootCert' that is automatically installed in 'Certificates-Current
User\Personal\Certificates'. You can view the certificate by opening certmgr.msc, or Manage User
Certificates.
Run the following example with any necessary modifications.
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `

-Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
3. Leave the PowerShell console open and proceed with the next steps to generate a client certificate.
Generate a client certificate

Each client computer that connects to a VNet using Point-to-Site must have a client certificate installed. You
generate a client certificate from the self-signed root certificate, and then export and install the client certificate.
If the client certificate is not installed, authentication fails.
The following steps walk you through generating a client certificate from a self-signed root certificate. You may
generate multiple client certificates from the same root certificate. When you generate client certificates using
the steps below, the client certificate is automatically installed on the computer that you used to generate the
certificate. If you want to install a client certificate on another client computer, you can export the certificate.
The examples use the New-SelfSignedCertificate cmdlet to generate a client certificate that expires in one year.
For additional parameter information, such as setting a different expiration value for the client certificate, see
New-SelfSignedCertificate.
Example 1 - PowerShell console session still open
Use this example if you have not closed your PowerShell console after creating the self-signed root certificate.
This example continues from the previous section and uses the declared '$cert' variable. If you closed the
PowerShell console after creating the self-signed root certificate, or are creating additional client certificates in a
new PowerShell console session, use the steps in Example 2.
Modify and run the example to generate a client certificate. If you run the following example without modifying
it, the result is a client certificate named 'P2SChildCert'. If you want to name the child certificate something else,
modify the CN value. Do not change the TextExtension when running this example. The client certificate that you
generate is automatically installed in 'Certificates - Current User\Personal\Certificates' on your computer.
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `

-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
Example 2 - New PowerShell console session

If you are creating additional client certificates, or are not using the same PowerShell session that you used to
create your self-signed root certificate, use the following steps:
1. Identify the self-signed root certificate that is installed on the computer. This cmdlet returns a list of
certificates that are installed on your computer.
Get-ChildItem -Path "Cert:\CurrentUser\My"
2. Locate the subject name from the returned list, then copy the thumbprint that is located next to it to a text
file. In the following example, there are two certificates. The CN name is the name of the self-signed root
certificate from which you want to generate a child certificate. In this case, 'P2SRootCert'.
Thumbprint Subject
---------- -------
AED812AD883826FF76B4D1D5A77B3C08EFA79F3F CN=P2SChildCert4
7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655 CN=P2SRootCert
3. Declare a variable for the root certificate using the thumbprint from the previous step. Replace
THUMBPRINT with the thumbprint of the root certificate from which you want to generate a child
certificate.
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My\<THUMBPRINT>"
For example, using the thumbprint for P2SRootCert in the previous step, the variable looks like this:
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My\7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655"
4. Modify and run the example to generate a client certificate. If you run the following example without
modifying it, the result is a client certificate named 'P2SChildCert'. If you want to name the child
certificate something else, modify the CN value. Do not change the TextExtension when running this
example. The client certificate that you generate is automatically installed in 'Certificates - Current
User\Personal\Certificates' on your computer.
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `
-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
Export the root certificate public key (.cer)

After creating a self-signed root certificate, export the root certificate public key .cer file (not the private key). You
will later upload this file to Azure. The following steps help you export the .cer file for your self-signed root
certificate:
1. To obtain a .cer file from the certificate, open Manage user cer tificates . Locate the self-signed root
certificate, typically in 'Certificates - Current User\Personal\Certificates', and right-click. Click All Tasks ,
and then click Expor t . This opens the Cer tificate Expor t Wizard . If you can't find the certificate under
Current User\Personal\Certificates, you may have accidentally opened "Certificates - Local Computer",
rather than "Certificates - Current User"). If you want to open Certificate Manager in current user scope
using PowerShell, you type certmgr in the console window.
2. In the Wizard, click Next .

3. Select No, do not expor t the private key , and then click Next .
4. On the Expor t File Format page, select Base-64 encoded X.509 (.CER)., and then click Next .
5. For File to Expor t , Browse to the location to which you want to export the certificate. For File name ,
name the certificate file. Then, click Next .
6. Click Finish to export the certificate.

7. Your certificate is successfully exported.
8. The exported certificate looks similar to this:
9. If you open the exported certificate using Notepad, you see something similar to this example. The
section in blue contains the information that is uploaded to Azure. If you open your certificate with
Notepad and it does not look similar to this, typically this means you did not export it using the Base-64
encoded X.509(.CER) format. Additionally, if you want to use a different text editor, understand that some
editors can introduce unintended formatting in the background. This can create problems when uploaded
the text from this certificate to Azure.
Export the self-signed root certificate and private key to store it (optional)
You may want to export the self-signed root certificate and store it safely as backup. If need be, you can later
install it on another computer and generate more client certificates. To export the self-signed root certificate as a
.pfx, select the root certificate and use the same steps as described in Export a client certificate.
Export the client certificate

When you generate a client certificate, it's automatically installed on the computer that you used to generate it. If
you want to install the client certificate on another client computer, you need to export the client certificate that
you generated.
1. To export a client certificate, open Manage user cer tificates . The client certificates that you generated
are, by default, located in 'Certificates - Current User\Personal\Certificates'. Right-click the client
certificate that you want to export, click all tasks , and then click Expor t to open the Cer tificate Expor t
Wizard .
2. In the Certificate Export Wizard, click Next to continue.
3. Select Yes, expor t the private key , and then click Next .
4. On the Expor t File Format page, leave the defaults selected. Make sure that Include all cer tificates
in the cer tification path if possible is selected. This setting additionally exports the root certificate
information that is required for successful client authentication. Without it, client authentication fails
because the client doesn't have the trusted root certificate. Then, click Next .
5. On the Security page, you must protect the private key. If you select to use a password, make sure to
record or remember the password that you set for this certificate. Then, click Next .
6. On the File to Expor t , Browse to the location to which you want to export the certificate. For File
name , name the certificate file. Then, click Next .
7. Click Finish to export the certificate.
Next steps
Continue with the Virtual WAN steps for user VPN connection
Prepare Azure Active Directory tenant for User VPN
OpenVPN protocol connections
When connecting to your Virtual Hub over the IKEv2 protocol, you can use certificate-based authentication or
RADIUS authentication. However, when you use the OpenVPN protocol, you can also use Azure Active Directory
authentication. This article helps you set up an Azure AD tenant for Virtual WAN User VPN (point-to-site) using
OpenVPN authentication.
NOTE
Azure AD authentication is supported only for OpenVPN® protocol connections.
1. Create the Azure AD tenant

Verify that you have an Azure AD tenant. If you don't have an Azure AD tenant, you can create one using the
steps in the Create a new tenant article:
Organization name
Initial domain name
Example:
2. Create Azure AD tenant users

Next, create two user accounts in the newly created Azure AD tenant, one Global administrator account and one
user account. The user account can be used to test OpenVPN authentication and the Global administrator
account will be used to grant consent to the Azure VPN app registration. After you have created an Azure AD
user account, you assign a Director y Role to the user in order to delegate administrative permissions.
Use the steps in this article to create the two users for your Azure AD tenant. Be sure to change the Director y
Role on one of the created accounts to Global administrator .
3. Grant consent to the Azure VPN app registration
1. Sign in to the Azure Portal as a user that is assigned the Global administrator role.
2. Next, grant admin consent for your organization, this allows the Azure VPN application to sign in and
read user profiles. Copy and paste the URL that pertains to your deployment location in the address bar
of your browser:
Public
https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-
cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent
Azure Government
https://login-us.microsoftonline.com/common/oauth2/authorize?client_id=51bb15d4-3a4f-4ebf-9dca-
40096fe32426&response_type=code&redirect_uri=https://portal.azure.us&nonce=1234&prompt=admin_consent
Microsoft Cloud Germany
https://login-us.microsoftonline.de/common/oauth2/authorize?client_id=538ee9e6-310a-468d-afef-
ea97365856a9&response_type=code&redirect_uri=https://portal.microsoftazure.de&nonce=1234&prompt=admin
_consent
Azure China 21Vianet
https://https://login.chinacloudapi.cn/common/oauth2/authorize?client_id=49f817b6-84ae-4cc0-928c-
73f27289b3aa&response_type=code&redirect_uri=https://portal.azure.cn&nonce=1234&prompt=admin_consent
3. Select the Global administrator account if prompted.
4. Select Accept when prompted.

5. Under your Azure AD, in Enterprise applications , you should now see Azure VPN listed.
Next steps
In order to connect to your virtual networks using Azure AD authentication, you must create a User VPN
configuration and associate it to a Virtual Hub. See Configure Azure AD authentication for Point-to-Site
connection to Azure.
Download a global or hub-based profile for User
VPN clients
Azure Virtual WAN offers two types of connectivity for remote users: global and hub-based. Use the following
sections to learn about profile types and how to download them.
IMPORTANT
RADIUS authentication supports only the hub-based profile.
Global profile
The global profile associated with a User VPN configuration points to a load balancer that includes all active
User VPN hubs that are using that User VPN configuration. A user connected to the global profile is directed to
the hub that's closest to the user's geographic location. This type of connectivity is useful when users travel to
different locations frequently.
For example, you can associate a VPN configuration with two Virtual WAN hubs, one in West US and one in
Southeast Asia. If a user connects to the global profile associated with the User VPN configuration, they'll
connect to the closest Virtual WAN hub based on their location.
To download the global profile:
2. Select User VPN configurations .
3. Select the configuration for which you want to download the profile.
4. Select Download vir tual WAN user VPN profile .
Include or exclude a hub from a global profile

By default, every hub that uses a specific User VPN configuration is included in the corresponding global VPN
profile. You can choose to exclude a hub from the global VPN profile. If you do, a user won't be load balanced to
connect to that hub's gateway if they're using the global VPN profile.
To check whether or not the hub is included in the global VPN profile:
1. Go to the hub.
2. On the left panel, go to User VPN (Point to site) under Connectivity .
3. See Gateway attachment state to determine if this hub is included in the global VPN profile. If the
state is attached , the hub is included. If the state is detached , the hub is not included.
To include or exclude a specific hub from the global VPN profile:

1. Select Include/Exclude Gateway from Global Profile .
2. Make one of the following choices:

Select Exclude if you want to remove this hub's gateway from the Virtual WAN global User VPN
profile. Users who are using the hub-level User VPN profile will still be able to connect to this
gateway. Users who are using the WAN-level profile will not be able to connect to this gateway.
Select Include if you want to include this hub's gateway in the Virtual WAN global User VPN
profile. Users who are using this WAN-level profile will be able to connect to this gateway.
Hub-based profile
The profile points to a single hub. The user can connect to only the particular hub by using this profile. To
download the hub-based profile:
2. On the Over view page, select the hub.
3. Select User VPN (Point to site) .
4. Select Download vir tual Hub User VPN profile .
5. Select EAPTLS as the authentication type.

6. Select Generate and download profile .
Next steps
To learn more about Virtual WAN, see the Virtual WAN overview article.
Working with User VPN client profile files
The profile files contain information that is necessary to configure a VPN connection. This article helps you
obtain and understand the information necessary for a User VPN client profile.
Download the profile

You can use the steps in the Download profiles article to download the client profile zip file.
Extract the zip file

Extract the zip file. The file contains the following folders:
AzureVPN
Generic
OpenVPN (If you have enabled the OpenVPN with Azure cer tificate or RADIUS authentication
settings on the gateway). Select the appropriate article that corresponds to your configuration to create a
tenant.
VPN Gateway- Create a tenant.
Virtual WAN - Create a tenant.
Retrieve information
In the AzureVPN folder, navigate to the azurevpnconfig.xml file and open it with Notepad. Make a note of the
text between the following tags.
<audience> </audience>
<issuer> </issuer>
<tennant> </tennant>
<fqdn> </fqdn>
<serversecret> </serversecret>
Profile details
When you add a connection, use the information you collected in the previous step for the profile details page.
The fields correspond to the following information:
Audience: Identifies the recipient resource the token is intended for.
Issuer : Identifies the Security Token Service (STS) that emitted the token as well as the Azure AD tenant.
Tenant: Contains an immutable, unique identifier of the directory tenant that issued the token.
FQDN: The fully qualified domain name (FQDN) on the Azure VPN gateway.
Ser verSecret: The VPN gateway preshared key.
Folder contents
The generic folder contains the public server certificate and the VpnSettings.xml file. The
VpnSettings.xml file contains information needed to configure a generic client.
The downloaded zip file may also contain WindowsAmd64 and WindowsX86 folders. These folders
contain the installer for SSTP and IKEv2 for Windows clients. You need admin rights on the client to install
them.
The OpenVPN folder contains the ovpn profile that needs to be modified to include the key and the
certificate. For more information, see Configure OpenVPN clients.
Next steps
For more information about Virtual WAN User VPN, see Create a User VPN connection.
Create custom Intune profiles to deploy User VPN
client profiles
You can deploy profiles for Azure VPN clients (Windows 10) by using Microsoft Intune. This article helps you
create an Intune profile using custom settings.
NOTE
This article applies to deploying profiles that use Azure Active Directory for authentication only.
Prerequisites
Devices are already enrolled with Intune MDM.
The Azure VPN Client for Windows 10 is already deployed on the client machine.
Only Windows version 19H2 or higher is supported.
Modify XML
In the following steps, we use a sample XML for a custom OMA-URI profile for Intune with the following
settings:
Always On VPN is configured.
Trusted Network detection enabled.
For other supported options, see the VPNv2 CSP article.
1. Download the VPN profile from the Azure portal and extract the azurevpnconfig.xml file from the
package.
2. Copy and paste the text below into a new text editor file.
<VPNProfile>

<RememberCredentials>true</RememberCredentials>
<AlwaysOn>true</AlwaysOn>
<TrustedNetworkDetection>contoso.com,test.corp.contoso.com</TrustedNetworkDetection>
<DeviceTunnel>false</DeviceTunnel>
<RegisterDNS>false</RegisterDNS>
<PluginProfile>
<ServerUrlList>azuregateway-7cee0077-d553-4323-87df-069c331f58cb-
053dd0f6af02.vpn.azure.com</ServerUrlList>
<CustomConfiguration>
</CustomConfiguration>
<PluginPackageFamilyName>Microsoft.AzureVpn_8wekyb3d8bbwe</PluginPackageFamilyName>
</PluginProfile>
</VPNProfile>
3. Modify the entry between <ServerUrlList> and </ServerUrlList> with the entry from your downloaded
profile (azurevpnconfig.xml). Change the "TrustedNetworkDetection" FQDN to fit your environment.
4. Open the Azure downloaded profile (azurevpnconfig.xml) and copy the entire contents to the clipboard
by highlighting the text and pressing (ctrl) + C.
5. Paste the copied text from the previous step into the file you created in step 2 between the
<CustomConfiguration> </CustomConfiguration> tags. Save the file with an xml extension.
6. Write down the value in the <name> </name> tags. This is the name of the profile. You will need this name
when you create the profile in Intune. Close the file and remember the location where it is saved.
Create Intune profile

In this section, you create a Microsoft Intune profile with custom settings.
1. Sign in to Intune and navigate to Devices -> Configuration profiles . Select + Create profile .
2. For Platform , select Windows 10 and later . For Profile Type , select Templates and Custom . Then,
select Create .
3. Give the profile a name and description, then select Next .
4. On the Configuration settings tab, select Add .
Name: Enter a name for the configuration.
Description: Optional description.
OMA-URI: ./User/Vendor/MSFT/VPNv2/<name of your connection>/ProfileXML (this information can be
found in the azurevpnconfig.xml file in the <name> </name> tag).
Data type: String (XML file).
Select the folder icon and pick the file you saved in step 6 in the XML steps. Select Add .
5. Select Next .
6. Under Assignments , select the group to which you want to push the configuration. Then, select Next .
7. Applicability rules are optional. Define any rules if needed, and then select Next .
8. On the Review + create page, select Create .
9. Your custom profile is now created. For the Microsoft Intune steps to deploy this profile, see Assign user
and device profiles.
Next steps
For more information about User VPN (point-to-site) connections, see Create a User VPN connection.
Configure an OpenVPN client for Azure Virtual
WAN
This article helps you configure OpenVPN ® Protocol clients. You can also use the Azure VPN Client for
Windows 10 to connect via OpenVPN protocol. For more information, see Configure a VPN client for P2S
OpenVPN connections.
Before you begin

Create a User VPN (point-to-site) configuration. Make sure that you select "OpenVPN" for tunnel type. For steps,
see Create a P2S configuration for Azure Virtual WAN.
Windows clients
1. Download and install the OpenVPN client (version 2.4 or higher) from the official OpenVPN website.
2. Download the VPN client profile package from the Azure portal, or use the 'New-
AzVpnClientConfiguration' cmdlet in PowerShell.
3. Unzip the profile. Next, open the vpnconfig.ovpn configuration file from the OpenVPN folder using
Notepad.
4. Export the point-to-site client certificate you created and uploaded. Use the following article links:
VPN Gateway instructions
Virtual WAN instructions
5. Extract the private key and the base64 thumbprint from the .pfx. There are multiple ways to do this. Using
OpenSSL on your machine is one way. The profileinfo.txt file contains the private key and the thumbprint
for the CA and the Client certificate. Be sure to use the thumbprint of the client certificate.
openssl pkcs12 -in "filename.pfx" -nodes -out "profileinfo.txt"
6. Switch to the vpnconfig.ovpn file you opened in Notepad from step 3. Fill in the section between <cert>
and </cert> , getting the values for $CLIENT_CERTIFICATE , $INTERMEDIATE_CERTIFICATE , and
$ROOT_CERTIFICATE as shown below.
# P2S client certificate

# please fill this field with a PEM formatted cert
<cert>
$CLIENT_CERTIFICATE
$INTERMEDIATE_CERTIFICATE (optional)
$ROOT_CERTIFICATE
</cert>
Open profileinfo.txt from the previous step in Notepad. You can identify each certificate by looking at
the subject= line. For example, if your child certificate is called P2SChildCert, your client certificate
will be after the subject=CN = P2SChildCert attribute.
For each certificate in the chain, copy the text (including and between) "-----BEGIN CERTIFICATE-----"
and "-----END CERTIFICATE-----".
Only include an $INTERMEDIATE_CERTIFICATE value if you have an intermediate certificate in your
profileinfo.txt file.
7. Open the profileinfo.txt in Notepad. To get the private key, select the text (including and between) "-----
BEGIN PRIVATE KEY-----" and "-----END PRIVATE KEY-----" and copy it.
8. Go back to the vpnconfig.ovpn file in Notepad and find this section. Paste the private key replacing
everything between and <key> and </key> .
# P2S client root certificate private key

# please fill this field with a PEM formatted key
<key>
$PRIVATEKEY
</key>
9. Do not change any other fields. Use the filled in configuration in client input to connect to the VPN.
10. Copy the vpnconfig.ovpn file to C:\Program Files\OpenVPN\config folder.
11. Right-click the OpenVPN icon in the system tray and click connect.
Mac clients
1. Download and install an OpenVPN client, such as TunnelBlick.
3. Unzip the profile. Open the vpnconfig.ovpn configuration file from the OpenVPN folder in a text editor.
4. Fill in the P2S client certificate section with the P2S client certificate public key in base64. In a PEM
formatted certificate, you can open the .cer file and copy over the base64 key between the certificate
headers. Use the following article links for information about how to export a certificate to get the
encoded public key:
5. Fill in the private key section with the P2S client certificate private key in base64. See the Export your
private key on the OpenVPN site for information about how to extract a private key.
7. Double-click the profile file to create the profile in Tunnelblick.
8. Launch Tunnelblick from the applications folder.
9. Click on the Tunnelblick icon in the system tray and pick connect.
IMPORTANT
Only iOS 11.0 and above and MacOS 10.13 and above are supported with OpenVPN protocol.
iOS clients
1. Install the OpenVPN client (version 2.4 or higher) from the App store.
3. Unzip the profile. Open the vpnconfig.ovpn configuration file from the OpenVPN folder in a text editor.
4. Fill in the P2S client certificate section with the P2S client certificate public key in base64. In a PEM
formatted certificate, you can open the .cer file and copy over the base64 key between the certificate
headers. Use the following article links for information about how to export a certificate to get the
encoded public key:
5. Fill in the private key section with the P2S client certificate private key in base64. See Export your private
key on the OpenVPN site for information about how to extract a private key.
6. Do not change any other fields.
7. E-mail the profile file (.ovpn) to your email account that is configured in the mail app on your iPhone.
8. Open the e-mail in the mail app on the iPhone, and tap the attached file
9. Tap on More if you do not see Copy to OpenVPN option
10. Tap on Copy to OpenVPN

11. Tap on ADD in the Impor t Profile page
12. Tap on ADD in the Impor ted Profile page
13. Launch the OpenVPN app and slide the switch in the Profile page right to connect
Linux clients
1. Open a new Terminal session. You can open a new session by pressing 'Ctrl + Alt + t' at the same time.
2. Enter the following command to install needed components:
sudo apt-get install openvpn

sudo apt-get -y install network-manager-openvpn
sudo service network-manager restart
3. Download the VPN profile for the gateway. This can be done from the Point-to-site configuration tab in
the Azure portal.
4. Export the P2S client certificate you created and uploaded to your P2S configuration on the gateway. Use
the following article links:
5. Extract the private key and the base64 thumbprint from the .pfx. There are multiple ways to do this. Using
OpenSSL on your computer is one way.
openssl pkcs12 -in "filename.pfx" -nodes -out "profileinfo.txt"
The profileinfo.txt file will contain the private key and the thumbprint for the CA, and the Client certificate.
Be sure to use the thumbprint of the client certificate.
6. Open profileinfo.txt in a text editor. To get the thumbprint of the client (child) certificate, select the text
including and between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" for the child
certificate and copy it. You can identify the child certificate by looking at the subject=/ line.
7. Open the vpnconfig.ovpn file and find the section shown below. Replace everything between the and
"cert" and "/cert".
# P2S client certificate

# please fill this field with a PEM formatted cert
<cert>
$CLIENTCERTIFICATE
</cert>
8. Open the profileinfo.txt in a text editor. To get the private key, select the text including and between "-----
BEGIN PRIVATE KEY-----" and "-----END PRIVATE KEY-----" and copy it.
9. Open the vpnconfig.ovpn file in a text editor and find this section. Paste the private key replacing
everything between and "key" and "/key".
# P2S client root certificate private key

# please fill this field with a PEM formatted key
<key>
$PRIVATEKEY
</key>
11. To connect using the command line, type the following command:
sudo openvpn --config <name and path of your VPN profile file>&
12. To connect using the GUI, go to system settings.

13. Click + to add a new VPN connection.
14. Under Add VPN , pick Impor t from file…
15. Browse to the profile file and double-click or pick Open .
16. Click Add on the Add VPN window.
17. You can connect by turning the VPN ON on the Network Settings page, or under the network icon in
the system tray.
Next steps
For more information about User VPN (point-to-site), see Create User VPN connections.
"OpenVPN" is a trademark of OpenVPN Inc.
Configure a VPN client for P2S OpenVPN protocol
connections: Azure AD authentication
This article helps you configure a VPN client to connect to a virtual network using Point-to-Site VPN and Azure
Active Directory authentication. Before you can connect and authenticate using Azure AD, you must first
configure your Azure AD tenant. For more information, see Configure an Azure AD tenant.
NOTE
Working with client profiles

For every computer that wants to connect to the VNet via the VPN client, you need to download the Azure VPN
Client for the computer, and also configure a VPN client profile. If you want to configure multiple computers, you
can create a client profile on one computer, export it, and then import it to other computers.
To download the Azure VPN Client
1. Download the Azure VPN Client to the computer.
to On .
To create a certificate -based client profile
When working with a certificate-based profile, make sure that the appropriate certificates are installed on the
client computer. For more information about certificates, see Install client certificates.
To create a RADIUS client profile

NOTE
The Server Secret can be exported in the P2S VPN client profile. To export a client profile, see User VPN client profiles.
To export and distribute a client profile

Once you have a working profile and need to distribute it to other users, you can export it using the following
steps:
1. Highlight the VPN client profile that you want to export, select the ..., then select Expor t .
2. Select the location that you want to save this profile to, leave the file name as is, then select Save to save
the xml file.
To import a client profile


To delete a client profile
1. Select the ellipses next to the client profile that you want to delete. Then, select Remove .

Create a connection
1. On the page, select + , then + Add .
2. Fill out the connection information. If you are unsure of the values, contact your administrator. After filling
out the values, select Save .
4. Select the proper credentials, then select Continue .
5. Once successfully connected, the icon will turn green and say Connected .
To connect automatically
These steps help you configure your connection to connect automatically with Always-on.
1. On the home page for your VPN client, select VPN Settings .
2. Select Yes on the switch apps dialogue box.

3. Make sure the connection that you want to set is not already connected, then highlight the profile and
check the Connect automatically check box.
4. Select Connect to initiate the VPN connection.

Diagnose connection issues
1. To diagnose connection issues, you can use the Diagnose tool. Select the ... next to the VPN connection
that you want to diagnose to reveal the menu. Then select Diagnose .


FAQ
How do I add DNS suffixes to the VPN client?
You can modify the downloaded profile XML file and add the <dnssuffixes><dnssufix> </dnssufix>
</dnssuffixes> tags.
<azvpnprofile>
<clientconfig>
<dnssuffixes>
<dnssuffix>.mycorp.com</dnssuffix>
<dnssuffix>.xyz.com</dnssuffix>
<dnssuffix>.etc.net</dnssuffix>
</dnssuffixes>
</clientconfig>
</azvpnprofile>
How do I add custom DNS servers to the VPN client?

You can modify the downloaded profile XML file and add the <dnsser vers><dnsser ver> </dnsser ver>
</dnsser vers> tags.
<azvpnprofile>
<clientconfig>
<dnsservers>
<dnsserver>x.x.x.x</dnsserver>
<dnsserver>y.y.y.y</dnsserver>
</dnsservers>
</clientconfig>
</azvpnprofile>
NOTE
The OpenVPN Azure AD client utilizes DNS Name Resolution Policy Table (NRPT) entries, which means DNS servers will not
be listed under the output of ipconfig /all . To confirm your in-use DNS settings, please consult Get-
DnsClientNrptPolicy in PowerShell.
How do I add custom routes to the VPN client?

You can modify the downloaded profile XML file and add the <includeroutes><route><destination>
<mask> </destination></mask></route></includeroutes> tags.
<azvpnprofile>
<clientconfig>
<includeroutes>
<route>
<destination>x.x.x.x</destination><mask>24</mask>
</route>
</includeroutes>
</clientconfig>
</azvpnprofile>
How do I direct all traffic to the VPN tunnel (force tunnel)?

You can modify the downloaded profile XML file and add the <includeroutes><route><destination>
<mask> </destination></mask></route></includeroutes> tags.
<azvpnprofile>
<clientconfig>
<includeroutes>
<route>
<destination>0.0.0.0</destination><mask>1</mask>
</route>
<route>
<destination>128.0.0.0</destination><mask>1</mask>
</route>
</includeroutes>
</clientconfig>
</azvpnprofile>
How do I block (exclude ) routes from the VPN client?

You can modify the downloaded profile XML file and add the <excluderoutes><route><destination>
<mask> </destination></mask></route></excluderoutes> tags.
<azvpnprofile>
<clientconfig>
<excluderoutes>
<route>
<destination>x.x.x.x</destination><mask>24</mask>
</route>
</excluderoutes>
</clientconfig>
</azvpnprofile>
Can I import the profile from a command-line prompt?
You can import the profile from a command-line prompt by placing the downloaded azurevpnconfig.xml file
in the %userprofile%\AppData\Local\Packages\Microsoft.AzureVpn_8wekyb3d8bbwe\LocalState
folder and running the following command:
azurevpn -i azurevpnconfig.xml
To force the import, use the -f switch.
Next steps
For more information, see Create an Azure Active Directory tenant for P2S Open VPN connections that use
Azure AD authentication.
Azure Active Directory authentication: Configure
VPN clients for P2S OpenVPN protocol connections
- macOS
This article helps you configure a VPN client for a computer running macOS 10.15 and later to connect to a
virtual network using Point-to-Site VPN and Azure Active Directory authentication. Before you can connect and
authenticate using Azure AD, you must first configure your Azure AD tenant. For more information, see
Configure an Azure AD tenant.
NOTE
The Azure VPN Client may not be available in all regions due to local regulations.
Azure AD authentication is supported only for OpenVPN® protocol connections and requires the Azure VPN client.
For every computer that you want to connect to a VNet using a Point-to-Site VPN connection, you need to do
the following:
Download the Azure VPN Client to the computer.
Configure a client profile that contains the VPN settings.
If you want to configure multiple computers, you can create a client profile on one computer, export it, and then
import it to other computers.
Prerequisites
Before you can connect and authenticate using Azure AD, you must first configure your Azure AD tenant. For
more information, see Configure an Azure AD tenant.
To download the Azure VPN client

1. Download the Azure VPN Client from the Apple Store.
2. Install the client on your computer.
To import a connection profile

1. Download and extract the profile files. For steps, see Working with VPN client profile files.
2. On the Azure VPN Client page, select Impor t .
3. Navigate to the profile file that you want to import, select it, then click Open .
4. View the connection profile information, then click Save .

5. In the VPN connections pane, select the connection profile that you saved. Then, click Connect .
6. Once connected, the status will change to Connected . To disconnect from the session, click Disconnect .
To create a connection manually
1. Open the Azure VPN Client. Select Add to create a new connection.
2. On the Azure VPN Client page, you can configure the profile settings.
Configure the following settings:
Connection Name: The name by which you want to refer to the connection profile.
VPN Ser ver : This name is the name that you want to use to refer to the server. The name you choose
here does not need to be the formal name of a server.
Ser ver Validation
Cer tificate Information: The certificate CA.
Ser ver Secret: The server secret.
Client Authentication
Authentication Type: Azure Active Directory
Tenant: Name of the tenant.
Issuer : Name of the issuer.
3. After filling in the fields, click Save .
4. In the VPN connections pane, select the connection profile that you configured. Then, click Connect .
5. Using your credentials, sign in to connect.
6. Once connected, you will see the Connected status. When you want to disconnect, click Disconnect to
disconnect the connection.
To remove a connection profile
You can remove the VPN connection profile from your computer.
1. Navigate to the Azure VPN Client.
2. Select the VPN connection that you want to remove, click the dropdown, and select Remove .
3. On the Remove VPN connection? box, click Remove .

Next steps
For more information, see Create an Azure Active Directory tenant for P2S Open VPN connections that use
Azure AD authentication.
Configure an Always On VPN user tunnel for Virtual
WAN
A new feature of the Windows 10 VPN client, Always On, is the ability to maintain a VPN connection. With
Always On, the active VPN profile can connect automatically and remain connected based on triggers, such as
user sign-in, network state change, or device screen active.
You can use gateways with Windows 10 Always On to establish persistent user tunnels and device tunnels to
Azure.
Always On VPN connections include either of two types of tunnels:
Device tunnel : Connects to specified VPN servers before users sign in to the device. Pre-sign-in
connectivity scenarios and device management use a device tunnel.
User tunnel : Connects only after users sign in to the device. By using user tunnels, you can access
organization resources through VPN servers.
Device tunnels and user tunnels operate independent of their VPN profiles. They can be connected at the same
time, and they can use different authentication methods and other VPN configuration settings, as appropriate.
Prerequisites
You must create a point-to-site configuration and edit the virtual hub assignment. See the following sections for
instructions:
Create a P2S configuration
Create hub with P2S gateway
Configure a user tunnel

1. Install client certificates on the Windows 10 client, as shown in this point-to-site VPN client article. The
certificate must be in the current user store.
2. Configure the Always On VPN client through PowerShell, Configuration Manager, or Intune by following
the instructions in Configure Windows 10 client Always On VPN connections.
Example configuration for the user tunnel
After you've configured the virtual network gateway and installed the client certificate in the local machine store
on the Windows 10 client, configure a client device tunnel by using the following examples:
1. Copy the following text, and save it as usercert.ps1:
Param(
[string]$xmlFilePath,
[string]$ProfileName
)
$a = Test-Path $xmlFilePath
echo $a
$ProfileXML = Get-Content $xmlFilePath
echo $XML
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
$Version = 201606090004
$ProfileXML = $ProfileXML -replace '<', '<'

$ProfileXML = $ProfileXML -replace '>', '>'
$ProfileXML = $ProfileXML -replace '"', '"'
$nodeCSPURI = './Vendor/MSFT/VPNv2'
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"
$session = New-CimSession
try
{
$newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI",
'String', 'Key')
$newInstance.CimInstanceProperties.Add($property)
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID",
"$ProfileNameEscaped", 'String', 'Key')
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML",
'String', 'Property')
$session.CreateInstance($namespaceName, $newInstance)
$Message = "Created $ProfileName profile."
Write-Host "$Message"
}
catch [Exception]
{
$Message = "Unable to create $ProfileName profile: $_"
exit
}
$Message = "Complete."
2. Copy the following text, and save it as VPNProfile.xml in the same folder as usercert.ps1. Edit the
following text to match your environment:
<Servers>azuregateway-1234-56-78dc.cloudapp.net</Servers> <= Can be found in the VpnSettings.xml in
the downloaded profile zip file
<Address>192.168.3.5</Address> <= IP of resource in the vnet or the vnet address space
<PrefixSize>32</PrefixSize> <= Subnet mask
<VPNProfile>
<NativeProfile>
<Servers>azuregateway-b115055e-0882-49bc-a9b9-7de45cba12c0-8e6946892333.vpn.azure.com</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<UserMethod>Eap</UserMethod>
<Eap>
<Configuration>
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><EapMethod><Type
xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type><VendorId
xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId><VendorType
xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType><AuthorId
xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId></EapMethod><Config
xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><Eap
xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>13</Type><EapType
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1"><CredentialsSource>
<CertificateStore><SimpleCertSelection>true</SimpleCertSelection></CertificateStore>
</CredentialsSource><ServerValidation>
<DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation><ServerNames>
</ServerNames></ServerValidation><DifferentUsername>false</DifferentUsername><PerformServerValidation
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</PerformServerValida
tion><AcceptServerName
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
</EapType></Eap></Config></EapHostConfig>
</Configuration>
</Eap>
</Authentication>
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>

<Route>
<Address>192.168.3.5</Address>
<PrefixSize>32</PrefixSize>
</Route>
<Route>
</Route>

<TrafficFilter>
<RemoteAddressRanges>192.168.3.4, 192.168.3.5</RemoteAddressRanges>
</TrafficFilter>

<RememberCredentials>true</RememberCredentials>

<RegisterDNS>true</RegisterDNS>
</VPNProfile>
3. Run PowerShell as an administrator.

4. In PowerShell, switch to the folder where usercert.ps1 and VPNProfile.xml are located, and run the
following command:
C:\> .\usercert.ps1 .\VPNProfile.xml UserTest

5. Under VPN Settings , look for the UserTest entry, and then select Connect .
6. If the connection succeeds, you've successfully configured an Always On user tunnel.
To remove a profile
To remove a profile, use the following steps:
1. Run the following command:
C:\> Remove-VpnConnection UserTest
2. Disconnect the connection, and clear the Connect automatically check box.
Next steps
Configure an Always On VPN device tunnel for
Virtual WAN
A new feature of the Windows 10 VPN client, Always On, is the ability to maintain a VPN connection. With
Always On, the active VPN profile can connect automatically and remain connected based on triggers, such as
user sign-in, network state change, or device screen active.
You can use gateways with Windows 10 Always On to establish persistent user tunnels and device tunnels to
Azure.
Always On VPN connections include either of two types of tunnels:
Device tunnel : Connects to specified VPN servers before users sign in to the device. Pre-sign-in
connectivity scenarios and device management use a device tunnel.
User tunnel : Connects only after users sign in to the device. By using user tunnels, you can access
organization resources through VPN servers.
Device tunnels and user tunnels operate independent of their VPN profiles. They can be connected at the same
time, and they can use different authentication methods and other VPN configuration settings, as appropriate.
Prerequisites
You must create a point-to-site configuration and edit the virtual hub assignment. See the following sections for
instructions:
Create a P2S configuration
Create hub with P2S gateway
Configure the device tunnel

The following requirements must be met in order to successfully establish a device tunnel:
The device must be a domain joined computer running Windows 10 Enterprise or Education version 1809 or
later.
The tunnel is only configurable for the Windows built-in VPN solution and is established using IKEv2 with
computer certificate authentication.
Only one device tunnel can be configured per device.
1. Install client certificates on the Windows 10 client using the point-to-site VPN client article. The certificate
needs to be in the Local Machine store.
2. Create a VPN Profile and configure device tunnel in the context of the LOCAL SYSTEM account using these
instructions.
Configuration example for device tunnel
After you have configured the virtual network gateway and installed the client certificate in the Local Machine
store on the Windows 10 client, use the following examples to configure a client device tunnel:
1. Copy the following text and save it as devicecer t.ps1 .
Param(
[string]$xmlFilePath,
[string]$ProfileName
)
$a = Test-Path $xmlFilePath
echo $a
$ProfileXML = Get-Content $xmlFilePath
echo $XML
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
$Version = 201606090004
$ProfileXML = $ProfileXML -replace '<', '<'

$ProfileXML = $ProfileXML -replace '>', '>'
$ProfileXML = $ProfileXML -replace '"', '"'
$nodeCSPURI = './Vendor/MSFT/VPNv2'
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"
$session = New-CimSession
try
{
$newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI",
'String', 'Key')
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID",
"$ProfileNameEscaped", 'String', 'Key')
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML",
'String', 'Property')
$session.CreateInstance($namespaceName, $newInstance)
$Message = "Created $ProfileName profile."
}
catch [Exception]
{
$Message = "Unable to create $ProfileName profile: $_"
exit
}
$Message = "Complete."
2. Copy the following text and save it as VPNProfile.xml in the same folder as devicecer t.ps1 . Edit the
following text to match your environment.
<Servers>azuregateway-1234-56-78dc.cloudapp.net</Servers> <= Can be found in the VpnSettings.xml in
the downloaded profile zip file
<VPNProfile>
<NativeProfile>
<Servers>azuregateway-1234-56-78dc.cloudapp.net</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<MachineMethod>Certificate</MachineMethod>
</Authentication>
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>

<Route>
</Route>
<Route>
</Route>


<DeviceTunnel>true</DeviceTunnel>

<RegisterDNS>true</RegisterDNS>
</VPNProfile>
3. Download PsExec from Sysinternals and extract the files to C:\PSTools .

4. From an Admin CMD prompt, launch PowerShell by running:
For 32-bit Windows:
PsExec.exe -s -i powershell
For 64-bit Windows:
PsExec64.exe -s -i powershell
5. In PowerShell, switch to the folder where devicecer t.ps1 and VPNProfile.xml are located, and run the
following command:
.\devicecert.ps1 .\VPNProfile.xml MachineCertTest
6. Run rasphone .
7. Look for the MachineCer tTest entry and click Connect .
8. If the connection succeeds, reboot the computer. The tunnel will connect automatically.
To remove a profile
To remove the profile, run the following command:
Next steps
Enable Azure AD Multi-Factor Authentication (MFA)
for VPN users by using Azure AD authentication
If you want users to be prompted for a second factor of authentication before granting access, you can configure
Azure AD Multi-Factor Authentication (MFA). You can configure MFA on a per user basis, or you can leverage
MFA via Conditional Access.
MFA per user can be enabled at no-additional cost. When enabling MFA per user, the user will be prompted
for second factor authentication against all applications tied to the Azure AD tenant. See Option 1 for steps.
Conditional Access allows for finer-grained control over how a second factor should be promoted. It can
allow assignment of MFA to only VPN, and exclude other applications tied to the Azure AD tenant. See Option
2 for steps.
Enable authentication
1. Navigate to Azure Active Director y -> Enterprise applications -> All applications .
2. On the Enterprise applications - All applications page, select Azure VPN .
Configure sign-in settings

On the Azure VPN - Proper ties page, configure sign-in settings.
1. Set Enabled for users to sign-in? to Yes . This setting allows all users in the AD tenant to connect to
the VPN successfully.
2. Set User assignment required? to Yes if you want to limit sign-in to only users that have permissions
to the Azure VPN.
3. Save your changes.
Option 1 - Per User access
Open the MFA page
2. Navigate to Azure Active Director y -> All users .
3. Select Multi-Factor Authentication to open the multi-factor authentication page.
Select users
1. On the multi-factor authentication page, select the user(s) for whom you want to enable MFA.
2. Select Enable .
Option 2 - Conditional Access

Conditional Access allows for fine-grained access control on a per-application basis. In order to use Conditional
Access, you should have Azure AD Premium 1 or greater licensing applied to the users that will be subject to the
Conditional Access rules.
1. Navigate to the Enterprise applications - All applications page and click Azure VPN .
Click Conditional Access .
Click New policy to open the New pane.
2. On the New pane, navigate to Assignments -> Users and groups . On the Users and groups ->
Include tab:
Click Select users and groups .
Check Users and groups .
Click Select to select a group or set of users to be affected by MFA.
Click Done .
3. On the New pane, navigate to the Access controls -> Grant pane:
Click Grant access .
Click Require multi-factor authentication .
Click Require all the selected controls .
Click Select .
4. In the Enable policy section:
Select On .
Click Create .
Next steps
To connect to your virtual network, you must create and configure a VPN client profile. See Configure Azure AD
authentication for Point-to-Site connection to Azure.
Configure a Point-to-Site User VPN connection -
Azure Active Directory authentication
This article shows you how to configure Azure AD authentication for User VPN in Virtual WAN to connect to
your resources in Azure over an OpenVPN VPN connection. Azure Active Directory authentication is only
available for gateways using the OpenVPN protocol. For more information about Virtual WAN, see the Virtual
WAN Overview.
NOTE
Azure AD authentication is supported for OpenVPN® protocol connections only and requires the Azure VPN client.

Download a virtual WAN User VPN profile
Create a virtual hub
Edit a hub to add P2S gateway
Download and apply the User VPN client configuration
Before you begin

on premises. If you are unfamiliar with the IP address ranges located in your on-premises network

WAN page.
environment.


A User VPN configuration defines the parameters for connecting remote clients. It is important to create the
User VPN configuration before configuring your virtual hub with P2S settings, as you must specify the User
VPN configuration you want to use.
1. Navigate to your Vir tual WAN ->User VPN configurations page and click +Create user VPN
config .
2. On the Basics page, specify the parameters.

Configuration name - Enter the name you want to call your User VPN Configuration.
Tunnel type - Select OpenVPN from the dropdown menu.
3. Click Azure Active Director y to open the page.
Toggle Azure Active Director y to Yes and supply the following values based on your tenant details. You
can view the necessary values on the Azure Active Directory page for Enterprise applications in the
portal.
Authentication method - Select Azure Active Directory.
Audience - Type in the Application ID of the Azure VPN Enterprise Application registered in your
Azure AD tenant.
Issuer - https://sts.windows.net/<your Directory ID>/
AAD Tenant - https://login.microsoftonline.com/<your Directory ID>
4. Click Create to create the User VPN configuration. You will select this configuration later in the exercise.
Create an empty hub

For this exercise, we create an empty virtual hub. In the next section, you add a gateway to an already existing
hub. However, it is also possible to combine these steps and create the hub with the P2S gateway settings all at
once.
select Hubs .
Add a P2S gateway to a hub

This section shows you how to add a gateway to an already existing virtual hub. This step can take up to 30
minutes for the hub to complete updating.
1. Navigate to the Hubs page under the virtual WAN.
2. Select the hub to which you want to associate the VPN server configuration and click the ellipsis (...) to
show the menu. Then, click Edit vir tual hub .
3. On the Edit vir tual hub page, check the checkboxes for Include vpn gateway for vpn sites and
Include point-to-site gateway to reveal the settings. Then configure the values.
Gateway scale units : Select the Gateway scale units. Scale units represent the aggregate capacity of
the User VPN gateway. If you select 40 or more gateway scale units, plan your client address pool
accordingly. For information about how this setting impacts the client address pool, see About client
address pools. For information about gateway scale units, see the FAQ.
User VPN configuration : Select the configuration that you created earlier.
Client address pool : Specify the client address pool from which the VPN clients will be assigned IP
addresses. This setting corresponds to the gateway scale units that you
4. Click Confirm . It can take up to 30 minutes to update the hub.
Connect VNet to hub

In this section, you create a connection between your virtual hub and your VNet.
Download User VPN profile

All of the necessary configuration settings for the VPN clients are contained in a VPN client configuration zip file.
The settings in the zip file help you easily configure the VPN clients. The VPN client configuration files that you
generate are specific to the User VPN configuration for your gateway. In this section, you generate and
download the files used to configure your VPN clients.
user VPN profile .
VPN profile.
your computer.
Configure User VPN clients

Each computer that connects must have a client installed. You configure each client by using the VPN User client
profile files that you downloaded in the previous steps. Use the article that pertains to the operating system that
To configure macOS VPN clients (Preview)
For macOS client instructions, see Configure a VPN client - macOS (Preview).
To configure Windows VPN clients
1. Download the Azure VPN Client to each computer.
to On .
To import a VPN client profile (Windows )


To delete a client profile - Windows

Diagnose connection issues - Windows


3. In the Hubs and connections section, you can view hub status, site, region, VPN connection status, and bytes
in and out.
Clean up resources
complete.
VPN:
ExpressRoute:
the virtual WAN.
Next steps
Create an Azure Active Directory (AD) tenant for
P2S OpenVPN protocol connections
When connecting to your VNet, you can use certificate-based authentication or RADIUS authentication.
However, when you use the Open VPN protocol, you can also use Azure Active Directory authentication. If you
want different set of users to be able to connect to different gateways, you can register multiple apps in AD and
link them to different gateways.
This article helps you set up an Azure AD tenant for P2S OpenVPN authentication, and create and register
multiple apps in Azure AD to allow different access for different users and groups.
NOTE
1. Create the Azure AD tenant

Create an Azure AD tenant using the steps in the Create a new tenant article:
Organizational name
Initial domain name
Example:
2. Create tenant users

In this step, you create two Azure AD tenant users: One Global Admin account and one master user account. The
master user account is used as your master embedding account (service account). When you create an Azure AD
tenant user account, you adjust the Directory role for the type of user that you want to create. Use the steps in
this article to create at least two users for your Azure AD tenant. Be sure to change the Director y Role to create
the account types:
Global Admin
User
3. Register the VPN Client

Register the VPN client in the Azure AD tenant.
1. Locate the Directory ID of the directory that you want to use for authentication. It is listed in the
properties section of the Active Directory page.
2. Copy the Directory ID.

3. Sign in to the Azure portal as a user that is assigned the Global administrator role.
4. Next, give admin consent. Copy and paste the URL that pertains to your deployment location in the
address bar of your browser:
Public
https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-
cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent
Azure Government
https://login.microsoftonline.us/common/oauth2/authorize?client_id=51bb15d4-3a4f-4ebf-9dca-
40096fe32426&response_type=code&redirect_uri=https://portal.azure.us&nonce=1234&prompt=admin_consent
Microsoft Cloud Germany
https://login-us.microsoftonline.de/common/oauth2/authorize?client_id=538ee9e6-310a-468d-afef-
ea97365856a9&response_type=code&redirect_uri=https://portal.microsoftazure.de&nonce=1234&prompt=admin
_consent
Azure China 21Vianet
https://https://login.chinacloudapi.cn/common/oauth2/authorize?client_id=49f817b6-84ae-4cc0-928c-
73f27289b3aa&response_type=code&redirect_uri=https://portal.azure.cn&nonce=1234&prompt=admin_consent
NOTE
If you using a global admin account that is not native to the Azure AD tenant to provide consent, please replace
“common” with the Azure AD directory id in the URL. You may also have to replace “common” with your directory id in
certain other cases as well.
5. Select the Global Admin account if prompted.
6. Select Accept when prompted.

7. Under your Azure AD, in Enterprise applications , you will see Azure VPN listed.
4. Register additional applications

In this step, you register additional applications for various users and groups.
1. Under your Azure Active Directory, click App registrations and then + New registration .
2. On the Register an application page, enter the Name . Select the desired Suppor ted account types ,
then click Register .
3. Once the new app has been registered, click Expose an API under the app blade.
4. Click + Add a scope .
5. Leave the default Application ID URI . Click Save and continue .
6. Fill in the required fields and ensure that State is Enabled . Click Add scope .
7. Click Expose an API then + Add a client application . For Client ID , enter the following values
depending on the cloud:
Enter 41b23e61-6c1e-4545-b367-cd054e0ed4b4 for Azure Public
Enter 51bb15d4-3a4f-4ebf-9dca-40096fe32426 for Azure Government
Enter 538ee9e6-310a-468d-afef-ea97365856a9 for Azure Germany
Enter 49f817b6-84ae-4cc0-928c-73f27289b3aa for Azure China 21Vianet
8. Click Add application .
9. Copy the Application (client) ID from the Over view page. You will need this information to configure
your VPN gateway(s).
10. Repeat the steps in this register additional applications section to create as many applications that are
needed for your security requirement. Each application will be associated to a VPN gateway and can have
a different set of users. Only one application can be associated to a gateway.
5. Assign users to applications

Assign the users to your applications.
1. Under Azure AD -> Enterprise applications , select the newly registered application and click
Proper ties . Ensure that User assignment required? is set to yes . Click Save .
2. On the app page, click Users and groups , and then click +Add user .
3. Under Add Assignment , click Users and groups . Select the users that you want to be able to access
this VPN application. Click Select .
6. Create a new P2S configuration
A P2S configuration defines the parameters for connecting remote clients.
1. Set the following variables, replacing values as needed for your environment.
$aadAudience = "00000000-abcd-abcd-abcd-999999999999"
$aadIssuer = "https://sts.windows.net/00000000-abcd-abcd-abcd-999999999999/"
$aadTenant = "https://login.microsoftonline.com/00000000-abcd-abcd-abcd-999999999999"
2. Run the following commands to create the configuration:
$aadConfig = New-AzVpnServerConfiguration -ResourceGroupName <ResourceGroup> -Name newAADConfig -

VpnProtocol OpenVPN -VpnAuthenticationType AAD -AadTenant $aadTenant -AadIssuer $aadIssuer -
AadAudience $aadAudience -Location westcentralus
NOTE
Do not use the Azure VPN client's application ID in the commands above: It will grant all users access to the
gateway. Use the ID of the application(s) you registered.
7. Edit hub assignment

1. Navigate to the Hubs blade under the virtual WAN.
2. Select the hub that you want to associate the vpn server configuration to and click the ellipsis (...).
3. Click Edit vir tual hub .
4. Check the Include point-to-site gateway check box and pick the Gateway scale unit that you want.
5. Enter the Address pool from which the VPN clients will be assigned IP addresses.
6. Click Confirm .
7. The operation can take up to 30 minutes to complete.
8. Download VPN profile
Use the VPN profile to configure your clients.
1. On the page for your virtual WAN, click User VPN configurations .
2. At the top of the page, click Download user VPN config .
3. Once the file has finished creating, you can click the link to download it.
4. Use the profile file to configure the VPN clients.
5. Extract the downloaded zip file.
6. Browse to the unzipped "AzureVPN" folder.
7. Make a note of the location of the "azurevpnconfig.xml" file. The azurevpnconfig.xml contains the setting
for the VPN connection and can be imported directly into the Azure VPN Client application. You can also
distribute this file to all the users that need to connect via e-mail or other means. The user will need valid
Azure AD credentials to connect successfully.
9. Configure User VPN clients

To connect, you need to download the Azure VPN Client and import the VPN client profile that was downloaded
in the previous steps on every computer that wants to connect to the VNet.
NOTE
To download the Azure VPN client

Use this link to download the Azure VPN Client.
To import a client profile

To delete a client profile

To diagnose connection issues



10. View your virtual WAN

bytes in and out.
Clean up resources
When you no longer need these resources, you can use Remove-AzureRmResourceGroup to remove the
resource group and all of the resources it contains. Replace "myResourceGroup" with the name of your resource
group and run the following PowerShell command:
Remove-AzureRmResourceGroup -Name myResourceGroup -Force
Next steps
How to configure virtual hub routing
A virtual hub can contain multiple gateways such as a Site-to-site VPN gateway, ExpressRoute gateway, Point-to-
site gateway, and Azure Firewall. The routing capabilities in the virtual hub are provided by a router that
manages all routing, including transit routing, between the gateways using Border Gateway Protocol (BGP). This
router also provides transit connectivity between virtual networks that connect to a virtual hub and can support
up to an aggregate throughput of 50 Gbps. These routing capabilities apply to Standard Virtual WAN customers.
For more information, see About virtual hub routing.
Create a route table

1. In the Azure portal, navigate to the virtual hub.
2. Under Connectivity , select Routing . On the Routing page, you see the Default and None route tables.
3. Select +Create route table to open the Create Route Table page.
4. On the Create Route Table page Basics tab, complete the following fields.
Name
Routes
Route name
Destination type
Destination prefix : You can aggregate prefixes. For example: VNet 1: 10.1.0.0/24 and VNet 2:
10.1.1.0/24 can be aggregated as 10.1.0.0/16. Branch routes apply to all connected VPN sites,
ExpressRoute circuits, and User VPN connections.
Next hop : A list of virtual network connections, or Azure Firewall.
If you select a virtual network connection, you will see Configure static routes . This is an
optional configuration setting. For more information, see Configuring static routes.
5. Select the Labels tab to configure label names. Labels provide a mechanism to logically group route
tables.
6. Select the Associations tab to associate connections to the route table. You will see Branches , Vir tual
Networks , and the Current settings of the connections.
7. Select the Propagations tab to propagate routes from connections to the route table.
8. Select Create to create the route table.
To edit a route table

In the Azure portal, locate the route table of your virtual hub. Select the route table to edit any information.
To delete a route table

In the Azure portal, locate the route table of your virtual hub. You cannot delete a Default or None route table.
However, you can delete all custom route tables. Click "…" , and then select Delete .
To view effective routes

In the Azure portal, locate the route table of your virtual hub. Click "…" and select Effective Routes to view
routes learned by the selected route table. Propagated routes from the connection to the route table are
automatically populated in Effective Routes of the route table. For more information, see About effective
routes.
To set up routing configuration for a virtual network connection
1. In the Azure portal, navigate to your virtual WAN and, under Connectivity , select Vir tual Network
Connections .
2. Select +Add connection .
3. Select the virtual network from the dropdown.
4. Set up the routing configuration to associate to a route table. For Associate Route Table , select the route
table from the dropdown.
5. Set up the routing configuration to propagate to one or many route tables. For Propagate to Route Table ,
select from the dropdown.
6. For Static routes , configure static routes for Network Virtual Appliance (if applicable). Virtual WAN
supports a single next hop IP for static route in a virtual network connection. For example, if you have a
separate virtual appliance for ingress and egress traffic flows, it would be best to have the virtual appliances
in separate VNETs and attach the VNETs to the virtual hub.
Next steps
For more information about virtual hub routing, see About virtual hub routing. For more information about
Virtual WAN, see the FAQ.
View virtual hub effective routes
You can view all routes of your Virtual WAN hub in the Azure portal. This article walks you through the steps to
view effective routes. For more information about virtual hub routing, see About virtual hub routing.
Select connections or route tables

1. Navigate to your virtual hub, then select Routing . On the Routing page, select Effective Routes .
2. From the dropdown, you can select Route Table . If you don't see a Route Table option, this means that you
don't have a custom or default route table set up in this virtual hub.
View output
The page output shows the following fields:
Prefix : Address prefix known to the current entity (learnt from the virtual hub router)
Next hop type : Can be Virtual Network Connection, VPN_S2S_Gateway, ExpressRouteGateway, Remote
Hub, or Azure Firewall.
Next hop : This is the link to the resource ID of the next hop, or simply shows On-link to imply the current
hub.
Origin : Resource ID of the routing source.
AS Path : BGP Attribute AS (autonomous system) path lists all the AS numbers that need to be traversed to
reach the location where the prefix that the path is attached to, is advertised from.
Example
The values in the following example table imply that the virtual hub connection or route table has learned the
route of 10.2.0.0/24 (a branch prefix). It has learned the route due to the VPN Next hop type
VPN_S2S_Gateway with Next hop VPN Gateway resource ID. Route Origin points to the resource ID of the
originating VPN gateway/Route table/Connection. AS Path indicates the AS Path for the branch.
Use the scroll bar at the bottom of the table to view the "AS Path".
P REF IX N EXT H O P T Y P E N EXT H O P RO UT E O RIGIN A S PAT H
10.2.0.0/24 VPN_S2S_Gateway /subscriptions/ /subscriptions/ 20000

<sub id> <sub id>
/resourceGroups/ /resourceGroups/
<resource group <resource group
name> name>
/providers/Microsoft. /providers/Microsoft.
Network/vpnGatewa Network/vpnGatewa
ys/vpngw ys/vpngw
Considerations:
If you see 0.0.0.0/0 in the Get Effective Routes output, it implies the route exists in one of the route
tables. However, if this route was set up for internet, an additional flag "enableInternetSecurity": true
is required on the connection. The effective route on the VM NIC will not show the route if the
"enableInternetSecurity" flag on the connection is "false".
The Propagate Default Route field is seen in Azure Virtual WAN portal when you edit a virtual network
connection, a VPN connection, or an ExpressRoute connection. This field indicates the
enableInternetSecurity flag, which is always by default "false" for ExpressRoute and VPN connections,
but "true" for virtual network connections.
When viewing effective routes on a VM NIC, if you see the next hop as 'Virtual Network Gateway', that
implies the Virtual hub router when the VM is in a spoke connected to a Virtual WAN hub.
View Effective routes for a virtual hub route table is populated only if the virtual hub has at least one
type of connection (VPN/ER/VNET) connected to it.
Next steps
How to configure Virtual WAN Hub routing intent
and routing policies
NOTE
Hub Routing Intent is currently in gated public preview.
This preview is provided without a service-level agreement and isn't recommended for production workloads. Some
features might be unsupported or have constrained capabilities. For more information, see Supplemental terms of use for
Microsoft Azure previews.
To obtain access to the preview, please deploy two hubs in the same Azure region along side any gateways (Site-to-site
VPN Gateways, Point-to-site Gateways and ExpressRouteGateways) and then reach out to
previewinterhub@microsoft.com with the Virtual WAN ID, Subscription ID and Azure Region you wish to configure
Routing Intent in. Expect a response within 48 business hours (Monday-Friday) with confirmation of feature enablement.
Please note that any gateways created after feature enablement will need to be upgraded by the Virtual WAN team.
Background
Routing Policy, each with a single Next Hop resource.
as one entity within the Routing Intent Concepts.
NOTE
In the gated public preview of Virtual WAN Hub routing policies, inter-hub traffic is only inspected by Azure Firewall or a
Network Virtual Appliance deployed in the Virtual WAN Hub if the Virtual WAN Hubs are in the same region.
hub, all branch (User VPN (Point-to-site VPN), Site-to-site VPN, and ExpressRoute) and Virtual Network
connections to that Virtual WAN Hub will forward Internet-bound traffic to the Azure Firewall resource,
Third-Party Security provider or Network Virtual Appliance specified as part of the Routing Policy.
will be forwarded to the Next Hop Azure Firewall resource or Network Virtual Appliance resource that
was specified in the Private Traffic Routing Policy.
In other words, when a Private Traffic Routing Policy is configured on the Virtual WAN Hub, all branch-to-
branch, branch-to-virtual network, virtual network-to-branch and inter-hub traffic will be sent via Azure
Firewall or a Network Virtual Appliance deployed in the Virtual WAN Hub.
Key considerations
You will not be able to enable routing policies on your deployments with existing Custom Route tables
configured or if there are static routes configured in your Default Route Table.
Currently, Private Traffic Routing Policies are not supported in Hubs with Encrypted ExpressRoute
connections (Site-to-site VPN Tunnel running over ExpressRoute Private connectivity).
In the gated public preview of Virtual WAN Hub routing policies, inter-hub traffic is only inspected by Azure
Firewall or Network Virtual Appliances deployed in the Virtual WAN Hub if the Virtual WAN Hubs are in the
same region.
Routing Intent and Routing Policies currently must be configured via the custom portal link provided in Step
3 of Prerequisites . Routing Intents and Policies are not supported via Terraform, PowerShell, and CLI.
Prerequisites
1. Create a Virtual WAN. Make sure you create at least two Virtual Hubs in the same region. For instance, you
may create a Virtual WAN with two Virtual Hubs in East US. Note that if you only wish to inspect branch-to-
branch traffic, you may deploy a single Virtual WAN Hub as opposed to multiple Hubs in the same region.
2. Convert your Virtual WAN Hub into a Secured Virtual WAN Hub by deploying an Azure Firewall into the
Virtual Hubs in the chosen region. For more information on converting your Virtual WAN Hub to a Secured
Virtual WAN Hub, please see How to secure your Virtual WAN Hub.
3. Deploy any Site-to-site VPN, Point-to-site VPN and ExpressRoute Gateways you will use for testing. Reach out
to previewinterhub@microsoft.com with the Vir tual WAN Resource ID and the Azure Vir tual hub
Region you wish to configure Routing Policies in. To locate the Virtual WAN ID, open Azure portal, navigate
to your Virtual WAN resource and select Settings > Properties > Resource ID. For example:
/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtua
lWans/<virtualWANname>
4. Expect a response within 24-48 hours with confirmation of feature enablement.

5. Ensure that your Virtual Hubs do not have any Custom Route Tables or any routes you may have added into
the defaultRouteTable. You will not be able to enable routing policies on your deployments with existing
Custom Route tables configured or if there are static routes configured in your Default Route Table.
6. If you are using an Azure Firewall deployed in the Virtual WAN Hub, please reference Configuring routing
policies (through Azure Firewall Manager) to configure routing intent and routing policies. If you are using a
Network Vir tual Appliance deployed in the Virtual WAN Hub, please reference Configuring routing
policies (through Virtual WAN Portal) to configure routing intent and routing policies.
Configure routing policies (through Azure Firewall Manager)

1. From the custom portal Link provided in the confirmation email from Step 3 in the Prerequisites
section, navigate to the Virtual WAN Hub that you want to configure Routing Policies on.
2. Under Security, select Secured Vir tual hub settings and then Manage security provider and route
settings for this Secured vir tual hub in Azure Firewall Manager
3. Select the Hub you want to configure your Routing Policies on from the menu.
4. Select Security configuration under Settings
5. If you want to configure an Internet Traffic Routing Policy, select Azure Firewall or the relevant Internet
Security provider from the dropdown for Internet Traffic . If not, select None
6. If you want to configure a Private Traffic Routing Policy (for branch and Virtual Network traffic) via Azure
Firewall, select Azure Firewall from the dropdown for Private Traffic . If not, select Bypass Azure
Firewall .
7. If you want to configure a Private Traffic Routing Policy and have branches or virtual networks advertising
non-IANA RFC1918 Prefixes, select Private Traffic Prefixes and specify the non-IANA RFC1918 prefix
ranges in the text box that comes up. Select Done .
8. Select Inter-hub to be Enabled . Enabling this option ensures your Routing Policies are applied to the
Routing Intent of this Virtual WAN Hub.
9. Select Save . This operation will take around 10 minutes to complete.
10. Repeat steps 2-8 for other Secured Virtual WAN hubs that you want to configure Routing policies for.
Configure routing policies (through Virtual WAN portal)

NOTE
The only Network Virtual Appliance deployed in the Virtual WAN hub compatible with routing intent and routing policies
are listed in the Partners section as dual-role connectivity and Next-Generation Firewall solution providers.
1. From the custom portal link provided in the confirmation email from Step 3 in the Prerequisites section,
navigate to the Virtual WAN hub that you want to configure routing policies on.
2. Under Routing, select Routing Policies .
3. If you want to configure a Private Traffic Routing Policy (for branch and Virtual Network Traffic), select
Network Vir tual Appliance under Private Traffic and under Next Hop Resource select the Network
Virtual Appliance resource you wish to send traffic to.
4. If you want to configure a Private Traffic Routing Policy and have branches or virtual networks using non-
IANA RFC1918 Prefixes, select Additional Prefixes and specify the non-IANA RFC1918 prefix ranges in
the text box that comes up. Select Done .
5. If you want to configure a Internet Traffic Routing Policy, under Internet traffic select Network Vir tual
Appliance and under Next Hop Resource select the Network Virtual Appliance you want to send
internet-bound traffic to.
6. To apply your routing intent and routing policies configuration, click Save .
7. Repeat for all hubs you would like to configure routing policies for.
Routing policy configuration examples

The following section describes two common scenarios customers of applying Routing Policies to Secured
Virtual WAN hubs.
All Virtual WAN Hubs are secured (deployed with Azure Firewall or NVA )
In this scenario, all Virtual WAN hubs are deployed with an Azure Firewall or NVA in them. In this scenario, you
may configure an Internet Traffic Routing Policy, a Private Traffic Routing Policy or both on each Virtual WAN
Hub.
Consider the following configuration where Hub 1 and Hub 2 have Routing Policies for both Private and Internet
Traffic.
Hub 1 configuration:
Private Traffic Policy with Next Hop Hub 1 Azure Firewall or NVA
Internet Traffic Policy with Next Hop Hub 1 Azure Firewall or NVA
The following are the traffic flows that result from such a configuration.
NOTE
Internet Traffic must egress through the local Azure Firewall as the default route (0.0.0.0/0) does not propagate across
hubs.
H UB 1 H UB 2
F RO M TO H UB 1 VN ET S B RA N C H ES H UB 2 VN ET S B RA N C H ES IN T ERN ET
Hub 1 VNets → Hub 1 AzFW Hub 1 AzFW Hub 1 and 2 Hub 1 and 2 Hub 1 AzFW
or NVA or NVA AzFW or NVA AzFW or NVA or NVA
Hub 1 → Hub 1 AzFW Hub 1 AzFW Hub 1 and 2 Hub 1 and 2 Hub 1 AzFW
Branches or NVA or NVA AzFW or NVA AzFW or NVA or NVA
Hub 2 VNets → Hub 1 and 2 Hub 1 and 2 Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
AzFW or NVA AzFW or NVA or NVA or NVA or NVA
Hub 2 → Hub 1 and 2 Hub 1 and 2 Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
Branches AzFW or NVA AzFW or NVA or NVA or NVA or NVA
Mixture of secured and regular Virtual WAN Hubs

In this scenario, not all Virtual WAN hubs are deployed with an Azure Firewall or Network Virtual Appliances in
them. In this scenario, you may configure an Internet Traffic Routing Policy, a Private Traffic Routing Policy on the
secured Virtual WAN Hubs.
Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) are deployed in a Virtual
WAN. Hub 2 has Routing Policies for both Private and Internet Traffic.
Hub 1 Configuration:
N/A (cannot configure Routing Policies if hub is not deployed with Azure Firewall or NVA)
The following are the traffic flows that result from such a configuration. Branches and Virtual Networks
connected to Hub 1 cannot access the Internet via Azure Firewall in the Hub because the default route
(0.0.0.0/0) does not propagate across hubs.
H UB 1 H UB 2
Hub 1 VNets → Direct Direct Hub 2 AzFW Hub 2 AzFW -

or NVA or NVA
Hub 1 → Direct Direct Hub 2 AzFW Hub 2 AzFW -

Branches or NVA or NVA
Hub 2 VNets → Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
or NVA or NVA or NVA or NVA or NVA
Hub 2 → Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
Branches or NVA or NVA or NVA or NVA
Troubleshooting
The following section describes common issues encountered when you configure Routing Policies on your
Virtual WAN Hub. Read the below sections and if your issue is still unresolved, reach out to
previewinterhub@microsoft.com for support. Expect a response within 48 business hours (Monday through
Friday).
Troubleshooting configuration issues
Make sure that you have gotten confirmation from previewinterhub@microsoft.com that access to the
gated public preview has been granted to your subscription and chosen region. You will not be able to
configure routing policies without being granted access to the preview.
After enabling the Routing Policy feature on your deployment, ensure you only use the custom portal
link provided as part of your confirmation email. Do not use PowerShell, CLI, or REST API calls to manage
your Virtual WAN deployments. This includes creating new Branch (Site-to-site VPN, Point-to-site VPN or
ExpressRoute) connections.
NOTE
If you are using Terraform, routing policies are currently not supported.
Ensure that your Virtual Hubs do not have any Custom Route Tables or any static routes in the
defaultRouteTable. You will not be able to select Enable interhub from Firewall Manager on your Virtual
WAN Hub if there are Custom Route tables configured or if there are static routes in your
defaultRouteTable.
Troubleshooting data path
Currently, using Azure Firewall to inspect inter-hub traffic is only available for Virtual WAN hubs that are
deployed in the same Azure Region.
You can verify that the Routing Policies have been applied properly by checking the Effective Routes of the
DefaultRouteTable. If Private Routing Policies are configured, you should see routes in the DefaultRouteTable
for private traffic prefixes with next hop Azure Firewall. If Internet Traffic Routing Policies are configured, you
should see a default (0.0.0.0/0) route in the DefaultRouteTable with next hop Azure Firewall.
If there are any Site-to-site VPN gateways or Point-to-site VPN gateways created after the feature has been
confirmed to be enabled on your deployment, you will have to reach out again to
previewinterhub@microsoft.com to get the feature enabled.
Troubleshooting Azure Firewall
If you are using non IANA RFC1918 prefixes in your branches/Virtual Networks, make sure you have
specified those prefixes in the "Private Prefixes" text box in Firewall Manager.
If you have specified non RFC1918 addresses as part of the Private Traffic Prefixes text box in Firewall
Manager, you may need to configure SNAT policies on your Firewall to disable SNAT for non-RFC1918
private traffic. For more information, reference the following document.
Configure and view Azure Firewall logs to help troubleshoot and analyze your network traffic. For more
information on how to set-up monitoring for Azure Firewall, reference the following document. An overview
of the different types of Firewall logs can be found here.
For more information on Azure Firewall, review Azure Firewall Documentation.
Frequently asked questions

Why can't I edit the defaultRouteTable from the custom portal link provided by
previewinterhub@microsoft.com?
As part of the gated public preview of Routing Policies, your Virtual WAN hub routing is managed entirely by
Firewall Manager. Additionally, the managed preview of Routing Policies is not supported alongside Custom
Routing. Custom Routing with Routing Policies will be supported at a later date.
However, you can still view the Effective Routes of the DefaultRouteTable by navigating to the Effective Routes
Tab.
Can I configure a Routing Policy for Private Traffic and also send Internet Traffic (0.0.0.0/0) via a Network
Virtual Appliance in a Spoke Virtual Network?
This scenario is not supported in the gated public preview. However, reach out to
previewinterhub@microsoft.com to express interest in implementing this scenario.
Does the default route (0.0.0.0/0) propagate across hubs?
No. Currently, branches and Virtual Networks will egress to the internet using an Azure Firewall deployed inside
of the Virtual WAN hub the branches and Virtual Networks are connected to. You cannot configure a connection
to access the Internet via the Firewall in a remote hub.
Why do I see RFC1918 prefixes advertised to my on-premises devices?
When Private Traffic Routing Policies are configured, Virtual WAN Gateways will automatically advertise static
routes that are in the default route table (RFC1918 prefixes: 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16) in addition
to the explicit branch and Virtual Network prefixes.
Next steps
Create a Virtual WAN hub route table for NVAs:
Azure portal
This article shows you how to steer traffic from a branch (on-premises site) connected to the Virtual WAN hub
to a Spoke virtual network (VNet) via a Network Virtual Appliance (NVA).
Before you begin

Verify that you have met the following criteria:
You have a Network Virtual Appliance (NVA). A Network Virtual Appliance is a third-party software of
your choice that is typically provisioned from Azure Marketplace in a virtual network.
A private IP address must be assigned to the NVA network interface.
The NVA is not deployed in the virtual hub. It must be deployed in a separate virtual network.
The NVA virtual network may have one or many virtual networks connected to it. In this article, we
refer to the NVA virtual network as an 'indirect spoke VNet'. These virtual networks can be
connected to the NVA VNet by using VNet peering. The VNet Peering links are depicted by black
arrows in the above figure between VNet 1, VNet 2, and NVA VNet.
You have created two virtual networks. They will be used as spoke VNets.
The VNet spoke address spaces are: VNet1: 10.0.2.0/24 and VNet2: 10.0.3.0/24. If you need
information on how to create a virtual network, see Create a virtual network.
Ensure there are no virtual network gateways in any of the VNets.
The VNets do not require a gateway subnet.
1. Sign in
2. Create a virtual WAN

Create a virtual WAN. You can use the following example values, or replace with your own.
Vir tual WAN name: myVirtualWAN
Resource group: testRG
Location: West US
2. Select Vir tual WAN from the results. On the Virtual WAN page, click Create .
3. On the Create WAN page, fill in the following fields:
Name - Type the Name that you want to call your WAN.
Resource Location - Choose a resource location from the dropdown. A WAN is a global resource
and does not live in a particular region. However, you must select a region in order to more easily
4. After you finish filling out the fields, click Create .
3. Create a hub
Create the hub. You can use the following example values, or replace with your own.
Location: West US
Name: westushub
Hub private address space: 10.0.1.0/24
select Hubs .

4. Create and apply a hub route table

Update the hub with a hub route table. Use the following example values:
Spoke VNet address spaces: (VNet1 and VNet2) 10.0.2.0/24 and 10.0.3.0/24
DMZ NVA network interface private IP address: 10.0.4.5
1. Navigate to your virtual WAN.
2. Click the hub for which you want to create a route table.
3. Click the ..., and then click Edit vir tual hub .
4. On the Edit vir tual hub page, scroll down and select the checkbox Use table for routing .
5. In the If destination prefix is column, add the address spaces. In the Send to next hop column, add
the DMZ NVA network interface private IP address.
NOTE
The DMZ NVA network is applicable to the local hub.
6. Click Confirm to update the hub resource with the route table settings.
5. Create the VNet connections

Create a virtual network connection from each indirect spoke VNet (VNet1 and VNet2) to the hub. These virtual
network connections are depicted by the blue arrows in the above figure. Then, create a VNet connection from
the NVA VNet to the hub (black arrow in the figure).
For this step, you can use the following values:
VIRT UA L N ET W O RK N A M E C O N N EC T IO N N A M E
VNet1 testconnection1
VNet2 testconnection2
NVAVNet testconnection3
Repeat the following procedure for each virtual network that you want to connect.
1. On the page for your virtual WAN, click Vir tual network connections .
cannot have an already existing virtual network gateway.
4. Click OK to create the connection.
Next steps
Create a Virtual Hub route table to steer traffic to a
Network Virtual Appliance
This article shows you how to steer traffic from a Virtual Hub to a Network Virtual Appliance.
In this article you learn how to:

Create a WAN
Create a hub
Create hub virtual network connections
Create a hub route
Create a route table
Apply the route table
Before you begin

NOTE
This article uses the Azure Az PowerShell module, which is the recommended PowerShell module for interacting with
Azure. To get started with the Az PowerShell module, see Install Azure PowerShell. To learn how to migrate to the Az
PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
Verify that you have met the following criteria:

You have a Network Virtual Appliance (NVA). This is a third-party software of your choice that is typically
provisioned from Azure Marketplace in a virtual network.
You have a private IP assigned to the NVA network interface.
The NVA cannot be deployed in the virtual hub. It must be deployed in a separate VNet. For this article, the
NVA VNet is referred to as the 'DMZ VNet'.
The ‘DMZ VNet’ may have one or many virtual networks connected to it. In this article, this VNet is referred
to as ‘Indirect spoke VNet’. These VNets can be connected to the DMZ VNet using VNet peering.
Verify that you have 2 VNets already created. These will be used as spoke VNets. For this article, the VNet
spoke address spaces are 10.0.2.0/24 and 10.0.3.0/24. If you need information on how to create a VNet, see
Create a virtual network using PowerShell.
Ensure there are no virtual network gateways in any VNets.
1. Sign in
Make sure you install the latest version of the Resource Manager PowerShell cmdlets. For more information
about installing PowerShell cmdlets, see How to install and configure Azure PowerShell. This is important
because earlier versions of the cmdlets do not contain the current values that you need for this exercise.
1. Open your PowerShell console with elevated privileges, and sign in to your Azure account. This cmdlet
prompts you for the sign-in credentials. After signing in, it downloads your account settings so that they
are available to Azure PowerShell.
Connect-AzAccount
2. Get a list of your Azure subscriptions.
Get-AzSubscription
2. Create resources
1. Create a resource group.
2. Create a virtual WAN.
$virtualWan = New-AzVirtualWan -ResourceGroupName "testRG" -Name "myVirtualWAN" -Location "West US"
3. Create a virtual hub.
New-AzVirtualHub -VirtualWan $virtualWan -ResourceGroupName "testRG" -Name "westushub" -AddressPrefix

"10.0.1.0/24" -Location "West US"
3. Create connections
Create hub virtual network connections from Indirect Spoke VNet and the DMZ VNet to the virtual hub.
$remoteVirtualNetwork1= Get-AzVirtualNetwork -Name "indirectspoke1" -ResourceGroupName "testRG"

$remoteVirtualNetwork2= Get-AzVirtualNetwork -Name "indirectspoke2" -ResourceGroupName "testRG"
$remoteVirtualNetwork3= Get-AzVirtualNetwork -Name "dmzvnet" -ResourceGroupName "testRG"

"testvnetconnection1" -RemoteVirtualNetwork $remoteVirtualNetwork1
4. Create a virtual hub route
For this article, the Indirect Spoke VNet address spaces are 10.0.2.0/24 and 10.0.3.0/24, and the DMZ NVA
network interface private IP address is 10.0.4.5.
$route1 = New-AzVirtualHubRoute -AddressPrefix @("10.0.2.0/24", "10.0.3.0/24") -NextHopIpAddress "10.0.4.5"
5. Create a virtual hub route table

Create a virtual hub route table, then apply the created route to it.
$routeTable = New-AzVirtualHubRouteTable -Route @($route1)
6. Commit the changes

Commit the changes into the virtual hub.
Update-AzVirtualHub -ResourceGroupName "testRG" -Name "westushub" -RouteTable $routeTable
Next steps
How to create BGP peering with virtual hub
(Preview) - Azure portal
This article helps you configure an Azure Virtual WAN hub router to peer with a Network Virtual Appliance
(NVA) in your virtual network using the Azure portal. The virtual hub router learns routes from the NVA in a
spoke VNet that is connected to a virtual WAN hub. The virtual hub router also advertises the virtual network
routes to the NVA. For more information, see Scenario: BGP peering with a virtual hub.
IMPORTANT
This gated public preview is provided without a service-level agreement and shouldn't be used for production workloads.
Certain features might not be supported, might have constrained capabilities, or might not be available in all Azure
locations. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
Prerequisites
IMPORTANT
The BGP peering with Virtual WAN hub feature is currently in gated public preview. If you are interested in trying this
feature, please email previewbgpwithvhub@microsoft.com along with the Resource ID of your Virtual WAN resource.
To locate the Resource ID, open the Azure portal, navigate to your Virtual WAN resource, and click Settings >
Proper ties > Resource ID.
Example:
/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualWans/<virtualWANname>

WAN page.
environment.

Create a hub
Once the hub is created, you'll be charged for the hub, even if you don't attach any sites.
select Hubs .
your virtual hub.
Connect the VNet to the hub

In this section, you create a connection between your hub and VNet.

Configure a BGP peer
1. Open the Azure preview portal using https://aka.ms/azurecortexv2. The BGP peering with Virtual WAN
hub feature is currently in managed preview and the configuration pages are not available in the regular
Azure portal.
2. On the portal page for your virtual WAN, in the Connectivity section, select Hubs to view the list of
hubs. Click a hub to configure a BGP peer.
3. On the Vir tual Hub page, under the Routing section, select BGP Peers and click + Add to add a BGP
peer.
4. On the Add BGP Peer page, complete all the fields.

Name – Resource name to identify a specific BGP peer.
ASN – The ASN for the BGP peer.
IPv4 address – The IPv4 address of the BGP peer.
Vir tual Network connection – Choose the connection identifier that corresponds to the Virtual
network that hosts the BGP peer.
5. Click Add to complete the BGP peer configuration and view the peer.
Modify a BGP peer

1. On the Vir tual Hub resource, click BGP Peers and select the BGP peer. Click … then Edit .
2. Once the BGP peer is modified, click Add to save.
Delete a BGP peer

1. On the Vir tual Hub resource, click BGP Peers and select the BGP peer. Click … then Delete .
Next steps
For more information about BGP scenarios, see Scenario: BGP peering with a virtual hub.
Configure Azure Firewall in a Virtual WAN hub
A secured hub is an Azure Virtual WAN hub with Azure Firewall. This article walks you through the steps to
convert a virtual WAN hub to a secured hub by installing Azure Firewall directly from the Azure Virtual WAN
portal pages.
Before you begin

The steps in this article assume that you have already deployed a virtual WAN with one or more hubs.
To create a new virtual WAN and a new hub, use the steps in the following articles:
Create a hub
View virtual hubs

The Over view page for your virtual WAN shows a list of virtual hubs and secured hubs. The following figure
shows a virtual WAN with no secured hubs.
Convert to secured hub

1. On the Over view page for your virtual WAN, select the hub that you want to convert to a secured hub.
On the virtual hub page, you see two options to deploy Azure Firewall into this hub. Select either option.
2. After you select one of the options, you see the Conver t to secure hub page. Select a hub to convert,
and then select Next: Azure Firewall at the bottom of the page.
3. After completing the workflow, select Confirm .
4. After the hub has been converted to a secured hub, you can view it on the virtual WAN Over view page.
View hub resources
From the virtual WAN Over view page, select the secured hub. On the hub page, you can view all the virtual
hub resources, including Azure Firewall.
To view Azure Firewall settings from the secured hub, under Security , select Secured vir tual hub settings .
Configure additional settings

To configure additional Azure Firewall settings for the virtual hub, select the link to Azure Firewall Manager .
For information about firewall policies, see Azure Firewall Manager.
To return to the hub Over view page, you can navigate back by clicking the path, as shown by the arrow in the
following figure.
Upgrade to Azure Firewall Premium
At any time, it is possible to upgrade from Azure Firewall Standard to Premium following these instructions. This
operation will require a maintenance windows since some minimal downtime will be generated.
Next steps
How to configure Virtual WAN Hub routing intent
and routing policies
NOTE
Hub Routing Intent is currently in gated public preview.
This preview is provided without a service-level agreement and isn't recommended for production workloads. Some
features might be unsupported or have constrained capabilities. For more information, see Supplemental terms of use for
Microsoft Azure previews.
To obtain access to the preview, please deploy two hubs in the same Azure region along side any gateways (Site-to-site
VPN Gateways, Point-to-site Gateways and ExpressRouteGateways) and then reach out to
previewinterhub@microsoft.com with the Virtual WAN ID, Subscription ID and Azure Region you wish to configure
Routing Intent in. Expect a response within 48 business hours (Monday-Friday) with confirmation of feature enablement.
Please note that any gateways created after feature enablement will need to be upgraded by the Virtual WAN team.
Background
Routing Policy, each with a single Next Hop resource.
as one entity within the Routing Intent Concepts.
NOTE
In the gated public preview of Virtual WAN Hub routing policies, inter-hub traffic is only inspected by Azure Firewall or a
Network Virtual Appliance deployed in the Virtual WAN Hub if the Virtual WAN Hubs are in the same region.
hub, all branch (User VPN (Point-to-site VPN), Site-to-site VPN, and ExpressRoute) and Virtual Network
connections to that Virtual WAN Hub will forward Internet-bound traffic to the Azure Firewall resource,
Third-Party Security provider or Network Virtual Appliance specified as part of the Routing Policy.
will be forwarded to the Next Hop Azure Firewall resource or Network Virtual Appliance resource that
was specified in the Private Traffic Routing Policy.
In other words, when a Private Traffic Routing Policy is configured on the Virtual WAN Hub, all branch-to-
branch, branch-to-virtual network, virtual network-to-branch and inter-hub traffic will be sent via Azure
Firewall or a Network Virtual Appliance deployed in the Virtual WAN Hub.
Key considerations
You will not be able to enable routing policies on your deployments with existing Custom Route tables
configured or if there are static routes configured in your Default Route Table.
In the gated public preview of Virtual WAN Hub routing policies, inter-hub traffic is only inspected by Azure
Firewall or Network Virtual Appliances deployed in the Virtual WAN Hub if the Virtual WAN Hubs are in the
same region.
Routing Intent and Routing Policies currently must be configured via the custom portal link provided in Step
3 of Prerequisites . Routing Intents and Policies are not supported via Terraform, PowerShell, and CLI.
Prerequisites
1. Create a Virtual WAN. Make sure you create at least two Virtual Hubs in the same region. For instance, you
may create a Virtual WAN with two Virtual Hubs in East US. Note that if you only wish to inspect branch-to-
branch traffic, you may deploy a single Virtual WAN Hub as opposed to multiple Hubs in the same region.
2. Convert your Virtual WAN Hub into a Secured Virtual WAN Hub by deploying an Azure Firewall into the
Virtual Hubs in the chosen region. For more information on converting your Virtual WAN Hub to a Secured
Virtual WAN Hub, please see How to secure your Virtual WAN Hub.
3. Deploy any Site-to-site VPN, Point-to-site VPN and ExpressRoute Gateways you will use for testing. Reach out
to previewinterhub@microsoft.com with the Vir tual WAN Resource ID and the Azure Vir tual hub
Region you wish to configure Routing Policies in. To locate the Virtual WAN ID, open Azure portal, navigate
to your Virtual WAN resource and select Settings > Properties > Resource ID. For example:
/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtua
lWans/<virtualWANname>
4. Expect a response within 24-48 hours with confirmation of feature enablement.

5. Ensure that your Virtual Hubs do not have any Custom Route Tables or any routes you may have added into
the defaultRouteTable. You will not be able to enable routing policies on your deployments with existing
Custom Route tables configured or if there are static routes configured in your Default Route Table.
6. If you are using an Azure Firewall deployed in the Virtual WAN Hub, please reference Configuring routing
policies (through Azure Firewall Manager) to configure routing intent and routing policies. If you are using a
Network Vir tual Appliance deployed in the Virtual WAN Hub, please reference Configuring routing
policies (through Virtual WAN Portal) to configure routing intent and routing policies.
Configure routing policies (through Azure Firewall Manager)

1. From the custom portal Link provided in the confirmation email from Step 3 in the Prerequisites
section, navigate to the Virtual WAN Hub that you want to configure Routing Policies on.
2. Under Security, select Secured Vir tual hub settings and then Manage security provider and route
settings for this Secured vir tual hub in Azure Firewall Manager
3. Select the Hub you want to configure your Routing Policies on from the menu.
4. Select Security configuration under Settings
5. If you want to configure an Internet Traffic Routing Policy, select Azure Firewall or the relevant Internet
Security provider from the dropdown for Internet Traffic . If not, select None
6. If you want to configure a Private Traffic Routing Policy (for branch and Virtual Network traffic) via Azure
Firewall, select Azure Firewall from the dropdown for Private Traffic . If not, select Bypass Azure
Firewall .
7. If you want to configure a Private Traffic Routing Policy and have branches or virtual networks advertising
non-IANA RFC1918 Prefixes, select Private Traffic Prefixes and specify the non-IANA RFC1918 prefix
ranges in the text box that comes up. Select Done .
8. Select Inter-hub to be Enabled . Enabling this option ensures your Routing Policies are applied to the
Routing Intent of this Virtual WAN Hub.
9. Select Save . This operation will take around 10 minutes to complete.
10. Repeat steps 2-8 for other Secured Virtual WAN hubs that you want to configure Routing policies for.
Configure routing policies (through Virtual WAN portal)

NOTE
The only Network Virtual Appliance deployed in the Virtual WAN hub compatible with routing intent and routing policies
are listed in the Partners section as dual-role connectivity and Next-Generation Firewall solution providers.
1. From the custom portal link provided in the confirmation email from Step 3 in the Prerequisites section,
navigate to the Virtual WAN hub that you want to configure routing policies on.
2. Under Routing, select Routing Policies .
3. If you want to configure a Private Traffic Routing Policy (for branch and Virtual Network Traffic), select
Network Vir tual Appliance under Private Traffic and under Next Hop Resource select the Network
Virtual Appliance resource you wish to send traffic to.
4. If you want to configure a Private Traffic Routing Policy and have branches or virtual networks using non-
IANA RFC1918 Prefixes, select Additional Prefixes and specify the non-IANA RFC1918 prefix ranges in
the text box that comes up. Select Done .
5. If you want to configure a Internet Traffic Routing Policy, under Internet traffic select Network Vir tual
Appliance and under Next Hop Resource select the Network Virtual Appliance you want to send
internet-bound traffic to.
6. To apply your routing intent and routing policies configuration, click Save .
7. Repeat for all hubs you would like to configure routing policies for.
Routing policy configuration examples

The following section describes two common scenarios customers of applying Routing Policies to Secured
Virtual WAN hubs.
All Virtual WAN Hubs are secured (deployed with Azure Firewall or NVA )
In this scenario, all Virtual WAN hubs are deployed with an Azure Firewall or NVA in them. In this scenario, you
may configure an Internet Traffic Routing Policy, a Private Traffic Routing Policy or both on each Virtual WAN
Hub.
Consider the following configuration where Hub 1 and Hub 2 have Routing Policies for both Private and Internet
Traffic.
The following are the traffic flows that result from such a configuration.
NOTE
Internet Traffic must egress through the local Azure Firewall as the default route (0.0.0.0/0) does not propagate across
hubs.
H UB 1 H UB 2
Hub 1 VNets → Hub 1 AzFW Hub 1 AzFW Hub 1 and 2 Hub 1 and 2 Hub 1 AzFW
or NVA or NVA AzFW or NVA AzFW or NVA or NVA
Hub 1 → Hub 1 AzFW Hub 1 AzFW Hub 1 and 2 Hub 1 and 2 Hub 1 AzFW
Branches or NVA or NVA AzFW or NVA AzFW or NVA or NVA
Hub 2 VNets → Hub 1 and 2 Hub 1 and 2 Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
AzFW or NVA AzFW or NVA or NVA or NVA or NVA
Hub 2 → Hub 1 and 2 Hub 1 and 2 Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
Branches AzFW or NVA AzFW or NVA or NVA or NVA or NVA
Mixture of secured and regular Virtual WAN Hubs

In this scenario, not all Virtual WAN hubs are deployed with an Azure Firewall or Network Virtual Appliances in
them. In this scenario, you may configure an Internet Traffic Routing Policy, a Private Traffic Routing Policy on the
secured Virtual WAN Hubs.
Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) are deployed in a Virtual
WAN. Hub 2 has Routing Policies for both Private and Internet Traffic.
N/A (cannot configure Routing Policies if hub is not deployed with Azure Firewall or NVA)
The following are the traffic flows that result from such a configuration. Branches and Virtual Networks
connected to Hub 1 cannot access the Internet via Azure Firewall in the Hub because the default route
(0.0.0.0/0) does not propagate across hubs.
H UB 1 H UB 2
Hub 1 VNets → Direct Direct Hub 2 AzFW Hub 2 AzFW -

or NVA or NVA
Hub 1 → Direct Direct Hub 2 AzFW Hub 2 AzFW -

Branches or NVA or NVA
Hub 2 VNets → Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
or NVA or NVA or NVA or NVA or NVA
Hub 2 → Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW Hub 2 AzFW
Branches or NVA or NVA or NVA or NVA
Troubleshooting
The following section describes common issues encountered when you configure Routing Policies on your
Virtual WAN Hub. Read the below sections and if your issue is still unresolved, reach out to
previewinterhub@microsoft.com for support. Expect a response within 48 business hours (Monday through
Friday).
Troubleshooting configuration issues
Make sure that you have gotten confirmation from previewinterhub@microsoft.com that access to the
gated public preview has been granted to your subscription and chosen region. You will not be able to
configure routing policies without being granted access to the preview.
After enabling the Routing Policy feature on your deployment, ensure you only use the custom portal
link provided as part of your confirmation email. Do not use PowerShell, CLI, or REST API calls to manage
your Virtual WAN deployments. This includes creating new Branch (Site-to-site VPN, Point-to-site VPN or
ExpressRoute) connections.
NOTE
If you are using Terraform, routing policies are currently not supported.
Ensure that your Virtual Hubs do not have any Custom Route Tables or any static routes in the
defaultRouteTable. You will not be able to select Enable interhub from Firewall Manager on your Virtual
WAN Hub if there are Custom Route tables configured or if there are static routes in your
defaultRouteTable.
Troubleshooting data path
Currently, using Azure Firewall to inspect inter-hub traffic is only available for Virtual WAN hubs that are
deployed in the same Azure Region.
You can verify that the Routing Policies have been applied properly by checking the Effective Routes of the
DefaultRouteTable. If Private Routing Policies are configured, you should see routes in the DefaultRouteTable
for private traffic prefixes with next hop Azure Firewall. If Internet Traffic Routing Policies are configured, you
should see a default (0.0.0.0/0) route in the DefaultRouteTable with next hop Azure Firewall.
If there are any Site-to-site VPN gateways or Point-to-site VPN gateways created after the feature has been
confirmed to be enabled on your deployment, you will have to reach out again to
previewinterhub@microsoft.com to get the feature enabled.
Troubleshooting Azure Firewall
If you are using non IANA RFC1918 prefixes in your branches/Virtual Networks, make sure you have
specified those prefixes in the "Private Prefixes" text box in Firewall Manager.
If you have specified non RFC1918 addresses as part of the Private Traffic Prefixes text box in Firewall
Manager, you may need to configure SNAT policies on your Firewall to disable SNAT for non-RFC1918
private traffic. For more information, reference the following document.
Configure and view Azure Firewall logs to help troubleshoot and analyze your network traffic. For more
information on how to set-up monitoring for Azure Firewall, reference the following document. An overview
of the different types of Firewall logs can be found here.
For more information on Azure Firewall, review Azure Firewall Documentation.
Frequently asked questions

Why can't I edit the defaultRouteTable from the custom portal link provided by
previewinterhub@microsoft.com?
As part of the gated public preview of Routing Policies, your Virtual WAN hub routing is managed entirely by
Firewall Manager. Additionally, the managed preview of Routing Policies is not supported alongside Custom
Routing. Custom Routing with Routing Policies will be supported at a later date.
However, you can still view the Effective Routes of the DefaultRouteTable by navigating to the Effective Routes
Tab.
Can I configure a Routing Policy for Private Traffic and also send Internet Traffic (0.0.0.0/0) via a Network
Virtual Appliance in a Spoke Virtual Network?
This scenario is not supported in the gated public preview. However, reach out to
previewinterhub@microsoft.com to express interest in implementing this scenario.
Does the default route (0.0.0.0/0) propagate across hubs?
No. Currently, branches and Virtual Networks will egress to the internet using an Azure Firewall deployed inside
of the Virtual WAN hub the branches and Virtual Networks are connected to. You cannot configure a connection
to access the Internet via the Firewall in a remote hub.
Why do I see RFC1918 prefixes advertised to my on-premises devices?
When Private Traffic Routing Policies are configured, Virtual WAN Gateways will automatically advertise static
routes that are in the default route table (RFC1918 prefixes: 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16) in addition
to the explicit branch and Virtual Network prefixes.
Next steps
Use Private Link in Virtual WAN
Azure Private Link is a technology that allows you to connect Azure Platform-as-a-Service offerings using
private IP address connectivity by exposing Private Endpoints. With Azure Virtual WAN, you can deploy a Private
Endpoint in one of the virtual networks connected to any virtual hub. This provides connectivity to any other
virtual network or branch connected to the same Virtual WAN.
Before you begin

The steps in this article assume that you have already deployed a virtual WAN with one or more hubs, as well as
at least two virtual networks connected to Virtual WAN.
To create a new virtual WAN and a new hub, use the steps in the following articles:
Create a hub
Create a private link endpoint

You can create a private link endpoint for many different services. In this example, we will use Azure SQL
Database. You can find more information about how to create a private endpoint for an Azure SQL Database in
Quickstart: Create a Private Endpoint using the Azure portal. The following image shows the network
configuration of the Azure SQL Database:
After creating the Azure SQL Database, you can verify the private endpoint IP address browsing your private
endpoints:
Clicking on the private endpoint we have created, you should see its private IP address, as well as its Fully
Qualified Domain Name (FQDN). Note that the private endpoint has an IP address in the range of the VNet
where it has been deployed (10.1.3.0/24):
Verify connectivity from the same VNet

In this example, we will verify connectivity to the Azure SQL Database from an Ubuntu virtual machine with MS
SQL tools installed. The first step is verifying that DNS resolution works and the Azure SQL Database Fully
Qualified Domain Name is resolved to a private IP address, in the same VNet where the Private Endpoint has
been deployed (10.1.3.0/24):
$ nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
As you can see in the previous output, the FQDN wantest.database.windows.net is mapped to
wantest.privatelink.database.windows.net , that the private DNS zone created along the private endpoint will
resolve to the private IP address 10.1.3.228 . Looking into the private DNS zone will confirm that there is an A
record for the private endpoint mapped to the private IP address:
After verifying the correct DNS resolution, we can attempt to connect to the database:
$ query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"

$ sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75
As you can see, we are using a special SQL query that gives us the source IP address that the SQL server sees
from the client. In this case the server sees the client with its private IP ( 10.1.3.75 ), which means that the traffic
goes from the VNet straight into the private endpoint.
Note that you need to set the variables username and password to match the credentials defined in the Azure
SQL Database to make the examples in this guide work.
Connect from a different VNet

Now that one VNet in Azure Virtual WAN has connectivity to the private endpoint, all of the other VNets and
branches connected to Virtual WAN can have access to it as well. You need to provide connectivity through any
of the models supported by Azure Virtual WAN, such as the Any-to-any scenario or the Shared Services VNet
scenario, to name two examples.
Once you have connectivity between the VNet or the branch to the VNet where the private endpoint has been
deployed, you need to configure DNS resolution:
If connecting to the private endpoint from a VNet, you can use the same private zone that was created with
the Azure SQL Database.
If connecting to the private endpoint from a branch (Site-to-site VPN, Point-to-site VPN or ExpressRoute), you
need to use on-premises DNS resolution.
In this example we will connect from a different VNet, so first we will attach the private DNS zone to the new
VNet so that its workloads can resolve the Azure SQL Database Fully Qualified Domain Name to the private IP
address. This is done through linking the private DNS zone to the new VNet:
Now any virtual machine in the attached VNet should correctly resolve the Azure SQL Database FQDN to the
private link's private IP address:
$ nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
In order to double-check that this VNet (10.1.1.0/24) has connectivity to the original VNet where the private
endpoint was configured (10.1.3.0/24), you can verify the effective route table in any virtual machine in the
VNet:
As you can see, there is a route pointing to the VNet 10.1.3.0/24 injected by the Virtual Network Gateways in
Azure Virtual WAN. Now we can finally test connectivity to the database:
$ query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"

$ sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75
With this example, we have seen how creating a private endpoint in one of the VNets attached to a Virtual WAN
provides connectivity to the rest of VNets and branches in the Virtual WAN.
Next steps
for User VPN clients
This article shows you how to use Virtual WAN and Azure Firewall rules and filters to manage secure access for
connections to your resources in Azure over point-to site IKEv2 or Open VPN connections. This configuration is
helpful if you have remote users for whom you want to restrict access to Azure resources, or to secure your
resources in Azure.
The steps in this article help you create the architecture in the following diagram to allow User VPN clients to
access a specific resource (VM1) in a spoke VNet connected to the virtual hub, but not other resources (VM2).
Use this architecture example as a basic guideline.
Prerequisites
You have the values available for the authentication configuration that you want to use. For example, a
RADIUS server, Azure Active Directory authentication, or Generate and export certificates.

WAN page.
environment.

Define P2S configuration parameters

The point-to-site (P2S) configuration defines the parameters for connecting remote clients. This section helps
you define P2S configuration parameters, and then create the configuration that will be used for the VPN client
profile. The instructions you follow depend on the authentication method you want to use.
Authentication methods
When selecting the authentication method, you have three choices. Each method has specific requirements.
Select one of the following methods, and then complete the steps.
Azure Active Director y authentication: Obtain the following:
The Application ID of the Azure VPN Enterprise Application registered in your Azure AD tenant.
The Issuer . Example: https://sts.windows.net/your-Directory-ID .
The Azure AD tenant . Example: https://login.microsoftonline.com/your-Directory-ID .
information.
IKEv2 VPN
OpenVPN

Create the hub and gateway

In this section, you create the virtual hub with a point-to-site gateway. When configuring, you can use the
following example values:
Hub private IP address space: 10.0.0.0/24
Client address pool: 10.5.0.0/16
Custom DNS Ser vers: You can list up to 5 DNS Servers
step.
NOTE
up to 5.
Generate VPN client configuration files

In this section, you generate and download the configuration profile files. These files are used to configure the
native VPN client on the client computer. For information about the contents of the client profile files, see Point-
to-site configuration - certificates.
user VPN profile .
VPN profile.
your computer.

Use the downloaded profile to configure the remote access clients. The procedure for each operating system is
different, follow the instructions that apply to your system.
OpenVPN
IKEv2
anyway .
Connect the spoke VNet

In this section, you create a connection between your hub and the spoke VNet.
Create virtual machines

In this section, you create two VMs in your VNet, VM1 and VM2. In the network diagram, we use 10.18.0.4 and
10.18.0.5. When configuring your VMs, make sure to select the virtual network that you created (found on the
Networking tab). For steps to create a VM, see Quickstart: Create a VM.
Secure the virtual hub

A standard virtual hub has no built-in security policies to protect the resources in spoke virtual networks. A
secured virtual hub uses Azure Firewall or a third-party provider to manage incoming and outgoing traffic to
protect your resources in Azure.
Convert the hub to a secured hub using the following article: Configure Azure Firewall in a Virtual WAN hub.
Create rules to manage and filter traffic

Create rules that dictate the behavior of Azure Firewall. By securing the hub, we ensure that all packets that enter
the virtual hub are subject to firewall processing before accessing your Azure resources.
Once you complete these steps, you will have created an architecture that allows VPN users to access the VM
with private IP address 10.18.0.4, but NOT access the VM with private IP address 10.18.0.5
1. In the Azure portal, navigate to Firewall Manager .
2. Under Security, select Azure Firewall policies .
3. Select Create Azure Firewall Policy .
4. Under Policy details , type in a name and select the region your virtual hub is deployed in.
5. Select Next: DNS Settings (preview) .
6. Select Next: Rules .
7. On the Rules tab, select Add a rule collection .
8. Provide a name for the collection. Set the type as Network . Add a priority value 100 .
9. Fill in the name of the rule, source type, source, protocol, destination ports, and destination type, as
shown in the example below. Then, select add . This rule allows any IP address from the VPN client pool to
access the VM with private IP address 10.18.04, but not any other resource connected to the virtual hub.
Create any rules you want that fit your desired architecture and permissions rules.
10. Select Next: Threat intelligence .

11. Select Next: Hubs .
12. On the Hubs tab, select Associate vir tual hubs .
13. Select the virtual hub you created earlier, and then select Add .
14. Select Review + create .
15. Select Create .
It can take 5 minutes or more for this process to complete.
Route traffic through Azure Firewall

In this section, you need to ensure that the traffic is routed through Azure Firewall.
1. In the portal, from Firewall Manager , select Secured vir tual hubs .
2. Select the virtual hub you created.
3. Under Settings , select Security configuration .
4. Under Private traffic , select Send via Azure Firewall .
5. Verify that the VNet connection and the Branch connection private traffic is secured by Azure Firewall.
6. Select Save .
Validate
Verify the setup of your secured hub.
1. Connect to the Secured Vir tual Hub via VPN from your client device.
2. Ping the IP address 10.18.0.4 from your client. You should see a response.
3. Ping the IP address 10.18.0.5 from your client. You should not be able to see a response.
Considerations
Make sure that the Effective Routes Table on the secured virtual hub has the next hop for private traffic by
the firewall. To access the Effective Routes Table, navigate to your Vir tual Hub resource. Under
Connectivity , select Routing , and then select Effective Routes . From there, select the Default Route table.
Verify that you created rules in the Create Rules section. If these steps are missed, the rules you created will
not actually be associated to the hub and the route table and packet flow will not use Azure Firewall.
Next steps
For more information about Azure Firewall, see the Azure Firewall FAQ.
Monitoring Virtual WAN
You can monitor Azure Virtual WAN using Azure Monitor. Virtual WAN is a networking service that brings
together many networking, security, and routing functionalities to provide a single operational interface. Virtual
WAN VPN gateways, ExpressRoute gateways, and Azure Firewall have logging and metrics available through
Azure Monitor.
This article discusses metrics and diagnostics that are available through the portal. Metrics are lightweight and
can support near real-time scenarios, making them useful for alerting and fast issue detection.
Monitoring Secured Hub (Azure Firewall)
If you have chosen to secure your Virtual Hub using Azure Firewall, relevant logs and metrics are available here:
Azure Firewall logs and metrics. You can monitor the Secured Hub using Azure Firewall logs and metrics. You
can also use activity logs to audit operations on Azure Firewall resources. For every Azure Virtual WAN you
secure and convert to a Secured Hub, an explicit firewall resource object is created in the resource group where
the hub is located.
Diagnostics and logging configuration must be done from there accessing the Diagnostic Setting tab:
Metrics
Metrics in Azure Monitor are numerical values that describe some aspect of a system at a particular time.
Metrics are collected every minute, and are useful for alerting because they can be sampled frequently. An alert
can be fired quickly with relatively simple logic.
Virtual Hub Router
The following metric is available for Virtual Hub Router within a Virtual Hub:
Virtual Hub Router Metric
M ET RIC DESC RIP T IO N
Vir tual Hub Data Processed Data in bytes/second on how much traffic traverses the
Virtual Hub Router in a given time period. Please note only
the following flows use the Virtual Hub Router - VNET to
VNET same hub and inter hub Branch to VNET interhub via
VPN or Express Route Gateways.
P o w e r Sh e l l C o m m a n d s
To query via PowerShell, use the following commands:

Step 1:
$MetricInformation = Get-AzMetric -ResourceId

"/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Network/VirtualHubs/
<VirtualHubName>" -MetricName "VirtualHubDataProcessed" -TimeGrain 00:05:00 -StartTime 2022-2-20T01:00:00Z -
EndTime 2022-2-20T01:30:00Z -AggregationType Average
Step 2:
$MetricInformation.Data
Resource ID - Your Virtual Hub's Resource ID can be found on the Azure portal. Navigate to the Virtual Hub
page within vWAN and select JSON View under Essentials.
Metric Name - Refers to the name of the metric you are querying, which in this case is called
'VirtualHubDataProcessed'. This metric shows all the data that the Virtual Hub Router has processed in the
selected time period of the hub.
Time Grain - Refers to the frequency at which you want see the aggregation of. In the current command, you
will see a selected aggregated unit per 5 mins. You can select – 5M/15M/30M/1H/6H/12H and 1D.
Star t Time and End Time - This time is based on UTC, so please ensure that you are entering UTC values
when inputting these parameters. If these parameters are not used, by default the past one hour's worth of data
is shown.
Aggregation Types - Average/Minimum/Maximum/Total
Average - Total average of bytes/sec per the selected time period
Minimum – Minimum bytes that were sent during the selected time grain period.
Maximum – Maximum bytes that were sent during the selected time grain period
Total – Total bytes/sec that were sent during the selected time grain period.
Site -to -site VPN gateways
The following metrics are available for Azure site-to-site VPN gateways:
Tunnel Packet Drop Metrics
Tunnel Egress Packet Drop Count Count of Outgoing packets dropped by tunnel.
Tunnel Ingress Packet Drop Count Count of Incoming packets dropped by tunnel.
Tunnel NAT Packet Drops Number of NATed packets dropped on a tunnel by drop type
and NAT rule.
Tunnel Egress TS Mismatch Packet Drop Outgoing packet drop count from traffic selector mismatch
of a tunnel.
Tunnel Ingress TS Mismatch Packet Drop Incoming packet drop count from traffic selector mismatch
of a tunnel.
IPSEC Metrics
Tunnel MMSA Count Number of MMSAs getting created or deleted.
Tunnel QMSA Count Number of IPSEC QMSAs getting created or deleted.
Routing Metrics
BGP Peer Status BGP connectivity status per peer and per instance.
BGP Routes Adver tised Number of routes advertised per peer and per instance.
BGP Routes Learned Number of routes learned per peer and per instance.
VNET Address Prefix Count Number of VNET address prefixes that are used/advertised
by the gateway.
You can review per peer and instance metrics by selecting Apply splitting and choosing the preferred value.
Traffic Flow Metrics
Gateway Bandwidth Average site-to-site aggregate bandwidth of a gateway in

bytes per second.
Tunnel Bandwidth Average bandwidth of a tunnel in bytes per second.
Tunnel Egress Bytes Outgoing bytes of a tunnel.
Tunnel Egress Packets Outgoing packet count of a tunnel.
Tunnel Ingress Bytes Incoming bytes of a tunnel.
Tunnel Ingress Packet Incoming packet count of a tunnel.

Tunnel Peak PPS Number of packets per second per link connection in the last
minute.
Tunnel Flow Count Number of distinct flows created per link connection.
Point-to -site VPN gateways

The following metrics are available for Azure point-to-site VPN gateways:
Gateway P2S Bandwidth Average point-to-site aggregate bandwidth of a gateway in

bytes per second.
P2S Connection Count Point-to-site connection count of a gateway. Point-to-site

connection count of a gateway. To ensure you are viewing
accurate Metrics in Azure Monitor, select the Aggregation
Type for P2S Connection Count as Sum . You may also
select Max if you also Split By Instance .
User VPN Routes Count Number of User VPN Routes configured on the VPN
Gateway. This metric can be broken down into Static and
Dynamic Routes.
Azure ExpressRoute gateways

The following metrics are available for Azure ExpressRoute gateways:
BitsInPerSecond Bits ingressing Azure per second.
BitsOutPerSecond Bits egressing Azure per second.
CPU Utilization CPU Utilization of the ExpressRoute Gateway.
Packets per second Packet count of ExpressRoute Gateway.
Count of routes adver tised to peer Count of Routes Advertised to Peer by ExpressRoute
Gateway.
Count of routes learned from peer Count of Routes Learned from Peer by ExpressRoute
Gateway.
Frequency of routes changed Frequency of Route changes in ExpressRoute Gateway.
Number of VMs in Vir tual Network Number of VM's that use this ExpressRoute Gateway.
View gateway metrics

The following steps help you locate and view metrics:
1. In the portal, navigate to the virtual hub that has the gateway.
2. Select VPN (Site to site) to locate a site-to-site gateway, ExpressRoute to locate an ExpressRoute
gateway, or User VPN (Point to site) to locate a point-to-site gateway.
3. Select Metrics .
4. On the Metrics page, you can view the metrics that you are interested in.
Diagnostic logs
Site -to -site VPN gateways
The following diagnostics are available for Azure site-to-site VPN gateways:
Gateway Diagnostic Logs Gateway-specific diagnostics such as health, configuration,

service updates, and additional diagnostics.
Tunnel Diagnostic Logs These are IPsec tunnel-related logs such as connect and
disconnect events for a site-to-site IPsec tunnel, negotiated
SAs, disconnect reasons, and additional diagnostics.
Route Diagnostic Logs These are logs related to events for static routes, BGP, route
updates, and additional diagnostics.
IKE Diagnostic Logs IKE-specific diagnostics for IPsec connections.
Point-to -site VPN gateways

The following diagnostics are available for Azure point-to-site VPN gateways:
Gateway Diagnostic Logs Gateway-specific diagnostics such as health, configuration,

service updates, and other diagnostics.
IKE Diagnostic Logs IKE-specific diagnostics for IPsec connections.
P2S Diagnostic Logs These are User VPN (Point-to-site) P2S configuration and
client events. They include client connect/disconnect, VPN
client address allocation, and other diagnostics.
Express Route gateways

Diagnostic logs for Express Route gateways in Azure Virtual WAN are not supported.
View diagnostic logs configuration
The following steps help you create, edit, and view diagnostic settings:
1. In the portal, navigate to your Virtual WAN resource, then select Hubs in the Connectivity group.
2. Under the Connectivity group on the left select the gateway you want to examine the diagnostics:
3. On the right part of the page, click on View in Azure Monitor link right to Logs then select an option.
You can choose to send to Log Analytics, stream to an event hub, or to simply archive to a storage
account.
4. In this page, you can create new diagnostic setting (+Add diagnostic setting ) or edit existing one (Edit
setting ). You can choose to send the diagnostic logs to Log Analytics (as shown in the example below),
stream to an event hub, send to a 3rd-party solution, or to archive to a storage account.
Log Analytics sample query

If you selected to send diagnostic data to a Log Analytics Workspace, then you can use SQL-like queries such as
the example below to examine the data. For more information, see Log Analytics Query Language.
The following example contains a query to obtain site-to-site route diagnostics.
AzureDiagnostics | where Category == "RouteDiagnosticLog"
Replace the values below, after the = = , as needed based on the tables reported in the previous section of this
article.
"GatewayDiagnosticLog"
"IKEDiagnosticLog"
"P2SDiagnosticLog”
"TunnelDiagnosticLog"
"RouteDiagnosticLog"
In order to execute the query, you have to open the Log Analytics resource you configured to receive the
diagnostic logs, and then select Logs under the General tab on the left side of the pane:
For additional Log Analytics query samples for Azure VPN Gateway, both Site-to-Site and Point-to-Site, you can
visit the page Troubleshoot Azure VPN Gateway using diagnostic logs. For Azure Firewall, a workbook is
provided to make log analysis easier. Using its graphical interface, it will be possible to investigate into the
diagnostic data without manually writing any Log Analytics query.
Activity logs
Activity log entries are collected by default and can be viewed in the Azure portal. You can use Azure activity
logs (formerly known as operational logs and audit logs) to view all operations submitted to your Azure
subscription.
Next steps
To learn how to monitor Azure Firewall logs and metrics, see Tutorial: Monitor Azure Firewall logs.
To learn more about metrics in Azure Monitor, see Metrics in Azure Monitor.
Azure Monitor Insights for Virtual WAN
Azure Monitor Insights for Azure Virtual WAN gives users and operators the ability to view the state and status
of a virtual WAN, presented via an autodiscovered topological map. Resource state and status overlays on the
map give you a snapshot view of the overall health of the virtual WAN. You can navigate resources on the map
via one-click access to the resource configuration pages of the Virtual WAN portal.
Virtual WAN resource-level metrics are collected and presented via a pre-packaged Virtual WAN metrics
workbook. The workbook shows the metrics at virtual WAN, hub, gateway, and connection levels. This article
walks you through the steps to use Azure Monitor Insights for Virtual WAN to view your Virtual WAN topology
and metrics all in a single place.
NOTE
The Insights menu option is in the Virtual WAN portal under Monitoring . You can also access the Virtual WAN
Topology and Metrics Workbook by using Azure Monitor for Networks. For more information, see Azure Monitor for
Networks.
Before you begin

To complete the steps in this article, you need to have a virtual WAN with one or more hubs. To create a virtual
WAN and a hub, follow the steps in these articles:
Create a hub
View VWAN topology

Go to Azure por tal > Vir tual WAN . In the Monitor menu in the left pane, select Insights (preview) . The
Insights view appears. It shows the Virtual WAN Dependency map and high-level Metrics mini workbook.
Figure 1: Monitor > Insights menu
In the Insights view, you can view the autodiscovered Virtual WAN resources. These resources include hubs,
gateways, firewalls, connections and spoke virtual networks, third-party NVAs, and branches in an end-to-end
Virtual WAN. For an example, see Figure 2 .
The resource state and status are color-coded and overlaid on the resource icons in the map. High-level Virtual
WAN metrics, like hub capacities and gateway utilization, appear on the right side of the window in a mini
workbook.
Figure 2: Insights view
Dependency view
The Dependency view for Virtual WAN helps you visualize the interconnected view of all the Virtual WAN
resources broadly organized into a hub-and-spoke architecture.
Figure 3: VWAN Dependency view
The Dependency view map displays the following resources as a connected graph:
Virtual WAN hubs across the various Azure regions.
Spoke virtual networks that are directly connected to the hub.
VPN and Azure ExpressRoute branch sites and P2S users that are connected to each hub via their respective
ExpressRoute, S2S, and P2S connections, and virtual network gateways.
Azure firewalls (including third-party firewall proxies) deployed in a hub (secured hub).
Third-party NVAs (network virtual appliances) that are deployed in spoke virtual networks.
The dependency map also displays indirectly connected virtual networks (virtual networks that are peered with
Virtual WAN spoke virtual networks).
The dependency map enables easy navigation to the configuration settings of each resource. For example, you
can hover over the hub resource to view the basic resource configuration, like hub region and hub prefix. Right-
click to access the Azure portal page of the hub resource.
Figure 4: Navigate to resource-specific information
The search and filter bar in the Dependency view provides an easy way to search through the graph. Various
filters provide help to narrow your search down to a specific path and state.
Figure 5: Search and filtering
Detailed metrics
You can select View detailed metrics to access the detailed Metrics page. The Metrics page is a dashboard
that's preconfigured with separate tabs. These tabs provide insights into your virtual WAN resource capacity,
performance, and utilization at the virtual-WAN level and hub level, and at the level of individual connections.
Figure 6: Detailed Metrics dashboard
Next steps
To learn more, see Metrics in Azure Monitor.
For a full description of all the Virtual WAN metrics, see Monitoring Virtual WAN.
Configure a packet capture for Virtual WAN site-to-
site VPN: Azure portal
This article helps you create a packet capture for an Azure Virtual WAN site-to-site VPN gateway using the
Azure portal. Packet capture helps you narrow down the scope of a problem to certain parts of the network. It
can help you determine whether the problem is on the on-premises side of the network, the Azure side of the
network, or somewhere in between. By narrowing down the problem, you can more efficiently debug and take
remedial action.
While some commonly available packet capture tools do exist, getting relevant packet captures with these tools
can be cumbersome, especially in high-volume traffic scenarios. The filtering capabilities provided by the Virtual
WAN packet capture are a major differentiator. The Virtual WAN packet capture can be used along with
commonly available packet capture tools.
NOTE
Features and settings are in the process of rolling out across regions to the Azure portal.
Prerequisites
Verify that you have the following configuration already set up in your environment:
A virtual WAN and a virtual hub.
A site-to-site VPN gateway deployed in the virtual hub.
You may also have connections connecting VPN sites to your site-to-site VPN gateway.
Create a storage account and container

A storage account is used to store the results of packet captures.
1. Create a storage account. For steps, see Create a storage account.
2. Create a container object within your storage account. For steps, see Create a container.
Generate the SAS URL

When you stop a packet capture, you must provide the SAS URL of the storage container that you created. The
results of your packet capture will be stored via this URL. To generate the SAS URL for your storage container:
1. Navigate to your newly created container.
2. Under Settings , select Shared access tokens .
3. On the Permissions tab, verify that both Read and Write are enabled.
4. At the bottom of the page, click the Generate SAS token and URL button.
5. Click to copy the Blob SAS URL link that is generated to your clipboard.
Start a packet capture
In this section, you start the packet capture on the virtual hub.
1. Navigate to the virtual hub.
2. Click VPN (Site to site) .
3. On the VPN (Site to site) page, click the Packet Capture button at the top of the page.
4. On the Packet Capture page, click Star t .

5. On the Star t Packet Capture page , modify settings, if needed. See the Filters section for options.
6. Click the Star t button to start the packet capture. We recommend letting the packet capture run for at
least 600 seconds. Due to sync issues among multiple components on the path, shorter packet captures
might not provide complete data.
Optional: Specify filters

To simplify your packet captures, you may specify filters on your packet capture to focus on specific behaviors.
PA RA M ET ER DESC RIP T IO N DEFA ULT VA L UES AVA IL A B L E VA L UES
TracingFlags Integer that determines 11 (ESP, IKE, OVPN) ESP = 1 IKE = 2 OPVN = 8
what types of packets are
captured
TCPFlags Integer that determines 0 (none) FIN = 1, SYN = 2, RST = 4,

which Types of TCP Packets PSH = 8, ACK = 16,URG =
are captured 32, ECE = 64, CWR = 128
MaxPacketBufferSize Maximum size of a captured 120 Any

packet in bytes. Packets are
truncated if larger than the
provided value.
MaxFileSize Maximum capture file size 100 Any

in Mb. Captures are stored
in a circular buffer so
overflow is handled in a
FIFO manner (older packets
removed first)
SourceSubnets Packets from the specified [ ] (all IPv4 addresses) Array of comma-separated
CIDR ranges are captured. IPV4 Subnets
Specified as an array.
DestinationSubnets Packets destined for the [ ] (all IPv4 addresses) Array of comma-separated
specified CIDR ranges are IPV4 Subnets
captured. Specified as an
array.
SourcePort Packets with source in the [ ] (all ports) Array of comma-separated

specified ranges are ports
array.
DestinationPort Packets with destination in [ ] (all ports) Array of comma-separated

the specified ranges are ports
array.
CaptureSingleDirectionTraffi If true, only one direction of True True, False

cOnly a bidirectional flow will
show up in the packet
capture. This will capture all
possible combo of IP and
ports.
Protocol An array of integers that [ ] (all protocols) Any protocols listed on this
correspond IANA protocols. iana.org page.
NOTE
For TracingFlags and TCPFlags, you may specify multiple protocols by adding up the numerical values for the protocols
you want to capture (same as a logical OR). For example, if you want to capture only ESP and OPVN packets, specify a
TracingFlag value of 8+1 = 9.
Stop a packet capture

This section helps you stop or abort a packet capture.
1. On the virtual hub page, click the Packet Capture button to open the Packet Capture page, then click
Stop . This opens the Stop Packet Capture page. At this point, the packet capture is not yet stopped.
2. On the Stop Packet Capture page, paste the SaS URL for the storage container that you created earlier
into the Output Sas Url field. This is the location where the packet capture files will be stored.
3. Next, click Stop . The packet capture will stop and the PCAP file is created and saved to the storage
account. This can take a few minutes to complete.
To abort a packet capture
If for any reason you need to abort the packet capture, navigate to the virtual hub, click the Packet Capture
button to open the Packet Capture page , then click Abor t . The PCAP files will not be generated or stored
when a packet capture is aborted.
View a packet capture

This section helps you download the packet capture PCAP file to view.
1. In the Azure portal, navigate to the storage account that you created.
2. Click Containers to view the containers for the storage account.
3. Click the container that you created.
4. Navigate through the folder structure to locate your PCAP file. The folder name and structure is based on
the date and UTC time. When you locate the PCAP file, click Download .
5. Packet capture data files are generated in PCAP format. You can use Wireshark or another commonly
available application to open PCAP files.
Key considerations
Running packet capture can affect performance. Remember to stop the packet capture when you don't need
it.
Suggested minimum packet capture duration is 600 seconds. Because of sync issues among multiple
components on the path, shorter packet captures might not provide complete data.
Packet capture data files are generated in PCAP format. Use Wireshark or other commonly available
applications to open PCAP files.
If the SASurl parameter isn't configured correctly, the trace might fail with storage errors.
Next steps
To learn more about Azure Virtual WAN, see the FAQ.
Configure a packet capture for Virtual WAN site-to-
site VPN: PowerShell
This article helps you create a packet capture for an Azure Virtual WAN site-to-site VPN gateway using Azure
PowerShell. Packet capture helps you narrow down the scope of a problem to certain parts of the network. It can
help you determine whether the problem is on the on-premises side of the network, the Azure side of the
network, or somewhere in between. By narrowing down the problem, you can more efficiently debug and take
remedial action.
While some commonly available packet capture tools do exist, getting relevant packet captures with these tools
can be cumbersome, especially in high-volume traffic scenarios. The filtering capabilities provided by the Virtual
WAN packet capture are a major differentiator. The Virtual WAN packet capture can be used along with
commonly available packet capture tools.
Prerequisites
Verify that you have the following configuration already set up in your environment:
A virtual WAN and a virtual hub.
A site-to-site VPN gateway deployed in the virtual hub.
You may also have connections connecting VPN sites to your site-to-site VPN gateway.
Working with Azure PowerShell
Set up the environment
Use the following command to verify that you are using the correct subscription and are logged in as a user that
has permissions to perform the packet capture on the site-to-site VPN gateway
$subid = “<insert Virtual WAN subscription ID here>”

Set-AzContext -SubscriptionId $subid
Create a storage account and container

A storage account is used to store the results of packet captures.
1. Create a storage account. For steps, see Create a storage account.
2. Create a container object within your storage account. For steps, see Create a container.
Generate the SAS URL

When you stop a packet capture, you must provide the SAS URL of the storage container that you created. The
results of your packet capture will be stored via this URL.
Run the following commands to generate a shared access signature (SAS) URL:
$rg = “<resource group name containing storage account>”

$storeName = “<name of storage account> “
$containerName = “<name of container you want to store packet capture in>
$key = Get-AzStorageAccountKey -ResourceGroupName $rg -Name $storeName
$context = New-AzStorageContext -StorageAccountName $storeName -StorageAccountKey $key[0].value
New-AzStorageContainer -Name $containerName -Context $context
$container = Get-AzStorageContainer -Name $containerName -Context $context
$now = get-date
$sasurl = New-AzStorageContainerSASToken -Name $containerName -Context $context -Permission "rwd" -StartTime
$now.AddHours(-1) -ExpiryTime $now.AddDays(1) -FullUri
Start a packet capture

This section helps you start a packet capture for your site-to-site VPN gateway (all connections).
1. To run a packet capture, you need the -Name value of the site-to-site VPN gateway. To find the -Name
value, in the Azure portal, navigate to your virtual hub, under Connectivity , click VPN (Site-to-site) .
2. To start a packet capture, run the following command:
Start-AzVpnGatewayPacketCapture -ResourceGroupName $rg -Name "<name of the Gateway>"
Optional: Specify filters

To simplify your packet captures, you may specify filters on your packet capture to focus on specific behaviors.
NOTE
For TracingFlags and TCPFlags, you may specify multiple protocols by adding up the numerical values for the protocols
you wish to capture (same as a logical OR). For example, if you want to capture only ESP and OPVN packets, specify a
TracingFlag value of 8+1 = 9.
TracingFlags Integer that determines 11 (ESP, IKE, OVPN) ESP = 1 IKE = 2 OPVN = 8
what types of packets are
captured
TCPFlags Integer that determines 0 (none) FIN = 1, SYN = 2, RST = 4,

which Types of TCP Packets PSH = 8, ACK = 16,URG =
are captured 32, ECE = 64, CWR = 128
MaxPacketBufferSize Maximum size of a captured 120 Any

packet in bytes. Packets are
truncated if larger than the
provided value.
MaxFileSize Maximum capture file size 100 Any

in Mb. Captures are stored
in a circular buffer so
overflow is handled in a
FIFO manner (older packets
removed first)
SourceSubnets Packets from the specified [] (all IPv4 addresses) Array of comma-separated
CIDR ranges are captured. IPV4 Subnets
Specified as an array.
DestinationSubnets Packets destined for the [] (all IPv4 addresses) Array of comma-separated
specified CIDR ranges are IPV4 Subnets
array.
SourcePort Packets with source in the [] (all ports) Array of comma-separated

specified ranges are ports
array.
DestinationPort Packets with destination in [] (all ports) Array of comma-separated

the specified ranges are ports
array.
CaptureSingleDirectionTraffi If true, only one direction of True True, False

cOnly a bidirectional flow will
show up in the packet
capture. This will capture all
possible combo of IP and
ports.
Protocol An array of integers that [] (all protocols) Any protocols found here
correspond IANA protocols.
The following example shows a packet capture using a filter string. You can change the parameters to suit your
needs.
$filter="{`"TracingFlags`":11,`"MaxPacketBufferSize`":120,`"MaxFileSize`":500,`"Filters`":
[{`"SourceSubnets`":[`"10.19.0.4/32`",`"10.20.0.4/32`"],`"DestinationSubnets`":
[`"10.20.0.4/32`",`"10.19.0.4/32`"],`"TcpFlags`":9,`"CaptureSingleDirectionTrafficOnly`":true}]}"
Start-AzVpnConnectionPacketCapture -ResourceGroupName $rg -Name "<name of the VPN connection>" -
ParentResourceName “<name of the Gateway>” -LinkConnection “<comma separated list of links>” -SasUrl $sasurl
-FilterData $filter
Start-AzVpnGatewayPacketCapture -ResourceGroupName $rg -Name "<name of the Gateway>" -FilterData $filter

Stop a packet capture
We recommend that you let the packet capture run for at least 600 seconds before stopping. When you stop a
packet capture, the parameters are similar to the parameters in the Start a packet capture section. In the
command, the SAS URL value was generated in the Create a storage account section. If the SasUrl parameter
isn't configured correctly, the capture might fail with storage errors.
When you are ready to stop the packet capture, run the following command:
Stop-AzVpnGatewayPacketCapture -ResourceGroupName $rg -Name <GatewayName> -SasUrl $sasurl
View a packet capture

This section helps you download the packet capture PCAP file to view.
1. In the Azure portal, navigate to the storage account that you created.
2. Click Containers to view the containers for the storage account.
3. Click the container that you created.
4. Navigate through the folder structure to locate your PCAP file. The folder name and structure is based on
the date and UTC time. When you locate the PCAP file, click Download .
5. Packet capture data files are generated in PCAP format. You can use Wireshark or another commonly
available application to open PCAP files.
Next steps
Next, to learn more about Virtual WAN, see the Virtual WAN FAQ.
How to monitor point-to-site connections for
Virtual WAN
This section documents how to create an Azure Workbook that shows relevant data of User VPN clients
connected to Azure Virtual WAN.
Before you begin

To complete the steps in this article, you need to have a virtual WAN, a hub, and a User VPN Gateway. To create
these resources, follow the steps in this article: Create virtual WAN, a hub, and a gateway
Workbook solution architecture

When you work with Azure Virtual WAN and look at metrics, it’s most often done from within the context of an
Azure workbook. In this solution, we'll use what's already available in Azure workbook and enrich it with more
details, especially about active connections.
AzureDiagnostics: These logs are received by enabling P2S Debugging through Azure Monitor debug
settings and enabling the following logs: GatewayDiagnosticLog, IKEDiagnosticLog, P2SDiagnosticLog,
AllMetrics. Some logs are noisy and costly regarding Log Analytics cost, specially IKEDiagnostics.
Get-AzP2sVpnGatewayDetailedConnectionHealth: This is a PowerShell command (running in a
function app) to get active sessions details. This command only supports storing data in a storage
account based on a SAS Key.
The following figure shows the involved components in the suggested solution:
The VPN service is running in the Azure vWAN P2S VPN gateway. It has associated metrics and debugs settings
that can be read from within an Azure workbook. To get the extra information that the PowerShell command can
provide, we choose to execute this command in an Azure function app. From the function app, we store the
output in an Azure storage account.
The output stored in the storage account is fetched from within the workbook by using a special function called
"externaldata".
Create Azure storage account

1. In the portal, in the Search resources bar, type Storage accounts .
2. Select Storage accounts from the results. On the Storage accounts page, select + Create to open the
Create a storage account page.
environment.
Subscription : Select the subscription that you want to use

Resource group : Create new or use existing
Storage account name : Type the name you want to call your storage account
Region : Select a region for your storage account
Performance : Standard or Premium. Standard is adequate for our monitoring purposes
Redundancy : Choose between Locally redundant storage, Geo-redundant storage, Zone-redundant
storage, and Geo-zone-redundant storage
After you finish filling out the fields, at the bottom of the page, select Next: Advanced> .
4. On the Advanced page, fill out the following fields.
Require secure transfer for REST API operations : Choose Enabled .

Enable blob public access : Choose Disabled .
Enable storage account key access : Choose Enabled .
Default to Azure Active Director y authorization in the Azure por tal : Choose Enabled .
Minimum TLS version : Choose Version 1.2 .
5. Select Review + create at the bottom to run validation.
6. Once validation passes, select Create to create the storage account.
Create container
1. Once the deployment is complete, go to the resource.
2. On the left panel, select Containers under Data storage .
3. Select + Container to create a new container.

4. Type a Name for your container and select Create .
Create and upload blob to container

1. On your computer, open a text editor application such as Notepad .
2. Leave the text file empty and select File -> Save As .
3. Save the empty text file with a name of your choice followed by the .json extension.
4. Go back to the Containers section in portal.
5. Select on the second row, which corresponds to the container you created (not $logs).
6. If you see this red warning message saying ""You do not have permission..."", then select Switch to
Access key as your authentication method. This is located right below the red warning box.
7. Select Upload .
8. Select the file corresponding to your empty JSON file on your machine and select Upload .
9. After the file gets uploaded, select on the JSON file and navigate to the Generate SAS tab.
10. Under Signing method , choose Account key .

11. Under Permissions , give the key the following permissions: Read, Add, Create, and Write .
12. Choose an Expir y date and time for the key.
13. Select Generate SAS token and URL .
14. Copy down the Blob SAS token and Blob SAS URL to a secure location.
Create Azure function app

1. In the portal, in the Search resources bar, type Function App .
2. Select Function App from the results. On the Function App page, select + Create to open the Create
Function App page.
environment.
Subscription : Select the subscription that you want to use

Resource group : Create new or use existing
Function App name : Choose a name for Function App
Publish : Select Code
Runtime stack : Select PowerShell Core
Version : Choose 7.0 (or your preferred version)
Region : Choose your preferred region
4. The remaining tabs are optional to change, so you can select Review + create and then select Create
when validation passes.
5. Go to the Function App resource.
6. Select on Identity under Settings in the left panel. Toggle the Status button to On for System
assigned and select Save .
7. Select on Configuration under Settings in the left panel.
8. Select on + New application setting .
9. Create the following 7 entries by inputting the Name and Value , then select OK after each value..
NAME VA L UE
"resourcegroup" your resource group
"sasuri" your resource group
"storageaccountname" @Microsoft.KeyVault(SecretUri=https://\
<keyvaultname>.vault.azure.net/secrets/sasuri/\
<version>)
-->update accordingly after keyvault is created in next
section.
"storagecontainer" your storage container name
"subscription" your subscription ID
"tenantname" your tenant ID
"vpngw" This name is something like <guid>-eastus-ps2-gw. You

can get this from the vWAN HUB User VPN settings.
10. Select Save .

11. Select on Functions in the left panel and select + Create .
12. Fill in the fields.
Development Environment : Develop in portal

Template : Timer Trigger
New Function : Choose a name for the Function
Schedule : Enter a cron expression of the format '{second} {minute} {hour} {day} {month} {day of the
week}' to specify the schedule
13. Select Code + Test in the left panel, and type the following code in the run.ps1 file. Select Save .
# Input bindings are passed in via param block.
param($Timer)
# Get the current universal time in the default string format.

$currentUTCtime = (Get-Date).ToUniversalTime()
# The 'IsPastDue' property is "true" when the current function invocation is later than scheduled.
if($Timer.IsPastDue){
Write-Host "PowerShell timer is running late!"
}
## Write an information log with current time.

Write-Host "PowerShell timer trigger function ran! TIME:$currentUTCtime"
$tenantname = $env:appsetting_tenantname
$subscription = $env:appsetting_subscription
$resourceGroup = $env:appsetting_resourcegroup
$storageAccountName = $env:appsetting_storageaccountname
$vpnstatsfile = $env:appsetting_vpnstatsfile
$vpngw = $env:appsetting_vpngw
$sasuri = $env:appsetting_sasuri
connect-azaccount -tenant $tenantname -identity -subscription $subscription
Get-AzP2sVpnGatewayDetailedConnectionHealth -name $vpngw -ResourceGroupName $resourceGroup -

OutputBlobSasUrl
$sasuri
14. Navigate back to the Function App page and select on App Ser vice Editor in the left panel under
Development Tools . Then, select Go --> .
15. Go to requirements.psd1 and uncomment the line beginning with 'Az'... as shown.
16. For the get-AzP2sVpnGatewayDetailedConnectionHealth command to succeed, you need to have

the right permissions to the information. Navigate to your resource group and choose "Access Control
(IAM)" in the left panel. This corresponds to identity and access management. Assign the FunctionApp
read access over the resource group.
Create Azure Key Vault

1. In the portal, in the Search resources bar, type Key vaults .
2. Select + Create from the results to open the Create a key vault page.
3. On the Basics tab, fill in the fields. Modify the example values to apply to your environment.
Storage account name : Type the name you want to call your key vault.
Region : Select a region for your storage account.
Pricing tier : Standard or Premium. Standard is adequate for our monitoring purposes.
4. Select Next: Access policy > .
5. Under Permission model , choose Vault access policy .
6. Leave the options under Resource access as disabled.
7. Under Access policies , select + Create .
8. Select Next to go to the Principal tab. Type the name of your function app and select it.
9. Select Next twice to get to the fourth tab: Review + create and select Create at the bottom.
10. You should now see the newly created access policy under the Access policies section. Modifying the
default values under the Networking tab is optional, so select Review + create in the bottom left
corner.
11. Go to Secrets under Objects under the left panel of the key vault resource. Select + Generate/Impor t
and add secret as follows:
Name : sasuri
value : <SASURI>
Enabled : Yes
12. Go back to the Configuration tab for the Function App and modify the following entry. The value comes
from the Secret Identifier field that appears after clicking on the secret:
Name : "sasuri"
Value :
@Microsoft.KeyVault(SecretUri=https://\<keyvaultname>.vault.azure.net/secrets/sasuri/\<version>)
Create Azure Workbook

The Azure workbook is now ready to be created. We'll use a mix of built-in functionality and the added session
details from our function app solution.
1. Navigate to your Virtual WAN resource and select on Insights under Monitor in the left panel. Select on
Workbooks and then select + New .
2. Add the following query into the workbook. Replace "SASURI" with your sas uri.
let P2Svpnconnections = (externaldata (resource:string, UserNameVpnConnectionHealths: dynamic) [

@"SASURI"
] with(format="multijson"));
P2Svpnconnections
| mv-expand UserNameVpnConnectionHealths
| extend Username = parse_json(UserNameVpnConnectionHealths).UserName
| extend VpnConnectionHealths =
parse_json(parse_json(UserNameVpnConnectionHealths).VpnConnectionHealths)
| mv-expand VpnConnectionHealths
| extend VpnConnectionId = parse_json(VpnConnectionHealths).VpnConnectionId, VpnConnectionDuration =
parse_json(VpnConnectionHealths).VpnConnectionDuration, VpnConnectionTime =
parse_json(VpnConnectionHealths).VpnConnectionTime, PublicIpAddress =
parse_json(VpnConnectionHealths).PublicIpAddress, PrivateIpAddress =
parse_json(VpnConnectionHealths).PrivateIpAddress, MaxBandwidth =
parse_json(VpnConnectionHealths).MaxBandwidth, EgressPacketsTransferred =
parse_json(VpnConnectionHealths).EgressPacketsTransferred, EgressBytesTransferred =
parse_json(VpnConnectionHealths).EgressBytesTransferred, IngressPacketsTransferred =
parse_json(VpnConnectionHealths).IngressPacketsTransferred, IngressBytesTransferred =
parse_json(VpnConnectionHealths).IngressBytesTransferred, MaxPacketsPerSecond =
parse_json(VpnConnectionHealths).MaxPacketsPerSecond
| extend PubIp = tostring(split(PublicIpAddress, ":").[0])
| project Username, VpnConnectionId, VpnConnectionDuration, VpnConnectionTime, PubIp,
PublicIpAddress, PrivateIpAddress, MaxBandwidth, EgressPacketsTransferred, EgressBytesTransferred,
IngressPacketsTransferred, IngressBytesTransferred, MaxPacketsPerSecond;
3. To see the results, select the blue button Run Quer y to see the results.
4. If you see the following error, then navigate back to the file (vpnstatfile.json) in the storage container's
blob, and regenerate the SAS URL. Then paste the updated SAS URL in the query.
5. Save the workbook to return to it later.

6. For the following metrics, you must enable diagnostics logging by adding diagnostic settings in Azure
portal. Fill in the required fields for subscription and resource group. For resource type, type in
"microsoft.network/p2svpngateways". Add a diagnostic setting (or edit the current diagnostic setting) for
the point-to-site gateway you wish to monitor.
7. Enable allLogs and allMetrics, and choose to send to "Log Analytics workspace" as the destination. Some
logs are noisy and might be costly (specifically IKEDiagnosticLog). As a result, feel free to enable only
specific logs you want to view instead of enabling allLogs.
Example queries
The following section shows example queries.
P2S User successful connections with IP
EAP (Extensible Authentication Protocol) authentication succeeded
P2S VPN user info
P2S VPN successful connections per user

P2S VPN connections
Successful P2S VPN connections
Failed P2S VPN connections
VPN connection count by P2SDiagnosticLog
IKEDiagnosticLog
Additional IKE diagnostics details

P2S VPN statistics
Next steps
To learn more about frequently asked questions, see the Virtual WAN FAQ page.
Azure subscription and service limits, quotas, and
constraints
This document lists some of the most common Microsoft Azure limits, which are also sometimes called quotas.
To learn more about Azure pricing, see Azure pricing overview. There, you can estimate your costs by using the
pricing calculator. You also can go to the pricing details page for a particular service, for example, Windows VMs.
For tips to help manage your costs, see Prevent unexpected costs with Azure billing and cost management.
Managing limits
NOTE
Some services have adjustable limits.
When a service doesn't have adjustable limits, the following tables use the header Limit . In those cases, the default and
the maximum limits are the same.
When the limit can be adjusted, the tables include Default limit and Maximum limit headers. The limit can be raised
above the default limit but not above the maximum limit.
If you want to raise the limit or quota above the default limit, open an online customer support request at no charge.
The terms soft limit and hard limit often are used informally to describe the current, adjustable limit (soft limit) and the
maximum limit (hard limit). If a limit isn't adjustable, there won't be a soft limit, only a hard limit.
Free Trial subscriptions aren't eligible for limit or quota increases. If you have a Free Trial subscription, you can
upgrade to a Pay-As-You-Go subscription. For more information, see Upgrade your Azure Free Trial subscription
to a Pay-As-You-Go subscription and the Free Trial subscription FAQ.
Some limits are managed at a regional level.
Let's use vCPU quotas as an example. To request a quota increase with support for vCPUs, you must decide how
many vCPUs you want to use in which regions. You then request an increase in vCPU quotas for the amounts
and regions that you want. If you need to use 30 vCPUs in West Europe to run your application there, you
specifically request 30 vCPUs in West Europe. Your vCPU quota isn't increased in any other region--only West
Europe has the 30-vCPU quota.
As a result, decide what your quotas must be for your workload in any one region. Then request that amount in
each region into which you want to deploy. For help in how to determine your current quotas for specific
regions, see Resolve errors for resource quotas.
General limits
For limits on resource names, see Naming rules and restrictions for Azure resources.
For information about Resource Manager API read and write limits, see Throttling Resource Manager requests.
Management group limits
The following limits apply to management groups.
RESO URC E L IM IT
Management groups per Azure AD tenant 10,000
Subscriptions per management group Unlimited.
Levels of management group hierarchy Root level plus 6 levels1
Direct parent management group per management group One
Management group level deployments per location 8002
Locations of Management group level deployments 10
1The 6 levels don't include the subscription level.

2If you reach the limit of 800
deployments, delete deployments from the history that are no longer needed. To
delete management group level deployments, use Remove-AzManagementGroupDeployment or az deployment
mg delete.
Subscription limits
The following limits apply when you use Azure Resource Manager and Azure resource groups.
RESO URC E L IM IT
Subscriptions associated with an Azure Active Directory Unlimited

tenant
Coadministrators per subscription Unlimited
Resource groups per subscription 980
Azure Resource Manager API request size 4,194,304 bytes
Tags per subscription1 50
Unique tag calculations per subscription1 80,000
Subscription-level deployments per location 8002
Locations of Subscription-level deployments 10
1You can apply up to 50 tags directly to a subscription. However, the subscription can contain an unlimited
number of tags that are applied to resource groups and resources within the subscription. The number of tags
per resource or resource group is limited to 50. Resource Manager returns a list of unique tag name and values
in the subscription only when the number of tags is 80,000 or less. You still can find a resource by tag when the
number exceeds 80,000.
2Deployments are automatically deleted from the history as you near the limit. For more information, see
Automatic deletions from deployment history.
Resource group limits
RESO URC E L IM IT
Resources per resource group Resources aren't limited by resource group. Instead, they're
limited by resource type in a resource group. See next row.
Resources per resource group, per resource type 800 - Some resource types can exceed the 800 limit. See
Resources not limited to 800 instances per resource group.
Deployments per resource group in the deployment history 8001
Resources per deployment 800
Management locks per unique scope 20
Number of tags per resource or resource group 50
Tag key length 512
Tag value length 256
1Deployments are automatically deleted from the history as you near the limit. Deleting an entry from the
deployment history doesn't affect the deployed resources. For more information, see Automatic deletions from
deployment history.
Template limits
VA L UE L IM IT
Parameters 256
Variables 256
Resources (including copy count) 800
Outputs 64
Template expression 24,576 chars
Resources in exported templates 200
Template size 4 MB
Parameter file size 4 MB
You can exceed some template limits by using a nested template. For more information, see Use linked
templates when you deploy Azure resources. To reduce the number of parameters, variables, or outputs, you can
combine several values into an object. For more information, see Objects as parameters.
You may get an error with a template or parameter file of less than 4 MB, if the total size of the request is too
large. For more information about how to simplify your template to avoid a large request, see Resolve errors for
job size exceeded.
Active Directory limits

Here are the usage constraints and other service limits for the Azure AD service.
C AT EGO RY L IM IT
Tenants A single user can belong to a maximum of 500 Azure AD

tenants as a member or a guest.
A single user can create a maximum of 200 directories.
Domains You can add no more than 5,000 managed domain

names.
If you set up all of your domains for federation with on-
premises Active Directory, you can add no more than 2,500
domain names in each tenant.
Resources By default, a maximum of 50,000 Azure AD resources

can be created in a single tenant by users of the
Azure Active Directory Free edition. If you have at
least one verified domain, the default Azure AD
service quota for your organization is extended to
300,000 Azure AD resources.
The Azure AD service quota for organizations created
by self-service sign-up remains 50,000 Azure AD
resources, even after you perform an internal admin
takeover and the organization is converted to a
managed tenant with at least one verified domain.
This service limit is unrelated to the pricing tier limit
of 500,000 resources on the Azure AD pricing page.
To go beyond the default quota, you must contact
Microsoft Support.
A non-admin user can create no more than 250
Azure AD resources. Both active resources and
deleted resources that are available to restore count
toward this quota. Only deleted Azure AD resources
that were deleted fewer than 30 days ago are
available to restore. Deleted Azure AD resources that
are no longer available to restore count toward this
quota at a value of one-quarter for 30 days.
If you have developers who are likely to repeatedly
exceed this quota in the course of their regular
duties, you can create and assign a custom role with
permission to create a limitless number of app
registrations.
Schema extensions String-type extensions can have a maximum of 256

characters.
Binary-type extensions are limited to 256 bytes.
Only 100 extension values, across all types and all
applications, can be written to any single Azure AD
resource.
Only User, Group, TenantDetail, Device, Application,
and ServicePrincipal entities can be extended with
string-type or binary-type single-valued attributes.
C AT EGO RY L IM IT
Applications A maximum of 100 users and service principals can

be owners of a single application.
A user, group, or service principal can have a
maximum of 1,500 app role assignments. The
limitation is on the service principal, user, or group
across all app roles and not on the number of
assignments on a single app role.
An app configured for password-based single sign-
on can have a maximum of 48 groups assigned with
credentials configured.
A user can have credentials configured for a
maximum of 48 apps using password-based single
sign-on. This limit only applies for credentials
configured when the user is directly assigned the
app, not when the user is a member of a group
which is assigned.
See additional limits in Validation differences by
supported account types.
Application manifest A maximum of 1,200 entries can be added to the application

manifest.
See additional limits in Validation differences by supported
account types.
C AT EGO RY L IM IT
Groups A non-admin user can create a maximum of 250

groups in an Azure AD organization. Any Azure AD
admin who can manage groups in the organization
can also create an unlimited number of groups (up to
the Azure AD object limit). If you assign a role to a
user to remove the limit for that user, assign a less
privileged, built-in role such as User Administrator or
Groups Administrator.
An Azure AD organization can have a maximum of
5,000 dynamic groups.
A maximum of 500 role-assignable groups can be
created in a single Azure AD organization (tenant).
A maximum of 100 users can be owners of a single
group.
Any number of Azure AD resources can be members
of a single group.
A user can be a member of any number of groups.
When security groups are being used in combination
with SharePoint Online, a user can be a part of 2,049
security groups in total. This includes both direct and
indirect group memberships. When this limit is
exceeded, authentication and search results become
unpredictable.
By default, the number of members in a group that
you can synchronize from your on-premises Active
Directory to Azure Active Directory by using Azure
AD Connect is limited to 50,000 members. If you
need to sync a group membership that's over this
limit, you must onboard the Azure AD Connect Sync
V2 endpoint API.
Nested groups in Azure AD are not supported within
all scenarios.
When you select a list of groups, you can assign a
group expiration policy to a maximum of 500
Microsoft 365 groups. There is no limit when the
policy is applied to all Microsoft 365 groups.
At this time, the following scenarios are supported with

nested groups:
One group can be added as a member of another
group, and you can achieve group nesting.
Group membership claims. When an app is
configured to receive group membership claims in
the token, nested groups in which the signed-in user
is a member are included.
Conditional access (when a conditional access policy
has a group scope).
Restricting access to self-serve password reset.
Restricting which users can do Azure AD Join and
device registration.
The following scenarios are not supported with nested

groups:
App role assignment, for both access and
provisioning. Assigning groups to an app is
supported, but any groups nested within the directly
assigned group won't have access.
Group-based licensing (assigning a license
automatically to all members of a group).
Microsoft 365 Groups.
C AT EGO RY L IM IT
Application Proxy A maximum of 500 transactions* per second per

Application Proxy application.
A maximum of 750 transactions per second for the
Azure AD organization.
*A transaction is defined as a single HTTP request and

response for a unique resource. When clients are
throttled, they'll receive a 429 response (too many
requests).
Access Panel There's no limit to the number of applications per user that
can be displayed in the Access Panel, regardless of the
number of assigned licenses.
Reports A maximum of 1,000 rows can be viewed or downloaded in

any report. Any additional data is truncated.
Administrative units An Azure AD resource can be a member of no more than 30

administrative units.
Azure AD roles and permissions A maximum of 30 Azure AD custom roles can be

created in an Azure AD organization.
A maximum of 100 Azure AD custom role
assignments for a single principal at tenant scope.
A maximum of 100 Azure AD built-in role
assignments for a single principal at non-tenant
scope (such as an administrative unit or Azure AD
object). There is no limit to Azure AD built-in role
assignments at tenant scope.
A group can't be added as a group owner.
A user's ability to read other users' tenant
information can be restricted only by the Azure AD
organization-wide switch to disable all non-admin
users' access to all tenant information (not
recommended). For more information, see To restrict
the default permissions for member users.
It might take up to 15 minutes or you might have to
sign out and sign back in before admin role
membership additions and revocations take effect.
API Management limits

RESO URC E L IM IT
Maximum number of scale units 12 per region1
Cache size 5 GiB per unit2
Concurrent back-end connections3 per HTTP authority 2,048 per unit4
Maximum cached response size 2 MiB
Maximum policy document size 256 KiB5

RESO URC E L IM IT
Maximum custom gateway domains per service instance6 20
Maximum number of CA certificates per service instance7 10
Maximum number of service instances per subscription8 20
Maximum number of subscriptions per service instance8 500
Maximum number of client certificates per service instance8 50
Maximum number of APIs per service instance8 50
Maximum number of API management operations per 1,000

service instance8
Maximum total request duration8 30 seconds
Maximum request payload size8 1 GiB
Maximum buffered payload size8 2 MiB
Maximum request URL size9 16,384 bytes
Maximum length of URL path segment10 260 characters
Maximum size of API schema used by validation policy10 4 MB
Maximum size of request or response body in validate- 100 KB

content policy10
Maximum number of self-hosted gateways11 25
1 Scaling limits depend on the pricing tier. For details on the pricing tiers and their scaling limits, see API
Management pricing.
2 Per unit cache size depends on the pricing tier. To see the pricing tiers and their scaling limits, see API
Management pricing.
3 Connections are pooled and reused unless explicitly closed by the back end.
4 This limit is per unit of the Basic, Standard, and Premium tiers. The Developer tier is limited to 1,024. This limit
doesn't apply to the Consumption tier.

5 This limit applies to the Basic, Standard, and Premium tiers. In the Consumption tier, policy document size is
limited to 16 KiB.
6 Multiple custom domains are supported in the Developer and Premium tiers only.
7 CA certificates are not supported in the Consumption tier.
8 This limit applies to the Consumption tier only. There are no limits in these categories for other tiers.
9 Applies to the Consumption tier only. Includes an up to 2048-bytes long query string.
10 To increase this limit, contact support.
11 Self-hosted gateways are supported in the Developer and Premium tiers only. The limit applies to the number
of self-hosted gateway resources. To raise this limit contact support. Note, that the number of nodes (or replicas)
associated with a self-hosted gateway resource is unlimited in the Premium tier and capped at a single node in
the Developer tier.
App Service limits
P REM IUM
RESO URC E F REE SH A RED B A SIC STA N DA RD ( V1- V3) ISO L AT ED
Web, mobile, 10 100 Unlimited2 Unlimited2 Unlimited2 Unlimited2

or API apps
per Azure
App Service
plan1
App Service 10 per region 10 per 100 per 100 per 100 per 100 per
plan resource resource resource resource resource
group group group group group
Compute Shared Shared Dedicated3 Dedicated3 Dedicated3 Dedicated3

instance type
Scale out 1 shared 1 shared 3 dedicated3 10 dedicated3 20 dedicated 100

(maximum for v1; 30 dedicated4
instances) dedicated for
v2 and v3.3
Storage5 1 GB5 1 GB5 10 GB5 50 GB5 250 GB5 1 TB12
The available
storage quota
is 999 GB.
CPU time (5 3 minutes 3 minutes Unlimited, Unlimited, Unlimited, Unlimited,

minutes)6 pay at pay at pay at pay at
standard standard standard standard
rates rates rates rates
CPU time 60 minutes 240 minutes Unlimited, Unlimited, Unlimited, Unlimited,

(day)6 pay at pay at pay at pay at
standard standard standard standard
rates rates rates rates
Memory (1 1,024 MB per 1,024 MB per N/A N/A N/A N/A

hour) App Service app
plan
Bandwidth 165 MB Unlimited, Unlimited, Unlimited, Unlimited, Unlimited,

data transfer data transfer data transfer data transfer data transfer
rates apply rates apply rates apply rates apply rates apply
Application 32-bit 32-bit 32-bit/64-bit 32-bit/64-bit 32-bit/64-bit 32-bit/64-bit

architecture
Web sockets 5 35 350 Unlimited Unlimited Unlimited

per instance7
Outbound IP 600 600 Depends on Depends on Depends on 16,000

connections instance size8 instance size8 instance size8
per instance
P REM IUM
Concurrent 1 1 1 5 5 5
debugger
connections
per
application
App Service Not Not 10 10 10 10

Certificates supported supported
per
subscription
Custom 0 500 500 500 500 500

domains per (azurewebsite
app s.net
subdomain
only)
Custom Not Not Unlimited SNI Unlimited SNI Unlimited SNI Unlimited SNI
domain SSL supported, supported, SSL SSL and 1 IP SSL and 1 IP SSL and 1 IP
support wildcard wildcard connections SSL SSL SSL
certificate for certificate for connections connections connections
*.azurewebsit *.azurewebsit included included included
es.net es.net
available by available by
default default
Hybrid 5 per plan 25 per plan 220 per app 220 per app
connections
Virtual X X X
Network
Integration
Private 100 per app

Endpoints
Integrated X X X X X9
load balancer
Access 512 rules per 512 rules per 512 rules per 512 rules per 512 rules per 512 rules per
restrictions app app app app app app
Always On X X X X
Scheduled Scheduled Scheduled Scheduled

backups backups backups backups
every 2 every hour, a every hour, a
hours, a maximum of maximum of
maximum of 50 backups 50 backups
12 backups per day per day
per day (manual + (manual +
(manual + scheduled) scheduled)
scheduled)
Autoscale X X X
P REM IUM
WebJobs10 X X X X X X
Endpoint X X X X
monitoring
Staging slots 5 20 20
per app
Testing in X X X
Production
Diagnostic X X X X X X
Logs
Kudu X X X X X X
Authenticatio X X X X X X
n and
Authorization
App Service X X X X
Managed
Certificates11
SLA 99.95% 99.95% 99.95% 99.95%
1 Apps and storage quotas are per App Service plan unless noted otherwise.
2 The actual number of apps that you can host on these machines depends on the activity of the apps, the size of
the machine instances, and the corresponding resource utilization.
3 Dedicated instances can be of different sizes. For more information, see App Service pricing.
4 More are allowed upon request.
5 The storage limit is the total content size across all apps in the same App service plan. The total content size of
all apps across all App service plans in a single resource group and region cannot exceed 500 GB. The file
system quota for App Service hosted apps is determined by the aggregate of App Service plans created in a
region and resource group.
6 These resources are constrained by physical resources on the dedicated instances (the instance size and the
number of instances).
7 If you scale an app in the Basic tier
to two instances, you have 350 concurrent connections for each of the two
instances. For Standard tier and above, there are no theoretical limits to web sockets, but other factors can limit
the number of web sockets. For example, maximum concurrent requests allowed (defined by
maxConcurrentRequestsPerCpu ) are: 7,500 per small VM, 15,000 per medium VM (7,500 x 2 cores), and 75,000
per large VM (18,750 x 4 cores).
8 The maximum IP connections are per instance and depend on the instance size: 1,920 per B1/S1/P1V3
instance, 3,968 per B2/S2/P2V3 instance, 8,064 per B3/S3/P3V3 instance.
9 App Service Isolated SKUs can be internally load balanced (ILB) with Azure Load Balancer, so there's no public
connectivity from the internet. As a result, some features of an ILB Isolated App Service must be used from
machines that have direct access to the ILB network endpoint.
10 Run custom executables and/or scripts on demand, on a schedule, or continuously as a background task
within your App Service instance. Always On is required for continuous WebJobs execution. There's no
predefined limit on the number of WebJobs that can run in an App Service instance. There are practical limits
that depend on what the application code is trying to do.
11 Only issuing standard certificates (wildcard certificates aren't available). Limited to only one free certificate
per custom domain.

12 Total storage usage across all apps deployed in a single App Service Environment (regardless of how they're
allocated across different resource groups).
Automation limits
Process automation
RESO URC E L IM IT N OT ES
Maximum number of new jobs that 100 When this limit is reached, the
can be submitted every 30 seconds subsequent requests to create a job
per Azure Automation account fail. The client receives an error
(nonscheduled jobs) response.
Maximum number of concurrent 200 When this limit is reached, the

running jobs at the same instance of subsequent requests to create a job
time per Automation account fail. The client receives an error
(nonscheduled jobs) response.
Maximum storage size of job metadata 10 GB (approximately 4 million jobs) When this limit is reached, the
for a 30-day rolling period subsequent requests to create a job
fail.
Maximum job stream limit 1 MiB A single stream cannot be larger than
1 MiB.
Maximum number of modules that 5

can be imported every 30 seconds per
Automation account
Maximum size of a module 100 MB
Maximum size of a node configuration 1 MB Applies to state configuration

file
Job run time, Free tier 500 minutes per subscription per
calendar month
Maximum amount of disk space 1 GB Applies to Azure sandboxes only.

allowed per sandbox1
Maximum amount of memory given 400 MB Applies to Azure sandboxes only.

to a sandbox1
Maximum number of network sockets 1,000 Applies to Azure sandboxes only.

allowed per sandbox1
Maximum runtime allowed per 3 hours Applies to Azure sandboxes only.

runbook1
Maximum number of Automation No limit

accounts in a subscription
Maximum number of system hybrid 4,000

runbook workers per Automation
Account
Maximum number of user hybrid 4,000

runbook workers per Automation
Account
Maximum number of concurrent jobs 50

that can be run on a single Hybrid
Runbook Worker
Maximum runbook job parameter size 512 kilobytes
Maximum runbook parameters 50 If you reach the 50-parameter limit,

you can pass a JSON or XML string to
a parameter and parse it with the
runbook.
Maximum webhook payload size 512 kilobytes
Maximum days that job data is 30 days

retained
Maximum PowerShell workflow state 5 MB Applies to PowerShell workflow

size runbooks when checkpointing
workflow.
Maximum number of tags supported 15

by an Automation account
1A sandbox is a shared environment that can be used by multiple jobs. Jobs that use the same sandbox are
bound by the resource limitations of the sandbox.

Change Tracking and Inventory
The following table shows the tracked item limits per machine for change tracking.
File 500
File size 5 MB
Registry 250
Windows software 250 Doesn't include software updates.

Linux packages 1,250
Services 250
Daemon 250
Update Management
The following table shows the limits for Update Management.
Number of machines per update 1000

deployment
Number of dynamic groups per 500

update deployment
Azure App Configuration

RESO URC E L IM IT C O M M EN T
Configuration stores for Free tier 1 store per subscription
Configuration stores for Standard tier Unlimited stores per subscription
Configuration store requests for Free 1,000 requests per day Once the quota is exhausted, HTTP
tier status code 429 will be returned for all
requests until the end of the day
Configuration store requests for 30,000 per hour Once the quota is exhausted, requests
Standard tier may return HTTP status code 429
indicating Too Many Requests - until
the end of the hour
Storage for Free tier 10 MB
Storage for Standard tier 1 GB
Keys and Values 10 KB For a single key-value item, including

all metadata
Azure Cache for Redis limits

RESO URC E L IM IT
Cache size 1.2 TB
Databases 64
Maximum connected clients 40,000

RESO URC E L IM IT
Azure Cache for Redis replicas, for high availability 3
Shards in a premium cache with clustering 10
Azure Cache for Redis limits and sizes are different for each pricing tier. To see the pricing tiers and their
associated sizes, see Azure Cache for Redis pricing.
For more information on Azure Cache for Redis configuration limits, see Default Redis server configuration.
Because configuration and management of Azure Cache for Redis instances is done by Microsoft, not all Redis
commands are supported in Azure Cache for Redis. For more information, see Redis commands not supported
in Azure Cache for Redis.
Azure Cloud Services limits

RESO URC E L IM IT
Web or worker roles per deployment1 25
Instance input endpoints per deployment 25
Input endpoints per deployment 25
Internal endpoints per deployment 25
Hosted service certificates per deployment 199
1Each Azure Cloud Service with web or worker roles can have two deployments, one for production and one for
staging. This limit refers to the number of distinct roles, that is, configuration. This limit doesn't refer to the
number of instances per role, that is, scaling.
Azure Cognitive Search limits

Pricing tiers determine the capacity and limits of your search service. Tiers include:
Free multi-tenant service, shared with other Azure subscribers, is intended for evaluation and small
development projects.
Basic provides dedicated computing resources for production workloads at a smaller scale, with up to three
replicas for highly available query workloads.
Standard , which includes S1, S2, S3, and S3 High Density, is for larger production workloads. Multiple levels
exist within the Standard tier so that you can choose a resource configuration that best matches your
workload profile.
Limits per subscription
You can create multiple services, limited only by the number of services allowed at each tier. For example, you
could create up to 16 services at the Basic tier and another 16 services at the S1 tier within the same
subscription. For more information about tiers, see Choose an SKU or tier for Azure Cognitive Search.
Maximum service limits can be raised upon request. If you need more services within the same subscription,
contact Azure Support.
RESO URC
E F REE 1 B A SIC S1 S2 S3 S3 H D L1 L2
Maximu 1 16 16 8 6 6 6 6
m
services
Maximu N/A 3 SU 36 SU 36 SU 36 SU 36 SU 36 SU 36 SU
m scale in
search
units
(SU)2
1 Free is based on infrastructure that's shared with other customers. Because the hardware isn't dedicated, scale-
up isn't supported on the free tier.
2 Search units are billing units, allocated as either
a replica or a partition. You need both resources for storage,
indexing, and query operations. To learn more about SU computations, see Scale resource levels for query and
index workloads.
Limits per search ser vice
A search service is constrained by disk space or by a hard limit on the maximum number of indexes or indexers,
whichever comes first. The following table documents storage limits. For maximum object limits, see Limits by
resource.
RESO URC
E F REE B A SIC 1 S1 S2 S3 S3 H D L1 L2
Service No Yes Yes Yes Yes Yes Yes Yes

level
agreeme
nt (SLA)2
Storage 50 MB 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB

per
partition
Partitions N/A 1 12 12 12 3 12 12
per
service
Partition N/A 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB

size
Replicas N/A 3 12 12 12 12 12 12
1 Basic has one fixed partition. Additional search units can be used to add replicas for larger query volumes.
2 Service level agreements are in effect forbillable services on dedicated resources. Free services and preview
features have no SLA. For billable services, SLAs take effect when you provision sufficient redundancy for your
service. Two or more replicas are required for query (read) SLAs. Three or more replicas are required for query
and indexing (read-write) SLAs. The number of partitions isn't an SLA consideration.
To learn more about limits on a more granular level, such as document size, queries per second, keys, requests,
and responses, see Service limits in Azure Cognitive Search.
Azure Cognitive Services limits
The following limits are for the number of Cognitive Services resources per Azure subscription. There is a limit
of only one allowed 'Free' account, per Cognitive Service type, per subscription. Each of the Cognitive Services
may have other limitations, for more information, see Azure Cognitive Services.
TYPE L IM IT EXA M P L E
A mixture of Cognitive Services Maximum of 200 total Cognitive 100 Computer Vision resources in
resources Services resources per region. West US, 50 Speech Service resources
in West US, and 50 Text Analytics
resources in West US.
A single type of Cognitive Services Maximum of 100 resources per region 100 Computer Vision resources in
resources. West US 2, and 100 Computer Vision
resources in East US.
Azure Cosmos DB limits

For Azure Cosmos DB limits, see Limits in Azure Cosmos DB.
Azure Data Explorer limits

The following table describes the maximum limits for Azure Data Explorer clusters.
RESO URC E L IM IT
Clusters per region per subscription 20
Instances per cluster 1000
Number of databases in a cluster 10,000
Number of follower clusters (data share consumers) per 100

leader cluster (data share producer)
The following table describes the limits on management operations performed on Azure Data Explorer clusters.
SC O P E O P ERAT IO N L IM IT
Cluster read (for example, get a cluster) 500 per 5 minutes
Cluster write (for example, create a database) 1000 per hour
Azure Database for MySQL

For Azure Database for MySQL limits, see Limitations in Azure Database for MySQL.
Azure Database for PostgreSQL

For Azure Database for PostgreSQL limits, see Limitations in Azure Database for PostgreSQL.
Azure Functions limits

C O N SUM P T IO N DEDIC AT ED
RESO URC E PLAN P REM IUM P L A N PLAN A SE K UB ERN ET ES
Default timeout 5 30 301 30 30

duration (min)
Max timeout 10 unbounded7 unbounded2 unbounded unbounded

duration (min)
Max outbound 600 active (1200 unbounded unbounded unbounded unbounded

connections (per total)
instance)
Max request size 100 100 100 100 Depends on

(MB)3 cluster
Max query string 4096 4096 4096 4096 Depends on

length3 cluster
Max request URL 8192 8192 8192 8192 Depends on

length3 cluster
ACU per 100 210-840 100-840 210-2508 AKS pricing

instance
Max memory 1.5 3.5-14 1.75-14 3.5 - 14 Any node is

(GB per instance) supported
Max instance 200/100 100/20 varies by SKU9 1009 Depends on

count cluster
(Windows/Linux)
Function apps 100 100 unbounded4 unbounded unbounded

per plan
App Service 100 per region 100 per resource 100 per resource - -
plans group group
Deployment 2 3 1-209 20 n/a

slots per app10
Storage5 5 TB 250 GB 50-1000 GB 1 TB n/a
Custom domains 5006 500 500 500 n/a

per app
Custom domain unbounded SNI unbounded SNI unbounded SNI unbounded SNI n/a
SSL support SSL connection SSL and 1 IP SSL SSL and 1 IP SSL SSL and 1 IP SSL
included connections connections connections
included included included
1 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
2 Requires the App Service plan be set to Always On. Pay at standard rates.
3 These limits are set in the host.
4 The actual number of function apps that you can host depends on the activity of the apps, the size of the
machine instances, and the corresponding resource utilization.
5
5 The storage limit is the total content size in temporary storage across all apps in the same App Service plan.
Consumption plan uses Azure Files for temporary storage.

6 When your function app is hosted in a Consumption plan, only the CNAME option is supported. For function
apps in a Premium plan or an App Service plan, you can map a custom domain using either a CNAME or an A
record.
7 Guaranteed for up to 60 minutes.
8 Workers are roles that host customer apps. Workers are available in three fixed sizes: One vCPU/3.5 GB RAM;
Two vCPU/7 GB RAM; Four vCPU/14 GB RAM.

9 See App Service limits for details.
10 Including the production slot.
For more information, see Functions Hosting plans comparison.
Azure Healthcare APIs

Healthcare APIs service limits
Azure Healthcare APIs is a set of managed API services based on open standards and frameworks. The service
enables workflows to improve healthcare, and offers scalable and secure healthcare solutions. It's currently in
public preview. Azure Healthcare APIs includes the Fast Healthcare Interoperability Resources (FHIR) service, the
Digital Imaging and Communications in Medicine (DICOM) service, and the IoT connector.
The FHIR service is an implementation of the FHIR specification within the Azure Healthcare APIs. It enables you
to combine in a single workspace one or more FHIR service instances with optional DICOM service instances
and IoT connectors. The Azure API for FHIR is General Availability (GA), and available as a stand-alone service
offering.
Q UOTA N A M E DEFA ULT L IM IT M A XIM UM L IM IT N OT ES
Workspace 10 Contact support Limit per subscription
FHIR 10 Contact support Limit per workspace
DICOM 10 Contact support Limit per workspace
IoT connector 10 N/A Limit per workspace, can't

be increased
Azure API for FHIR service limits

Azure API for FHIR is a managed, standards-based, compliant API for clinical health data that enables solutions
for actionable analytics and machine learning.
Q UOTA N A M E DEFA ULT L IM IT M A XIM UM L IM IT N OT ES
Request Units (RUs) 10,000 RUs Contact support Maximum You need a minimum of
available is 1,000,000. 400 RUs or 40 RUs/GB,
whichever is larger.
Concurrent connections 15 concurrent connections Contact support

on two instances (for a total
of 30 concurrent requests)
Azure API for FHIR Service 10 Contact support

Instances per Subscription
Azure Kubernetes Service limits
RESO URC E L IM IT
Maximum clusters per subscription 5000
Maximum nodes per cluster with Virtual Machine Availability 100

Sets and Basic Load Balancer SKU
Maximum nodes per cluster with Virtual Machine Scale Sets 1000 (across all node pools)
and Standard Load Balancer SKU
Maximum node pools per cluster 100
Maximum pods per node: Basic networking with Kubenet Maximum: 250
Azure CLI default: 110
Azure Resource Manager template default: 110
Azure portal deployment default: 30
Maximum pods per node: Advanced networking with Azure Maximum: 250
Container Networking Interface Default: 30
Open Service Mesh (OSM) AKS addon Kubernetes Cluster Version: 1.19+
OSM controllers per cluster: 1
Pods per OSM controller: 500
Kubernetes service accounts managed by OSM: 50
K UB ERN ET ES C O N T RO L P L A N E T IER L IM IT
Paid tier Automatically scales out based on the load
Free tier Limited resources with inflight requests limit of 50 mutating

and 100 read-only calls
Azure Machine Learning limits

The latest values for Azure Machine Learning Compute quotas can be found in the Azure Machine Learning
quota page
Azure Maps limits

The following table shows the usage limit for the Azure Maps S0 pricing tier. Usage limit depends on the pricing
tier.
RESO URC E S0 P RIC IN G T IER L IM IT
Maximum request rate per subscription 50 requests per second
The following table shows the cumulative data size limit for Azure Maps accounts in an Azure subscription. The
Azure Maps Data service is available only at the S1 pricing tier.
RESO URC E L IM IT
Maximum storage per Azure subscription 1 GB

RESO URC E L IM IT
Maximum size per file upload 100 MB
For more information on the Azure Maps pricing tiers, see Azure Maps pricing.
Azure Monitor limits

Alerts
RESO URC E DEFA ULT L IM IT M A XIM UM L IM IT
Metric alerts (classic) 100 active alert rules per subscription. Call support
Metric alerts 5,000 active alert rules per Call support.

subscription in Azure public, Azure
China 21Vianet and Azure
Government clouds. If you are hitting
this limit, explore if you can use same
type multi-resource alerts.
5,000 metric time-series per alert rule.
Activity log alerts 100 active alert rules per subscription Same as default
(cannot be increased).
Log alerts 1000 active alert rules per Call support

subscription. 1000 active alert rules
per resource.
Alert processing rules 1000 active rules per subscription. Call support
Alert rules and alert processing rules Log search alerts 4096 characters Same as default
description length All other 2048 characters
Alerts API
Azure Monitor Alerts have several throttling limits to protect against users making an excessive number of calls.
Such behavior can potentially overload the system backend resources and jeopardize service responsiveness.
The following limits are designed to protect customers from interruptions and ensure consistent service level.
The user throttling and limits are designed to impact only extreme usage scenario and should not be relevant
for typical usage.
Alerts - Get Summary 50 calls per minute per subscription Same as default
Alerts - Get All (not "Get By Id") 100 calls per minute per subscription Same as default
All other alerts calls 1000 calls per minute per subscription Same as default
Action groups
You may have an unlimited number of action groups in a subscription.
Azure app push 10 Azure app actions per action group. Same as Default
Email 1,000 email actions in an action group. Same as Default

No more than 100 emails in an hour.
Also see the rate limiting information.
Email ARM role 10 Email ARM role actions per action Same as Default
group.
Event Hub 10 Event Hub actions per action Same as Default

group.
ITSM 10 ITSM actions in an action group. Same as Default
Logic app 10 logic app actions in an action Same as Default

group.
Runbook 10 runbook actions in an action group. Same as Default
Secure Webhook 10 secure webhook actions in an Same as Default

action group. Maximum number of
webhook calls is 1500 per minute per
subscription. Other limits are available
at action-specific information.
SMS 10 SMS actions in an action group. Same as Default

No more than 1 SMS message every 5
minutes.
Voice 10 voice actions in an action group. Same as Default

No more than 1 voice call every 5
minutes.
Webhook 10 webhook actions in an action Same as Default

group. Maximum number of webhook
calls is 1500 per minute per
subscription. Other limits are available
at action-specific information.
Autoscale
Autoscale settings 100 per region per subscription. Same as default
Autoscale profiles 20 profiles per autoscale setting. Same as default
Log queries and language

General query limits
L IM IT DESC RIP T IO N
Query language Azure Monitor uses the same Kusto query language as
Azure Data Explorer. See Azure Monitor log query language
differences for KQL language elements not supported in
Azure Monitor.
Azure regions Log queries can experience excessive overhead when data
spans Log Analytics workspaces in multiple Azure regions.
See Query limits for details.
Cross resource queries Maximum number of Application Insights resources and Log
Analytics workspaces in a single query limited to 100.
Cross-resource query is not supported in View Designer.
Cross-resource query in log alerts is supported in the new
scheduledQueryRules API.
See Cross-resource query limits for details.
User query throttling

Azure Monitor has several throttling limits to protect against users sending an excessive number of queries.
Such behavior can potentially overload the system backend resources and jeopardize service responsiveness.
The following limits are designed to protect customers from interruptions and ensure consistent service level.
The user throttling and limits are designed to impact only extreme usage scenario and should not be relevant
for typical usage.
M EA SURE L IM IT P ER USER DESC RIP T IO N
Concurrent queries 5 A user can run up to 5 concurrent

queries, any additional query will be
added to a queue. When one of the
running queries finishes, the first query
in the queue is pulled from the queue
and starts running. Note: Alerts
queries are not part of this limit.
Time in concurrency queue 3 minutes If a query sits in the queue for more
than 3 minutes without being started,
it will be terminated with an HTTP
error response with code 429.
Total queries in concurrency queue 200 Once the number of queries in the
queue reach 200, the next query will
be rejected with an HTTP error code
429. This number is in addition to the
five queries that can be running
simultaneously.
Query rate 200 queries per 30 seconds Overall rate of queries that can be
submitted by a single user to all
workspaces. This limit applies to
programmatic queries or queries
initiated by visualization parts such as
Azure dashboards and the Log
Analytics workspace summary page.
Optimize your queries as described in Optimize log queries in Azure Monitor.

Dashboards and workbooks can contain multiple queries in a single view that generate a burst of queries
every time they load or refresh. Consider breaking them up into multiple views that load on demand.
In Power BI, consider extracting only aggregated results rather than raw logs.
Log Analytics workspaces
Data collection volume and retention
T IER L IM IT P ER DAY DATA RET EN T IO N C O M M EN T
Current Per GB pricing tier No limit 30 - 730 days Data retention beyond 31
(introduced April 2018) days is available for
additional charges. Learn
more about Azure Monitor
pricing.
Legacy Free tiers 500 MB 7 days When your workspace

(introduced April 2016) reaches the 500 MB per
day limit, data ingestion
stops and resumes at the
start of the next day. A day
is based on UTC. Note that
data collected by Microsoft
Defender for Cloud is not
included in this 500 MB per
day limit and will continue
to be collected above this
limit.
Legacy Standalone Per GB No limit 30 to 730 days Data retention beyond 31

tier days is available for
(introduced April 2016) additional charges. Learn
pricing.
Legacy Per Node (OMS) No limit 30 to 730 days Data retention beyond 31
(introduced April 2016) days is available for
additional charges. Learn
pricing.
Legacy Standard tier No limit 30 days Retention can't be adjusted
Legacy Premium tier No limit 365 days Retention can't be adjusted
Number of workspaces per subscription.
P RIC IN G T IER W O RK SPA C E L IM IT C O M M EN T S
Free tier 10 This limit can't be increased.
All other tiers No limit You're limited by the number of

resources within a resource group and
the number of resource groups per
subscription.
Azure por tal

C AT EGO RY L IM IT C O M M EN T S
Maximum records returned by a log 30,000 Reduce results using query scope, time
query range, and filters in the query.
Data Collector API
Maximum size for a single post 30 MB Split larger volumes into multiple
posts.
Maximum size for field values 32 KB Fields longer than 32 KB are truncated.
Quer y API
Maximum records returned in a single 500,000

query
Maximum size of data returned ~104 MB (~100 MiB)
Maximum query running time 10 minutes See Timeouts for details.
Maximum request rate 200 requests per 30 seconds per See Log queries and language.
Azure AD user or client IP address
Azure Monitor Logs connector
Max size of data ~16.7 MB (~16 MiB) The connector infrastructure dictates
that limit is set lower than query API
limit
Max number of records 500,000
Max connector timeout 110 second
Max query timeout 100 second
Charts Visualization in Logs page and the

connector are using different charting
libraries and some functionality isn't
available in the connector currently
General workspace limits
Maximum columns in a table 500
Maximum characters for column name 45

Data ingestion volume rate

Azure Monitor is a high scale data service that serves thousands of customers sending terabytes of data each
month at a growing pace. The volume rate limit intends to isolate Azure Monitor customers from sudden
ingestion spikes in multitenancy environment. A default ingestion volume rate threshold of 500 MB
(compressed) is defined in workspaces, this is translated to approximately 6 GB/min uncompressed -- the
actual size can vary between data types depending on the log length and its compression ratio. The volume rate
limit applies to data ingested from Azure resources via Diagnostic settings. When volume rate limit is reached, a
retry mechanism attempts to ingest the data 4 times in a period of 30 minutes and drop it if operation fails. It
doesn't apply to data ingested from agents or Data Collector API.
When data sent to your workspace is at a volume rate higher than 80% of the threshold configured in your
workspace, an event is sent to the Operation table in your workspace every 6 hours while the threshold
continues to be exceeded. When ingested volume rate is higher than threshold, some data is dropped and an
event is sent to the Operation table in your workspace every 6 hours while the threshold continues to be
exceeded. If your ingestion volume rate continues to exceed the threshold or you are expecting to reach it
sometime soon, you can request to increase it in by opening a support request.
See Monitor health of Log Analytics workspace in Azure Monitor to create alert rules to be proactively notified
when you reach any ingestion limits.
NOTE
Depending on how long you've been using Log Analytics, you might have access to legacy pricing tiers. Learn more about
Log Analytics legacy pricing tiers.
Application Insights
There are some limits on the number of metrics and events per application, that is, per instrumentation key.
Limits depend on the pricing plan that you choose.
RESO URC E DEFA ULT L IM IT N OT E
Total data per day 100 GB You can reduce data by setting a cap. If
you need more data, you can increase
the limit in the portal, up to 1,000 GB.
For capacities greater than 1,000 GB,
send email to
AIDataCap@microsoft.com.
Throttling 32,000 events/second The limit is measured over a minute.
Data retention Logs 30 - 730 days This resource is for Logs.
Data retention Metrics 90 days This resource is for Metrics Explorer.
Availability multi-step test detailed 90 days This resource provides detailed results
results retention of each step.
Maximum telemetry item size 64 kB
Maximum telemetry items per batch 64 K

RESO URC E DEFA ULT L IM IT N OT E
Property and metric name length 150 See type schemas.
Property value string length 8,192 See type schemas.
Trace and exception message length 32,768 See type schemas.
Availability tests count per app 100
Profiler data retention 5 days
Profiler data sent per day 10 GB
For more information, see About pricing and quotas in Application Insights.
Azure Data Factory limits

Azure Data Factory is a multitenant service that has the following default limits in place to make sure customer
subscriptions are protected from each other's workloads. To raise the limits up to the maximum for your
subscription, contact support.
Version 2
Total number of entities, such as 5,000 Contact support.

pipelines, data sets, triggers, linked
services, Private Endpoints, and
integration runtimes, within a data
factory
Total CPU cores for Azure-SSIS 256 Contact support.

Integration Runtimes under one
subscription
Concurrent pipeline runs per data 10,000 10,000

factory that's shared among all
pipelines in the factory
Concurrent External activity runs per 3,000 3,000

subscription per Azure Integration
Runtime region
External activities are managed on
integration runtime but execute on linked
services, including Databricks, stored
procedure, Web, and others. This limit does
not apply to Self-hosted IR.
Concurrent Pipeline activity runs per 1,000 1,000

Runtime region
Pipeline activities execute on integration
runtime, including Lookup, GetMetadata,
and Delete. This limit does not apply to Self-
hosted IR.
Concurrent authoring operations per 200 200

Runtime region
Including test connection, browse folder list
and table list, preview data. This limit does
Concurrent Data Integration Units1 Region group 12 : 6,000 Region group 12 : 6,000
consumption per subscription per Region group 22 : 3,000 Region group 22 : 3,000
Azure Integration Runtime region Region group 32 : 1,500 Region group 32 : 1,500
Managed virtual network2 : 2,400 Managed virtual network: Contact
support.
Maximum activities per pipeline, which 40 40

includes inner activities for containers
Maximum number of linked 100 Contact support.

integration runtimes that can be
created against a single self-hosted
integration runtime
Maximum number of node that can be 4 Contact support

integration runtime
Maximum parameters per pipeline 50 50
ForEach items 100,000 100,000
ForEach parallelism 20 50
Maximum queued runs per pipeline 100 100
Characters per expression 8,192 8,192
Minimum tumbling window trigger 5 min 15 min

interval
Maximum timeout for pipeline activity 7 days 7 days

runs
Bytes per object for pipeline objects3 200 KB 200 KB
Bytes per object for dataset and linked 100 KB 2,000 KB

service objects3
Bytes per payload for each activity 896 KB 896 KB

run4
Data Integration Units1 per copy 256 256

activity run
Write API calls 1,200/h 1,200/h
This limit is imposed by Azure Resource

Manager, not Azure Data Factory.
Read API calls 12,500/h 12,500/h

Monitoring queries per minute 1,000 1,000
Maximum time of data flow debug 8 hrs 8 hrs

session
Concurrent number of data flows per 50 Contact support.

integration runtime

integration runtime in managed vNet
Concurrent number of data flow 3 3

debug sessions per user per factory
Data Flow Azure IR TTL limit 4 hrs 4 hrs
Meta Data Entity Size limit in a factory 2 GB Contact support.
1 The data integration unit (DIU) is used in a cloud-to-cloud copy operation, learn more from Data integration
units (version 2). For information on billing, see Azure Data Factory pricing.
2 Azure Integration Runtime is globally available to ensure data compliance, efficiency, and reduced network
egress costs.
REGIO N GRO UP REGIO N S
Region group 1 Central US, East US, East US 2, North Europe, West Europe,
West US, West US 2
Region group 2 Australia East, Australia Southeast, Brazil South, Central

India, Japan East, North Central US, South Central US,
Southeast Asia, West Central US
Region group 3 Other regions
If managed virtual network is enabled, the data integration unit (DIU) in all region groups are 2,400.
3 Pipeline, data set, and linked service objects represent a logical grouping of your
workload. Limits for these
objects don't relate to the amount of data you can move and process with Azure Data Factory. Data Factory is
designed to scale to handle petabytes of data.
4 The payload for each activity run includes the activity configuration, the associated dataset(s) and linked
service(s) configurations if any, and a small portion of system properties generated per activity type. Limit for
this payload size doesn't relate to the amount of data you can move and process with Azure Data Factory. Learn
about the symptoms and recommendation if you hit this limit.
Version 1
Pipelines within a data factory 2,500 Contact support.
Data sets within a data factory 5,000 Contact support.
Concurrent slices per data set 10 10
Bytes per object for data set and 100 KB 2,000 KB

linked service objects1
Azure HDInsight on-demand cluster 60 Contact support.

cores within a subscription2
Cloud data movement units per copy 32 32

activity run3
Retry count for pipeline activity runs 1,000 MaxInt (32 bit)
2 On-demand HDInsight cores are allocated out of the subscription that contains the data factory. As a result, the
previous limit is the Data Factory-enforced core limit for on-demand HDInsight cores. It's different from the core
limit that's associated with your Azure subscription.
3 The cloud data movement unit (DMU) for version 1 is used in a cloud-to-cloud copy operation, learn more
from Cloud data movement units (version 1). For information on billing, see Azure Data Factory pricing.
RESO URC E DEFA ULT LO W ER L IM IT M IN IM UM L IM IT
Scheduling interval 15 minutes 15 minutes
Interval between retry attempts 1 second 1 second
Retry timeout value 1 second 1 second
Web service call limits

Azure Resource Manager has limits for API calls. You can make API calls at a rate within the Azure Resource
Manager API limits.
Azure NetApp Files

Azure NetApp Files has a regional limit for capacity. The standard capacity limit for each subscription is 25 TiB,
per region, across all service levels. To increase the capacity, use the Service and subscription limits (quotas)
support request.
To learn more about the limits for Azure NetApp Files, see Resource limits for Azure NetApp Files.
Azure Policy limits
There's a maximum count for each object type for Azure Policy. For definitions, an entry of Scope means the
management group or subscription. For assignments and exemptions, an entry of Scope means the
management group, subscription, resource group, or individual resource.
W H ERE W H AT M A XIM UM C O UN T
Scope Policy definitions 500
Scope Initiative definitions 200
Tenant Initiative definitions 2,500
Scope Policy or initiative assignments 200
Scope Exemptions 1000
Policy definition Parameters 20
Initiative definition Policies 1000
Initiative definition Parameters 300
Policy or initiative assignments Exclusions (notScopes) 400
Policy rule Nested conditionals 512
Remediation task Resources 50,000
Policy definition, initiative, or Bytes 1,048,576

assignment request body
Policy rules have additional limits to the number of conditions and their complexity. See Policy rule limits for
more details.
Azure Quantum limits

Provider Limits & Quota
The Azure Quantum Service supports both first and third-party service providers. Third-party providers own
their limits and quotas. Users can view offers and limits in the Azure portal when configuring third-party
providers.
You can find the published quota limits for Microsoft's first party Optimization Solutions provider below.
Learn & Develop SKU
RESO URC E L IM IT
CPU-based concurrent jobs up to 51 concurrent jobs
FPGA-based concurrent jobs up to 21 concurrent jobs
CPU-based solver hours 20 hours per month

RESO URC E L IM IT
FPGA-based solver hours 1 hour per month
While on the Learn & Develop SKU, you cannot request an increase on your quota limits. Instead you should
switch to the Performance at Scale SKU.
Performance at Scale SKU
CPU-based concurrent jobs up to 1001 concurrent jobs same as default limit
FPGA-based concurrent jobs up to 101 concurrent jobs same as default limit
Solver hours 1,000 hours per month up to 50,000 hours per month
Reach out to Azure Support to request a limit increase.

For more information, please review the Azure Quantum pricing page. Review the relevant provider pricing
pages in the Azure portal for details on third-party offerings.
1 Describes the number of jobs that can be queued at the same time.
Azure RBAC limits

The following limits apply to Azure role-based access control (Azure RBAC).
RESO URC E L IM IT
Azure role assignments per Azure subscription 2,000

The role assignments limit for a subscription is currently
being increased. For more information, see Troubleshoot
Azure RBAC.
Azure role assignments per management group 500
Size of description for Azure role assignments 2 KB
Size of condition for Azure role assignments 8 KB
Azure custom roles per tenant 5,000
Azure custom roles per tenant 2,000

(for Azure Germany and Azure China 21Vianet)
Azure SignalR Service limits

Azure SignalR Service units per 1 1

instance for Free tier

instance for Standard tier

subscription per region for Free tier
Total Azure SignalR Service unit counts 150 Unlimited

per subscription per region
Concurrent connections per unit for 20 20

Free tier
Concurrent connections per unit for 1,000 1,000

Standard tier
Included messages per unit per day for 20,000 20,000

Free tier
Additional messages per unit per day 0 0

for Free tier
Included messages per unit per day for 1,000,000 1,000,000

Standard tier
Additional messages per unit per day Unlimited Unlimited

for Standard tier
To request an update to your subscription's default limits, open a support ticket.

For more information about how connections and messages are counted, see Messages and connections in
Azure SignalR Service.
If your requirements exceed the limits, switch from Free tier to Standard tier and add units. For more
information, see How to scale an Azure SignalR Service instance?.
If your requirements exceed the limits of a single instance, add instances. For more information, see How to
scale SignalR Service with multiple instances?.
Azure Virtual Desktop Service limits

The following table describes the maximum limits for Azure Virtual Desktop.
A Z URE VIRT UA L DESK TO P O B JEC T PA REN T C O N TA IN ER O B JEC T SERVIC E L IM IT
Workspace Azure Active Directory Tenant 1300
HostPool Workspace 400
Application group HostPool 5001
RemoteApp Application group 500
Role Assignment Any Azure Virtual Desktop Object 200
Session Host HostPool 10,000
1If you require over 500 Application groups then please raise a support ticket via the Azure portal.
All other Azure resources used in Azure Virtual Desktop such as Virtual Machines, Storage, Networking etc. are
all subject to their own resource limitations documented in the relevant sections of this article.
To get started with Azure Virtual Desktop, use the getting started guide. For deeper architectural content for
Azure Virtual Desktop, use the Azure Virtual Desktop section of the Cloud Adoption Framework. For pricing
information for Azure Virtual Desktop, add "Azure Virtual Desktop" within the Compute section of the Azure
Pricing Calculator.
Azure VMware Solution limits

The following table describes the maximum limits for Azure VMware Solution.
RESO URC E L IM IT
Clusters per private cloud 12
Minimum number of hosts per cluster 3
Maximum number of hosts per cluster 16
hosts per private cloud 96
vCenter per private cloud 1
HCX site pairings 25 (any edition)
Azure VMware Solution ExpressRoute max linked private 4

clouds The virtual network gateway used determines the actual max
linked private clouds. For more details, see About
ExpressRoute virtual network gateways
Azure VMware Solution ExpressRoute port speed 10 Gbps

The virtual network gateway used determines the actual
bandwidth. For more details, see About ExpressRoute virtual
network gateways
Public IPs exposed via vWAN 100
vSAN capacity limits 75% of total usable (keep 25% available for SLA)
For other VMware-specific limits, use the VMware configuration maximum tool!.
Backup limits
For a summary of Azure Backup support settings and limitations, see Azure Backup Support Matrices.
Batch limits
Azure Batch accounts per region per 1-3 50

subscription
Dedicated cores per Batch account 90-900 Contact support

Low-priority cores per Batch account 10-100 Contact support
Active jobs and job schedules per 100-300 1,0001

Batch account (completed jobs have
no limit)
Pools per Batch account 20-100 5001
1To request an increase beyond this limit, contact Azure Support.
NOTE
Default limits vary depending on the type of subscription you use to create a Batch account. Cores quotas shown are for
Batch accounts in Batch service mode. View the quotas in your Batch account.
IMPORTANT
To help us better manage capacity during the global health pandemic, the default core quotas for new Batch accounts in
some regions and for some types of subscription have been reduced from the above range of values, in some cases to
zero cores. When you create a new Batch account, check your core quota and request a core quota increase, if required.
Alternatively, consider reusing Batch accounts that already have sufficient quota.
Classic deployment model limits

If you use classic deployment model instead of the Azure Resource Manager deployment model, the following
limits apply.
vCPUs per subscription1 20 10,000
Coadministrators per subscription 200 200
Storage accounts per subscription2 100 100
Cloud services per subscription 20 200
Local networks per subscription 10 500
DNS servers per subscription 9 100
Reserved IPs per subscription 20 100
Affinity groups per subscription 256 256
Subscription name length (characters) 64 64
1Extra small instances count as one vCPU toward the vCPU limit despite using a partial CPU core.
2The storage account limit includes both Standard and Premium storage accounts.
Container Instances limits
RESO URC E L IM IT
Standard sku container groups per region per subscription 1001
Dedicated sku container groups per region per subscription 01
Number of containers per container group 60
Number of volumes per container group 20
Standard sku cores (CPUs) per region per subscription 101,2
Standard sku cores (CPUs) for K80 GPU per region per 181,2
subscription
Standard sku cores (CPUs) for P100 or V100 GPU per region 01,2
per subscription
Ports per IP 5
Container instance log size - running instance 4 MB
Container instance log size - stopped instance 16 KB or 1,000 lines
Container group creates per hour 3001
Container group creates per 5 minutes 1001
Container group deletes per hour 3001
Container group deletes per 5 minutes 1001
1To request a limit increase, create an Azure Support request. Free subscriptions including Azure Free Account
and Azure for Students aren't eligible for limit or quota increases. If you have a free subscription, you can
upgrade to a Pay-As-You-Go subscription.
2Default limit for Pay-As-You-Go subscription. Limit may differ for other category types.
Container Registry limits

The following table details the features and limits of the Basic, Standard, and Premium service tiers.
RESO URC E B A SIC STA N DA RD P REM IUM
Included storage1 (GiB) 10 100 500
Storage limit (TiB) 20 20 20
Maximum image layer size 200 200 200

(GiB)
RESO URC E B A SIC STA N DA RD P REM IUM
Maximum manifest size 4 4 4

(MiB)
ReadOps per minute2, 3 1,000 3,000 10,000
WriteOps per minute2, 4 100 500 2,000
Download bandwidth2 30 60 100

(Mbps)
Upload bandwidth 2 (Mbps) 10 20 50
Webhooks 2 10 500
Geo-replication N/A N/A Supported
Availability zones N/A N/A Preview
Content trust N/A N/A Supported
Private link with private N/A N/A Supported

endpoints
• Private endpoints N/A N/A 200
Public IP network rules N/A N/A 100
Service endpoint VNet N/A N/A Preview

access
• Virtual network rules N/A N/A 100
Customer-managed keys N/A N/A Supported
Repository-scoped N/A N/A Preview

permissions
• Tokens N/A N/A 20,000
• Scope maps N/A N/A 20,000
• Repositories per scope N/A N/A 500

map
1 Storage included in the daily rate for each tier. Additional storage may be used, up to the registry storage limit,
at an additional daily rate per GiB. For rate information, see Azure Container Registry pricing. If you need
storage beyond the registry storage limit, please contact Azure Support.
2ReadOps, WriteOps, and Bandwidth are minimum estimates. Azure Container Registry strives to improve
performance as usage requires.
3A docker pull translates to multiple read operations based on the number of layers in the image, plus the
manifest retrieval.
4A docker push translates to multiple write operations, based on the number of layers that must be pushed. A
docker push includes ReadOps to retrieve a manifest for an existing image.
Content Delivery Network limits

RESO URC E L IM IT
Azure Content Delivery Network profiles 25
Content Delivery Network endpoints per profile 25
Custom domains per endpoint 25
Maximum origin group per profile 10
Maximum origin per origin group 10
Maximum number of rules per CDN endpoint 25
Maximum number of match conditions per rule 10
Maximum number of actions per rule 5
A Content Delivery Network subscription can contain one or more Content Delivery Network profiles. A Content
Delivery Network profile can contain one or more Content Delivery Network endpoints. You might want to use
multiple profiles to organize your Content Delivery Network endpoints by internet domain, web application, or
some other criteria.
Data Lake Analytics limits

Azure Data Lake Analytics makes the complex task of managing distributed infrastructure and complex code
easy. It dynamically provisions resources, and you can use it to do analytics on exabytes of data. When the job
completes, it winds down resources automatically. You pay only for the processing power that was used. As you
increase or decrease the size of data stored or the amount of compute used, you don't have to rewrite code. To
raise the default limits for your subscription, contact support.
RESO URC E L IM IT C O M M EN T S
Maximum number of concurrent jobs 20
Maximum number of analytics units 250 Use any combination of up to a

(AUs) per account maximum of 250 AUs across 20 jobs.
To increase this limit, contact Microsoft
Support.
Maximum script size for job 3 MB

submission
Maximum number of Data Lake 5 To increase this limit, contact Microsoft

Analytics accounts per region per Support.
subscription
Data Factory limits
Azure Data Factory is a multitenant service that has the following default limits in place to make sure customer
subscriptions are protected from each other's workloads. To raise the limits up to the maximum for your
subscription, contact support.
Version 2

integration runtimes, within a data
factory

subscription
Concurrent pipeline runs per data 10,000 10,000

factory that's shared among all
pipelines in the factory

Runtime region
procedure, Web, and others. This limit does

Runtime region
hosted IR.

Runtime region
consumption per subscription per Region group 22 : 3,000 Region group 22 : 3,000
Azure Integration Runtime region Region group 32 : 1,500 Region group 32 : 1,500
support.


integration runtime
Maximum number of node that can be 4 Contact support

integration runtime

interval

runs

service objects3

run4

activity run



session

integration runtime


debug sessions per user per factory
Meta Data Entity Size limit in a factory 2 GB Contact support.
units (version 2). For information on billing, see Azure Data Factory pricing.
egress costs.
REGIO N GRO UP REGIO N S
Region group 1 Central US, East US, East US 2, North Europe, West Europe,
West US, West US 2
Region group 2 Australia East, Australia Southeast, Brazil South, Central

India, Japan East, North Central US, South Central US,
Southeast Asia, West Central US
Region group 3 Other regions
If managed virtual network is enabled, the data integration unit (DIU) in all region groups are 2,400.
this payload size doesn't relate to the amount of data you can move and process with Azure Data Factory. Learn
about the symptoms and recommendation if you hit this limit.
Version 1
Pipelines within a data factory 2,500 Contact support.
Data sets within a data factory 5,000 Contact support.
Concurrent slices per data set 10 10
Bytes per object for data set and 100 KB 2,000 KB

linked service objects1
Azure HDInsight on-demand cluster 60 Contact support.

cores within a subscription2
Cloud data movement units per copy 32 32

activity run3
Retry count for pipeline activity runs 1,000 MaxInt (32 bit)
2 On-demand HDInsight cores are allocated out of the subscription that contains the data factory. As a result, the
previous limit is the Data Factory-enforced core limit for on-demand HDInsight cores. It's different from the core
limit that's associated with your Azure subscription.
3 The cloud data movement unit (DMU) for version 1 is used in a cloud-to-cloud copy operation, learn more
from Cloud data movement units (version 1). For information on billing, see Azure Data Factory pricing.
RESO URC E DEFA ULT LO W ER L IM IT M IN IM UM L IM IT
Scheduling interval 15 minutes 15 minutes
Interval between retry attempts 1 second 1 second
Retry timeout value 1 second 1 second

Manager API limits.
Data Lake Storage limits

Azure Data Lake Storage Gen2 is not a dedicated service or storage account type. It is the latest release of
capabilities that are dedicated to big data analytics. These capabilities are available in a general-purpose v2 or
BlockBlobStorage storage account, and you can obtain them by enabling the Hierarchical namespace feature
of the account. For scale targets, see these articles.
Scale targets for Blob storage.
Scale targets for standard storage accounts.
Azure Data Lake Storage Gen1 is a dedicated service. It's an enterprise-wide hyper-scale repository for big
data analytic workloads. You can use Data Lake Storage Gen1 to capture data of any size, type, and ingestion
speed in one single place for operational and exploratory analytics. There's no limit to the amount of data you
can store in a Data Lake Storage Gen1 account.
Maximum number of Data Lake 10 To request an increase for this limit,

Storage Gen1 accounts, per contact support.
subscription, per region
Maximum number of access ACLs, per 32 This is a hard limit. Use groups to
file or folder manage access with fewer entries.
Maximum number of default ACLs, per 32 This is a hard limit. Use groups to
file or folder manage access with fewer entries.
Data Share limits

Azure Data Share enables organizations to simply and securely share data with their customers and partners.
RESO URC E L IM IT
Maximum number of Data Share resources per Azure 100

subscription
Maximum number of sent shares per Data Share resource 200
Maximum number of received shares per Data Share 100

resource
Maximum number of invitations per sent share 200
Maximum number of share subscriptions per sent share 200
Maximum number of datasets per share 200
Maximum number of snapshot schedules per share 1
Database Migration Service Limits

Azure Database Migration Service is a fully managed service designed to enable seamless migrations from
multiple database sources to Azure data platforms with minimal downtime.
Maximum number of services per 10 To request an increase for this limit,

subscription, per region contact support.
Device Update for IoT Hub limits

NOTE
When a given resource or operation doesn't have adjustable limits, the default and the maximum limits are the same.
When the limit can be adjusted, the table includes different values for Default limit and Maximum limit headers. The limit
can be raised above the default limit but not above the maximum limit. If you want to raise the limit or quota above the
default limit, open an online customer support request.
This table provides the limits for the Device Update for IoT Hub resource in Azure Resource Manager:
RESO URC E DEFA ULT L IM IT M A XIM UM L IM IT A DJUSTA B L E?
Accounts per subscription 2 25 Yes
Instances per account 2 25 Yes
Length of account name Minimum: 3 Minimum: 3 No

Maximum: 24 Maximum: 24
Length of instance name Minimum: 3 Minimum: 3 No

Maximum: 36 Maximum: 36
This table provides the various limits associated with the operations within Device Update for IoT Hub:
O P ERAT IO N DEFA ULT L IM IT M A XIM UM L IM IT A DJUSTA B L E?
Number of devices per 10,000 10,000 No

instance
Number of update 25 25 No
providers per instance
Number of update names 25 25 No

per provider per instance
Number of update versions 100 100 No

per update provider and
name per instance
Total number of updates 100 100 No

per instance
Maximum single update file 2 GB 2 GB No

size
Maximum combined size of 2 GB 2 GB No

all files in a single import
action
Number of device groups 75 75 No

per instance
Digital Twins limits

NOTE
Some areas of this service have adjustable limits, and others do not. This is represented in the tables below with the
Adjustable? column. When the limit can be adjusted, the Adjustable? value is Yes.
Functional limits
The following table lists the functional limits of Azure Digital Twins.
TIP
For modeling recommendations to operate within these functional limits, see Modeling best practices.
A REA C A PA B IL IT Y DEFA ULT L IM IT A DJUSTA B L E?
Azure resource Number of Azure Digital 10 Yes

Twins instances in a region,
per subscription
Digital twins Number of twins in an 1,000,000 Yes

Azure Digital Twins instance
Digital twins Number of incoming 5,000 No

relationships to a single
twin
Digital twins Number of outgoing 5,000 No

relationships from a single
twin
Digital twins Maximum size (of JSON 32 KB No

body in a PUT or PATCH
request) of a single twin
Digital twins Maximum request payload 32 KB No

size
Digital twins Maximum size of a string 4 KB No

property value (UTF-8)
Digital twins Maximum size of a propery 1 KB No

name
Routing Number of endpoints for a 6 No

single Azure Digital Twins
instance
Routing Number of routes for a 6 Yes

instance
Models Number of models within a 10,000 Yes

instance
Models Number of models that can 250 No

be uploaded in a single API
call
Models Maximum size (of JSON 1 MB No

body in a PUT or PATCH
request) of a single model
Models Number of items returned 100 No

in a single page
A REA C A PA B IL IT Y DEFA ULT L IM IT A DJUSTA B L E?
Query Number of items returned 100 Yes

in a single page
Query Number of AND / OR 50 Yes

expressions in a query
Query Number of array items in an 50 Yes

IN / NOT IN clause
Query Number of characters in a 8,000 Yes

query
Query Number of JOINS in a 5 Yes

query
Rate limits
The following table reflects the rate limits of different APIs.
API C A PA B IL IT Y DEFA ULT L IM IT A DJUSTA B L E?
Models API Number of requests per 100 Yes

second
Digital Twins API Number of read requests 1,000 Yes

per second
Digital Twins API Number of patch requests 1,000 Yes

per second
Digital Twins API Number of create/delete 50 Yes

operations per second
across all twins and
relationships
Digital Twins API Number of 10 No

create/update/delete
operations per second on a
single twin or its
incoming/outgoing
relationships
Query API Number of requests per 500 Yes

second
Query API Query Units per second 4,000 Yes
Event Routes API Number of requests per 100 Yes

second
Other limits
Limits on data types and fields within DTDL documents for Azure Digital Twins models can be found within its
spec documentation in GitHub: Digital Twins Definition Language (DTDL) - version 2.
Query latency details are described in Query language. Limitations of particular query language features can be
found in the query reference documentation.
Event Grid limits

The following limits apply to Azure Event Grid topics (system, custom, and partner topics).
NOTE
These limits are per region.
RESO URC E L IM IT
Custom topics per Azure subscription 100
Event subscriptions per topic 500
Publish rate for a custom or a partner topic (ingress) 5,000 events/sec or 5 MB/sec (whichever is met first)
Event size 1 MB
Number of incoming events per batch 5,000
Private endpoint connections per topic 64
IP Firewall rules per topic 16
The following limits apply to Azure Event Grid domains .
RESO URC E L IM IT
Topics per event domain 100,000
Event subscriptions per topic within a domain 500
Domain scope event subscriptions 50
Publish rate for an event domain (ingress) 5,000 events/sec or 5 MB/sec (whichever is met first)
Event Domains per Azure Subscription 100
Private endpoint connections per domain 64
IP Firewall rules per domain 16
Event Hubs limits

The following tables provide quotas and limits specific to Azure Event Hubs. For information about Event Hubs
pricing, see Event Hubs pricing.
Common limits for all tiers
The following limits are common across all tiers.
L IM IT N OT ES VA L UE
Size of an event hub name - 256 characters
Size of a consumer group name Kafka protocol doesn't require the Kafka: 256 characters
creation of a consumer group.
AMQP: 50 characters
Number of non-epoch receivers per - 5

consumer group
Number of authorization rules per Subsequent requests for authorization 12

namespace rule creation are rejected.
Number of calls to the - 50 per second

GetRuntimeInformation method
Number of virtual networks (VNet) - 128
Number of IP Config rules - 128
Maximum length of a schema group 50

name
Maximum length of a schema name 100
Size in bytes per schema 1 MB
Number of properties per schema 1024

group
Size in bytes per schema group 256

property key
Size in bytes per schema group 1024

property value
Basic vs. standard vs. premium vs. dedicated tiers

The following table shows limits that may be different for basic, standard, premium, and dedicated tiers.
NOTE
In the table, CU is capacity unit, PU is processing unit, and TU is throughput unit.
You can configure TUs for a basic or standard tier namespace or PUs for a premium tier namespace.
When you create a dedicated cluster, 1 CU is assigned to the cluster. To have more CUs for the cluster, submit a ticket.
L IM IT B A SIC STA N DA RD P REM IUM DEDIC AT ED
Maximum size of 256 KB 1 MB 1 MB 1 MB

Event Hubs
publication
Number of consumer 1 20 100 1000

groups per event No limit per CU
hub
Number of brokered 100 5,000 10000 per PU 100, 000 per CU

connections per
namespace For example, if the
namespace is
assigned 3 PUs, the
limit is 30000.
Maximum retention 1 day 7 days 90 days 90 days

period of event data
Maximum TUs or 40 TUs 40 TUs 16 PUs 20 CUs

PUs or CUs
Number of partitions 32 32 100 per event hub, 1024 per event hub
per event hub but there is a limit of 2000 per CU
200 per PU at the
namespace level.
For example, if a
namespace is
assigned 2 PUs, the
limit for total number
of partitions in all
event hubs in the
namespace is 2 * 200
= 400.
Number of 1000 1000 1000 1000 (50 per CU)

namespaces per
subscription
Number of event 10 10 100 per PU 1000

hubs per namespace
Capture N/A Pay per hour Included Included
Size of the schema N/A 25 100 1024

registry (namespace)
in mega bytes
Number of schema N/A 1 - excluding the 100 1000

groups in a schema default group 1 MB per schema 1 MB per schema
registry or
namespace
Number of schema N/A 25 1000 10000

versions across all
schema groups
Throughput per unit Ingress - 1 MB/s or Ingress - 1 MB/s or No limits per PU * No limits per CU *
1000 events per 1000 events per
second second
Egress – 2 MB/s or Egress – 2 MB/s or
4096 events per 4096 events per
second second
* Depends on various factors such as resource allocation, number of partitions, storage, and so on.
NOTE
You can publish events individually or batched. The publication limit (according to SKU) applies regardless of whether it is
a single event or a batch. Publishing events larger than the maximum threshold will be rejected.
IoT Central limits

IoT Central limits the number of applications you can deploy in a subscription to 10. If you need to increase this
limit, contact Microsoft support.
IoT Hub limits

The following table lists the limits associated with the different service tiers S1, S2, S3, and F1. For information
about the cost of each unit in each tier, see Azure IoT Hub pricing.
RESO URC E S1 STA N DA RD S2 STA N DA RD S3 STA N DA RD F 1 F REE
Messages/day 400,000 6,000,000 300,000,000 8,000
Maximum units 200 200 10 1
NOTE
If you anticipate using more than 200 units with an S1 or S2 tier hub or 10 units with an S3 tier hub, contact Microsoft
Support.
The following table lists the limits that apply to IoT Hub resources.
RESO URC E L IM IT
Maximum paid IoT hubs per Azure subscription 50
Maximum free IoT hubs per Azure subscription 1
Maximum number of characters in a device ID 128
Maximum number of device identities 1,000

returned in a single call
IoT Hub message maximum retention for device-to-cloud 7 days

messages
RESO URC E L IM IT
Maximum size of device-to-cloud message 256 KB
Maximum size of device-to-cloud batch AMQP and HTTP: 256 KB for the entire batch
MQTT: 256 KB for each message
Maximum messages in device-to-cloud batch 500
Maximum size of cloud-to-device message 64 KB
Maximum TTL for cloud-to-device messages 2 days
Maximum delivery count for cloud-to-device 100

messages
Maximum cloud-to-device queue depth per device 50
Maximum delivery count for feedback messages 100

in response to a cloud-to-device message
Maximum TTL for feedback messages in 2 days

response to a cloud-to-device message
Maximum size of device twin 8 KB for tags section, and 32 KB for desired and reported
properties sections each
Maximum length of device twin string key 1 KB
Maximum length of device twin string value 4 KB
Maximum depth of object in device twin 10
Maximum size of direct method payload 128 KB
Job history maximum retention 30 days
Maximum concurrent jobs 10 (for S3), 5 for (S2), 1 (for S1)
Maximum additional endpoints (beyond built-in endpoints) 10 (for S1, S2, and S3)
Maximum message routing rules 100 (for S1, S2, and S3)
Maximum number of concurrently connected device streams 50 (for S1, S2, S3, and F1 only)
Maximum device stream data transfer 300 MB per day (for S1, S2, S3, and F1 only)
NOTE
If you need more than 50 paid IoT hubs in an Azure subscription, contact Microsoft Support.
NOTE
Currently, the total number of devices plus modules that can be registered to a single IoT hub is capped at 1,000,000. If
you want to increase this limit, contact Microsoft Support.
IoT Hub throttles requests when the following quotas are exceeded.
T H ROT T L E P ER- H UB VA L UE
Identity registry operations 83.33/sec/unit (5,000/min/unit) (for S3).

(create, retrieve, list, update, and delete), 1.67/sec/unit (100/min/unit) (for S1 and S2).
individual or bulk import/export
Device connections 6,000/sec/unit (for S3), 120/sec/unit (for S2), 12/sec/unit (for
S1).
Minimum of 100/sec.
Device-to-cloud sends 6,000/sec/unit (for S3), 120/sec/unit (for S2), 12/sec/unit (for
S1).
Minimum of 100/sec.
Cloud-to-device sends 83.33/sec/unit (5,000/min/unit) (for S3), 1.67/sec/unit

(100/min/unit) (for S1 and S2).
Cloud-to-device receives 833.33/sec/unit (50,000/min/unit) (for S3), 16.67/sec/unit

(1,000/min/unit) (for S1 and S2).
File upload operations 83.33 file upload initiations/sec/unit (5,000/min/unit) (for

S3), 1.67 file upload initiations/sec/unit (100/min/unit) (for
S1 and S2).
10 concurrent file uploads per device.
Direct methods 24 MB/sec/unit (for S3), 480 KB/sec/unit (for S2), 160
KB/sec/unit (for S1).
Based on 8-KB throttling meter size.
Device twin reads 500/sec/unit (for S3), Maximum of 100/sec or 10/sec/unit

(for S2), 100/sec (for S1)
Device twin updates 250/sec/unit (for S3), Maximum of 50/sec or 5/sec/unit (for
S2), 50/sec (for S1)
Jobs operations 83.33/sec/unit (5,000/min/unit) (for S3), 1.67/sec/unit

(create, update, list, and delete) (100/min/unit) (for S2), 1.67/sec/unit (100/min/unit) (for S1).
Jobs per-device operation throughput 50/sec/unit (for S3), maximum of 10/sec or 1/sec/unit (for
S2), 10/sec (for S1).
Device stream initiation rate 5 new streams/sec (for S1, S2, S3, and F1 only).
IoT Hub Device Provisioning Service limits

NOTE
Some areas of this service have adjustable limits. This is represented in the tables below with the Adjustable? column.
When the limit can be adjusted, the Adjustable? value is Yes.
The actual value to which a limit can be adjusted may vary based on each customer’s deployment. Multiple instances of
DPS may be required for very large deployments.
If your business requires raising an adjustable limit or quota above the default limit, you can submit a request for
additional resources by opening a support ticket. Requesting an increase does not guarantee that it will be
granted, as it needs to be reviewed on a case-by-case basis. Please contact Microsoft suppor t as early as
possible during your implementation, to be able to determine if your request could be approved and
plan accordingly.
The following table lists the limits that apply to Azure IoT Hub Device Provisioning Service resources.
RESO URC E L IM IT A DJUSTA B L E?
Maximum device provisioning services 10 Yes

per Azure subscription
Maximum number of registrations 1,000,000 Yes
Maximum number of individual 1,000,000 Yes

enrollments
Maximum number of enrollment 100 Yes

groups (X.509 certificate)
Maximum number of enrollment 100 No

groups (symmetric key)
Maximum number of CAs 25 No
Maximum number of linked IoT hubs 50 No
Maximum size of message 96 KB No
TIP
If the hard limit on symmetric key enrollment groups is a blocking issue, it is recommended to use individual enrollments
as a workaround.
The Device Provisioning Service has the following rate limits.
RAT E P ER- UN IT VA L UE A DJUSTA B L E?
Operations 200/min/service Yes
Device registrations 200/min/service Yes
Device polling operation 5/10 sec/device No

Key Vault limits
Azure Key Vault service supports two resource types: Vaults and Managed HSMs. The following two sections
describe the service limits for each of them respectively.
Resource type: vault
This section describes service limits for resource type vaults .
Key transactions (maximum transactions allowed in 10 seconds, per vault per region 1):
H SM K EY SO F T WA RE K EY
H SM K EY A L L OT H ER SO F T WA RE K EY A L L OT H ER
K EY T Y P E C REAT E K EY T RA N SA C T IO N S C REAT E K EY T RA N SA C T IO N S
RSA 2,048-bit 10 2,000 20 4,000
RSA 3,072-bit 10 500 20 1,000
RSA 4,096-bit 10 250 20 500
ECC P-256 10 2,000 20 4,000
ECC P-384 10 2,000 20 4,000
ECC P-521 10 2,000 20 4,000
ECC SECP256K1 10 2,000 20 4,000
NOTE
In the previous table, we see that for RSA 2,048-bit software keys, 4,000 GET transactions per 10 seconds are allowed. For
RSA 2,048-bit HSM-keys, 2,000 GET transactions per 10 seconds are allowed.
The throttling thresholds are weighted, and enforcement is on their sum. For example, as shown in the previous table,
when you perform GET operations on RSA HSM-keys, it's eight times more expensive to use 4,096-bit keys compared to
2,048-bit keys. That's because 2,000/250 = 8.
In a given 10-second interval, an Azure Key Vault client can do only one of the following operations before it encounters a
429 throttling HTTP status code:
4,000 RSA 2,048-bit software-key GET transactions

2,000 RSA 2,048-bit HSM-key GET transactions
250 RSA 4,096-bit HSM-key GET transactions
248 RSA 4,096-bit HSM-key GET transactions and 16 RSA 2,048-bit HSM-key GET transactions
Secrets, managed storage account keys, and vault transactions:
M A XIM UM T RA N SA C T IO N S A L LO W ED IN 10 SEC O N DS, P ER

T RA N SA C T IO N S T Y P E VA ULT P ER REGIO N 1
All transactions 4,000
For information on how to handle throttling when these limits are exceeded, see Azure Key Vault throttling
guidance.
1 A subscription-wide limit for all transaction types is five times per key vault limit. For example, HSM-other
transactions per subscription are limited to 10,000 transactions in 10 seconds per subscription.
Backup keys, secrets, certificates
When you back up a key vault object, such as a secret, key, or certificate, the backup operation will download the
object as an encrypted blob. This blob cannot be decrypted outside of Azure. To get usable data from this blob,
you must restore the blob into a key vault within the same Azure subscription and Azure geography
T RA N SA C T IO N S T Y P E M A XIM UM K EY VA ULT O B JEC T VERSIO N S A L LO W ED
Back up individual key, secret, certificate 500
NOTE
Attempting to backup a key, secret, or certificate object with more versions than above limit will result in an error. It is not
possible to delete previous versions of a key, secret, or certificate.
Limits on count of keys, secrets and certificates:

Key Vault does not restrict the number of keys, secrets or certificates that can be stored in a vault. The
transaction limits on the vault should be taken into account to ensure that operations are not throttled.
Key Vault does not restrict the number of versions on a secret, key or certificate, but storing a large number of
versions (500+) can impact the performance of backup operations. See Azure Key Vault Backup.
Azure Private Link integration
NOTE
The number of key vaults with private endpoints enabled per subscription is an adjustable limit. The limit shown below is
the default limit. If you would like to request a limit increase for your service, please create a support request and it will be
assessed on a case by case basis.
RESO URC E L IM IT
Private endpoints per key vault or managed HSM 64
Key vaults with private endpoints per subscription 400
Resource type: Managed HSM

This section describes service limits for resource type managed HSM .
Object limits
IT EM L IM IT S
Number of HSM instances per subscription per region 5
Number of keys per HSM instance 5000
Number of versions per key 100
Number of custom role definitions per HSM instance 50
Number of role assignments at HSM scope 50

IT EM L IM IT S
Number of role assignments at each individual key scope 10
Transaction limits for administrative operations (number of operations per second per HSM instance)
O P ERAT IO N N UM B ER O F O P ERAT IO N S P ER SEC O N D
All RBAC operations 5

(includes all CRUD operations for role definitions and role
assignments)
Full HSM Backup/Restore 1

(only one concurrent backup or restore operation per HSM
instance supported)
Transaction limits for cryptographic operations (number of operations per second per HSM instance)
Each Managed HSM instance constitutes three load balanced HSM partitions. The throughput limits are a
function of underlying hardware capacity allocated for each partition. The tables below show maximum
throughput with at least one partition available. Actual throughput may be up to 3x higher if all three
partitions are available.
Throughput limits noted assume that one single key is being used to achieve maximum throughput. For
example, if a single RSA-2048 key is used the maximum throughput will be 1100 sign operations. If you use
1100 different keys with one transaction per second each, they will not be able to achieve the same
throughput.
R SA k e y o p e r a t i o n s (n u m b e r o f o p e r a t i o n s p e r se c o n d p e r H SM i n st a n c e )
O P ERAT IO N 2048- B IT 3072- B IT 4096- B IT
Create Key 1 1 1
Delete Key (soft-delete) 10 10 10
Purge Key 10 10 10
Backup Key 10 10 10
Restore Key 10 10 10
Get Key Information 1100 1100 1100
Encrypt 10000 10000 6000
Decrypt 1100 360 160
Wrap 10000 10000 6000
Unwrap 1100 360 160
Sign 1100 360 160
Verify 10000 10000 6000

E C k e y o p e r a t i o n s (n u m b e r o f o p e r a t i o n s p e r se c o n d p e r H SM i n st a n c e )
This table describes number of operations per second for each curve type.
O P ERAT IO N P - 256 P - 256K P - 384 P - 521
Create Key 1 1 1 1
Delete Key (soft- 10 10 10 10

delete)
Purge Key 10 10 10 10
Backup Key 10 10 10 10
Restore Key 10 10 10 10
Get Key Information 1100 1100 1100 1100
Sign 260 260 165 56
Verify 130 130 82 28
A E S k e y o p e r a t i o n s (n u m b e r o f o p e r a t i o n s p e r se c o n d p e r H SM i n st a n c e )
Encrypt and Decrypt operations assume a 4KB packet size.

Throughput limits for Encrypt/Decrypt apply to AES-CBC and AES-GCM algorithms.
Throughput limits for Wrap/Unwrap apply to AES-KW algorithm.
Create Key 1 1 1
Delete Key (soft-delete) 10 10 10
Purge Key 10 10 10
Backup Key 10 10 10
Restore Key 10 10 10
Get Key Information 1100 1100 1100
Encrypt 8000 8000 8000
Decrypt 8000 8000 8000
Wrap 9000 9000 9000
Unwrap 9000 9000 9000

Managed identity limits
Each managed identity counts towards the object quota limit in an Azure AD tenant as described in Azure
AD service limits and restrictions.
The rate at which managed identities can be created have the following limits:
1. Per Azure AD Tenant per Azure region: 400 create operations per 20 seconds.
2. Per Azure Subscription per Azure region : 80 create operations per 20 seconds.
The rate at which a user-assigned managed identity can be assigned with an Azure resource :
1. Per Azure AD Tenant per Azure region: 400 assignment operations per 20 seconds.
2. Per Azure Subscription per Azure region : 300 assignment operations per 20 seconds.
Media Services limits

NOTE
For resources that aren't fixed, open a support ticket to ask for an increase in the quotas. Don't create additional Azure
Media Services accounts in an attempt to obtain higher limits.
Account limits
RESO URC E DEFA ULT L IM IT
Media Services accounts in a single subscription 100 (fixed)
Asset limits
Assets per Media Services account 1,000,000
Storage (media) limits

File size In some scenarios, there is a limit on the maximum file size
supported for processing in Media Services. (1)
Storage accounts 100(2) (fixed)
1 The maximum size supported for a single blob is currently up to 5 TB in Azure Blob Storage. Additional limits
apply in Media Services based on the VM sizes that are used by the service. The size limit applies to the files that
you upload and also the files that get generated as a result of Media Services processing (encoding or
analyzing). If your source file is larger than 260-GB, your Job will likely fail.
2 The storage accounts must be from the same Azure subscription.
Jobs (encoding & analyzing) limits
Jobs per Media Services account 500,000 (3) (fixed)

Job inputs per Job 50 (fixed)
Job outputs per Job 20 (fixed)
Transforms per Media Services account 100 (fixed)
Transform outputs in a Transform 20 (fixed)
Files per job input 10 (fixed)
3 This number includes queued, finished, active, and canceled Jobs. It does not include deleted Jobs.
Any Job record in your account older than 90 days will be automatically deleted, even if the total number of
records is below the maximum quota.
Live streaming limits
Live Events (4) per Media Services account 5
Live Outputs per Live Event 3 (5)
Max Live Output duration Size of the DVR window
4 For detailed information about Live Event limitations, see Live Event types comparison and limitations.
5 Live Outputs start on creation and stop when deleted.
Packaging & delivery limits

Streaming Endpoints (stopped or running) per Media 2

Services account
Dynamic Manifest Filters 100
Streaming Policies 100 (6)
Unique Streaming Locators associated with an Asset at one 100(7) (fixed)

time
6 When using a custom Streaming Policy, you should design a limited set of such policies for your Media Service
account, and re-use them for your StreamingLocators whenever the same encryption options and protocols are
needed. You should not be creating a new Streaming Policy for each Streaming Locator.
7 Streaming Locators are not designed for managing per-user access control. To give different access rights to
individual users, use Digital Rights Management (DRM) solutions.
Protection limits
Options per Content Key Policy 30
Licenses per month for each of the DRM types on Media 1,000,000
Services key delivery service per account
Support ticket
For resources that are not fixed, you may ask for the quotas to be raised, by opening a support ticket. Include
detailed information in the request on the desired quota changes, use-case scenarios, and regions required.
Do not create additional Azure Media Services accounts in an attempt to obtain higher limits.
Media Services v2 (legacy)
For limits specific to Media Services v2 (legacy), see Media Services v2 (legacy)
Mobile Services limits

T IER F REE B A SIC STA N DA RD
API calls 500,000 1.5 million per unit 15 million per unit
Active devices 500 Unlimited Unlimited
Scale N/A Up to 6 units Unlimited units
Push notifications Azure Notification Hubs Notification Hubs Basic tier Notification Hubs Standard
Free tier included, up to 1 included, up to 10 million tier included, up to 10
million pushes pushes million pushes
Real-time messaging/ Limited 350 per mobile service Unlimited

Web Sockets
Offline synchronizations Limited Included Included
Scheduled jobs Limited Included Included
Azure SQL Database 20 MB included 20 MB included 20 MB included

(required)
Standard rates apply for
additional capacity
CPU capacity 60 minutes per day Unlimited Unlimited
Outbound data transfer 165 MB per day (daily Included Included

rollover)
For more information on limits and pricing, see Azure Mobile Services pricing.
Multi-Factor Authentication limits

Maximum number of trusted IP 0 50

addresses or ranges per subscription
Remember my devices, number of 14 60

days
Maximum number of app passwords 0 No limit
Allow X attempts during MFA call 1 99
Two-way text message timeout 60 600

seconds
Default one-time bypass seconds 300 1,800
Lock user account after X consecutive Not set 99

MFA denials
Reset account lockout counter after X Not set 9,999

minutes
Unlock account after X minutes Not set 9,999
Networking limits
Networking limits - Azure Resource Manager
The following limits apply only for networking resources managed through Azure Resource Manager per
region per subscription. Learn how to view your current resource usage against your subscription limits.
NOTE
We recently increased all default limits to their maximum limits. If there's no maximum limit column, the resource doesn't
have adjustable limits. If you had these limits increased by support in the past and don't see updated limits in the
following tables, open an online customer support request at no charge
RESO URC E L IM IT
Virtual networks 1,000
Subnets per virtual network 3,000
Virtual network peerings per virtual network 500
Virtual network gateways (VPN gateways) per virtual 1

network
Virtual network gateways (ExpressRoute gateways) per 1

virtual network
DNS servers per virtual network 20

RESO URC E L IM IT
Private IP addresses per virtual network 65,536
Private IP addresses per network interface 256
Private IP addresses per virtual machine 256
Public IP addresses per network interface 256
Public IP addresses per virtual machine 256
Concurrent TCP or UDP flows per NIC of a virtual machine 500,000

or role instance
Network interface cards 65,536
Network Security Groups 5,000
NSG rules per NSG 1,000
IP addresses and ranges specified for source or destination 4,000

in a security group
Application security groups 3,000
Application security groups per IP configuration, per NIC 20
IP configurations per application security group 4,000
Application security groups that can be specified within all 100

security rules of a network security group
User-defined route tables 200
User-defined routes per route table 400
Point-to-site root certificates per Azure VPN Gateway 20
Point-to-site revoked client certificates per Azure VPN 300

Gateway
Virtual network TAPs 100
Network interface TAP configurations per virtual network 100

TAP
Public IP address limits
Public IP addresses1,2 10 for Basic. Contact support.
Static Public IP addresses1 10 for Basic. Contact support.

Standard Public IP addresses1 10 Contact support.
Public IP addresses per Resource 800 Contact support.

Group
Public IP Prefixes limited by number of Standard Public Contact support.

IPs in a subscription
Public IP prefix length /28 Contact support.
1Default limits for

Public IP addresses vary by offer category type, such as Free Trial, Pay-As-You-Go, CSP. For
example, the default for Enterprise Agreement subscriptions is 1000.
2Public IP addresses limit refers to the total amount of Public IP addresses, including Basic and Standard.
Load balancer limits

The following limits apply only for networking resources managed through Azure Resource Manager per region
per subscription. Learn how to view your current resource usage against your subscription limits.
Standard Load Balancer
RESO URC E L IM IT
Load balancers 1,000
Rules (Load Balancer + Inbound NAT) per resource 1,500
Rules per NIC (across all IPs on a NIC) 300
Frontend IP configurations 600
Backend pool size 1,000 IP configurations, single virtual network
Backend resources per Load Balancer 1 1,200
High-availability ports rule 1 per internal frontend
Outbound rules per Load Balancer 600
Load Balancers per VM 2 (1 Public and 1 internal)
1 The limit is up to 1,200

resources, in any combination of standalone virtual machine resources, availability set
resources, and virtual machine scale-set placement groups.
Basic Load Balancer
RESO URC E L IM IT
Load balancers 1,000
Rules per resource 250

RESO URC E L IM IT
Rules per NIC (across all IPs on a NIC) 300
Frontend IP configurations 2 200
Backend pool size 300 IP configurations, single availability set
Availability sets per Load Balancer 1
Load Balancers per VM 2 (1 Public and 1 internal)
2 The limit for

a single discrete resource in a backend pool (standalone virtual machine, availability set, or virtual
machine scale-set placement group) is to have up to 250 Frontend IP configurations across a single Basic Public
Load Balancer and Basic Internal Load Balancer.
The following limits apply only for networking resources managed through the classic deployment model per
subscription. Learn how to view your current resource usage against your subscription limits.
Virtual networks 100 100
Local network sites 20 50
DNS servers per virtual network 20 20
Private IP addresses per virtual 4,096 4,096

network
Concurrent TCP or UDP flows per NIC 500,000, up to 1,000,000 for two or 500,000, up to 1,000,000 for two or
of a virtual machine or role instance more NICs. more NICs.
Network Security Groups (NSGs) 200 200
NSG rules per NSG 200 1,000
User-defined route tables 200 200
User-defined routes per route table 400 400
Public IP addresses (dynamic) 500 500
Reserved public IP addresses 500 500
Public IP per deployment 5 Contact support
Private IP (internal load balancing) per 1 1

deployment
Endpoint access control lists (ACLs) 50 50
ExpressRoute limits
RESO URC E L IM IT
ExpressRoute circuits per subscription 50
ExpressRoute circuits per region per subscription, with Azure 10

Resource Manager
Maximum number of IPv4 routes advertised to Azure 4,000

private peering with ExpressRoute Standard
Maximum number of IPv4 routes advertised to Azure 10,000

private peering with ExpressRoute Premium add-on
Maximum number of IPv6 routes advertised to Azure 100

private peering with ExpressRoute Standard
Maximum number of IPv6 routes advertised to Azure 100

private peering with ExpressRoute Premium add-on
Maximum number of IPv4 routes advertised from Azure 1,000

private peering from the VNet address space for an
ExpressRoute connection
Maximum number of IPv6 routes advertised from Azure 1,000

private peering from the VNet address space for an
ExpressRoute connection
Maximum number of IPv4 routes advertised to Microsoft 200

peering with ExpressRoute Standard

peering with ExpressRoute Premium add-on

peering with ExpressRoute Standard

peering with ExpressRoute Premium add-on
Maximum number of ExpressRoute circuits linked to the 4

same virtual network in the same peering location
Maximum number of ExpressRoute circuits linked to the 16 (For more information, see Gateway SKU.)
same virtual network in different peering locations
Number of virtual network links allowed per ExpressRoute See the Number of virtual networks per ExpressRoute circuit
circuit table.
Number of virtual networks per ExpressRoute circuit
N UM B ER O F VIRT UA L N ET W O RK L IN K S N UM B ER O F VIRT UA L N ET W O RK L IN K S
C IRC UIT SIZ E F O R STA N DA RD W IT H P REM IUM A DD- O N
50 Mbps 10 20
100 Mbps 10 25
N UM B ER O F VIRT UA L N ET W O RK L IN K S N UM B ER O F VIRT UA L N ET W O RK L IN K S
C IRC UIT SIZ E F O R STA N DA RD W IT H P REM IUM A DD- O N
200 Mbps 10 25
500 Mbps 10 40
1 Gbps 10 50
2 Gbps 10 60
5 Gbps 10 75
10 Gbps 10 100
40 Gbps* 10 100
100 Gbps* 10 100
*100 Gbps ExpressRoute Direct Only
NOTE
Global Reach connections count against the limit of virtual network connections per ExpressRoute Circuit. For example, a
10 Gbps Premium Circuit would allow for 5 Global Reach connections and 95 connections to the ExpressRoute Gateways
or 95 Global Reach connections and 5 connections to the ExpressRoute Gateways or any other combination up to the
limit of 100 connections for the circuit.
Virtual Network Gateway limits

RESO URC E L IM IT
VNet Address Prefixes 600 per VPN gateway
Aggregate BGP routes 4,000 per VPN gateway
Local Network Gateway address prefixes 1000 per local network gateway
S2S connections Depends on the gateway SKU
P2S connections Depends on the gateway SKU
P2S route limit - IKEv2 256 for non-Windows / 25 for Windows
P2S route limit - OpenVPN 1000
Max. flows 100K for VpnGw1/AZ / 512K for VpnGw2-4/AZ
NAT Gateway limits

RESO URC E L IM IT
Public IP addresses 16 per NAT gateway

Virtual WAN limits
RESO URC E L IM IT
VPN (branch) connections per hub 1,000
Aggregate throughput per Virtual WAN Site-to-site VPN 20 Gbps

gateway
Throughput per Virtual WAN VPN connection (2 tunnels) 2 Gbps with 1 Gbps/IPsec tunnel
Point-to-Site users per hub 100,000
Aggregate throughput per Virtual WAN User VPN (Point-to- 200 Gbps
site) gateway
Aggregate throughput per Virtual WAN ExpressRoute 20 Gbps

gateway
ExpressRoute Circuit connections per hub 8
VNet connections per hub 500 minus total number of hubs in Virtual WAN
Aggregate throughput per Virtual WAN Hub Router 50 Gbps for VNet to VNet transit
VM workload across all VNets connected to a single Virtual 2000 (If you want to raise the limit or quota above the
WAN hub default limit, open an online customer support request.)
Application Gateway limits

The following table applies to v1, v2, Standard, and WAF SKUs unless otherwise stated.
RESO URC E L IM IT N OT E
Azure Application Gateway 1,000 per subscription
Front-end IP configurations 2 1 public and 1 private
Front-end ports 1001
Back-end address pools 1001
Back-end servers per pool 1,200
HTTP listeners 2001 Limited to 100 active listeners that are

routing traffic. Active listeners = total
number of listeners - listeners not
active.
If a default configuration inside a
routing rule is set to route traffic (for
example, it has a listener, a backend
pool, and HTTP settings) then that also
counts as a listener. See Frequently
asked questions about Application
Gateway for additional details.
HTTP load-balancing rules 4001
Back-end HTTP settings 1001
Instances per gateway V1 SKU - 32

V2 SKU - 125
SSL certificates 1001 1 per HTTP listener
Maximum SSL certificate size V1 SKU - 10 KB

V2 SKU - 16 KB
Authentication certificates 100
Trusted root certificates 100
Request timeout minimum 1 second
Request timeout maximum to private 24 hours

backend
Request timeout maximum to external 4 minutes

backend
Number of sites 1001 1 per HTTP listener
URL maps per listener 1
Maximum path-based rules per URL 100

map
Redirect configurations 1001
Number of rewrite rule sets 400
Number of Header or URL 40

configuration per rewrite rule set
Number of conditions per rewrite rule 40

set
Concurrent WebSocket connections Medium gateways 20k2

Large gateways 50k2
Maximum URL length 32KB
Maximum header size 32KB
Maximum header field size for HTTP/2 8KB
Maximum header size for HTTP/2 16KB

Maximum file upload size (Standard V2 - 4 GB

SKU) V1 - 2GB
Maximum file upload size (WAF SKU) V1 Medium - 100 MB

V1 Large - 500 MB
V2 - 750 MB
V2 (with CRS 3.2 or newer) - 4GB3
WAF body size limit (without files) V1 or V2 (with CRS 3.1 and older) -
128KB
V2 (with CRS 3.2 or newer) - 2MB3
Maximum WAF custom rules 100
Maximum WAF exclusions per 40

Application Gateway
1 In case of WAF-enabled SKUs, you must limit the number of resources to 40.
2 Limit is per Application Gateway instance not per Application Gateway resource.
3 Must define the value via WAF Policy for Application Gateway
Network Watcher limits
Azure Network Watcher 1 per region Network Watcher is created to enable

access to the service. Only one
instance of Network Watcher is
required per subscription per region.
Packet capture sessions 10,000 per region Number of sessions only, not saved
captures.
Private Link limits

The following limits apply to Azure private link:
RESO URC E L IM IT
Number of private endpoints per virtual network 1000
Number of private endpoints per subscription 64000
Number of private link services per subscription 800
Number of IP Configurations on a private link service 8 (This number is for the NAT IP addresses used per PLS)
Number of private endpoints on the same private link 1000

service
Number of subscriptions allowed in visibility setting on 100

private link service
RESO URC E L IM IT
Number of subscriptions allowed in auto-approval setting on 100

private link service
Number of private endpoints per key vault 64
Number of key vaults with private endpoints per 400

subscription
Number of private DNS zone groups that can be linked to a 1

private endpoint
Number of DNS zones in each group 5
Traffic Manager limits

RESO URC E L IM IT
Profiles per subscription 200
Endpoints per profile 200
Azure Bastion limits

W O RK LO A D T Y P E* SESSIO N L IM IT P ER IN STA N C E**
Light 50
Medium 25
Heavy 2
*These workload types are defined here: Remote Desktop workloads

**These limits are based on RDP performance tests for Azure Bastion. The numbers may vary due to other on-
going RDP sessions or other on-going SSH sessions.
Azure DNS limits
Public DNS zones
RESO URC E L IM IT
Public DNS Zones per subscription 250 1
Record sets per public DNS zone 10,000 1
Records per record set in public DNS zone 20
Number of Alias records for a single Azure resource 20
1If you need to increase these limits, contact Azure Support.
Private DNS zones

RESO URC E L IM IT
Private DNS zones per subscription 1000
Record sets per private DNS zone 25000
Records per record set for private DNS zones 20
Virtual Network Links per private DNS zone 1000
Virtual Networks Links per private DNS zones with auto- 100
registration enabled
Number of private DNS zones a virtual network can get 1

linked to with auto-registration enabled
Number of private DNS zones a virtual network can get 1000

linked
Number of DNS queries a virtual machine can send to Azure 1000 1

DNS resolver, per second
Maximum number of DNS queries queued (pending 200 1

response) per virtual machine
1These limits are applied to every individual virtual machine and not at the virtual network level. DNS queries
exceeding these limits are dropped.
Azure Firewall limits
RESO URC E L IM IT
Data throughput 30 Gbps
Rule limits 10,000 unique source/destinations in network and

application rules
Total size of rules within a single Rule Collection Group 2 Mb
Number of Rule Collection Groups in a Firewall Policy 50
Maximum DNAT rules 298 (for firewalls configured with a single Public IP address)
The DNAT limitation is due to the underlying platform. The

maximum number of DNAT rules is 298. However, any
additional public IP addresses reduce the number of the
available DNAT rules. For example, two public IP addresses
allow for 297 DNAT rules. If a rule's protocol is configured for
both TCP and UDP, it counts as two rules.
Minimum AzureFirewallSubnet size /26
Port range in network and application rules 1 - 65535

RESO URC E L IM IT
Public IP addresses 250 maximum. All public IP addresses can be used in DNAT
rules and they all contribute to available SNAT ports.
IP addresses in IP Groups Maximum of 100 IP Groups per firewall.

Maximum 5000 individual IP addresses or IP prefixes per
each IP Group.
Route table By default, AzureFirewallSubnet has a 0.0.0.0/0 route with

the NextHopType value set to Internet .
Azure Firewall must have direct Internet connectivity. If your

AzureFirewallSubnet learns a default route to your on-
premises network via BGP, you must override that with a
0.0.0.0/0 UDR with the NextHopType value set as
Internet to maintain direct Internet connectivity. By default,
Azure Firewall doesn't support forced tunneling to an on-
premises network.
However, if your configuration requires forced tunneling to

an on-premises network, Microsoft will support it on a case
by case basis. Contact Support so that we can review your
case. If accepted, we'll allow your subscription and ensure the
required firewall Internet connectivity is maintained.
FQDNs in network rules For good performance, do not exceed more than 1000
FQDNs across all network rules per firewall.
Azure Front Door Service limits

In addition to the limits below, there is a composite limit on the number of routing rules, front-end domains,
protocols, and paths.
RESO URC E L IM IT
Azure Front Door resources per subscription 100
Front-end hosts, which includes custom domains per 500

resource
Routing rules per resource 500
Back-end pools per resource 50
Back ends per back-end pool 100
Path patterns to match for a routing rule 25
URLs in a single cache purge call 100
Custom web application firewall rules per policy 100
Web application firewall policy per subscription 100
Web application firewall match conditions per custom rule 10

RESO URC E L IM IT
Web application firewall IP address ranges per custom rule 600
Web application firewall string match values per match 10

condition
Web application firewall string match value length 256
Web application firewall POST body parameter name length 256
Web application firewall HTTP header name length 256
Web application firewall cookie name length 256
Web application firewall exclusion limit 100
Web application firewall HTTP request body size inspected 128 KB
Web application firewall custom response body length 32 KB
Azure Front Door Standard/Premium (Preview) Service Limits

Maximum 500 total Standard and Premium profiles per subscription.
In addition to the limits below, there is a composite limit on the number of routes, domains, protocols, and
paths.
RESO URC E STA N DA RD SK U L IM IT P REM IUM SK U L IM IT
Maximum endpoint per profile 10 25
Maximum custom domain per profile 100 200
Maximum origin group per profile 100 200
Maximum secrets per profile 100 200
Maximum security policy per profile 100 200
Maximum rule set per profile 100 200
Maximum rules per rule set 100 100
Maximum origin per origin group 50 50
Maximum routes per endpoint 100 200
URLs in a single cache purge call 100 100
Custom web application firewall rules 100 100

per policy
RESO URC E STA N DA RD SK U L IM IT P REM IUM SK U L IM IT
Web application firewall match 10 10

conditions per custom rule
Web application firewall IP address 600 600

ranges per custom rule
Web application firewall string match 10 10

values per match condition
Web application firewall string match 256 256

value length
Web application firewall POST body 256 256

parameter name length
Web application firewall HTTP header 256 256

name length
Web application firewall cookie name 256 256

length
Web application firewall HTTP request 128 KB 128 KB

body size inspected
Web application firewall custom 32 KB 32 KB

response body length
Timeout values
Cl i en t t o Fr o n t Do o r
Front Door has an idle TCP connection timeout of 61 seconds.

F r o n t D o o r t o a p p l i c a t i o n b a c k- e n d
If the response is a chunked response, a 200 is returned if or when the first chunk is received.
After the HTTP request is forwarded to the back end, Front Door waits for 30 seconds for the first packet
from the back end. Then it returns a 503 error to the client. This value is configurable via the field
sendRecvTimeoutSeconds in the API.
If a request is cached and it takes more than 30 seconds for the first packet from Front Door or from
the backend, then a 504 error is returned to the client.
After the first packet is received from the back end, Front Door waits for 30 seconds in an idle timeout. Then
it returns a 503 error to the client. This timeout value is not configurable.
Front Door to the back-end TCP session timeout is 90 seconds.
Upload and download data limit
W IT H C H UN K ED T RA N SF ER
EN C O DIN G ( C T E) W IT H O UT H T T P C H UN K IN G
Download There's no limit on the download size. There's no limit on the download size.
Upload There's no limit as long as each CTE The size can't be larger than 2 GB.
upload is less than 2 GB.
Other limits
Maximum URL size - 8,192 bytes - Specifies maximum length of the raw URL (scheme + hostname + port +
path + query string of the URL)
Maximum Query String size - 4,096 bytes - Specifies the maximum length of the query string, in bytes.
Maximum HTTP response header size from health probe URL - 4,096 bytes - Specified the maximum length
of all the response headers of health probes.
Maximum rules engine action header value character: 640 characters.
Maximum rules engine condition header value character: 256 characters.
Maximum ETag header size: 128 bytes
For more information about limits that apply to Rules Engine configurations, see Rules Engine terminology
Notification Hubs limits

T IER F REE B A SIC STA N DA RD
Included pushes 1 million 10 million 10 million
Active devices 500 200,000 10 million
Tag quota per installation or 60 60 60

registration
For more information on limits and pricing, see Notification Hubs pricing.
Azure Purview limits

The latest values for Azure Purview quotas can be found in the Azure Purview quota page.
Service Bus limits

The following table lists quota information specific to Azure Service Bus messaging. For information about
pricing and other quotas for Service Bus, see Service Bus pricing.
Q UOTA N A M E SC O P E VA L UE N OT ES
Maximum number of Namespace 1000 (default and Subsequent requests for

namespaces per Azure maximum) additional namespaces are
subscription rejected.
Queue or topic size Entity 1, 2, 3, 4 GB or 5 GB Defined upon

creation/updation of the
In the Premium SKU, queue or topic.
and the Standard SKU
with partitioning Subsequent incoming
enabled, the maximum messages are rejected, and
queue or topic size is an exception is received by
80 GB. the calling code.
Total size limit for a
premium namespace is
1 TB per messaging
unit. Total size of all
entities in a namespace
can't exceed this limit.
Number of concurrent Namespace Net Messaging: 1,000. Subsequent requests for

connections on a additional connections are
namespace AMQP: 5,000. rejected, and an exception is
received by the calling code.
REST operations don't count
toward concurrent TCP
connections.
Number of concurrent Entity 5,000 Subsequent receive

receive requests on a requests are rejected, and
queue, topic, or an exception is received by
subscription entity the calling code. This quota
applies to the combined
number of concurrent
receive operations across all
subscriptions on a topic.
Number of topics or queues Namespace 10,000 for the Basic or Subsequent requests for
per namespace Standard tier. The total creation of a new topic or
number of topics and queue on the namespace
queues in a namespace are rejected. As a result, if
must be less than or equal configured through the
to 10,000. Azure portal, an error
message is generated. If
For the Premium tier, 1,000 called from the
per messaging unit (MU). management API, an
exception is received by the
calling code.
Number of partitioned Namespace Basic and Standard tiers: Subsequent requests for
topics or queues per 100. creation of a new
namespace partitioned topic or queue
Partitioned entities aren't in the namespace are
supported in the Premium rejected. As a result, if
tier. configured through the
Azure portal, an error
Each partitioned queue or message is generated. If
topic counts toward the called from the
quota of 1,000 entities per management API, the
namespace. exception
QuotaExceededExceptio
n is received by the calling
code.
If you want to have
more partitioned
entities in a basic or a
standard tier
namespace, create
additional namespaces.
Maximum size of any Entity - 260 characters.

messaging entity path:
queue or topic
Maximum size of any Entity - 50 characters.

messaging entity name:
namespace, subscription, or
subscription rule
Maximum size of a message Entity - 128

ID
Maximum size of a message Entity - 128

session ID
Message size for a queue, Entity Incoming messages that 256 KB for Standard tier
topic, or subscription entity exceed these quotas are 100 MB for Premium tier.
rejected, and an exception is
received by the calling code. The message size includes
the size of properties
(system and user) and the
size of payload. The size of
system properties varies
depending on your
scenario.
Message property size for a Entity The exception Maximum message

queue, topic, or SerializationException property size for each
subscription entity is generated. property is 32 KB.
Cumulative size of all
properties can't exceed
64 KB. This limit applies
to the entire header of
the brokered message,
which has both user
properties and system
properties, such as
sequence number, label,
and message ID.
Maximum number of
header properties in
property bag:
byte/int.MaxValue .
Number of subscriptions Entity Subsequent requests for 2,000 per-topic for the
per topic creating additional Standard tier and Premium
subscriptions for the topic tier.
are rejected. As a result, if
configured through the
portal, an error message is
shown. If called from the
management API, an
calling code.
Number of SQL filters per Entity Subsequent requests for 2,000

topic creation of additional filters
on the topic are rejected,
and an exception is received
by the calling code.
Number of correlation filters Entity Subsequent requests for 100,000

per topic creation of additional filters
on the topic are rejected,
and an exception is received
by the calling code.
Size of SQL filters or actions Namespace Subsequent requests for Maximum length of filter
creation of additional filters condition string: 1,024 (1
are rejected, and an K).
calling code. Maximum length of rule
action string: 1,024 (1 K).
Maximum number of
expressions per rule action:
32.
Number of shared access Entity, namespace Subsequent requests for Maximum number of rules
authorization rules per creation of additional rules per entity type: 12.
namespace, queue, or topic are rejected, and an
exception is received by the Rules that are configured
calling code. on a Service Bus namespace
apply to all types: queues,
topics.
Number of messages per Transaction Additional incoming 100

transaction messages are rejected, and
an exception stating "Can't For both Send() and
send more than 100 SendAsync() operations.
messages in a single
transaction" is received by
the calling code.
Number of virtual network Namespace 128

and IP filter rules
Site Recovery limits

The following limits apply to Azure Site Recovery.
L IM IT IDEN T IF IER L IM IT
Number of vaults per subscription 500
Number of servers per Recovery Services vault 250
Number of protection groups per Recovery Services vault No limit
Number of recovery plans per Recovery Services vault No limit
Number of servers per protection group No limit
Number of servers per recovery plan 100
SQL Database limits

For SQL Database limits, see SQL Database resource limits for single databases, SQL Database resource limits
for elastic pools and pooled databases, and SQL Database resource limits for SQL Managed Instance.
The maximum number of private endpoints per Azure SQL Database logical server is 250.
Azure Synapse Analytics limits
Azure Synapse Analytics has the following default limits to ensure customer's subscriptions are protected from
each other's workloads. To raise the limits to the maximum for your subscription, contact support.
Synapse Workspace Limits
Synapse workspaces in an Azure 20 20

subscription
Synapse Pipeline Limits

Synapse pipelines in a Synapse 800 800

workspace

integration runtimes, within a
workspace

workspace
Concurrent pipeline runs per 10,000 10,000

workspace that's shared among all
pipelines in the workspace

workspace per Azure Integration
Runtime region
procedure, HDInsight, Web, and others. This
limit does not apply to Self-hosted IR.

Runtime region
hosted IR.

Runtime region
consumption per workspace per Azure Region group 22 : 3,000 Region group 22 : 3,000
Integration Runtime region Region group 32 : 1,500 Region group 32 : 1,500
support.


integration runtime

interval

runs

service objects3

run4

activity run

Manager, not Azure Synapse Analytics.

Manager, not Azure Synapse Analytics.


session

integration runtime


debug sessions per user per
workspace
Meta Data Entity Size limit in a 2 GB Contact support.

workspace
units (version 2). For information on billing, see Azure Synapse Analytics Pricing.
egress costs.
| Region group | Regions | | -------- | ------ | | Region group 1 | Central US, East US, East US 2, North Europe, West
Europe, West US, West US 2 | | Region group 2 | Australia East, Australia Southeast, Brazil South, Central India,
Japan East, North Central US, South Central US, Southeast Asia, West Central US | | Region group 3 | Other
regions | If managed virtual network is enabled, the data integration unit (DIU) in all region groups are 2,400.
objects don't relate to the amount of data you can move and process with Azure Synapse Analytics. Synapse
Analytics is designed to scale to handle petabytes of data.
this payload size doesn't relate to the amount of data you can move and process with Azure Synapse Analytics.
Learn about the symptoms and recommendation if you hit this limit.
Dedicated SQL pool limits
For details of capacity limits for dedicated SQL pools in Azure Synapse Analytics, see dedicated SQL pool
resource limits.
Manager API limits.
Azure Files and Azure File Sync

To learn more about the limits for Azure Files and File Sync, see Azure Files scalability and performance targets.
Storage limits
The following table describes default limits for Azure general-purpose v2 (GPv2), general-purpose v1 (GPv1),
and Blob storage accounts. The ingress limit refers to all data that is sent to a storage account. The egress limit
refers to all data that is received from a storage account.
Microsoft recommends that you use a GPv2 storage account for most scenarios. You can easily upgrade a GPv1
or a Blob storage account to a GPv2 account with no downtime and without the need to copy data. For more
information, see Upgrade to a GPv2 storage account.
NOTE
You can request higher capacity and ingress limits. To request an increase, contact Azure Support.
RESO URC E L IM IT
Number of storage accounts per region per subscription, 250

including standard, and premium storage accounts.
Default maximum storage account capacity 5 PiB 1
Maximum number of blob containers, blobs, file shares, No limit

tables, queues, entities, or messages per storage account.
Default maximum request rate per storage account 20,000 requests per second1
Default maximum ingress per general-purpose v2 and Blob 60 Gbps1

storage account in the following regions (LRS/GRS):
Australia East
Central US
East Asia
East US 2
Japan East
Korea Central
North Europe
South Central US
Southeast Asia
UK South
West Europe
West US

storage account in the following regions (ZRS):
Australia East
Central US
East US
East US 2
Japan East
North Europe
South Central US
Southeast Asia
UK South
West Europe
West US 2

storage account in regions that aren't listed in the previous
row.
RESO URC E L IM IT
Default maximum ingress for general-purpose v1 storage 10 Gbps1

accounts (all regions)
Default maximum egress for general-purpose v2 and Blob 120 Gbps1

storage accounts in the following regions (LRS/GRS):
Australia East
Central US
East Asia
East US 2
Japan East
Korea Central
North Europe
South Central US
Southeast Asia
UK South
West Europe
West US

storage accounts in the following regions (ZRS):
Australia East
Central US
East US
East US 2
Japan East
North Europe
South Central US
Southeast Asia
UK South
West Europe
West US 2

storage accounts in regions that aren't listed in the previous
row.
Maximum egress for general-purpose v1 storage accounts 20 Gbps if RA-GRS/GRS is enabled, 30 Gbps for LRS/ZRS2
(US regions)
Maximum egress for general-purpose v1 storage accounts 10 Gbps if RA-GRS/GRS is enabled, 15 Gbps for LRS/ZRS2
(non-US regions)
Maximum number of IP address rules per storage account 200
Maximum number of virtual network rules per storage 200

account
Maximum number of resource instance rules per storage 200

account
Maximum number of private endpoints per storage account 200
1 Azure Storage standard accounts support higher capacity limits and higher limits for ingress and egress by
request. To request an increase in account limits, contact Azure Support.
2 If yourstorage account has read-access enabled with geo-redundant storage (RA-GRS) or geo-zone-redundant
storage (RA-GZRS), then the egress targets for the secondary location are identical to the egress targets of the
primary location. For more information, see Azure Storage replication.
For more information on limits for standard storage accounts, see Scalability targets for standard storage
accounts.
Storage resource provider limits
The following limits apply only when you perform management operations by using Azure Resource Manager
with Azure Storage.
RESO URC E L IM IT
Storage account management operations (read) 800 per 5 minutes
Storage account management operations (write) 10 per second / 1200 per hour
Storage account management operations (list) 100 per 5 minutes
Azure Blob storage limits

RESO URC E TA RGET
Maximum size of single blob container Same as maximum storage account capacity
Maximum number of blocks in a block blob or append blob 50,000 blocks
Maximum size of a block in a block blob 4000 MiB
Maximum size of a block blob 50,000 X 4000 MiB (approximately 190.7 TiB)
Maximum size of a block in an append blob 4 MiB
Maximum size of an append blob 50,000 x 4 MiB (approximately 195 GiB)
Maximum size of a page blob 8 TiB2
Maximum number of stored access policies per blob 5

container
Target request rate for a single blob Up to 500 requests per second
Target throughput for a single page blob Up to 60 MiB per second2
Target throughput for a single block blob Up to storage account ingress/egress limits1
1 Throughput for a single blob depends on several factors, including, but not limited to: concurrency, request
size, performance tier, speed of source for uploads, and destination for downloads. To take advantage of the
performance enhancements of high-throughput block blobs, upload larger blobs or blocks. Specifically, call the
Put Blob or Put Block operation with a blob or block size that is greater than 4 MiB for standard storage
accounts. For premium block blob or for Data Lake Storage Gen2 storage accounts, use a block or blob size that
is greater than 256 KiB.
2
2 Page blobs are not yet supported in accounts that have the Hierarchical namespace setting on them.
The following table describes the maximum block and blob sizes permitted by service version.
M A XIM UM B LO B SIZ E VIA

M A XIM UM B LO C K SIZ E ( VIA M A XIM UM B LO B SIZ E ( VIA SIN GL E W RIT E O P ERAT IO N
SERVIC E VERSIO N P UT B LO C K ) P UT B LO C K L IST ) ( VIA P UT B LO B )
Version 2019-12-12 and 4000 MiB Approximately 190.7 TiB 5000 MiB (preview)
later (4000 MiB X 50,000 blocks)
Version 2016-05-31 100 MiB Approximately 4.75 TiB 256 MiB

through version 2019-07- (100 MiB X 50,000 blocks)
07
Versions prior to 2016-05- 4 MiB Approximately 195 GiB (4 64 MiB

31 MiB X 50,000 blocks)
Azure Queue storage limits

RESO URC E TA RGET
Maximum size of a single queue 500 TiB
Maximum size of a message in a queue 64 KiB
Maximum number of stored access policies per queue 5
Maximum request rate per storage account 20,000 messages per second, which assumes a 1-KiB
message size
Target throughput for a single queue (1-KiB messages) Up to 2,000 messages per second
Azure Table storage limits

The following table describes capacity, scalability, and performance targets for Table storage.
RESO URC E TA RGET
Number of tables in an Azure storage account Limited only by the capacity of the storage account
Number of partitions in a table Limited only by the capacity of the storage account
Number of entities in a partition Limited only by the capacity of the storage account
Maximum size of a single table 500 TiB
Maximum size of a single entity, including all property values 1 MiB
Maximum number of properties in a table entity 255 (including the three system properties, Par titionKey ,
RowKey , and Timestamp )
Maximum total size of an individual property in an entity Varies by property type. For more information, see
Proper ty Types in Understanding the Table Service Data
Model.
RESO URC E TA RGET
Size of the Par titionKey A string up to 1 KiB in size
Size of the RowKey A string up to 1 KiB in size
Size of an entity group transaction A transaction can include at most 100 entities and the
payload must be less than 4 MiB in size. An entity group
transaction can include an update to an entity only once.
Maximum number of stored access policies per table 5
Maximum request rate per storage account 20,000 transactions per second, which assumes a 1-KiB
entity size
Target throughput for a single table partition (1 KiB-entities) Up to 2,000 entities per second
Virtual machine disk limits

You can attach a number of data disks to an Azure virtual machine (VM). Based on the scalability and
performance targets for a VM's data disks, you can determine the number and type of disk that you need to
meet your performance and capacity requirements.
IMPORTANT
For optimal performance, limit the number of highly utilized disks attached to the virtual machine to avoid possible
throttling. If all attached disks aren't highly utilized at the same time, the virtual machine can support a larger number of
disks.
For Azure managed disks:

The following table illustrates the default and maximum limits of the number of resources per region per
subscription. The limits remain the same irrespective of disks encrypted with either platform-managed keys or
customer-managed keys. There is no limit for the number of Managed Disks, snapshots and images per
resource group.
RESO URC E L IM IT
Standard managed disks 50,000
Standard SSD managed disks 50,000
Premium managed disks 50,000
Standard_LRS snapshots1 75,000
Standard_ZRS snapshots1 75,000
Managed image 50,000
1 The total numberof full disk snapshots an individual disk may have is 200. An individual disk may also have
200 incremental snapshots, which are counted separately from full disk snapshots.
For standard storage accounts: A Standard storage account has a maximum total request rate of 20,000
IOPS. The total IOPS across all of your virtual machine disks in a Standard storage account should not exceed
this limit.
You can roughly calculate the number of highly utilized disks supported by a single standard storage account
based on the request rate limit. For example, for a Basic tier VM, the maximum number of highly utilized disks is
about 66, which is 20,000/300 IOPS per disk. The maximum number of highly utilized disks for a Standard tier
VM is about 40, which is 20,000/500 IOPS per disk.
For premium storage accounts: A premium storage account has a maximum total throughput rate of 50
Gbps. The total throughput across all of your VM disks should not exceed this limit.
For more information, see Virtual machine sizes.
Disk encryption sets
There's a limitation of 1000 disk encryption sets per region, per subscription. For more information, see the
encryption documentation for Linux or Windows virtual machines. If you need to increase the quota, contact
Azure support.
Managed virtual machine disks
Standard HDD managed disks
STA N
DA RD
DISK
TYPE S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Disk 32 64 128 256 512 1,024 2,048 4,096 8,192 16,38 32,76
size in 4 7
GiB
IOPS Up to Up to Up to Up to Up to Up to Up to Up to Up to Up to Up to
per 500 500 500 500 500 500 500 500 1,300 2,000 2,000
disk
Throu Up to Up to Up to Up to Up to Up to Up to Up to Up to Up to Up to
ghput 60 60 60 60 60 60 60 60 300 500 500
per MB/s MB/s MB/s MB/se MB/se MB/se MB/se MB/se MB/se MB/se MB/se
disk ec ec ec c c c c c c c c
Standard SSD managed disks

STA
ND
AR
D
SSD
SIZ
ES E1 E2 E3 E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
Dis 4 8 16 32 64 128 256 512 1,0 2,0 4,0 8,1 16, 32,
k 24 48 96 92 384 767
size
in
GiB
IOP Up Up Up Up Up Up Up Up Up Up Up Up Up Up
S to to to to to to to to to to to to to to
per 500 500 500 500 500 500 500 500 500 500 500 2,0 4,0 6,0
disk 00 00 00
STA
ND
AR
D
SSD
SIZ
ES E1 E2 E3 E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
Thr Up Up Up Up Up Up Up Up Up Up Up Up Up Up
oug to to to to to to to to to to to to to to
hpu 60 60 60 60 60 60 60 60 60 60 60 400 600 750
t MB MB MB MB MB MB MB MB MB MB/ MB/ MB/ MB/ MB/
per /sec /sec /sec /sec /sec /sec /sec /sec /sec sec sec sec sec sec
disk
Ma 600 600 600 600 600 600 600 600 100

x 0
bur
st
IOP
S
per
disk
Ma 150 150 150 150 150 150 150 150 250

x MB MB MB MB MB MB MB MB MB
bur /sec /sec /sec /sec /sec /sec /sec /sec /sec
st
thr
oug
hpu
t
per
disk
Ma 30 30 30 30 30 30 30 30 30
x min min min min min min min min min
bur
st
dur
atio
n
Premium SSD managed disks: Per-disk limits

P RE
M IU
M
SSD
SIZ
ES P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Dis 4 8 16 32 64 128 256 512 1,0 2,0 4,0 8,1 16, 32,
k 24 48 96 92 384 767
size
in
GiB
P RE
M IU
M
SSD
SIZ
ES P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Pro 120 120 120 120 240 500 1,1 2,3 5,0 7,5 7,5 16, 18, 20,
visi 00 00 00 00 00 000 000 000
one
d
IOP
S
per
disk
Pro 25 25 25 25 50 100 125 150 200 250 250 500 750 900
visi MB MB MB MB MB MB MB MB MB MB/ MB/ MB/ MB/ MB/
one /sec /sec /sec /sec /sec /sec /sec /sec /sec sec sec sec sec sec
d
Thr
oug
hpu
t
per
disk
Ma 3,5 3,5 3,5 3,5 3,5 3,5 3,5 3,5 30, 30, 30, 30, 30, 30,
x 00 00 00 00 00 00 00 00 000 000 000 000 000 000
bur * * * * * *
st
IOP
S
per
disk
Ma 170 170 170 170 170 170 170 170 1,0 1,0 1,0 1,0 1,0 1,0
x MB MB MB MB MB MB MB MB 00 00 00 00 00 00
bur /sec /sec /sec /sec /sec /sec /sec /sec MB MB/ MB/ MB/ MB/ MB/
st /sec sec* sec* sec* sec* sec*
thr *
oug
hpu
t
per
disk
Ma 30 30 30 30 30 30 30 30 Unli Unli Unli Unli Unli Unli

x min min min min min min min min mit mit mit mit mit mit
bur ed* ed* ed* ed* ed* ed*
st
dur
atio
n
Eligi No No No No No No No No Yes, Yes, Yes, Yes, Yes, Yes,

ble up up up up up up
for to to to to to to
rese one one one one one one
rvat yea year year year year year
ion r
*Applies only to disks with on-demand bursting enabled.
Premium SSD managed disks: Per-VM limits
RESO URC E L IM IT
Maximum IOPS Per VM 80,000 IOPS with GS5 VM
Maximum throughput per VM 2,000 MB/s with GS5 VM
Unmanaged virtual machine disks

Standard unmanaged vir tual machine disks: Per-disk limits
VM T IER B A SIC T IER VM STA N DA RD T IER VM
Disk size 4,095 GB 4,095 GB
Maximum 8-KB IOPS per persistent 300 500

disk
Maximum number of disks that 66 40

perform the maximum IOPS
Premium unmanaged vir tual machine disks: Per-account limits
RESO URC E L IM IT
Total disk capacity per account 35 TB
Total snapshot capacity per account 10 TB
Maximum bandwidth per account (ingress + egress)1 <=50 Gbps
1Ingress refers to all data from

requests that are sent to a storage account. Egress refers to all data from
responses that are received from a storage account.
Premium unmanaged vir tual machine disks: Per-disk limits
P REM IUM
STO RA GE DISK
TYPE P 10 P 20 P 30 P 40 P 50
Disk size 128 GiB 512 GiB 1,024 GiB (1 TB) 2,048 GiB (2 TB) 4,095 GiB (4 TB)
Maximum IOPS 500 2,300 5,000 7,500 7,500

per disk
Maximum 100 MB/sec 150 MB/sec 200 MB/sec 250 MB/sec 250 MB/sec
throughput per
disk
Maximum 280 70 35 17 8
number of disks
per storage
account
Premium unmanaged vir tual machine disks: Per-VM limits
RESO URC E L IM IT
Maximum IOPS per VM 80,000 IOPS with GS5 VM
Maximum throughput per VM 2,000 MB/sec with GS5 VM
StorSimple System limits

L IM IT IDEN T IF IER L IM IT C O M M EN T S
Maximum number of storage account 64

credentials
Maximum number of volume 64

containers
Maximum number of volumes 255
Maximum number of schedules per 168 A schedule for every hour, every day
bandwidth template of the week.
Maximum size of a tiered volume on 64 TB for StorSimple 8100 and StorSimple 8100 and StorSimple 8600
physical devices StorSimple 8600 are physical devices.
Maximum size of a tiered volume on 30 TB for StorSimple 8010 StorSimple 8010 and StorSimple 8020
virtual devices in Azure are virtual devices in Azure that use
64 TB for StorSimple 8020 Standard storage and Premium
storage, respectively.
Maximum size of a locally pinned 9 TB for StorSimple 8100 StorSimple 8100 and StorSimple 8600
volume on physical devices are physical devices.
24 TB for StorSimple 8600
Maximum number of iSCSI 512

connections
Maximum number of iSCSI 512

connections from initiators
Maximum number of access control 64

records per device
Maximum number of volumes per 24

backup policy
Maximum number of backups retained 64

per backup policy
Maximum number of schedules per 10

backup policy
Maximum number of snapshots of any 256 This amount includes local snapshots
type that can be retained per volume and cloud snapshots.
Maximum number of snapshots that 10,000

can be present in any device
Maximum number of volumes that can 16 If there are more than 16

be processed in parallel for backup, volumes, they're processed
restore, or clone sequentially as processing slots
become available.
New backups of a cloned or a
restored tiered volume can't
occur until the operation is
finished. For a local volume,
backups are allowed after the
volume is online.
Restore and clone recover time for <2 minutes The volume is made available
tiered volumes within 2 minutes of a restore or
clone operation, regardless of
the volume size.
The volume performance might
initially be slower than normal
as most of the data and
metadata still resides in the
cloud. Performance might
increase as data flows from the
cloud to the StorSimple device.
The total time to download
metadata depends on the
allocated volume size.
Metadata is automatically
brought into the device in the
background at the rate of 5
minutes per TB of allocated
volume data. This rate might be
affected by Internet bandwidth
to the cloud.
The restore or clone operation
is complete when all the
metadata is on the device.
Backup operations can't be
performed until the restore or
clone operation is fully
complete.
Restore recover time for locally pinned <2 minutes The volume is made available
volumes within 2 minutes of the restore
operation, regardless of the
volume size.
The volume performance might
initially be slower than normal
as most of the data and
metadata still resides in the
cloud. Performance might
increase as data flows from the
cloud to the StorSimple device.
The total time to download
metadata depends on the
allocated volume size.
Metadata is automatically
brought into the device in the
background at the rate of 5
minutes per TB of allocated
volume data. This rate might be
affected by Internet bandwidth
to the cloud.
Unlike tiered volumes, if there
are locally pinned volumes, the
volume data is also
downloaded locally on the
device. The restore operation is
complete when all the volume
data has been brought to the
device.
The restore operations might
be long and the total time to
complete the restore will
depend on the size of the
provisioned local volume, your
Internet bandwidth, and the
existing data on the device.
Backup operations on the
locally pinned volume are
allowed while the restore
operation is in progress.
Thin-restore availability Last failover
Maximum client read/write 920/720 MB/sec with a single 10- Up to two times with MPIO and two
throughput, when served from the gigabit Ethernet network interface network interfaces.
SSD tier*
Maximum client read/write 120/250 MB/sec

throughput, when served from the
HDD tier*
Maximum client read/write 11/41 MB/sec Read throughput depends on clients

throughput, when served from the generating and maintaining sufficient
cloud tier* I/O queue depth.
*Maximum throughput per I/O type was measured with 100 percent read and 100 percent write scenarios.
Actual throughput might be lower and depends on I/O mix and network conditions.
Stream Analytics limits
Maximum number of streaming units 500 To request an increase in streaming

per subscription per region units for your subscription beyond
500, contact Microsoft Support.
Maximum number of inputs per job 60 There's a hard limit of 60 inputs per
Azure Stream Analytics job.
Maximum number of outputs per job 60 There's a hard limit of 60 outputs per
Stream Analytics job.
Maximum number of functions per job 60 There's a hard limit of 60 functions per
Stream Analytics job.
Maximum number of streaming units 192 There's a hard limit of 192 streaming
per job units per Stream Analytics job.
Maximum number of jobs per region 1,500 Each subscription can have up to
1,500 jobs per geographical region.
Reference data blob MB 5 GB Up to 5 GB when using 6 SUs or more.
Maximum number of characters in a 512000 There's a hard limit of 512k characters

query in an Azure Stream Analytics job query.
Virtual Machines limits

Virtual Machines limits
RESO URC E L IM IT
Virtual machines per cloud service 1 50
Input endpoints per cloud service 2 150
1 Virtual machines created by using the classic deployment model instead of Azure Resource Manager are
automatically stored in a cloud service. You can add more virtual machines to that cloud service for load
balancing and availability.
2 Input endpoints allow communications to a virtual machine from outside the virtual machine's cloud service.
Virtual machines in the same cloud service or virtual network can automatically communicate with each other.
Virtual Machines limits - Azure Resource Manager
The following limits apply when you use Azure Resource Manager and Azure resource groups.
RESO URC E L IM IT
VMs per subscription 25,0001 per region.
VM total cores per subscription 201 per region. Contact support to increase limit.
RESO URC E L IM IT
Azure Spot VM total cores per subscription 201 per region. Contact support to increase limit.
VM per series, such as Dv2 and F, cores per subscription 201 per region. Contact support to increase limit.
Availability sets per subscription 2,500 per region.
Virtual machines per availability set 200
Proximity placement groups per resource group 800
Certificates per availability set 1992
Certificates per subscription Unlimited3
1 Default limits vary by offercategory type, such as Free Trial and Pay-As-You-Go, and by series, such as Dv2, F,
and G. For example, the default for Enterprise Agreement subscriptions is 350. For security, subscriptions default
to 20 cores to prevent large core deployments. If you need more cores, submit a support ticket.
2 Properties such as SSH public keys are also pushed as certificates and count towards this limit. To bypass this
limit, use the Azure Key Vault extension for Windows or the Azure Key Vault extension for Linux to install
certificates.
3 With Azure Resource Manager, certificates are stored in the Azure Key Vault. The number of certificates is
unlimited for a subscription. There's a 1-MB limit of certificates per deployment, which consists of either a single
VM or an availability set.
NOTE
Virtual machine cores have a regional total limit. They also have a limit for regional per-size series, such as Dv2 and F.
These limits are separately enforced. For example, consider a subscription with a US East total VM core limit of 30, an A
series core limit of 30, and a D series core limit of 30. This subscription can deploy 30 A1 VMs, or 30 D1 VMs, or a
combination of the two not to exceed a total of 30 cores. An example of a combination is 10 A1 VMs and 20 D1 VMs.
Shared Image Gallery limits

There are limits, per subscription, for deploying resources using Shared Image Galleries:
100 shared image galleries, per subscription, per region
1,000 image definitions, per subscription, per region
10,000 image versions, per subscription, per region
Virtual machine scale sets limits

RESO URC E L IM IT
Maximum number of VMs in a scale set 1,000
Maximum number of VMs based on a custom VM image in 600

a scale set
Maximum number of scale sets in a region 2,500

RESO URC E L IM IT
Maximum number of nodes supported in VMSS for IB 100

cluster
See also
Understand Azure limits and increases
Virtual machine and cloud service sizes for Azure
Sizes for Azure Cloud Services
Naming rules and restrictions for Azure resources

Virtual WAN Documentation

Uploaded by

Copyright:

Available Formats

Virtual WAN Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Virtual WAN Documentation

Uploaded by

Copyright:

Available Formats

Contents

Virtual WAN documentation

Basic and Standard virtual WANs

VIRT UA L WA N T Y P E H UB T Y P E AVA IL A B L E C O N F IGURAT IO N S

Basic Basic Site-to-site VPN only

Standard Standard ExpressRoute

Virtual WAN resources

Route tables for Basic and Standard virtual WANs

Gated public preview

Review the template

To find more templates, see Azure Quickstart Templates.

Deploy the template

4. When you have finished entering values, select Review + create .

Validate the deployment

Complete the hybrid configuration

Review the template

To find more templates, see Azure Quickstart Templates.

Deploy the template

4. When you have finished entering values, select Review + create .

Validate the deployment

Complete the hybrid configuration

Create a virtual WAN

Subscription : Select the subscription that you want to use.

Configure hub settings

2. On the Site to site tab, complete the following fields:

Connect the VPN site to a hub

4. On the Connect sites page, configure the required settings.

From this page, you can do the following:

Connect a VNet to the hub

Download VPN configuration

Address space of the VNets that are connected to the hub.

Configuring your VPN device

View or edit gateway settings

Create a virtual WAN

Subscription : Select the subscription that you want to use.

Create a User VPN configuration

Example - RADIUS authentication

Example - Azure Active Director y authentication

Create a virtual hub and gateway

Generate client configuration files

Configure VPN clients

Connect VNet to hub

View a virtual WAN

Create a virtual WAN

Create a virtual hub and gateway

Connect your VNet to the hub

Connect your circuit to the hub gateway

To connect by redeeming an authorization key

3. Select Add to add the key.

To change the size of a gateway

To advertise default route 0.0.0.0/0 to endpoints

2. Select Enable to propagate the default route.

Sharing our best practices - Azure network is designed for elasticity

Extend employees' connection to access globally distributed

Scale customer connectivity to frontend resources

Microsoft support for multi-cloud traffic

Set up remote user connectivity

Existing basic Virtual WAN customer

Is Azure Virtual WAN in GA?

1 scale unit 14,000 2,000 200,000