Configure VPN Gateway Connections

Table of Contents
Overview
About VPN Gateway
VPN Gateway FAQ
Subscription and service limits
Get Started
Planning and design for VPN Gateway
About VPN Gateway settings
About VPN devices
About cryptographic requirements
About BGP and VPN Gateway
About highly available connections
How To
Configure a Site-to-Site connection
Azure portal
PowerShell
Azure CLI
Azure portal (classic)
Classic portal (classic)
Configure a Point-to-Site connection
Azure portal
PowerShell
Generate self-signed certificates for Point-to-Site
Configure a VNet-to-VNet connection
Azure portal
PowerShell
Azure CLI
Configure a VNet-to-VNet connection between deployment models
Azure portal
PowerShell
Configure Site-to-Site and ExpressRoute coexisting connections
PowerShell
Configure multiple Site-to-Site connections
Azure portal
PowerShell (classic)
Connect multiple policy-based VPN devices
PowerShell
Configure IPsec/IKE policies on connections
PowerShell
Configure highly available active-active connections
PowerShell
Configure BGP for a VPN gateway
PowerShell
Configure forced tunneling
PowerShell
Modify local network gateway settings
PowerShell
Azure CLI
Verify a VPN gateway connection
Reset a VPN gateway
Delete a VPN gateway
Azure portal
PowerShell
Configure a VPN gateway (classic)
Gateway SKUs (old)
Troubleshoot
Validate VPN throughput to a VNet
Reference
PowerShell
REST
REST (classic)
Azure CLI
Related
Virtual Network
Application Gateway
Azure DNS
Traffic Manager
Load Balancer
ExpressRoute
Resources
Blog
Forum
Pricing
SLA
Videos
About VPN Gateway
6/6/2017 10 min to read Edit Online
A VPN gateway is a type of virtual network gateway that sends encrypted traffic across a public connection to an
on-premises location. You can also use VPN gateways to send encrypted traffic between Azure virtual networks
over the Microsoft network. To send encrypted network traffic between your Azure virtual network and your on-
premises site, you must create a VPN gateway for your virtual network.
Each virtual network can have only one VPN gateway, however, you can create multiple connections to the same
VPN gateway. An example of this is a Multi-Site connection configuration. When you create multiple connections
to the same VPN gateway, all VPN tunnels, including Point-to-Site VPNs, share the bandwidth that is available for
the gateway.
What is a virtual network gateway?
A virtual network gateway is composed of two or more virtual machines that are deployed to a specific subnet
called the GatewaySubnet. The VMs that are located in the GatewaySubnet are created when you create the
virtual network gateway. Virtual network gateway VMs are configured to contain routing tables and gateway
services specific to the gateway. You can't directly configure the VMs that are part of the virtual network gateway
and you should never deploy additional resources to the GatewaySubnet.
When you create a virtual network gateway using the gateway type 'Vpn', it creates a specific type of virtual
network gateway that encrypts traffic; a VPN gateway. The Gateway SKU that you select when you create your
virtual network gateway determines the VMs that are created and configured in the GatewaySubnet.
Gateway SKUs
When you create a virtual network gateway, you need to specify the gateway SKU that you want to use. Select the
SKUs that satisfy your requirements based on the types of workloads, throughputs, features, and SLAs.
Azure offers the following VPN gateway SKUs:
S2S/VNET-TO-VNET P2S AGGREGATE

SKU TUNNELS CONNECTIONS THROUGHPUT
VpnGw1 Max. 30 Max. 128 500 Mbps
VpnGw2 Max. 30 Max. 128 1 Gbps
VpnGw3 Max. 30 Max. 128 1.25 Gbps
Basic Max. 10 Max. 128 100 Mbps
Throughput is based on measurements of multiple tunnels aggregated through a single gateway. It is not
a guaranteed throughput due to Internet traffic conditions and your application behaviors.
Pricing information can be found on the Pricing page.
SLA (Service Level Agreement) information can be found on the SLA page.
Production vs. Dev-Test Workloads
Due to the differences in SLAs and feature sets, we recommend the following SKUs for production vs. dev-test:
WORKLOAD SKUS
Production, critical workloads VpnGw1, VpnGw2, VpnGw3
Dev-test or proof of concept Basic
If you are still using the old SKUs, the production SKU recommendations are Standard and HighPerformance
SKUs. For information on the old SKUs, see Gateway SKUs (old).
Gateway SKU feature sets
The new gateway SKUs streamline the feature sets offered on the gateways:
SKU FEATURES
VpnGw1 Route- and policy-based VPN up to 30 tunnels

VpnGw2 P2S, BGP, active-active, custom IPsec/IKE policy,
VpnGw3 ExpressRoute/VPN co-existence
Basic Route-based: 10 tunnels with P2S

Policy-based (IKEv1): 1 tunnel; no P2S
Resizing gateway SKUs
IMPORTANT
1. You can resize between VpnGw1, VpnGw2, and VpnGw3 SKUs
2. You cannot resize from Basic/Standard/HighPerformance SKUs to the new VpnGw1/VpnGw2/VpnGw3 SKUs
3. For the old SKUs, you can still resize between Basic, Standard, and HighPerformance SKUs
Migrating from old SKUs to VpnGw1/VpnGw2/VpnGw3

You cannot resize your Azure VPN gateways directly between the old (Basic/Standard/HighPerformance) and the
new (VpnGw1/VpnGw2/VpnGw3) SKU families. You need to delete the existing
(Basic/Standard/HighPerformance) gateway and create a new (VpnGw1/VpnGw2/VpnGw3) gateway with the
new SKUs. Note that your Azure Gateway public IP address will change as a result.
1. Delete the old gateway.
2. Create the new gateway.
3. Update your on-premises VPN devices with the new Azure VPN gateway public IP address.
Configuring a VPN Gateway

A VPN gateway connection relies on multiple resources that are configured with specific settings. Most of the
resources can be configured separately, although they must be configured in a certain order in some cases.
Settings
The settings that you chose for each resource are critical to creating a successful connection. For information
about individual resources and settings for VPN Gateway, see About VPN Gateway settings. You'll find
information to help you understand gateway types, VPN types, connection types, gateway subnets, local network
gateways, and various other resource settings that you may want to consider.
Deployment tools
You can start out creating and configuring resources using one configuration tool, such as the Azure portal. You
can then later decide to switch to another tool, such as PowerShell, to configure additional resources, or modify
existing resources when applicable. Currently, you can't configure every resource and resource setting in the
Azure portal. The instructions in the articles for each connection topology specify when a specific configuration
tool is needed.
Deployment model
When you configure a VPN gateway, the steps you take depend on the deployment model that you used to
create your virtual network. For example, if you created your VNet using the classic deployment model, you use
the guidelines and instructions for the classic deployment model to create and configure your VPN gateway
settings. For more information about deployment models, see Understanding Resource Manager and classic
deployment models.
Connection topology diagrams

It's important to know that there are different configurations available for VPN gateway connections. You need to
determine which configuration best fits your needs. In the sections below, you can view information and
topology diagrams about the following VPN gateway connections: The following sections contain tables which
list:
Available deployment model
Available configuration tools
Links that take you directly to an article, if available
Use the diagrams and descriptions to help select the connection topology to match your requirements. The
diagrams show the main baseline topologies, but it's possible to build more complex configurations using the
diagrams as a guideline.
Site-to-Site and Multi-Site (IPsec/IKE VPN tunnel)

Site -to -Site
A Site-to-Site (S2S) VPN gateway connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. This
type of connection requires a VPN device located on-premises that has a public IP address assigned to it and is
not located behind a NAT. S2S connections can be used for cross-premises and hybrid configurations.
Multi-Site
This type of connection is a variation of the Site-to-Site connection. You create more than one VPN connection
from your virtual network gateway, typically connecting to multiple on-premises sites. When working with
multiple connections, you must use a RouteBased VPN type (known as a dynamic gateway when working with
classic VNets). Because each virtual network can only have one VPN gateway, all connections through the
gateway share the available bandwidth. This is often called a "multi-site" connection.
Deployment models and methods for Site -to -Site and Multi-Site
DEPLOYMENT
MODEL/METHOD AZURE PORTAL CLASSIC PORTAL POWERSHELL AZURE CLI
Resource Manager Article Not Supported Article Article
Classic Article** Article* Article+ Not Supported
(*) denotes that the classic portal can only support creating one S2S VPN connection.
(**) denotes that this method contains steps that require PowerShell.
(+) denotes that this article is written for multi-site connections.
Point-to-Site (VPN over SSTP)

A Point-to-Site (P2S) VPN gateway connection allows you to create a secure connection to your virtual network
from an individual client computer. P2S is a VPN connection over SSTP (Secure Socket Tunneling Protocol). P2S
connections do not require a VPN device or a public-facing IP address to work. You establish the VPN connection
by starting it from the client computer. This solution is useful when you want to connect to your VNet from a
remote location, such as from home or a conference, or when you only have a few clients that need to connect to
a VNet. P2S connections can be used with S2S connections through the same VPN gateway, as long as all the
configuration requirements for both connections are compatible.
Deployment models and methods for Point-to -Site
DEPLOYMENT
MODEL/METHOD AZURE PORTAL CLASSIC PORTAL POWERSHELL
Classic Article Supported Supported
Resource Manager Article Not Supported Article
VNet-to-VNet connections (IPsec/IKE VPN tunnel)

Connecting a virtual network to another virtual network (VNet-to-VNet) is similar to connecting a VNet to an on-
premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. You
can even combine VNet-to-VNet communication with multi-site connection configurations. This lets you
establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.
The VNets you connect can be:
in the same or different regions
in the same or different subscriptions
in the same or different deployment models
Connections between deployment models

Azure currently has two deployment models: classic and Resource Manager. If you have been using Azure for
some time, you probably have Azure VMs and instance roles running in a classic VNet. Your newer VMs and role
instances may be running in a VNet created in Resource Manager. You can create a connection between the
VNets to allow the resources in one VNet to communicate directly with resources in another.
VNet peering
You may be able to use VNet peering to create your connection, as long as your virtual network meets certain
requirements. VNet peering does not use a virtual network gateway. For more information, see VNet peering.
Deployment models and methods for VNet-to -VNet
DEPLOYMENT
MODEL/METHOD AZURE PORTAL CLASSIC PORTAL POWERSHELL CLI
Classic Article* Article* Supported Not Supported
Resource Manager Article+ Not Supported Article Article
Connections Article* Supported* Article Not Supported

between different
deployment
models
(+) denotes this deployment method is available only for VNets in the same subscription.
(*) denotes that this deployment method also requires PowerShell.
ExpressRoute (dedicated private connection)

Microsoft Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a
dedicated private connection facilitated by a connectivity provider. With ExpressRoute, you can establish
connections to Microsoft cloud services, such as Microsoft Azure, Office 365, and CRM Online. Connectivity can
be from an any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection
through a connectivity provider at a co-location facility.
ExpressRoute connections do not go over the public Internet. This allows ExpressRoute connections to offer more
reliability, faster speeds, lower latencies, and higher security than typical connections over the Internet.
An ExpressRoute connection does not use a VPN gateway, although it does use a virtual network gateway as part
of its required configuration. In an ExpressRoute connection, the virtual network gateway is configured with the
gateway type 'ExpressRoute', rather than 'Vpn'. For more information about ExpressRoute, see the ExpressRoute
technical overview.
Site-to-Site and ExpressRoute coexisting connections

ExpressRoute is a direct, dedicated connection from your WAN (not over the public Internet) to Microsoft
Services, including Azure. Site-to-Site VPN traffic travels encrypted over the public Internet. Being able to
configure Site-to-Site VPN and ExpressRoute connections for the same virtual network has several advantages.
You can configure a Site-to-Site VPN as a secure failover path for ExpressRoute, or use Site-to-Site VPNs to
connect to sites that are not part of your network, but that are connected through ExpressRoute. Notice that this
configuration requires two virtual network gateways for the same virtual network, one using the gateway type
'Vpn', and the other using the gateway type 'ExpressRoute'.
Deployment models and methods for S2S and ExpressRoute
CLASSIC DEPLOYMENT RESOURCE MANAGER DEPLOYMENT
Classic Portal Not Supported Not Supported
Azure Portal Not Supported Not Supported
PowerShell Article Article
Pricing
You pay for two things: the hourly compute costs for the virtual network gateway, and the egress data transfer
from the virtual network gateway. Pricing information can be found on the Pricing page.
Virtual network gateway compute costs
Each virtual network gateway has an hourly compute cost. The price is based on the gateway SKU that you
specify when you create a virtual network gateway. The cost is for the gateway itself and is in addition to the data
transfer that flows through the gateway.
Data transfer costs
Data transfer costs are calculated based on egress traffic from the source virtual network gateway.
If you are sending traffic to your on-premises VPN device, it will be charged with the Internet egress data
transfer rate.
If you are sending traffic between virtual networks in different regions, the pricing is based the region.
If you are sending traffic only between virtual networks that are in the same region, there are no data costs.
Traffic between VNets in the same region is free.
For more information about gateway SKUs for VPN Gateway, see Gateway SKUs.
FAQ
For frequently asked questions about VPN gateway, see the VPN Gateway FAQ.
Next steps
Plan your VPN gateway configuration. See VPN Gateway Planning and Design.
View the VPN Gateway FAQ for additional information.
View the Subscription and service limits.
VPN Gateway FAQ
Connecting to virtual networks

Can I connect virtual networks in different Azure regions?
Yes. In fact, there is no region constraint. One virtual network can connect to another virtual network in the same
region, or in a different Azure region.
Can I connect virtual networks in different subscriptions?
Yes.
Can I connect to multiple sites from a single virtual network?
You can connect to multiple sites by using Windows PowerShell and the Azure REST APIs. See the Multi-Site and
VNet-to-VNet Connectivity FAQ section.
What are my cross-premises connection options?
The following cross-premises connections are supported:
Site-to-Site VPN connection over IPsec (IKE v1 and IKE v2). This type of connection requires a VPN device or
RRAS. For more information, see Site-to-Site.
Point-to-Site VPN connection over SSTP (Secure Socket Tunneling Protocol). This connection does not require
a VPN device. For more information, see Point-to-Site.
VNet-to-VNet This type of connection is the same as a Site-to-Site configuration. VNet to VNet is a VPN
connection over IPsec (IKE v1 and IKE v2). It does not require a VPN device. For more information, see VNet-to-
VNet.
Multi-Site This is a variation of a Site-to-Site configuration that allows you to connect multiple on-premises
sites to a virtual network. For more information, see Multi-Site.
ExpressRoute ExpressRoute is a direct connection to Azure from your WAN, not a VPN connection over the
public Internet. For more information, see the ExpressRoute Technical Overview and the ExpressRoute FAQ.
For more information about VPN gateway connections, see About VPN Gateway.
What is the difference between a Site -to -Site connection and Point-to -Site?
Site-to-Site (IPsec/IKE VPN tunnel) configurations are between your on-premises location and Azure. This means
that you can connect from any of your computers located on your premises to any virtual machine or role instance
within your virtual network, depending on how you choose to configure routing and permissions. It's a great
option for an always-available cross-premises connection and is well-suited for hybrid configurations. This type of
connection relies on an IPsec VPN appliance (hardware device or soft appliance), which must be deployed at the
edge of your network. To create this type of connection, you must have an externally facing IPv4 address that is
not behind a NAT.
Point-to-Site (VPN over SSTP) configurations let you connect from a single computer from anywhere to anything
located in your virtual network. It uses the Windows in-box VPN client. As part of the Point-to-Site configuration,
you install a certificate and a VPN client configuration package, which contains the settings that allow your
computer to connect to any virtual machine or role instance within the virtual network. It's great when you want to
connect to a virtual network, but aren't located on-premises. It's also a good option when you don't have access to
VPN hardware or an externally facing IPv4 address, both of which are required for a Site-to-Site connection.
You can configure your virtual network to use both Site-to-Site and Point-to-Site concurrently, as long as you
create your Site-to-Site connection using a route-based VPN type for your gateway. Route-based VPN types are
called dynamic gateways in the classic deployment model.
Virtual network gateways

Is a VPN gateway a virtual network gateway?
A VPN gateway is a type of virtual network gateway. A VPN gateway sends encrypted traffic between your virtual
network and your on-premises location across a public connection. You can also use a VPN gateway to send traffic
between virtual networks. When you create a VPN gateway, you use the -GatewayType value 'Vpn'. For more
information, see About VPN Gateway configuration settings.
What is a policy-based (static-routing) gateway?
Policy-based gateways implement policy-based VPNs. Policy-based VPNs encrypt and direct packets through IPsec
tunnels based on the combinations of address prefixes between your on-premises network and the Azure VNet.
The policy (or Traffic Selector) is usually defined as an access list in the VPN configuration.
What is a route -based (dynamic-routing) gateway?
Route-based gateways implement the route-based VPNs. Route-based VPNs use "routes" in the IP forwarding or
routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or
decrypt the packets in and out of the tunnels. The policy or traffic selector for route-based VPNs are configured as
any-to-any (or wild cards).
Do I need a 'GatewaySubnet'?
Yes. The gateway subnet contains the IP addresses that the virtual network gateway services use. You need to
create a gateway subnet for your VNet in order to configure a virtual network gateway. All gateway subnets must
be named 'GatewaySubnet' to work properly. Don't name your gateway subnet something else. And don't deploy
VMs or anything else to the gateway subnet.
When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The IP
addresses in the gateway subnet are allocated to the gateway service. Some configurations require more IP
addresses to be allocated to the gateway services than do others. You want to make sure your gateway subnet
contains enough IP addresses to accommodate future growth and possible additional new connection
configurations. So, while you can create a gateway subnet as small as /29, we recommend that you create a
gateway subnet of /27 or larger (/27, /26, /25 etc.). Look at the requirements for the configuration that you want to
create and verify that the gateway subnet you have will meet those requirements.
Can I deploy Virtual Machines or role instances to my gateway subnet?
No.
Can I get my VPN gateway IP address before I create it?
No. You have to create your gateway first to get the IP address. The IP address changes if you delete and recreate
your VPN gateway.
Can I request a Static Public IP address for my VPN gateway?
No. Only Dynamic IP address assignment is supported. However, this does not mean that the IP address changes
after it has been assigned to your VPN gateway. The only time the VPN gateway IP address changes is when the
gateway is deleted and re-created. The VPN gateway public IP address doesn't change across resizing, resetting, or
other internal maintenance/upgrades of your VPN gateway.
How does my VPN tunnel get authenticated?
Azure VPN uses PSK (Pre-Shared Key) authentication. We generate a pre-shared key (PSK) when we create the
VPN tunnel. You can change the auto-generated PSK to your own with the Set Pre-Shared Key PowerShell cmdlet
or REST API.
Can I use the Set Pre -Shared Key API to configure my policy-based (static routing) gateway VPN?
Yes, the Set Pre-Shared Key API and PowerShell cmdlet can be used to configure both Azure policy-based (static)
VPNs and route-based (dynamic) routing VPNs.
Can I use other authentication options?
We are limited to using pre-shared keys (PSK) for authentication.
How do I specify which traffic goes through the VPN gateway?
Resource Manager deployment model
PowerShell: use "AddressPrefix" to specify traffic for the local network gateway.
Azure portal: navigate to the Local network gateway > Configuration > Address space.
Classic deployment model
Azure portal: navigate to the classic virtual network > VPN connections > Site-to-site VPN connections > Local
site name > Local site > Client address space.
Classic portal: add each range that you want sent through the gateway for your virtual network on the
Networks page under Local Networks.
Can I configure Forced Tunneling?
Yes. See Configure forced tunneling.
Can I set up my own VPN server in Azure and use it to connect to my on-premises network?
Yes, you can deploy your own VPN gateways or servers in Azure either from the Azure Marketplace or creating
your own VPN routers. You need to configure user-defined routes in your virtual network to ensure traffic is
routed properly between your on-premises networks and your virtual network subnets.
Why are certain ports opened on my VPN gateway?
They are required for Azure infrastructure communication. They are protected (locked down) by Azure certificates.
Without proper certificates, external entities, including the customers of those gateways, will not be able to cause
any effect on those endpoints.
A VPN gateway is fundamentally a multi-homed device with one NIC tapping into the customer private network,
and one NIC facing the public network. Azure infrastructure entities cannot tap into customer private networks for
compliance reasons, so they need to utilize public endpoints for infrastructure communication. The public
endpoints are periodically scanned by Azure security audit.
More information about gateway types, requirements, and throughput
For more information, see About VPN Gateway configuration settings.
Site-to-Site connections and VPN devices

What should I consider when selecting a VPN device?
We have validated a set of standard Site-to-Site VPN devices in partnership with device vendors. A list of known
compatible VPN devices, their corresponding configuration instructions or samples, and device specs can be found
in the About VPN devices article. All devices in the device families listed as known compatible should work with
Virtual Network. To help configure your VPN device, refer to the device configuration sample or link that
corresponds to appropriate device family.
Where can I find VPN device configuration settings?
See the following links for configuration information:
For information about compatible VPN devices, see VPN Devices.
Before configuring your VPN device, check for any Known device compatibility issues for the VPN device that
you want to use.
For links to device configuration settings, see Validated VPN Devices. The device configuration links are
provided on a best-effort basis. It's always best to check with your device manufacturer for the latest
configuration information.
For information about editing device configuration samples, see Editing samples.
For cryptographic requirements, see About cryptographic requirements and Azure VPN gateways.
For information about IPsec/IKE parameters, see About VPN devices and IPsec/IKE parameters for Site-to-Site
VPN gateway connections.
For IPsec/IKE policy configuration steps, see Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet
connections.
How do I edit VPN device configuration samples?
Where do I find IPsec and IKE parameters?
For IPsec/IKE parameters, see Parameters.
Why does my policy-based VPN tunnel go down when traffic is idle?
This is expected behavior for policy-based (also known as static routing) VPN gateways. When the traffic over the
tunnel is idle for more than 5 minutes, the tunnel will be torn down. When traffic starts flowing in either direction,
the tunnel will be reestablished immediately.
Can I use software VPNs to connect to Azure?
We support Windows Server 2012 Routing and Remote Access (RRAS) servers for Site-to-Site cross-premises
configuration.
Other software VPN solutions should work with our gateway as long as they conform to industry standard IPsec
implementations. Contact the vendor of the software for configuration and support instructions.
Point-to-Site connections
What client operating systems can I use with Point-to -Site?
The following client operating systems are supported:
Windows 7 (32-bit and 64-bit)
Windows Server 2008 R2 (64-bit only)
Windows 8.1 (32-bit and 64-bit)
Windows Server 2012 (64-bit only)
Windows 10
Can I use any software VPN client for Point-to -Site that supports SSTP?
No. Support is limited only to the Windows operating system versions listed above.
How many VPN client endpoints can I have in my Point-to -Site configuration?
We support up to 128 VPN clients to be able to connect to a virtual network at the same time.
Can I use my own internal PKI root CA for Point-to -Site connectivity?
Yes. Previously, only self-signed root certificates could be used. You can still upload 20 root certificates.
Can I traverse proxies and firewalls using Point-to -Site capability?
Yes. We use SSTP (Secure Socket Tunneling Protocol) to tunnel through firewalls. This tunnel will appear as an
HTTPs connection.
If I restart a client computer configured for Point-to -Site, will the VPN automatically reconnect?
By default, the client computer will not reestablish the VPN connection automatically.
Does Point-to -Site support auto -reconnect and DDNS on the VPN clients?
Auto-reconnect and DDNS are currently not supported in Point-to-Site VPNs.
Can I have Site -to -Site and Point-to -Site configurations coexist for the same virtual network?
Yes. Both these solutions will work if you have a RouteBased VPN type for your gateway. For the classic
deployment model, you need a dynamic gateway. We do not support Point-to-Site for static routing VPN gateways
or gateways using the -VpnType PolicyBased cmdlet.
Can I configure a Point-to -Site client to connect to multiple virtual networks at the same time?
Yes, it is possible. But the virtual networks cannot have overlapping IP prefixes and the Point-to-Site address
spaces must not overlap between the virtual networks.
How much throughput can I expect through Site -to -Site or Point-to -Site connections?
It's difficult to maintain the exact throughput of the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols.
Throughput is also limited by the latency and bandwidth between your premises and the Internet.
VNet-to-VNet and Multi-Site connections

Does Azure charge for traffic between VNets?
VNet-to-VNet traffic within the same region is free for both directions when using a VPN gateway connection.
Cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the
source regions. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using VNet
Peering, rather than VPN Gateway, see the Virtual Network pricing page.
Does VNet-to -VNet traffic travel across the Internet?
No. VNet-to-VNet traffic travels across the Microsoft Azure backbone, not the Internet.
Is VNet-to -VNet traffic secure?
Yes, it is protected by IPsec/IKE encryption.
Do I need a VPN device to connect VNets together?
No. Connecting multiple Azure virtual networks together doesn't require a VPN device unless cross-premises
connectivity is required.
Do my VNets need to be in the same region?
No. The virtual networks can be in the same or different Azure regions (locations).
Can I use VNet-to -VNet along with multi-site connections?
Yes. Virtual network connectivity can be used simultaneously with multi-site VPNs.
How many on-premises sites and virtual networks can one virtual network connect to?
See Gateway requirements table.
Can I use VNet-to -VNet to connect VMs or cloud services outside of a VNet?
No. VNet-to-VNet supports connecting virtual networks. It does not support connecting virtual machines or cloud
services that are not in a virtual network.
Can a cloud service or a load balancing endpoint span VNets?
No. A cloud service or a load balancing endpoint can't span across virtual networks, even if they are connected
together.
Can I used a PolicyBased VPN type for VNet-to -VNet or Multi-Site connections?
No. VNet-to-VNet and Multi-Site connections require Azure VPN gateways with RouteBased (previously called
Dynamic Routing) VPN types.
Can I connect a VNet with a RouteBased VPN Type to another VNet with a PolicyBased VPN type?
No, both virtual networks MUST be using route-based (previously called Dynamic Routing) VPNs.
Do VPN tunnels share bandwidth?
Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the same
VPN gateway uptime SLA in Azure.
Are redundant tunnels supported?
Redundant tunnels between a pair of virtual networks are supported when one virtual network gateway is
configured as active-active.
Can I have overlapping address spaces for VNet-to -VNet configurations?
No. You can't have overlapping IP address ranges.
Can there be overlapping address spaces among connected virtual networks and on-premises local sites?
Can I use Azure VPN gateway to transit traffic between my on-premises sites or to another virtual network?
Yes. See the BGP section for more information.
Transit traffic via Azure VPN gateway is possible using the classic deployment model, but relies on statically
defined address spaces in the network configuration file. BGP is not yet supported with Azure Virtual Networks
and VPN gateways using the classic deployment model. Without BGP, manually defining transit address spaces is
very error prone, and not recommended.
Does Azure generate the same IPsec/IKE pre -shared key for all my VPN connections for the same virtual
network?
No, Azure by default generates different pre-shared keys for different VPN connections. However, you can use the
Set VPN Gateway Key REST API or PowerShell cmdlet to set the key value you prefer. The key MUST be
alphanumerical string of length between 1 to 128 characters.
Do I get more bandwidth with more Site -to -Site VPNs than for a single virtual network?
No, all VPN tunnels, including Point-to-Site VPNs, share the same Azure VPN gateway and the available
bandwidth.
Can I configure multiple tunnels between my virtual network and my on-premises site using multi-site VPN?
Yes, but you must configure BGP on both tunnels to the same location.
Can I use Point-to -Site VPNs with my virtual network with multiple VPN tunnels?
Yes, Point-to-Site (P2S) VPNs can be used with the VPN gateways connecting to multiple on-premises sites and
other virtual networks.
Can I connect a virtual network with IPsec VPNs to my ExpressRoute circuit?
Yes, this is supported. For more information, see Configure ExpressRoute and Site-to-Site VPN connections that
coexist.
IPsec/IKE policy
Is Custom IPsec/IKE policy supported on all Azure VPN Gateway SKUs?
Custom IPsec/IKE policy is supported on Azure Standard and HighPerformance VPN gateways. Basic SKU is
NOT supported.
How many policies can I specify on a connection?
You can only specify one policy combination for a given connection.
Can I specify a partial policy on a connection? (E.g., only IKE algorithms but not IPsec)
No, you must specify all algorithms and parameters for both IKE (Main Mode) and IPsec (Quick Mode). Partial
policy specification is not allowed.
What are the algorithms and key strengths supported in the custom policy?
The table below lists the supported cryptographic algorithms and key strengths configurable by the customers.
You must select one option for every field.
IPSEC/IKEV2 OPTIONS
IKEv2 Encryption AES256, AES192, AES128, DES3, DES
IKEv2 Integrity SHA384, SHA256, SHA1, MD5
DH Group ECP384, ECP256, DHGroup24, DHGroup14, DHGroup2048,

DHGroup2, DHGroup1, None
IPsec Encryption GCMAES256, GCMAES192, GCMAES128, AES256, AES192,

AES128, DES3, DES, None
IPsec Integrity GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1,

MD5
PFS Group ECP384, ECP256, PFS24, PFS2048, PFS14, PFS2, PFS1, None
QM SA Lifetime* Seconds (integer) and KBytes (integer)
Traffic Selector UsePolicyBasedTrafficSelectors** ($True/$False)
(*) IKEv2 Main Mode SA lifetime is fixed at 28,800 seconds on the Azure VPN gateways
(**) Please see the next FAQ item for "UsePolicyBasedTrafficSelectors"
Does everything need to match between the Azure VPN gateway policy and my on-premises VPN device
configurations?
Your on-premises VPN device configuration must match or contain the following algorithms and parameters that
you specify on the Azure IPsec/IKE policy:
IKE encryption algorithm
IKE integrity algorithm
DH Group
IPsec encryption algorithm
IPsec integrity algorithm
PFS Group
Traffic Selector (*)
The SA lifetimes are local specifications only, do not need to match.
If you enable UsePolicyBasedTrafficSelectors, you need to ensure your VPN device has the matching traffic
selectors defined with all combinations of your on-premises network (local network gateway) prefixes to/from the
Azure virtual network prefixes, instead of any-to-any. For example, if your on-premises network prefixes are
10.1.0.0/16 and 10.2.0.0/16, and your virtual network prefixes are 192.168.0.0/16 and 172.16.0.0/16, you need to
specify the following traffic selectors:
10.1.0.0/16 <====> 192.168.0.0/16
10.1.0.0/16 <====> 172.16.0.0/16
10.2.0.0/16 <====> 192.168.0.0/16
10.2.0.0/16 <====> 172.16.0.0/16
Refer to Connect multiple on-premises policy-based VPN devices for more details on how to use this option.
Does the custom policy replace the default IPsec/IKE policy sets for Azure VPN gateways?
Yes, once a custom policy is specified on a connection, Azure VPN gateway will only use the policy on the
connection, both as IKE initiator and IKE responder.
If I remove a custom IPsec/IKE policy, does the connection become unprotected?
No, the connection will still be protected by IPsec/IKE. Once you remove the custom policy from a connection, the
Azure VPN gateway will revert back to the default list of IPsec/IKE proposals and re-start the IKE handshake again
with your on-premises VPN device.
Would adding or updating an IPsec/IKE policy disrupt my VPN connection?
Yes, it could cause a small disruption (a few seconds) as the Azure VPN gateway will tear down the existing
connection and re-start the IKE handshake to re-establish the IPsec tunnel with the new cryptographic algorithms
and parameters. Please ensure your on-premises VPN device is also configured with the matching algorithms and
key strengths to minimize the disruption.
Can I use different policies on different connections?
Yes. Custom policy is applied on a per-connection basis. You can create and apply different IPsec/IKE policies on
different connections. You can also choose to apply custom policies on a subset of connections. The remaining
ones will use the Azure default IPsec/IKE policy sets.
Can I use the custom policy on VNet-to -VNet connection as well?
Yes, you can apply custom policy on both IPsec cross-premises connections or VNet-to-VNet connections.
Do I need to specify the same policy on both VNet-to -VNet connection resources?
Yes. A VNet-to-VNet tunnel consists of two connection resources in Azure, one for each direction. You need to
ensure both connection resources have the same policy, othereise the VNet-to-VNet connection will not establish.
Does custom IPsec/IKE policy work on ExpressRoute connection?
No. IPsec/IKE policy only works on S2S VPN and VNet-to-VNet connections via the Azure VPN gateways.
BGP
Is BGP supported on all Azure VPN Gateway SKUs?
No, BGP is supported on Azure Standard and HighPerformance VPN gateways. Basic SKU is NOT supported.
Can I use BGP with Azure Policy-Based VPN gateways?
No, BGP is supported on Route-Based VPN gateways only.
Can I use private ASNs (Autonomous System Numbers)?
Yes, you can use your own public ASNs or private ASNs for both your on-premises networks and Azure virtual
networks.
Are there ASNs reserved by Azure?
Yes, the following ASNs are reserved by Azure for both internal and external peerings:
Public ASNs: 8075, 8076, 12076
Private ASNs: 65515, 65517, 65518, 65519, 65520
You cannot specify these ASNs for your on premises VPN devices when connecting to Azure VPN gateways.
Can I use the same ASN for both on-premises VPN networks and Azure VNets?
No, you must assign different ASNs between your on-premises networks and your Azure VNets if you are
connecting them together with BGP. Azure VPN Gateways have a default ASN of 65515 assigned, whether BGP is
enabled or not for your cross-premises connectivity. You can override this default by assigning a different ASN
when creating the VPN gateway, or change the ASN after the gateway is created. You will need to assign your on-
premises ASNs to the corresponding Azure Local Network Gateways.
What address prefixes will Azure VPN gateways advertise to me?
Azure VPN gateway will advertise the following routes to your on-premises BGP devices:
Your VNet address prefixes
Address prefixes for each Local Network Gateways connected to the Azure VPN gateway
Routes learned from other BGP peering sessions connected to the Azure VPN gateway, except default route
or routes overlapped with any VNet prefix.
Can I advertise default route (0.0.0.0/0) to Azure VPN gateways?
Yes.
Please note this will force all VNet egress traffic towards your on-premises site, and will prevent the VNet VMs
from accepting public communication from the Internet directly, such RDP or SSH from the Internet to the VMs.
Can I advertise the exact prefixes as my Virtual Network prefixes?
No, advertising the same prefixes as any one of your Virtual Network address prefixes will be blocked or filtered
by the Azure platform. However you can advertise a prefix that is a superset of what you have inside your Virtual
Network.
For example, if your virtual network used the address space 10.0.0.0/16, you could advertise 10.0.0.0/8. But you
cannot advertise 10.0.0.0/16 or 10.0.0.0/24.
Can I use BGP with my VNet-to -VNet connections?
Yes, you can use BGP for both cross-premises connections and VNet-to-VNet connections.
Can I mix BGP with non-BGP connections for my Azure VPN gateways?
Yes, you can mix both BGP and non-BGP connections for the same Azure VPN gateway.
Does Azure VPN gateway support BGP transit routing?
Yes, BGP transit routing is supported, with the exception that Azure VPN gateways will NOT advertise default
routes to other BGP peers. To enable transit routing across multiple Azure VPN gateways, you must enable BGP on
all intermediate VNet-to-VNet connections.
Can I have more than one tunnel between Azure VPN gateway and my on-premises network?
Yes, you can establish more than one S2S VPN tunnel between an Azure VPN gateway and your on-premises
network. Please note that all these tunnels will be counted against the total number of tunnels for your Azure VPN
gateways and you must enable BGP on both tunnels.
For example, if you have two redundant tunnels between your Azure VPN gateway and one of your on-premises
networks, they will consume 2 tunnels out of the total quota for your Azure VPN gateway (10 for Standard and 30
for HighPerformance).
Can I have multiple tunnels between two Azure VNets with BGP?
Yes, but at least one of the virtual network gateways must be in active-active configuration.
Can I use BGP for S2S VPN in an ExpressRoute/S2S VPN co -existence configuration?
Yes.
What address does Azure VPN gateway use for BGP Peer IP?
The Azure VPN gateway will allocate a single IP address from the GatewaySubnet range defined for the virtual
network. By default, it is the second last address of the range. For example, if your GatewaySubnet is
10.12.255.0/27, ranging from 10.12.255.0 to 10.12.255.31, the BGP Peer IP address on the Azure VPN gateway will
be 10.12.255.30. You can find this information when you list the Azure VPN gateway information.
What are the requirements for the BGP Peer IP addresses on my VPN device?
Your on-premises BGP peer address MUST NOT be the same as the public IP address of your VPN device. 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 Local Network Gateway representing the
location.
What should I specify as my address prefixes for the Local Network Gateway when I use BGP?
Azure Local Network Gateway specifies the initial address prefixes for the on-premises network. With BGP, you
must allocate the host prefix (/32 prefix) of your BGP Peer IP address as the address space for that on-premises
network. If your BGP Peer IP is 10.52.255.254, you should specify "10.52.255.254/32" as the
localNetworkAddressSpace of the Local Network Gateway representing this on-premises network. This is to
ensure that the Azure VPN gateway establishes the BGP session through the S2S VPN tunnel.
What should I add to my on-premises VPN device for the BGP peering session?
You should add a host route of the Azure BGP Peer IP address on your VPN device pointing to the IPsec S2S VPN
tunnel. For example, if the Azure VPN Peer IP is "10.12.255.30", you should add a host route for "10.12.255.30"
with a nexthop interface of the matching IPsec tunnel interface on your VPN device.
Cross-premises connectivity and VMs

If my virtual machine is in a virtual network and I have a cross-premises connection, how should I connect to the
VM?
You have a few options. If you have RDP enabled for your VM, you can connect to your virtual machine by using
the private IP address. In that case, you would specify the private IP address and the port that you want to connect
to (typically 3389). You'll need to configure the port on your virtual machine for the traffic.
You can also connect to your virtual machine by private IP address from another virtual machine that's located on
the same virtual network. You can't RDP to your virtual machine by using the private IP address if you are
connecting from a location outside of your virtual network. For example, if you have a Point-to-Site virtual network
configured and you don't establish a connection from your computer, you can't connect to the virtual machine by
private IP address.
If my virtual machine is in a virtual network with cross-premises connectivity, does all the traffic from my VM go
through that connection?
No. Only the traffic that has a destination IP that is contained in the virtual network Local Network IP address
ranges that you specified will go through the virtual network gateway. Traffic has a destination IP located within
the virtual network stays within the virtual network. Other traffic is sent through the load balancer to the public
networks, or if forced tunneling is used, sent through the Azure VPN gateway.
How do I troubleshoot an RDP connection to a VM
If you are having trouble connecting to a virtual machine over your VPN connection, check the following:
Verify that your VPN connection is successful.
Verify that you are connecting to the private IP address for the VM.
If you can connect to the VM using the private IP address, but not the computer name, verify that you have
configured DNS properly. For more information about how name resolution works for VMs, see Name
Resolution for VMs.
When you connect over Point-to-Site, check the following additional items:
Use 'ipconfig' to check the IPv4 address assigned to the Ethernet adapter on the computer from which you are
connecting. If the IP address is within the address range of the VNet that you are connecting to, or within the
address range of your VPNClientAddressPool, this is referred to as an overlapping address space. When your
address space overlaps in this way, the network traffic doesn't reach Azure, it stays on the local network.
Verify that the VPN client configuration package was generated after the DNS server IP addresses were
specified for the VNet. If you updated the DNS server IP addresses, generate and install a new VPN client
configuration package.
For more information about troubleshooting an RDP connection, see Troubleshoot Remote Desktop connections
to a VM.
Virtual Network FAQ

You view additional virtual network information in the Virtual Network FAQ.
Next steps
For more information about VPN Gateway, see About VPN Gateway.
For more information about VPN Gateway configuration settings, see About VPN Gateway configuration
settings.
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. This
document doesn't currently cover all Azure services. Over time, the list will be expanded and updated to cover more
of the platform.
Please visit Azure Pricing Overview to learn more about Azure pricing. There, you can estimate your costs using the
Pricing Calculator or by visiting the pricing details page for a service (for example, Windows VMs). For tips to help
manage your costs, see Prevent unexpected costs with Azure billing and cost management.
NOTE
If you want to raise the limit or quota above the Default Limit, open an online customer support request at no charge. The
limits can't be raised above the Maximum Limit value shown in the following tables. If there is no Maximum Limit column,
then the resource doesn't have adjustable limits.
Free Trial subscriptions are not eligible for limit or quota increases. If you have a Free Trial, you can upgrade to a Pay-As-You-
Go subscription. For more information, see Upgrade Azure Free Trial to Pay-As-You-Go.
Limits and the Azure Resource Manager

It is now possible to combine multiple Azure resources in to a single Azure Resource Group. When using Resource
Groups, limits that once were global become managed at a regional level with the Azure Resource Manager. For
more information about Azure Resource Groups, see Azure Resource Manager overview.
In the limits below, a new table has been added to reflect any differences in limits when using the Azure Resource
Manager. For example, there is a Subscription Limits table and a Subscription Limits - Azure Resource
Manager table. When a limit applies to both scenarios, it is only shown in the first table. Unless otherwise
indicated, limits are global across all regions.
NOTE
It is important to emphasize that quotas for resources in Azure Resource Groups are per-region accessible by your
subscription, and are not per-subscription, as the service management quotas are. Let's use core quotas as an example. If you
need to request a quota increase with support for cores, you need to decide how many cores you want to use in which
regions, and then make a specific request for Azure Resource Group core quotas for the amounts and regions that you want.
Therefore, if you need to use 30 cores in West Europe to run your application there; you should specifically request 30 cores
in West Europe. But you will not have a core quota increase in any other region -- only West Europe will have the 30-core
quota.
As a result, you may find it useful to consider deciding what your Azure Resource Group quotas need to be for your workload
in any one region, and request that amount in each region into which you are considering deployment. See troubleshooting
deployment issues for more help discovering your current quotas for specific regions.
Service-specific limits
Active Directory
API Management
App Service
Application Gateway
Application Insights
Automation
Azure Redis Cache
Azure RemoteApp
Backup
Batch
BizTalk Services
CDN
Cloud Services
Data Factory
Data Lake Analytics
Data Lake Store
DNS
DocumentDB
Event Hubs
IoT Hub
Key Vault
Log Analytics / Operational Insights
Media Services
Mobile Engagement
Mobile Services
Monitor
Multi-Factor Authentication
Networking
Network Watcher
Notification Hub Service
Resource Group
Scheduler
Search
Service Bus
Site Recovery
SQL Database
Storage
StorSimple System
Stream Analytics
Subscription
Traffic Manager
Virtual Machines
Virtual Machine Scale Sets
Subscription limits
Subscription limits
RESOURCE DEFAULT LIMIT MAXIMUM LIMIT
Cores per subscription 1 20 10,000
Co-administrators per subscription 200 200
Storage accounts per subscription2 200 250
Cloud services per subscription 20 200
Local networks per subscription 10 500
SQL Database servers per subscription 6 150
DNS servers per subscription 9 100
Reserved IPs per subscription 20 100
Hosted service certificates per 400 400

subscription
Affinity groups per subscription 256 256
Alert rules per subscription 250 250
1Extra Small instances count as one core towards the core limit despite using a partial core.
2This includes both Standard and Premium storage accounts. If you require more than 200 storage accounts, make
a request through Azure Support. The Azure Storage team will review your business case and may approve up to
250 storage accounts.
Subscription limits - Azure Resource Manager
The following limits apply when using the Azure Resource Manager and Azure Resource Groups. Limits that have
not changed with the Azure Resource Manager are not listed below. Please refer to the previous table for those
limits.
For information about handling limits on Resource Manager requests, see Throttling Resource Manager requests.
VMs per subscription 201 per Region 10,000 per Region
VM total cores per subscription 201 per Region Contact support
VM per series (Dv2, F, etc.) cores per 201 per Region Contact support
subscription
Co-administrators per subscription Unlimited Unlimited
Storage accounts per subscription 200 2002
Resource Groups per subscription 800 800
Availability Sets per subscription 2000 per Region 2000 per Region
Resource Manager API Reads 15000 per hour 15000 per hour
Resource Manager API Writes 1200 per hour 1200 per hour
Resource Manager API request size 4194304 bytes 4194304 bytes
Tags per subscription 10000 10000
Cloud services per subscription Not Applicable3 Not Applicable3
Affinity groups per subscription Not Applicable3 Not Applicable3
1Default limits vary by offer Category Type, such as Free Trial, Pay-As-You-Go, and series, such as Dv2, F, G, etc.
3These features are no longer required with Azure Resource Groups and the Azure Resource Manager.
NOTE
It is important to emphasize that virtual machine cores have a regional total limit as well as a regional per size series (Dv2, F,
etc.) limit that 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 would be allowed to deploy 30 A1 VMs, or 30 D1
VMs, or a combnation of the two not to exceed a total of 30 cores (e.g. 10 A1 VMs and 20 D1 VMs).
Resource Group limits

Resources per resource group (per 800 Varies per resource type
resource type)
Deployments per resource group 800 800
Resources per deployment 800 800
Management Locks (per unique scope) 20 20
Number of Tags (per resource or 15 15

resource group)
Tag key length 512 512
Tag value length 256 256
Template limits
VALUE DEFAULT LIMIT MAXIMUM LIMIT
Parameters 256 256

VALUE DEFAULT LIMIT MAXIMUM LIMIT
Variables 256 256
Resources (including copy count) 800 800
Outputs 64 64
Template expression 24,576 chars 24,576 chars
Resources in exported templates 200 200
Template size 1 MB 1 MB
Parameter file size 64 KB 64 KB
You can exceed some template limits by using a nested template. For more information, see Using linked templates
when deploying 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.
Virtual Machines limits
Virtual Machine limits
Virtual machines per cloud service1 50 50
Input endpoints per cloud service2 150 150
1Virtual machines created in Service Management (instead of Resource Manager) are automatically stored in a
cloud service. You can add more virtual machines to that cloud service for load balancing and availability. See How
to Connect Virtual Machines with a Virtual Network or Cloud Service.
2Input 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. See
How to Set Up Endpoints to a Virtual Machine.
Virtual Machines limits - Azure Resource Manager
The following limits apply when using the Azure Resource Manager and Azure Resource Groups. Limits that have
not changed with the Azure Resource Manager are not listed below. Please refer to the previous table for those
limits.
RESOURCE DEFAULT LIMIT
Virtual machines per availability set 200
Certificates per subscription Unlimited1
1With Azure Resource Manager, certificates are stored in the Azure Key Vault. Although the number of certificates is
unlimited for a subscription, there is still a 1 MB limit of certificates per deployment (which consists of either a
single VM or an availability set).
Virtual Machine Scale Sets limits
RESOURCE MAXIMUM LIMIT
Maximum number of VMs in a scale set 1000
Maximum number of scale sets in a region 2000
Networking limits
ExpressRoute Limits
The following limits apply to ExpressRoute resources per subscription.
ExpressRoute circuits per subscription 10
ExpressRoute circuits per region per subscription for ARM 10
Maximum number of routes for Azure private peering with 4,000

ExpressRoute standard
Maximum number of routes for Azure private peering with 10,000

ExpressRoute premium add-on
Maximum number of routes for Azure public peering with 200

Maximum number of routes for Azure public peering with 200

Maximum number of routes for Azure Microsoft peering with 200

Maximum number of routes for Azure Microsoft peering with 200

Number of virtual network links allowed per ExpressRoute see table below
circuit
Number of Virtual Networks per ExpressRoute circuit
NUMBER OF VNET LINKS WITH PREMIUM

CIRCUIT SIZE NUMBER OF VNET LINKS FOR STANDARD ADD-ON
50 Mbps 10 20
100 Mbps 10 25
200 Mbps 10 25
500 Mbps 10 40
1 Gbps 10 50
2 Gbps 10 60
NUMBER OF VNET LINKS WITH PREMIUM
CIRCUIT SIZE NUMBER OF VNET LINKS FOR STANDARD ADD-ON
5 Gbps 10 75
10 Gbps 10 100
Networking limits
The following limits apply only for networking resources managed through the classic deployment model per
subscription.
Virtual networks 50 100
Local network sites 20 contact support
DNS Servers per virtual network 20 100
Private IP Addresses per virtual network 4096 4096
Concurrent TCP connections for a 500K 500K

virtual machine or role instance
Network Security Groups (NSG) 100 200
NSG rules per NSG 200 400
User defined route tables 100 200
User defined routes per route table 100 400
Public IP addresses (dynamic) 5 contact support
Reserved public IP addresses 20 contact support
Public VIP per deployment 5 contact support
Private VIP (ILB) per deployment 1 1
Endpoint Access Control Lists (ACLs) 50 50
Networking Limits - Azure Resource Manager

The following limits apply only for networking resources managed through Azure Resource Manager per region
per subscription.
Virtual networks 50 500
Subnets per virtual network 1,000 contact support
DNS Servers per virtual network 9 25

Private IP Addresses per virtual network 4096 4096
Private IP Addresses per network 50 contact support

interface
Concurrent TCP connections for a 500K 500K

virtual machine or role instance
Network Interfaces (NIC) 300 10000
Network Security Groups (NSG) 100 400
NSG rules per NSG 200 500
User defined route tables 100 200
User defined routes per route table 100 400
Public IP addresses (dynamic) 60 contact support
Public IP addresses (Static) 20 contact support
Load balancers (internal and internet 100 contact support

facing)
Load balancer rules per load balancer 150 150
Public front end IP per load balancer 10 30
Private front end IP per load balancer 10 contact support
VNets peerings per Virtual Network 10 50
Point-to-Site Root Certificates per VPN 20 20

Gateway
Secondary IP configurations per virtual 1000 contact support

network
Contact support in case you need to increase limits from default.

Application Gateway limits
RESOURCE DEFAULT LIMIT NOTE
Application Gateway 50 per subscription
Frontend IP Configurations 2 1 public and 1 private
Frontend Ports 20
Backend Address Pools 20

Backend Servers per pool 100
HTTP Listeners 20
HTTP load balancing rules 200 # of HTTP Listeners * n, n=10 Default
Backend HTTP settings 20 1 per Backend Address Pool
Instances per gateway 10
SSL certificates 20 1 per HTTP Listeners
Authentication certificates 5 Maximum 10
Request timeout min 1 second
Request timeout max 24hrs
Number of sites 20 1 per HTTP Listeners
URL Maps per listener 1
Network Watcher limits
Network Watcher 1 per region
Packet Capture sessions 10 per region # of sessions only, not saved captures
Traffic Manager limits
Profiles per subscription 100 1
Endpoints per profile 200
1Contact support in case you need to increase these limits.
DNS limits
Zones per subscription 100 1
Record sets per zone 5000 1
Records per record set 20
1 Contact Azure Support in case you need to increase these limits.
Storage limits
For additional details on storage account limits, see Azure Storage Scalability and Performance Targets.
Storage Service limits
Number of storage accounts per subscription 2001
TB per storage account 500 TB
Max number of blob containers, blobs, file shares, tables, Only limit is the 500 TB storage account capacity
queues, entities, or messages per storage account
Max size of a single blob container, table, or queue 500 TB
Max number of blocks in a block blob or append blob 50,000
Max size of a block in a block blob 100 MB
Max size of a block blob 50,000 X 100 MB (approx. 4.75 TB)
Max size of a block in an append blob 4 MB
Max size of an append blob 50,000 X 4 MB (approx. 195 GB)
Max size of a page blob 8 TB
Max size of a table entity 1 MB
Max number of properties in a table entity 252
Max size of a message in a queue 64 KB
Max size of a file share 5 TB
Max size of a file in a file share 1 TB
Max number of files in a file share Only limit is the 5 TB total capacity of the file share
Max IOPS per share 1000
Max number of files in a file share Only limit is the 5 TB total capacity of the file share
Max number of blob containers, blobs, file shares, tables, Only limit is the 500 TB storage account capacity
queues, entities, or messages per storage account
Max number of stored access policies per container, file share, 5

table, or queue
Maximum Request Rate per storage account Blobs: 20,000 requests per second for blobs of any valid size
(capped only by the account's ingress/egress limits)
Files: 1000 IOPS (8 KB in size) per file share
Queues: 20,000 messages per second (assuming 1 KB
message size)
Tables: 20,000 transactions per second (assuming 1 KB entity
size)
Target throughput for single blob Up to 60 MB per second, or up to 500 requests per second
Target throughput for single queue (1 KB messages) Up to 2000 messages per second
Target throughput for single table partition (1 KB entities) Up to 2000 entities per second
Target throughput for single file share Up to 60 MB per second
Max ingress2 per storage account (US Regions) 10 Gbps if GRS/ZRS3 enabled, 20 Gbps for LRS
Max egress2 per storage account (US Regions) 20 Gbps if RA-GRS/GRS/ZRS3 enabled, 30 Gbps for LRS
Max ingress2 per storage account (Non-US regions) 5 Gbps if GRS/ZRS3 enabled, 10 Gbps for LRS
Max egress2 per storage account (Non-US regions) 10 Gbps if RA-GRS/GRS/ZRS3 enabled, 15 Gbps for LRS
2Ingress refers to all data (requests) being sent to a storage account. Egress refers to all data (responses) being
received from a storage account.

3Azure Storage replication options include:
RA-GRS: Read-access geo-redundant storage. If RA-GRS is enabled, egress targets for the secondary location
are identical to those for the primary location.
GRS: Geo-redundant storage.
ZRS: Zone-redundant storage. Available only for block blobs.
LRS: Locally redundant storage.
Virtual machine disk limits
An Azure virtual machine supports attaching a number of data disks. For optimal performance, you will want to
limit the number of highly utilized disks attached to the virtual machine to avoid possible throttling. If all disks are
not being highly utilized at the same time, the storage account can support a larger number disks.
For Azure Managed Disks: Managed Disks count limit is regional for the subscription. The default soft limit
is 2,000 per region per subscription. To increase your limit, contact Azure support.
Managed Snapshots and Images are counted against the Managed Disks limit.
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 (20,000/300 IOPS per disk), and for a Standard Tier VM, it is about 40 (20,000/500
IOPS per disk), as shown in the table below.
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.
See Virtual machine sizes for additional details.
Managed virtual machine disks
Standard managed virtual machine disks
STANDARD
DISK TYPE S4 S6 S10 S20 S30 S40 S50
Disk size 30 GB 64 GB 128 GB 512 GB 1024 GB (1 2048 GB 4095 GB (4

TB) (2TB) TB)
IOPS per 500 500 500 500 500 500 500

disk
Throughput 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec

per disk
Premium managed virtual machine disks: per disk limits
PREMIUM
DISKS TYPE P4 P6 P10 P20 P30 P40 P50
Disk size 128 GB 512 GB 128 GB 512 GB 1024 GB (1 2048 GB (2 4095 GB (4

TB) TB) TB)
IOPS per 120 240 500 2300 5000 7500 7500

disk
Throughput 25 MB/sec 50 MB/sec 100 MB/sec 150 MB/sec 200 MB/sec 250 MB/sec 250 MB/sec
per disk
Premium managed virtual machine disks: per VM limits
Max IOPS Per VM 80,000 IOPS with GS5 VM1
Max throughput per VM 2,000 MB/s with GS5 VM1
1Refer to VM Size for limits on other VM sizes.

Unmanaged virtual machine disks
Standard unmanaged virtual machine disks: per disk limits
VM TIER BASIC TIER VM STANDARD TIER VM
Disk size 4095 GB 4095 GB
Max 8 KB IOPS per persistent disk 300 500

VM TIER BASIC TIER VM STANDARD TIER VM
Max number of disks performing max 66 40

IOPS
Premium unmanaged virtual machine disks: per account limits
Total disk capacity per account 35 TB
Total snapshot capacity per account 10 TB
Max bandwidth per account (ingress + egress1 ) <=50 Gbps
1Ingress refers to all data (requests) being sent to a storage account. Egress refers to all data (responses) being
received from a storage account.

Premium unmanaged virtual machine disks: per disk limits
PREMIUM
STORAGE DISK
TYPE P10 P20 P30 P40 P50
Disk size 128 GiB 512 GiB 1024 GiB (1 TB) 2048 GiB (2 TB) 4095 GiB (4 TB)
Max IOPS per 500 2300 5000 7500 7500

disk
Max throughput 100 MB/s 150 MB/s 200 MB/s 250 MB/s 250 MB/s
per disk
Max number of 280 70 35 17 8

disks per storage
account
Premium unmanaged virtual machine disks: per VM limits
Max IOPS Per VM 80,000 IOPS with GS5 VM1
Max throughput per VM 2,000 MB/s with GS5 VM1
1Refer to VM Size for limits on other VM sizes.

Storage Resource Provider limits
The following limits apply when using the Azure Resource Manager and Azure Resource Groups only.
Storage account management operations (read) 800 per 5 minutes
Storage account management operations (write) 200 per hour

Storage account management operations (list) 100 per 5 minutes
Cloud Services limits

Web/worker roles per deployment1 25 25
Instance Input Endpoints per 25 25

deployment
Input Endpoints per deployment 25 25
Internal Endpoints per deployment 25 25
1Each Cloud Service with Web/Worker roles can have two deployments, one for production and one for staging.
Also note that this limit refers to the number of distinct roles (configuration) and not the number of instances per
role (scaling).
App Service limits
The following App Service limits include limits for Web Apps, Mobile Apps, API Apps, and Logic Apps.
PREMIUM
RESOURCE FREE SHARED (PREVIEW) BASIC STANDARD (PREVIEW)
Web, mobile, or 10 100 Unlimited2 Unlimited2 Unlimited2

API apps per App
Service plan1
Logic apps per 10 10 10 20 per core 20 per core

App Service plan1
App Service plan 1 per region 10 per resource 100 per resource 100 per resource 100 per resource
group group group group
Compute Shared Shared Dedicated3 Dedicated3 Dedicated3

instance type
Scale-Out (max 1 shared 1 shared 3 dedicated3 10 dedicated3 20 dedicated (50

instances) in ASE)3,4
Storage5 1 GB5 1 GB5 10 GB5 50 GB5 500 GB4,5
CPU time (5 3 minutes 3 minutes Unlimited, pay at Unlimited, pay at Unlimited, pay at
min)6 standard rates standard rates standard rates
CPU time (day)6 60 minutes 240 minutes Unlimited, pay at Unlimited, pay at Unlimited, pay at
standard rates standard rates standard rates
Memory (1 hour) 1024 MB per 1024 MB per app N/A N/A N/A
App Service plan
PREMIUM
RESOURCE FREE SHARED (PREVIEW) BASIC STANDARD (PREVIEW)
Bandwidth 165 MB Unlimited, data Unlimited, data Unlimited, data Unlimited, data
transfer rates transfer rates transfer rates transfer rates
apply apply apply apply
Application 32-bit 32-bit 32-bit/64-bit 32-bit/64-bit 32-bit/64-bit

architecture
Web Sockets per 5 35 350 Unlimited Unlimited

instance7
Concurrent 1 1 1 5 5
debugger
connections per
application
azurewebsites.net X X X X X
subdomain with
FTP/S and SSL
Custom domain X X X X
support
Custom domain Unlimited Unlimited, 5 SNI Unlimited, 5 SNI

SSL support SSL and 1 IP SSL SSL and 1 IP SSL
connections connections
included included
Integrated Load X X X X
Balancer
Always On X X X
Scheduled Once per day Once every 5

Backups minutes8
Auto Scale X X X
WebJobs9 X X X X X
Azure Scheduler X X X X
support
Endpoint X X X
monitoring
Staging Slots 5 20
Custom domains 500 500 500 500

per app
SLA 99.9% 99.95%10 99.95%10
1Apps and storage quotas are per App Service plan unless noted otherwise.
2
2The 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.
3Dedicated instances can be of different sizes. See App Service Pricing for more details.
4Premium tier allows up to 50 computes instances (subject to availability) and 500 GB of disk space when using
App Service Environments, and 20 compute instances and 250 GB storage otherwise.
5The storage limit is the total content size across all apps in the same App Service plan. More storage options are
available in App Service Environment

6These resources are constrained by physical resources on the dedicated instances (the instance size and the
number of instances).
7If you scale an app in the Basic tier to two instances, you have 350 concurrent connections for each of the two
instances.
8Premium tier allows backup intervals down up to every 5 minutes when using App Service Environments, and 50
times per day otherwise.

9Run 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. Azure Scheduler Free or
Standard is required for scheduled WebJobs. There is no predefined limit on the number of WebJobs that can run
in an App Service instance, but there are practical limits that depend on what the application code is trying to do.
10SLA of 99.95% provided for deployments that use multiple instances with Azure Traffic Manager configured for
failover.
Scheduler limits
The following table describes each of the major quotas, limits, defaults, and throttles in Azure Scheduler.
RESOURCE LIMIT DESCRIPTION
Job size Maximum job size is 16K. If a PUT or a PATCH results in a job
larger than these limits, a 400 Bad Request status code is
returned.
Request URL size Maximum size of the request URL is 2048 chars.
Aggregate header size Maximum aggregate header size is 4096 chars.
Header count Maximum header count is 50 headers.
Body size Maximum body size is 8192 chars.
Recurrence span Maximum recurrence span is 18 months.
Time to start time Maximum time to start time is 18 months.
Job history Maximum response body stored in job history is 2048 bytes.
Frequency The default max frequency quota is 1 hour in a free job

collection and 1 minute in a standard job collection. The max
frequency is configurable on a job collection to be lower than
the maximum. All jobs in the job collection are limited the
value set on the job collection. If you attempt to create a job
with a higher frequency than the maximum frequency on the
job collection then request will fail with a 409 Conflict status
code.
RESOURCE LIMIT DESCRIPTION
Jobs The default max jobs quota is 5 jobs in a free job collection
and 50 jobs in a standard job collection. The maximum
number of jobs is configurable on a job collection. All jobs in
the job collection are limited the value set on the job
collection. If you attempt to create more jobs than the
maximum jobs quota, then the request fails with a 409
Conflict status code.
Job collections Maximum number of job collection per subscription is

200,000.
Job history retention Job history is retained for up to 2 months or up to the last
1000 executions.
Completed and faulted job retention Completed and faulted jobs are retained for 60 days.
Timeout Theres a static (not configurable) request timeout of 60

seconds for HTTP actions. For longer running operations,
follow HTTP asynchronous protocols; for example, return a
202 immediately but continue working in the background.
Batch limits
Batch accounts per region per 3 50

subscription
Dedicated cores per Batch account 20 N/A2

(Batch service mode)1
Low-priority cores per Batch account 50 N/A4

(Batch service mode)3
Active jobs and job schedules5 per 20 50006

Batch account
Pools per Batch account 20 2500
1 Dedicated core quotas shown are only for accounts with pool allocation mode set to Batch service. For accounts
with the mode set to user subscription, core quotas are based on the VM cores quota at a regional level or per VM
family in your subscription.
2 The number of dedicated cores per Batch account can be increased, but the maximum number is unspecified.
Contact Azure support to discuss increase options.
3 Low-priority core quotas shown are only for accounts with pool allocation mode set to Batch service. Low-
priority cores are not available for accounts with pool allocation mode set to user subscription.
4 The number of low-priority cores per Batch account can be increased, but the maximum number is unspecified.
Contact Azure support to discuss increase options.
5 Completed jobs and job schedules are not limited.
6 Contact Azure support if you want to request an increase beyond this limit.
BizTalk Services limits
The following table shows the limits for Azure Biztalk Services.
RESOURCE FREE (PREVIEW) DEVELOPER BASIC STANDARD PREMIUM
Scale out N/A N/A Yes, in Yes, in Yes, in

increments of 1 increments of 1 increments of 1
Basic Unit Standard Unit Premium Unit
Scale Limit N/A N/A Up to 8 units Up to 8 units Up to 8 units
EAI Bridges per N/A 25 25 125 500

Unit
EDI Agreements N/A 10 50 250 1000

per Unit
Hybrid 5 5 10 50 100
Connections per
Unit
Hybrid 5 5 50 250 500

Connection Data
Transfer (GBs) per
Unit
Number of N/A 1 2 5 25
connections
using BizTalk
Adapter Service
per Unit
Archiving N/A Available N/A N/A Available
High Availability N/A N/A Available Available Available
DocumentDB limits
DocumentDB is a global scale database in which throughput and storage can be scaled to handle whatever your
application requires. If you have any questions about the scale DocumentDB provides, please send email to
askdocdb@microsoft.com.
Mobile Engagement limits
App Collection Users 5 per App Collection
Average Data points 200 per Active User/Day
Average App-Info set 50 per Active User/Day
Average Messages pushed 20 per Active User/Day
Segments 100 per app

Criteria per segment 10
Active Push Campaigns 50 per app
Total Push Campaigns (includes Active & Completed) 1000 per app
Search limits
Pricing tiers determine the capacity and limits of your search service. Tiers include:
Free multi-tenant service, shared with other Azure subscribers, 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 (S1, S2, S3, 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 within a subscription, each one provisioned at a specific tier, limited only by the
number of services allowed at each tier. For example, you could create up to 12 services at the Basic tier and
another 12 services at the S1 tier within the same subscription. For more information about tiers, see Choose a SKU
or tier for Azure Search.
Maximum service limits can be raised upon request. Contact Azure Support if you need more services within the
same subscription.
RESOURCE FREE BASIC S1 S2 S3 S3 HD 1
Maximum 1 12 12 6 6 6
services
Maximum N/A 3 3 SU 4 36 SU 36 SU 36 SU 36 SU
scale in SU 2
1 S3 HD does not support indexers at this time.

2 Search units (SU) 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 how search units are computed, plus a chart of valid
combinations that stay under the maximum limits, see Scale resource levels for query and index workloads.
3 Free is based on shared resources used by multiple subscribers. At this tier, there are no dedicated resources for
an individual subscriber. For this reason, maximum scale is marked as not applicable.
4 Basic has one fixed partition. At this tier, additional SUs are used for allocating more replicas for increased query
workloads.
Limits per search service
Storage is constrained by disk space or by a hard limit on the maximum number of indexes or documents,
whichever comes first.
RESOURCE FREE BASIC S1 S2 S3 S3 HD
Service Level No 1 Yes Yes Yes Yes Yes

Agreement
(SLA)
Storage per 50 MB 2 GB 25 GB 100 GB 200 GB 200 GB

partition
Partitions per N/A 1 12 12 12 32

service
Partition size N/A 2 GB 25 GB 100 GB 200 GB 200 GB
Replicas N/A 3 12 12 12 12
Maximum 3 5 50 200 200 1000 per

indexes partition or
3000 per
service
Maximum 3 5 50 200 200 No indexer

indexers support
Maximum 3 5 50 200 200 No indexer

datasources support
Maximum 10,000 1 million 15 million per 60 million per 120 million 1 million per
documents partition or partition or per partition index or 200
180 million 720 million or 1.4 billion million per
per service per service per service partition
Estimated N/A ~3 per replica ~15 per ~60 per ~60 per >60 per
queries per replica replica replica replica
second (QPS)
1 Free tier
and preview features do not come with service level agreements (SLAs). For all billable tiers, SLAs take
effect when you provision sufficient redundancy for your service. Two or more replicas are required for query
(read) SLA. Three or more replicas are required for query and indexing (read-write) SLA. The number of partitions is
not an SLA consideration.
2 S3 HD has a hard limit of 3 partitions, which is lower than the partition limit for S3. The lower partition limit is
imposed because the index count for S3 HD is substantially higher. Given that service limits exist for both
computing resources (storage and processing) and content (indexes and documents), the content limit is reached
first.
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 Search.
Media Services limits
NOTE
For resources that are not fixed, you may ask for the quotas to be raised, by opening a support ticket. Do not create
additional Azure Media Services accounts in an attempt to obtain higher limits.
Azure Media Services (AMS) accounts in a single subscription 25 (fixed)
Media Reserved Units (RUs) per AMS account 25 (S1, S2)

10 (S3) (1)
Jobs per AMS account 50,000(2)
Chained tasks per job 30 (fixed)
Assets per AMS account 1,000,000
Assets per task 50
Assets per job 100
Unique locators associated with an asset at one time 5(4)
Live channels per AMS account 5
Programs in stopped state per channel 50
Programs in running state per channel 3
Streaming endpoints in running state per AMS account 2
Streaming units per streaming endpoint 10
Storage accounts 1,000(5) (fixed)
Policies 1,000,000(6)
File size In some scenarios there is a limit on the maximum file size
supported for processing in Media Services. 7
1 S3 RUs are not available in India West.

2 This number includes queued, finished, active, and canceled jobs. It does not include deleted jobs. You can delete
the old jobs using IJob.Delete or the DELETE HTTP request.
Starting April 1, 2017, any Job record in your account older than 90 days will be automatically deleted, along with
its associated Task records, even if the total number of records is below the maximum quota. If you need to archive
the job/task information, you can use the code described here.
3 When making a request to list Job entities, a maximum of 1,000 will be returned per request. If you need to keep
track of all submitted Jobs, you can use top/skip as described in OData system query options.
4 Locators are not designed for
managing per-user access control. To give different access rights to individual users,
use Digital Rights Management (DRM) solutions. For more information, see this section.
5 The storage accounts must be from the same Azure subscription.
6 There is a limit of 1,000,000
policies for different AMS policies (for example, for Locator policy or
ContentKeyAuthorizationPolicy).
NOTE
You should use the same policy ID if you are always using the same days / access permissions / etc. For information and an
example, see this section.
7If you are uploading content to an Asset in Azure Media Services with the intent to process it with one of the media
processors in our service (i.e. encoders like Media Encoder Standard and Media Encoder Premium Workflow, or
analysis engines like Face Detector), then you should be aware of the constraint on the maximum size.
As of May 15, 2017, the maximum size supported for a single blob is 195 TB - with file largers than this limit, your
Task will fail. We are working a fix to address this limit. In addition, the constraint on the maximum size of the Asset
is as follows.
MEDIA RESERVED UNIT TYPE MAXIMUM INPUT SIZE (GB)
S1 325
S2 640
S3 260
CDN limits
RESOURCE SOFT LIMIT
CDN profiles 8
CDN endpoints per profile 10
Custom domains per endpoint 10
Request an update to your subscription's soft limits by opening a support ticket.

Mobile Services limits
TIER: FREE BASIC STANDARD
API Calls 500 K 1.5 M / unit 15 M / unit
Active Devices 500 Unlimited Unlimited
Scale N/A Up to 6 units Unlimited units
Push Notifications Notification Hubs Free Tier Notification Hubs Basic Tier Notification Hubs Standard
included, up to 1 M pushes included, up to 10 M pushes Tier included, up to 10 M
pushes
Real time messaging/ Limited 350 / mobile service Unlimited

Web Sockets
Offline synchronizations Limited Included Included
Scheduled jobs Limited Included Included

SQL Database (required) 20 MB included 20 MB included 20 MB included

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

Rollover)
For additional details on these limits and for information on pricing, see Mobile Services Pricing.
Monitor limits
RESOURCE LIMIT
Autoscale Settings 100 per region per subscription
Metric Alerts 100 active alert rules per subscription
Notification Hub Service limits

Included Pushes 1 Million 10 Million 10 Million
Active Devices 500 200,000 10 million
Tag quota per 60 60 60

installation/registration
For additional details on these limits and for information on pricing, see Notification Hubs Pricing.
Event Hubs limits
The following table lists quotas and limits specific to Azure Event Hubs. For information about Event Hubs pricing,
see Event Hubs pricing.
BEHAVIOR WHEN
LIMIT SCOPE TYPE EXCEEDED VALUE
Number of Event Namespace Static Subsequent requests 10

Hubs per namespace for creation of a new
namespace will be
rejected.
Number of partitions Entity Static - 32

per Event Hub
Number of consumer Entity Static - 20

groups per Event Hub
BEHAVIOR WHEN
LIMIT SCOPE TYPE EXCEEDED VALUE
Number of AMQP Namespace Static Subsequent requests 5,000

connections per for additional
namespace connections will be
rejected and an
exception is received
by the calling code.
Maximum size of System-wide Static - 256 KB

Event Hubs event
Maximum size of an Entity Static - 50 characters

Event Hub name
Number of non- Entity Static - 5

epoch receivers per
consumer group
Maximum retention Entity Static - 1-7 days

period of event data
Maximum throughput Namespace Static Exceeding the 20

units throughput unit limit
causes your data to
be throttled and
generates a
ServerBusyExceptio
n. You can request a
larger number of
throughput units for a
Standard tier by filing
a support request.
Additional throughput
units are available in
blocks of 20 on a
committed purchase
basis.
Service Bus limits

The following table lists quota information specific to Service Bus messaging. For information about pricing and
other quotas for Service Bus, see the Service Bus Pricing overview.
BEHAVIOR WHEN
QUOTA NAME SCOPE TYPE EXCEEDED VALUE
Maximum number of Namespace Static Subsequent requests 100

basic / standard for additional basic /
namespaces per standard namespaces
Azure subscription will be rejected by the
portal.
Maximum number of Namespace Static Subsequent requests 10

premium namespaces for additional
per Azure premium namespaces
subscription will be rejected by the
portal.
BEHAVIOR WHEN
Queue/topic size Entity Defined upon creation Incoming messages 1, 2, 3, 4 or 5 GB.

of the queue/topic. will be rejected and an
exception will be If partitioning is
received by the calling enabled, the
code. maximum queue/topic
size is 80 GB.
Number of concurrent Namespace Static Subsequent requests NetMessaging: 1,000

connections on a for additional
namespace connections will be AMQP: 5,000
rejected and an
exception will be
received by the calling
code. REST operations
do not count towards
concurrent TCP
connections.
Number of concurrent Entity Static Subsequent receive 5,000

receive requests on a requests will be
queue/topic/subscripti rejected and an
on entity exception will be
code. This quota
applies to the
combined number of
concurrent receive
operations across all
subscriptions on a
topic.
Number of System-wide Static Subsequent requests 10,000

topics/queues per for creation of a new
service namespace topic or queue on the The total number of
service namespace will topics plus queues in
be rejected. As a a service namespace
result, if configured must be less than or
through the Azure equal to 10,000.
portal, an error This is not applicable
message will be to Premium as all
generated. If called entities are
from the partitioned.
management API, an
exception will be
code.
BEHAVIOR WHEN
Number of System-wide Static Subsequent requests Basic and Standard

partitioned for creation of a new Tiers - 100
topics/queues per partitioned topic or Premium - 1,000 (per
service namespace queue on the service messaging unit)
namespace will be
rejected. As a result, if Each partitioned
configured through queue or topic counts
the Azure portal, an towards the quota of
error message will be 10,000 entities per
generated. If called namespace.
from the
management API, a
QuotaExceededExce
ption exception will
be received by the
calling code.
Maximum size of any Entity Static - 260 characters

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

messaging entity
name: namespace,
subscription, or
subscription rule
Message size for a System-wide Static Incoming messages Maximum message

queue/topic/subscripti that exceed these size: 256KB (Standard
on entity quotas will be rejected tier) / 1MB (Premium
and an exception will tier).
be received by the
calling code. Note Due to system
overhead, this limit is
usually slightly less.
Maximum header size:

64KB
Maximum number of
header properties in
property bag:
byte/int.MaxValue
Maximum size of
property in property
bag: No explicit limit.
Limited by maximum
header size.
BEHAVIOR WHEN
Message property System-wide Static A Maximum message

size for a SerializationExcepti property size for each
queue/topic/subscripti on exception is property is 32K.
on entity generated. Cumulative size of all
properties cannot
exceed 64K. This
applies to the entire
header of the
BrokeredMessage,
which has both user
properties as well as
system properties
(such as
SequenceNumber,
Label, MessageId, and
so on).
Number of System-wide Static Subsequent requests 2,000

subscriptions per for creating additional
topic subscriptions for the
topic will be rejected.
As a result, if
configured through
the portal, an error
message will be
shown. If called from
the management API
an exception will be
code.
Number of SQL filters System-wide Static Subsequent requests 2,000

per topic for creation of
additional filters on
the topic will be
rejected and an
exception will be
code.
Number of correlation System-wide Static Subsequent requests 100,000

filters per topic for creation of
additional filters on
the topic will be
rejected and an
exception will be
code.
BEHAVIOR WHEN
Size of SQL System-wide Static Subsequent requests Maximum length of

filters/actions for creation of filter condition string:
additional filters will 1024 (1K).
be rejected and an
exception will be Maximum length of
received by the calling rule action string:
code. 1024 (1K).
Maximum number of
expressions per rule
action: 32.
Number of Entity, namespace Static Subsequent requests Maximum number of

SharedAccessAuthoriz for creation of rules: 12.
ationRule rules per additional rules will be
namespace, queue, or rejected and an Rules that are
topic exception will be configured on a
received by the calling Service Bus
code. namespace apply to
all queues and topics
in that namespace.
IoT Hub limits

The following table lists the limits associated with the different service tiers (S1, S2, S3, F1). For information about
the cost of each unit in each tier, see IoT Hub Pricing.
RESOURCE S1 STANDARD S2 STANDARD S3 STANDARD F1 FREE
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 or 10 units with an S3 tier hub, contact Microsoft support.
The following table lists the limits that apply to IoT Hub resources:
RESOURCE LIMIT
Maximum paid IoT hubs per Azure subscription 10
Maximum free IoT hubs per Azure subscription 1
Maximum number of device identities 1000

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

messages
Maximum size of device-to-cloud message 256 KB

RESOURCE LIMIT
Maximum size of device-to-cloud batch 256 KB
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 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

(tags, reported properties, and desired properties)
Maximum size of device twin string value 512 bytes
Maximum depth of object in device twin 5
Maximum size of direct method payload 8 KB
Job history maximum retention 30 days
Maximum concurrent jobs 10 (for S3), 5 for (S2), 1 (for S1)
Maximum additional endpoints 10 (for S1, S2, S3)
Maximum message routing rules 100 (for S1, S2, S3)
NOTE
If you need more than 10 paid IoT hubs in an Azure subscription, contact Microsoft support.
NOTE
Currently, the maximum number of devices you can connect to a single IoT hub is 500,000. If you want to increase this limit,
contact Microsoft Support.
The IoT Hub service throttles requests when the following quotas are exceeded:
THROTTLE PER-HUB VALUE
Identity registry operations 83.33/sec/unit (5000/min/unit) (for S3)

(create, retrieve, list, update, delete), 1.67/sec/unit (100/min/unit) (for S1 and S2).
individual or bulk import/export
THROTTLE PER-HUB VALUE
Device connections 6000/sec/unit (for S3), 120/sec/unit (for S2), 12/sec/unit (for
S1).
Minimum of 100/sec.
Device-to-cloud sends 6000/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 (5000/min/unit) (for S3), 1.67/sec/unit

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

(1000/min/unit) (for S1 and S2).
File upload operations 83.33 file upload notifications/sec/unit (5000/min/unit) (for

S3), 1.67 file upload notifications/sec/unit (100/min/unit) (for
S1 and S2).
10000 SAS URIs can be out for an Azure Storage account at
one time.
10 SAS URIs/device can be out at one time.
Direct methods 1500/sec/unit (for S3), 30/sec/unit (for S2), 10/sec/unit (for S1)
Device twin reads 50/sec/unit (for S3), Maximum of 10/sec or 1/sec/unit (for S2),
10/sec (for S1)
Device twin updates 50/sec/unit (for S3), Maximum of 10/sec or 1/sec/unit (for S2),
10/sec (for S1)
Jobs operations 83.33/sec/unit (5000/min/unit) (for S3), 1.67/sec/unit

(create, update, list, 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)
Data Factory limits

Data factory is a multi-tenant service that has the following default limits in place to make sure customer
subscriptions are protected from each other's workloads. Many of the limits can be easily raised for your
subscription up to the maximum limit by contacting support.
data factories in an Azure subscription 50 Contact support
pipelines within a data factory 2500 Contact support
datasets within a data factory 5000 Contact support
concurrent slices per dataset 10 10
bytes per object for pipeline objects 1 200 KB 200 KB

bytes per object for dataset and linked 100 KB 2000 KB

service objects 1
HDInsight on-demand cluster cores 60 Contact support

within a subscription 2
Cloud data movement unit 3 32 Contact support
Retry count for pipeline activity runs 1000 MaxInt (32 bit)
1 Pipeline, dataset, and linked service objects represent a logical grouping of your
workload. Limits for these objects
do not relate to amount of data you can move and process with the Azure Data Factory service. Data factory is
designed to scale to handle petabytes of data.
2 On-demand HDInsight cores are allocated out of the subscription that contains the data factory. As a result, the
above limit is the Data Factory enforced core limit for on-demand HDInsight cores and is different from the core
limit associated with your Azure subscription.
3 Cloud data movement unit (DMU) is being used in a cloud-to-cloud copy operation. It is a measure that
represents the power (a combination of CPU, memory, and network resource allocation) of a single unit in Data
Factory. You can achieve higher copy throughput by leveraging more DMUs for some scenarios. Refer to Cloud
data movement units section on details.
RESOURCE DEFAULT LOWER LIMIT MINIMUM LIMIT
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.
Data Lake Analytics limits
Data Lake Analytics makes the complex task of managing distributed infrastructure and complex code easy. It
dynamically provisions resources and lets you do analytics on exabytes of data. When the job completes, it winds
down resources automatically, and you pay only for the processing power used. As you increase or decrease the
size of data stored or the amount of compute used, you dont have to rewrite code. Many of the default limits can
be easily raised for your subscription by contacting support.
RESOURCE DEFAULT LIMIT COMMENTS
max concurrent jobs 3
Max parallelism per account 60 Use any combination of up to a

maximum of 60 units of parallelism
across three jobs.
Data Lake Store limits

Azure Data Lake Store is an enterprise-wide hyper-scale repository for big data analytic workloads. Data Lake Store
enables you to capture data of any size, type, and ingestion speed in one single place for operational and
exploratory analytics. There is no limit to the amount of data you can store in a Data Lake Store account.
Max number of Data Lake Store 10 Contact Support to request an increase

accounts, per subscription, per region for this limit
Max number of access ACLs, per file or 32 This is a hard limit. Use groups to
folder manage access with fewer entries
Max number of default ACLs, per file or 32 This is a hard limit. Use groups to
folder manage access with fewer entries
Stream Analytics limits
LIMIT IDENTIFIER LIMIT COMMENTS
Maximum number of Streaming Units 50 A request to increase streaming units

per subscription per region for your subscription beyond 50 can be
made by contacting Microsoft Support.
Maximum throughput of a Streaming 1MB/s* Maximum throughput per SU depends

Unit on the scenario. Actual throughput may
be lower and depends upon query
complexity and partitioning. Further
details can be found in the Scale Azure
Stream Analytics jobs to increase
throughput article.
Maximum number of inputs per job 60 There is a hard limit of 60 inputs per
Stream Analytics job.
Maximum number of outputs per job 60 There is a hard limit of 60 outputs per
Maximum number of functions per job 60 There is a hard limit of 60 functions per
Maximum number of Streaming Units 120 There is a hard limit of 120 Streaming
per job Units per Stream Analytics job.
Maximum number of jobs per region 1500 Each subscription may have up to 1500
jobs per geographical region.
Reference data blob MB 100 Reference data blobs cannot be larger

than 100 MB each.
Active Directory limits

Here are the usage constraints and other service limits for the Azure Active Directory service.
CATEGORY LIMITS
CATEGORY LIMITS
Directories A single user can only be associated with a maximum of 20

Azure Active Directory directories.
Examples of possible combinations:
A single user creates 20 directories.
A single user is added to 20 directories as a member.
A single user creates 10 directories and later is added
by others to 10 different directories.
Objects A maximum of 500,000 objects can be used in a single

directory by users of the Free edition of Azure Active
Directory.
A non-admin user can create no more than 250
objects.
Schema extensions String type extensions can have maximum of 256

characters.
Binary type extensions are limited to 256 bytes.
100 extension values (across ALL types and ALL
applications) can be written to any single object.
Only User, Group, TenantDetail, Device,
Application and ServicePrincipal entities can be
extended with String type or Binary type single-
valued attributes.
Schema extensions are available only in Graph API-
version 1.21-preview. The application must be granted
write access to register an extension.
Applications A maximum of 100 users can be owners of a single

application.
Groups A maximum of 100 users can be owners of a single

group.
Any number of objects can be members of a single
group in Azure Active Directory.
The number of members in a group you can
synchronize from your on-premises Active Directory to
Azure Active Directory is limited to 15K members,
using Azure Active Directory Directory Synchronization
(DirSync).
The number of members in a group you can
synchronize from your on-premises Active Directory to
Azure Active Directory using Azure AD Connect is
limited to 50K members.
Access Panel There is no limit to the number of applications that can

be seen in the Access Panel per end user, for users
assigned licenses for Azure AD Premium or the
Enterprise Mobility Suite.
A maximum of 10 app tiles (examples: Box, Salesforce,
or Dropbox) can be seen in the Access Panel for each
end user for users assigned licenses for Free or Azure
AD Basic editions of Azure Active Directory. This limit
does not apply to Administrator accounts.
CATEGORY LIMITS
Reports A maximum of 1,000 rows can be viewed or downloaded in

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

units.
Azure RemoteApp limits

Collections per user 1
Published apps per collection 100
Paid collections 3
Paid template images 25
Users - basic tier 800 maximum
Users - standard tier 500 maximum
Users- premium tier 100 maximum
Users - premium plus tier 50 maximum
User data storage (UPD) per user per collection 50 GB
Idle timeout 4 hours
Disconnected timeout 4 hours
The number of users is determined by the number of VMs used for your collection:
Basic = 16 users per VM
Standard = 10 users per VM
Premium = 4 users per VM
Premium plus = 2 users per VM
StorSimple System limits
Maximum number of storage account 64

credentials
Maximum number of volume containers 64
Maximum number of volumes 255
Maximum number of schedules per 168 A schedule for every hour, every day of
bandwidth template the week (24*7).
Maximum size of a tiered volume on 64 TB for 8100 and 8600 8100 and 8600 are physical devices.
physical devices
Maximum size of a tiered volume on 30 TB for 8010 8010 and 8020 are virtual devices in
virtual devices in Azure 64 TB for 8020 Azure that use Standard Storage and
Premium Storage respectively.
Maximum size of a locally pinned 9 TB for 8100 8100 and 8600 are physical devices.
volume on physical devices 24 TB for 8600
Maximum number of iSCSI connections 512
Maximum number of iSCSI connections 512

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 includes local snapshots and cloud
type that can be retained per volume 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 will be processed
restore, or clone sequentially as processing slots
become available.
New backups of a cloned or a
restored tiered volume cannot
occur until the operation is
finished. However, 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 restore or
clone operation, regardless of
the volume size.
The volume performance may
initially be slower than normal as
most of the data and metadata
still resides in the cloud.
Performance may 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
may 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 cannot 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 may
initially be slower than normal as
most of the data and metadata
still resides in the cloud.
Performance may 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
may be affected by Internet
bandwidth to the cloud.
Unlike tiered volumes, in the
case of 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 may 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 throughput 920/720 MB/s with a single 10GbE Up to 2x with MPIO and two network
(when served from the SSD tier)* network interface interfaces.
Maximum client read/write throughput 120/250 MB/s

(when served from the HDD tier)*
Maximum client read/write throughput 11/41 MB/s Read throughput depends on clients
(when served from the cloud tier)* generating and maintaining sufficient
I/O queue depth.
* Maximum throughput per I/O type was measured with 100 percent read and 100 percent write scenarios. Actual
throughput may be lower and depends on I/O mix and network conditions.
Log Analytics limits
NOTE
Log Analytics was formerly known as Operational Insights.
The following limits apply to Log Analytics resources per subscription:
Number of free workspaces per 10 This limit cannot be increased.

subscription
Number of paid workspaces per N/A You are limited by the number of
subscription resources within a resource group and
number of resource groups per
subscription
The following limits apply to each Log Analytics workspace:
FREE STANDARD PREMIUM STANDALONE OMS
Data volume 500 MB1 None None None None

collected per day
Data retention 7 days 1 month 12 months 1 month2 1 month 2

period
1 When customers reach their 500 MB daily data transfer limit, data analysis stops and resumes at the start of the
next day. A day is based on UTC.
2 The data retention period for the Standalone and OMS pricing plans can be increased to 730 days.
CATEGORY LIMITS COMMENTS
Data Collector API Maximum size for a single post is 30 Split larger volumes into multiple posts
MB Fields longer than 32 KB are truncated.
Maximum size for field values is 32 KB
Search API 5000 records returned for non- Aggregated data is a search that
aggregated data includes the measure command
500000 records for aggregated data
Backup limits
The following limits apply to Azure Backup.
LIMIT IDENTIFIER DEFAULT LIMIT
Number of servers/machines that can be registered against 50 for Windows Server/Client/SCDPM

each vault 200 for IaaS VMs
Size of a data source for data stored in Azure vault storage 54400 GB max1
Number of backup vaults that can be created in each Azure 25(Backup vaults)
subscription 25 Recovery Services vault per region
Number of times backup can be scheduled per day 3 per day for Windows Server/Client
2 per day for SCDPM
Once a day for IaaS VMs
Data disks attached to an Azure virtual machine for backup 16
1The 54400 GB limit does not apply to IaaS VM backup.

Site Recovery limits
The following limits apply to Azure Site Recovery:
Number of vaults per subscription 25
Number of servers per Azure vault 250
Number of protection groups per Azure vault No limit
Number of recovery plans per Azure vault No limit
Number of servers per protection group No limit
Number of servers per recovery plan 50
Application Insights limits

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.
Total data per day 500 GB You can reduce data by setting a cap. If
you need more, mail
AIDataCap@microsoft.com.
Free data per month 1 GB Additional data is charged per gigabyte.

(Basic price plan)
Throttling 32 k events/second The limit is measured over a minute.
Data retention 90 days This resource is for Search, Analytics,

and Metrics Explorer.
Availability multi-step test detailed 90 days This resource provides detailed results
results retention of each step.
Maximum event size 64 K
Property and metric name length 150 See type schemas
Property value string length 8,192 See type schemas

Trace and exception message length 10 k See type schemas
Availability tests count per app 10
Profiler data retention 5 days
Profiler data sent per day 10GB
For more information, see About pricing and quotas in Application Insights.
API Management limits
RESOURCE LIMIT
API Calls (per unit of scale) 32 million per day1
Data transfer (per unit of scale) 161 GB per day1
Cache 5 GB1
Units of scale Unlimited1
Azure Active Directory Integration Unlimited User Accounts1
1API Management limits are different foreach pricing tier. To see the pricing tiers and their associated limits and
scaling options, see API Management Pricing.
Azure Redis Cache limits
RESOURCE LIMIT
Cache size 530 GB
Databases 64
Max connected clients 40,000
Redis Cache replicas (for high availability) 1
Shards in a premium cache with clustering 10
Azure Redis Cache limits and sizes are different for each pricing tier. To see the pricing tiers and their associated
sizes, see Azure Redis Cache Pricing.
For more information on Azure Redis Cache configuration limits, see Default Redis server configuration.
Because configuration and management of Azure Redis Cache instances is done by Microsoft, not all Redis
commands are supported in Azure Redis Cache. For more information, see Redis commands not supported in
Azure Redis Cache.
Key Vault limits
MAX TRANSACTIONS ALLOWED IN 10 SECONDS, PER VAULT PER
TRANSACTIONS TYPE REGION1
HSM- CREATE KEY 5
HSM- other transactions 1000
Soft-key CREATE KEY 10
Soft-key other transactions 1500
All secrets, vault related transactions 2000
1 There is a subscription-wide limit forall transaction types, that is 5x per key vault limit. For example, HSM- other
transactions per subscription are limited to 5000 transactions in 10 seconds per subscription.
Multi-Factor Authentication
Max number of Trusted IP 0 50

addresses/ranges per subscription
Remember my devices - number of 14 60

days
Max 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 1800
Lock user account after X consecutive Not Set 99

MFA denials
Reset account lockout counter after X Not Set 9999

minutes
Unlock account after X minutes Not Set 9999
Automation limits
Max number of new jobs that can be submitted every 30 100

seconds per Automation Account (non Scheduled jobs)
Max number of concurrent running jobs at the same instance 200

of time per Automation Account (non Scheduled jobs)
Max number of modules that can be imported every 30 5

seconds per Automation Account
Max size of a Module 100 MB
Job Run Time - Free tier 500 minutes per subscription per calendar month
Max amount of memory given to a job 400 MB
Max number of network sockets allowed per job 1000
SQL Database limits

For SQL Database limits, see SQL Database Resource Limits.
See also
Understanding Azure Limits and Increases
Virtual Machine and Cloud Service Sizes for Azure
Sizes for Cloud Services
Planning and design for VPN Gateway
Planning and designing your cross-premises and VNet-to-VNet configurations can be either simple, or
complicated, depending on your networking needs. This article walks you through basic planning and design
considerations.
Planning
Cross-premises connectivity options
If you want to connect your on-premises sites securely to a virtual network, you have three different ways to do so:
Site-to-Site, Point-to-Site, and ExpressRoute. Compare the different cross-premises connections that are available.
The option you choose can depend on various considerations, such as:
What kind of throughput does your solution require?
Do you want to communicate over the public Internet via secure VPN, or over a private connection?
Do you have a public IP address available to use?
Are you planning to use a VPN device? If so, is it compatible?
Are you connecting just a few computers, or do you want a persistent connection for your site?
What type of VPN gateway is required for the solution you want to create?
Which gateway SKU should you use?
Planning table
The following table can help you decide the best connectivity option for your solution.
POINT-TO-SITE SITE-TO-SITE EXPRESSROUTE
Azure Supported Services Cloud Services and Virtual Cloud Services and Virtual Services list
Machines Machines
Typical Bandwidths Typically < 100 Mbps Typically < 100 Mbps 50 Mbps, 100 Mbps, 200
aggregate aggregate Mbps, 500 Mbps, 1 Gbps, 2
Gbps, 5 Gbps, 10 Gbps
Protocols Supported Secure Sockets Tunneling IPsec Direct connection over

Protocol (SSTP) VLANs, NSP's VPN
technologies (MPLS, VPLS,...)
Routing RouteBased (dynamic) We support PolicyBased BGP

(static routing) and
RouteBased (dynamic
routing VPN)
Connection resiliency active-passive active-passive active-active
Typical use case Prototyping, dev / test / lab Dev / test / lab scenarios Access to all Azure services
scenarios for cloud services and small scale production (validated list), Enterprise-
and virtual machines workloads for cloud services class and mission critical
and virtual machines workloads, Backup, Big Data,
Azure as a DR site
POINT-TO-SITE SITE-TO-SITE EXPRESSROUTE
SLA SLA SLA SLA
Pricing Pricing Pricing Pricing
Technical Documentation VPN Gateway VPN Gateway ExpressRoute

Documentation Documentation Documentation
FAQ VPN Gateway FAQ VPN Gateway FAQ ExpressRoute FAQ
Gateway SKUs

Throughput is based on measurements of multiple tunnels aggregated through a single gateway. It is not a
guaranteed throughput due to Internet traffic conditions and your application behaviors.
Workflow
The following list outlines the common workflow for cloud connectivity:
1. Design and plan your connectivity topology and list the address spaces for all networks you want to connect.
2. Create an Azure virtual network.
3. Create a VPN gateway for the virtual network.
4. Create and configure connections to on-premises networks or other virtual networks (as needed).
5. Create and configure a Point-to-Site connection for your Azure VPN gateway (as needed).
Design
Connection topologies
Start by looking at the diagrams in the About VPN Gateway article. The article contains basic diagrams, the
deployment models for each topology (Resource Manager or classic), and which deployment tools you can use to
deploy your configuration.
Design basics
The following sections discuss the VPN gateway basics. Also, consider networking services limitations.
About subnets
When you are creating connections, you must consider your subnet ranges. You cannot have overlapping subnet
address ranges. An overlapping subnet is when one virtual network or on-premises location contains the same
address space that the other location contains. This means that you need your network engineers for your local on-
premises networks to carve out a range for you to use for your Azure IP addressing space/subnets. You need
address space that is not being used on the local on-premises network.
Avoiding overlapping subnets is also important when you are working with VNet-to-VNet connections. If your
subnets overlap and an IP address exists in both the sending and destination VNets, VNet-to-VNet connections fail.
Azure can't route the data to the other VNet because the destination address is part of the sending VNet.
VPN Gateways require a specific subnet called a gateway subnet. All gateway subnets must be named
GatewaySubnet to work properly. Be sure not to name your gateway subnet a different name, and don't deploy
VMs or anything else to the gateway subnet. See Gateway Subnets.
About local network gateways
The local network gateway typically refers to your on-premises location. In the classic deployment model, the local
network gateway is referred to as a Local Network Site. When you configure a local network gateway, you give it a
name, specify the public IP address of the on-premises VPN device, and specify the address prefixes that are in the
on-premises location. Azure looks at the destination address prefixes for network traffic, consults the configuration
that you have specified for the local network gateway, and routes packets accordingly. You can modify these
address prefixes as needed. For more information, see Local network gateways.
About gateway types
Selecting the correct gateway type for your topology is critical. If you select the wrong type, your gateway won't
work properly. The gateway type specifies how the gateway itself connects and is a required configuration setting
for the Resource Manager deployment model.
The gateway types are:
Vpn
ExpressRoute
About connection types
Each configuration requires a specific connection type. The connection types are:
IPsec
Vnet2Vnet
ExpressRoute
VPNClient
About VPN types
Each configuration requires a specific VPN type. If you are combining two configurations, such as creating a Site-
to-Site connection and a Point-to-Site connection to the same VNet, you must use a VPN type that satisfies both
connection requirements.
PolicyBased: PolicyBased VPNs were previously called static routing gateways in the classic deployment
model. Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the IPsec policies
configured with the combinations of address prefixes between your on-premises network and the Azure
VNet. The policy (or traffic selector) is usually defined as an access list in the VPN device configuration. The
value for a PolicyBased VPN type is PolicyBased. When using a PolicyBased VPN, keep in mind the following
limitations:
PolicyBased VPNs can only be used on the Basic gateway SKU. This VPN type is not compatible with
other gateway SKUs.
You can have only 1 tunnel when using a PolicyBased VPN.
You can only use PolicyBased VPNs for S2S connections, and only for certain configurations. Most VPN
Gateway configurations require a RouteBased VPN.
RouteBased: RouteBased VPNs were previously called dynamic routing gateways in the classic deployment
model. RouteBased VPNs use "routes" in the IP forwarding or routing table to direct packets into their
corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the
tunnels. The policy (or traffic selector) for RouteBased VPNs are configured as any-to-any (or wild cards). The
value for a RouteBased VPN type is RouteBased.
The following tables show the VPN type as it maps to each connection configuration. Make sure the VPN type for
your gateway matches the configuration that you want to create.
VPN type - Resource Manager deployment model
ROUTEBASED POLICYBASED
Site-to-Site Supported Supported
VNet-to-VNet Supported Not Supported
Multi-Site Supported Not Supported
S2S and ExpressRoute coexist Supported Not Supported
Point-to-Site Supported Not Supported
Classic to Resource Manager Supported Not Supported
VPN type - classic deployment model
DYNAMIC STATIC
Site-to-Site Supported Supported
VNet-to-VNet Supported Not Supported
Multi-Site Supported Not Supported
S2S and ExpressRoute coexist Supported Not Supported
Point-to-Site Supported Not Supported
Classic to Resource Manager Supported Not Supported
VPN devices for Site -to -Site connections

To configure a Site-to-Site connection, regardless of deployment model, you need the following items:
A VPN device that is compatible with Azure VPN gateways
A public-facing IPv4 IP address that is not behind a NAT
You need to have experience configuring your VPN device, or have someone that can configure the device for you.
For more information about VPN devices, see About VPN devices. The VPN devices article contains information
about validated devices, requirements for devices that have not been validated, and links to device configuration
documents if available.
Consider forced tunnel routing
For most configurations, you can configure forced tunneling. Forced tunneling lets you redirect or "force" all
Internet-bound traffic back to your on-premises location via a Site-to-Site VPN tunnel for inspection and auditing.
This is a critical security requirement for most enterprise IT policies.
Without forced tunneling, Internet-bound traffic from your VMs in Azure will always traverse from Azure network
infrastructure directly out to the Internet, without the option to allow you to inspect or audit the traffic.
Unauthorized Internet access can potentially lead to information disclosure or other types of security breaches.
A forced tunneling connection can be configured in both deployment models and by using different tools. For
more information, see Configure forced tunneling.
Forced tunneling diagram
Next steps
See the VPN Gateway FAQ and About VPN Gateway articles for more information to help you with your design.
For more information about specific gateway settings, see About VPN Gateway Settings.
About VPN Gateway configuration settings
A VPN gateway is a type of virtual network gateway that sends encrypted traffic between your virtual network and
your on-premises location across a public connection. You can also use a VPN gateway to send traffic between
virtual networks across the Azure backbone.
A VPN gateway connection relies on the configuration of multiple resources, each of which contains configurable
settings. The sections in this article discuss the resources and settings that relate to a VPN gateway for a virtual
network created in Resource Manager deployment model. You can find descriptions and topology diagrams for
each connection solution in the About VPN Gateway article.
Gateway types
Each virtual network can only have one virtual network gateway of each type. When you are creating a virtual
network gateway, you must make sure that the gateway type is correct for your configuration.
The available values for -GatewayType are:
Vpn
ExpressRoute
A VPN gateway requires the -GatewayType Vpn.
Example:
New-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg `

-Location 'West US' -IpConfigurations $gwipconfig -GatewayType Vpn `
-VpnType RouteBased
Gateway SKUs
When you create a virtual network gateway, you need to specify the gateway SKU that you want to use. Select the
SKUs that satisfy your requirements based on the types of workloads, throughputs, features, and SLAs.

Throughput is based on measurements of multiple tunnels aggregated through a single gateway. It is not a
guaranteed throughput due to Internet traffic conditions and your application behaviors.
Production vs. Dev-Test Workloads
Due to the differences in SLAs and feature sets, we recommend the following SKUs for production vs. dev-test:
WORKLOAD SKUS
Production, critical workloads VpnGw1, VpnGw2, VpnGw3
Dev-test or proof of concept Basic
If you are still using the old SKUs, the production SKU recommendations are Standard and HighPerformance
SKUs. For information on the old SKUs, see Gateway SKUs (old).
Gateway SKU feature sets
The new gateway SKUs streamline the feature sets offered on the gateways:
SKU FEATURES
VpnGw1 Route- and policy-based VPN up to 30 tunnels

VpnGw2 P2S, BGP, active-active, custom IPsec/IKE policy,
VpnGw3 ExpressRoute/VPN co-existence
Basic Route-based: 10 tunnels with P2S

Policy-based (IKEv1): 1 tunnel; no P2S
Resizing gateway SKUs
IMPORTANT
1. You can resize between VpnGw1, VpnGw2, and VpnGw3 SKUs
2. You cannot resize from Basic/Standard/HighPerformance SKUs to the new VpnGw1/VpnGw2/VpnGw3 SKUs
3. For the old SKUs, you can still resize between Basic, Standard, and HighPerformance SKUs
Migrating from old SKUs to VpnGw1/VpnGw2/VpnGw3

new (VpnGw1/VpnGw2/VpnGw3) SKU families. You need to delete the existing
(Basic/Standard/HighPerformance) gateway and create a new (VpnGw1/VpnGw2/VpnGw3) gateway with the new
SKUs. Note that your Azure Gateway public IP address will change as a result.
Configure the gateway SKU
Azure portal
If you use the Azure portal to create a Resource Manager virtual network gateway, you can select the gateway
SKU by using the dropdown. The options you are presented with correspond to the Gateway type and VPN type
that you select.
PowerShell
The following PowerShell example specifies the -GatewaySku as VpnGw1.

-Location 'West US' -IpConfigurations $gwipconfig -GatewaySku VpnGw1 `
-GatewayType Vpn -VpnType RouteBased
Change a gateway SKU

If you want to upgrade your gateway SKU to a more powerful SKU, you can use the
Resize-AzureRmVirtualNetworkGateway PowerShell cmdlet. You can also downgrade the gateway SKU size using
this cmdlet.
The following PowerShell example shows a gateway SKU being resized to VpnGw2.
$gw = Get-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg

Resize-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $gw -GatewaySku VpnGw2
Connection types
In the Resource Manager deployment model, each configuration requires a specific virtual network gateway
connection type. The available Resource Manager PowerShell values for -ConnectionType are:
IPsec
Vnet2Vnet
ExpressRoute
VPNClient
In the following PowerShell example, we create a S2S connection that requires the connection type IPsec.
New-AzureRmVirtualNetworkGatewayConnection -Name localtovon -ResourceGroupName testrg `

-Location 'West US' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
VPN types
When you create the virtual network gateway for a VPN gateway configuration, you must specify a VPN type. The
VPN type that you choose depends on the connection topology that you want to create. For example, a P2S
connection requires a RouteBased VPN type. A VPN type can also depend on the hardware that you will be using.
S2S configurations require a VPN device. Some VPN devices only support a certain VPN type.
The VPN type you select must satisfy all the connection requirements for the solution you want to create. For
example, if you want to create a S2S VPN gateway connection and a P2S VPN gateway connection for the same
virtual network, you would use VPN type RouteBased because P2S requires a RouteBased VPN type. You would
also need to verify that your VPN device supported a RouteBased VPN connection.
Once a virtual network gateway has been created, you can't change the VPN type. You have to delete the virtual
network gateway and create a new one. There are two VPN types:
PolicyBased: PolicyBased VPNs were previously called static routing gateways in the classic deployment
model. Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the IPsec policies
configured with the combinations of address prefixes between your on-premises network and the Azure
VNet. The policy (or traffic selector) is usually defined as an access list in the VPN device configuration. The
value for a PolicyBased VPN type is PolicyBased. When using a PolicyBased VPN, keep in mind the
following limitations:
PolicyBased VPNs can only be used on the Basic gateway SKU. This VPN type is not compatible with
other gateway SKUs.
You can have only 1 tunnel when using a PolicyBased VPN.
You can only use PolicyBased VPNs for S2S connections, and only for certain configurations. Most VPN
Gateway configurations require a RouteBased VPN.
RouteBased: RouteBased VPNs were previously called dynamic routing gateways in the classic deployment
model. RouteBased VPNs use "routes" in the IP forwarding or routing table to direct packets into their
corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the
tunnels. The policy (or traffic selector) for RouteBased VPNs are configured as any-to-any (or wild cards). The
value for a RouteBased VPN type is RouteBased.
The following PowerShell example specifies the -VpnType as RouteBased. When you are creating a gateway, you
must make sure that the -VpnType is correct for your configuration.

-Location 'West US' -IpConfigurations $gwipconfig `
-GatewayType Vpn -VpnType RouteBased
Gateway requirements
The following table lists the requirements for PolicyBased and RouteBased VPN gateways. This table applies to
both the Resource Manager and classic deployment models. For the classic model, PolicyBased VPN gateways are
the same as Static gateways, and Route-based gateways are the same as Dynamic gateways.
ROUTEBASED ROUTEBASED HIGH

POLICYBASED BASIC ROUTEBASED BASIC STANDARD VPN PERFORMANCE VPN
VPN GATEWAY VPN GATEWAY GATEWAY GATEWAY
Site-to-Site PolicyBased VPN RouteBased VPN RouteBased VPN RouteBased VPN

connectivity (S2S) configuration configuration configuration configuration
Point-to-Site Not supported Supported (Can Supported (Can Supported (Can

connectivity (P2S) coexist with S2S) coexist with S2S) coexist with S2S)
Authentication Pre-shared key Pre-shared key for Pre-shared key for Pre-shared key for
method S2S connectivity, S2S connectivity, S2S connectivity,
Certificates for P2S Certificates for P2S Certificates for P2S
connectivity connectivity connectivity
Maximum number 1 10 10 30
of S2S connections
Maximum number Not supported 128 128 128

of P2S connections
Active routing Not supported Not supported Supported Supported

support (BGP)
Gateway subnet
In order to configure a virtual network gateway for your VNet, you'll need to create a gateway subnet. The
gateway subnet contains the IP addresses that the virtual network gateway services use. The gateway subnet must
be named GatewaySubnet to work properly. This name lets Azure know that this subnet should be used for the
gateway.
When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The IP
addresses in the gateway subnet are allocated to the gateway service. Some configurations require more IP
addresses to be allocated to the gateway service than do others. You want to make sure your gateway subnet
contains enough IP addresses to accommodate future growth and possible additional new connection
configurations. So, while you can create a gateway subnet as small as /29, we recommend that you create a
gateway subnet of /28 or larger (/28, /27, /26 etc.). Look at the requirements for the configuration that you want
to create and verify that the gateway subnet that you have will meet those requirements.
The following Resource Manager PowerShell example shows a gateway subnet named GatewaySubnet. You can
see the CIDR notation specifies a /27, which allows for enough IP addresses for most configurations that currently
exist.
Add-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.3.0/27
IMPORTANT
When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating
a network security group to this subnet may cause your VPN gateway to stop functioning as expected. For more
information about network security groups, see What is a network security group?
Local network gateways

When creating a VPN gateway configuration, the local network gateway often represents your on-premises
location. In the classic deployment model, the local network gateway was referred to as a Local Site.
You give the local network gateway a name, the public IP address of the on-premises VPN device, and specify the
address prefixes that are located on the on-premises location. Azure looks at the destination address prefixes for
network traffic, consults the configuration that you have specified for your local network gateway, and routes
packets accordingly. You also specify local network gateways for VNet-to-VNet configurations that use a VPN
gateway connection.
The following PowerShell example creates a new local network gateway:
New-AzureRmLocalNetworkGateway -Name LocalSite -ResourceGroupName testrg `

-Location 'West US' -GatewayIpAddress '23.99.221.164' -AddressPrefix '10.5.51.0/24'
Sometimes you need to modify the local network gateway settings. For example, when you add or modify the
address range, or if the IP address of the VPN device changes. For a classic VNet, you can change these settings in
the classic portal on the Local Networks page. For Resource Manager, see Modify local network gateway settings
using PowerShell.
REST APIs and PowerShell cmdlets

For additional technical resources and specific syntax requirements when using REST APIs and PowerShell
cmdlets for VPN Gateway configurations, see the following pages:
CLASSIC RESOURCE MANAGER
PowerShell PowerShell
REST API REST API

Next steps
See About VPN Gateway for more information about available connection configurations.
About VPN devices and IPsec/IKE parameters for
Site-to-Site VPN Gateway connections
A VPN device is required to configure a Site-to-Site (S2S) cross-premises VPN connection using a VPN
gateway. Site-to-Site connections can be used to create a hybrid solution, or whenever you want secure
connections between your on-premises networks and your virtual networks. This article provides the list of
IPsec/IKE parameters for Azure VPN gateways, and a list of validated VPN devices connecting to Azure VPN
gateways.
IMPORTANT
If you are experiencing connectivity issues between your on-premises VPN devices and Azure VPN gateways, refer to
Known device compatibility issues.
Items to note when viewing the tables:

There has been a terminology change for Azure VPN gateways. There is no functionality change. Only the
names are changing.
Static Routing = PolicyBased
Dynamic Routing = RouteBased
Specifications for High Performance VPN gateway and RouteBased VPN gateway are the same unless
otherwise noted. For example, the validated VPN devices that are compatible with RouteBased VPN
gateways are also compatible with the Azure High Performance VPN gateway.
NOTE
When configuring a Site-to-Site connection, a public-facing IPv4 IP address is required for your VPN device.
Validated VPN devices and device configuration guides

We have validated a set of standard VPN devices in partnership with device vendors. All the devices in the
device families contained in the following list should work with Azure VPN gateways. See About VPN Gateway
to verify the type of gateway that you need to create for the solution you want to configure.
To help configure your VPN device, refer to the links that correspond to appropriate device family. The links to
configuration instructions are provided on a best-effort basis. For VPN device support, contact your device
manufacturer.
POLICYBASED ROUTEBASED
MINIMUM OS CONFIGURATION CONFIGURATION
VENDOR DEVICE FAMILY VERSION INSTRUCTIONS INSTRUCTIONS
A10 Networks, Inc. Thunder CFW ACOS 4.1.1 Not Compatible Configuration guide
Allied Telesis AR Series VPN 2.9.2 Coming soon Not compatible

Routers
Barracuda Networks, Barracuda NextGen PolicyBased: 5.4.3 Configuration guide Configuration guide
Inc. Firewall F-series RouteBased: 6.2.0
Barracuda Networks, Barracuda NextGen Barracuda Firewall Configuration guide Not compatible
Inc. Firewall X-series 6.5
Brocade Vyatta 5400 vRouter Virtual Router 6.6R3 Configuration guide Not compatible
GA
Check Point Security Gateway R77.30 Configuration guide Configuration guide
Cisco ASA 8.3 Configuration Not compatible

samples
Cisco ASR PolicyBased: IOS 15.1 Configuration Configuration

RouteBased: IOS samples samples
15.2
Cisco ISR PolicyBased: IOS 15.0 Configuration Configuration

RouteBased*: IOS samples samples*
15.1
Citrix NetScaler MPX, SDX, 10.1 and above Configuration guide Not compatible
VPX
F5 BIG-IP series 12.0 Configuration guide Configuration guide
Fortinet FortiGate FortiOS 5.4.2 Configuration guide
Internet Initiative SEIL Series SEIL/X 4.60 Configuration guide Not compatible
Japan (IIJ) SEIL/B1 4.60
SEIL/x86 3.20
Juniper SRX PolicyBased: JunOS Configuration Configuration

10.2 samples samples
Routebased: JunOS
11.4
Juniper J-Series PolicyBased: JunOS Configuration Configuration

10.4r9 samples samples
RouteBased: JunOS
11.4
Juniper ISG ScreenOS 6.3 Configuration Configuration

samples samples
Juniper SSG ScreenOS 6.2 Configuration Configuration

samples samples
Microsoft Routing and Remote Windows Server Not compatible Configuration

Access Service 2012 samples
Open Systems AG Mission Control N/A Configuration guide Not compatible

Security Gateway
Openswan Openswan 2.6.32 (Coming soon) Not compatible
Palo Alto Networks All devices running PAN-OS Configuration guide Configuration guide
PAN-OS PolicyBased: 6.1.5 or
later
RouteBased: 7.1.4
SonicWall TZ Series, NSA Series SonicOS 5.8.x Configuration guide Configuration guide
SuperMassive Series SonicOS 5.9.x for SonicOS 6.2 for SonicOS 6.2
E-Class NSA Series SonicOS 6.x Configuration guide Configuration guide
for SonicOS 5.9 for SonicOS 5.9
WatchGuard All Fireware XTM Configuration guide Configuration guide

PolicyBased: v11.11.x
RouteBased: v11.12.x
(*) ISR 7200 Series routers only support PolicyBased VPNs.
Non-validated VPN devices

If you dont see your device listed in the Validated VPN devices table, your device still may work with a Site-to-
Site connection. Contact your device manufacturer for additional support and configuration instructions.
Editing device configuration samples

After you download the provided VPN device configuration sample, youll need to replace some of the values
to reflect the settings for your environment.
To edit a sample:
1. Open the sample using Notepad.
2. Search and replace all <text> strings with the values that pertain to your environment. Be sure to include <
and >. When a name is specified, the name you select should be unique. If a command does not work,
consult your device manufacturer documentation.
SAMPLE TEXT CHANGE TO
<RP_OnPremisesNetwork> Your chosen name for this object. Example:

myOnPremisesNetwork
<RP_AzureNetwork> Your chosen name for this object. Example:

myAzureNetwork
<RP_AccessList> Your chosen name for this object. Example:

myAzureAccessList
<RP_IPSecTransformSet> Your chosen name for this object. Example:

myIPSecTransformSet
SAMPLE TEXT CHANGE TO
<RP_IPSecCryptoMap> Your chosen name for this object. Example:

myIPSecCryptoMap
<SP_AzureNetworkIpRange> Specify range. Example: 192.168.0.0
<SP_AzureNetworkSubnetMask> Specify subnet mask. Example: 255.255.0.0
<SP_OnPremisesNetworkIpRange> Specify on-premises range. Example: 10.2.1.0
<SP_OnPremisesNetworkSubnetMask> Specify on-premises subnet mask. Example: 255.255.255.0
<SP_AzureGatewayIpAddress> This information specific to your virtual network and is

located in the Management Portal as Gateway IP address.
<SP_PresharedKey> This information is specific to your virtual network and is

located in the Management Portal as Manage Key.
IPsec/IKE parameters
NOTE
Although the values listed in the following table are supported by the Azure VPN Gateway, currently there is no
mechanism for you to specify or select a specific combination of algorithms or parameters from the Azure VPN Gateway.
You must specify any constraints from the on-premises VPN device. In addition, you must clamp MSS at 1350.
In the following tables:

SA = Security Association
IKE Phase 1 is also called "Main Mode"
IKE Phase 2 is also called "Quick Mode"
IKE Phase 1 (Main Mode ) parameters
PROPERTY POLICYBASED ROUTEBASED
IKE Version IKEv1 IKEv2
Diffie-Hellman Group Group 2 (1024 bit) Group 2 (1024 bit)
Authentication Method Pre-Shared Key Pre-Shared Key
Encryption & Hashing Algorithms 1. AES256, SHA256 1. AES256, SHA1

2. AES256, SHA1 2. AES256, SHA256
3. AES128, SHA1 3. AES128, SHA1
4. 3DES, SHA1 4. AES128, SHA256
5. 3DES, SHA1
6. 3DES, SHA256
SA Lifetime 28,800 seconds 28,800 seconds
IKE Phase 2 (Quick Mode ) parameters

PROPERTY POLICYBASED ROUTEBASED
IKE Version IKEv1 IKEv2
Encryption & Hashing Algorithms 1. AES256, SHA256 RouteBased QM SA Offers

2. AES256, SHA1
3. AES128, SHA1
4. 3DES, SHA1
SA Lifetime (Time) 3,600 seconds 27,000 seconds
SA Lifetime (Bytes) 102,400,000 KB -
Perfect Forward Secrecy (PFS) No RouteBased QM SA Offers
Dead Peer Detection (DPD) Not supported Supported
RouteBased VPN IPsec Security Association (IKE Quick Mode SA ) Offers

The following table lists IPsec SA (IKE Quick Mode) Offers. Offers are listed the order of preference that the
offer is presented or accepted.
Azure Gateway as initiator
- ENCRYPTION AUTHENTICATION PFS GROUP
1 GCM AES256 GCM (AES256) None
2 AES256 SHA1 None
3 3DES SHA1 None
4 AES256 SHA256 None
5 AES128 SHA1 None
6 3DES SHA256 None
Azure Gateway as responder
1 GCM AES256 GCM (AES256) None
2 AES256 SHA1 None
3 3DES SHA1 None
5 AES128 SHA1 None
6 3DES SHA256 None
7 DES SHA1 None

8 AES256 SHA1 1
9 AES256 SHA1 2
10 AES256 SHA1 14
11 AES128 SHA1 1
12 AES128 SHA1 2
13 AES128 SHA1 14
14 3DES SHA1 1
15 3DES SHA1 2
16 3DES SHA256 2
17 AES256 SHA256 1
18 AES256 SHA256 2
19 AES256 SHA256 14
20 AES256 SHA1 24
21 AES256 SHA256 24
23 AES128 SHA256 1
24 AES128 SHA256 2
25 AES128 SHA256 14
26 3DES SHA1 14
You can specify IPsec ESP NULL encryption with RouteBased and High Performance VPN gateways. Null
based encryption does not provide protection to data in transit, and should only be used when maximum
throughput and minimum latency is required. Clients may choose to use this in VNet-to-VNet
communication scenarios, or when encryption is being applied elsewhere in the solution.
For cross-premises connectivity through the Internet, use the default Azure VPN gateway settings with
encryption and hashing algorithms listed in the tables above to ensure security of your critical
communication.
Known device compatibility issues

IMPORTANT
These are the known compatibility issues between third-party VPN devices and Azure VPN gateways. The Azure team is
actively working with the vendors to address the issues listed here. Once the issues are resolved, this page will be
updated with the most up-to-date information. Please check back periodically.
Feb. 16, 2017

Palo Alto Networks devices with version prior to 7.1.4 for Azure route-based VPN: If you are using VPN
devices from Palo Alto Networks with PAN-OS version prior to 7.1.4 and are experiencing connectivity issues to
Azure route-based VPN gateways, perform the following steps:
1. Check the firmware version of your Palo Alto Networks device. If your PAN-OS version is older than 7.1.4,
upgrade to 7.1.4.
2. On the Palo Alto Networks device, change the Phase 2 SA (or Quick Mode SA) lifetime to 28,800 seconds (8
hours) when connecting to the Azure VPN gateway.
3. If you are still experiencing connectivity issues, open a support request from the Azure portal.
About cryptographic requirements and Azure VPN
gateways
This article discuss how you can configure Azure VPN gateways to satisfy your cryptographic requirements for
both cross-premises S2S VPN tunnels and VNet-to-VNet connections within Azure.
About IPsec and IKE policy parameters for Azure VPN gateways
IPsec and IKE protocol standard supports a wide range of cryptographic algorithms in various combinations. If
customers do not request a specific combination of cryptographic alrogithms and parameters, Azure VPN
gateways use a set of default proposals. The default policy sets were chosen to maximize interoperability with a
wide range of third party VPN devices in default configurations. As a result, the policies and the number of
proposals cannot cover all possible combinations of available cryptographic algorithms and key strengths.
The default policy set for Azure VPN gateway is listed in the document: About VPN devices and IPsec/IKE
parameters for Site-to-Site VPN Gateway connections.
Cryptographic requirements
For communications that require specific cryptographic algorithms or parameters, typically due to compliance or
security requirements, customers can now configure their Azure VPN gateways to use a custom IPsec/IKE policy
with specific cryptographic algorithms and key strengths, rather than the Azure default policy sets.
For example, the IKEv2 main mode policies for Azure VPN gateways utilize only Diffie-Hellman Group 2 (1024bits),
whereas customers may need to specify stronger groups to be used in IKE, such as Group 14 (2048-bit), Group 24
(2048-bit MODP Group), or ECP (elliptic curve groups) 256 or 384 bit (Group 19 and Group 20, respectively).
Similar requirements apply to IPsec quick mode policies as well.
Custom IPsec/IKE policy with Azure VPN gateways

Azure VPN gateways now support per-connection, custom IPsec/IKE policy. You can choose a specific combination
of cryptographic algorithms for IPsec and IKE with desired key strength for a S2S or VNet-to-VNet connection, as
shown in the example below:
You can create an IPsec/IKE policy and apply to a new or existing connection. The workflow is listed below:
1. Create the virtual networks, VPN gateways, or local network gateways for your connectivity topology as
described in other how-to documents
2. Create an IPsec/IKE policy
3. You can apply the policy when you create a S2S or VNet-to-VNet connection
4. If the connection is already created, you can apply or update the policy to an existing connection
IPsec/IKE policy FAQ
Is Custom IPsec/IKE policy supported on all Azure VPN Gateway SKUs?
Custom IPsec/IKE policy is supported on Azure Standard and HighPerformance VPN gateways. Basic SKU is
NOT supported.
How many policies can I specify on a connection?
You can only specify one policy combination for a given connection.
Can I specify a partial policy on a connection? (E.g., only IKE algorithms but not IPsec)
No, you must specify all algorithms and parameters for both IKE (Main Mode) and IPsec (Quick Mode). Partial
policy specification is not allowed.
What are the algorithms and key strengths supported in the custom policy?
You must select one option for every field.
IPSEC/IKEV2 OPTIONS


IPsec Integrity GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1,

MD5
Traffic Selector UsePolicyBasedTrafficSelectors** ($True/$False)
(**) Please see the next FAQ item for "UsePolicyBasedTrafficSelectors"
Does everything need to match between the Azure VPN gateway policy and my on-premises VPN device
configurations?
Your on-premises VPN device configuration must match or contain the following algorithms and parameters that
you specify on the Azure IPsec/IKE policy:
IKE encryption algorithm
IKE integrity algorithm
DH Group
IPsec encryption algorithm
IPsec integrity algorithm
PFS Group
Traffic Selector (*)
The SA lifetimes are local specifications only, do not need to match.
If you enable UsePolicyBasedTrafficSelectors, you need to ensure your VPN device has the matching traffic
selectors defined with all combinations of your on-premises network (local network gateway) prefixes to/from the
Azure virtual network prefixes, instead of any-to-any. For example, if your on-premises network prefixes are
10.1.0.0/16 and 10.2.0.0/16, and your virtual network prefixes are 192.168.0.0/16 and 172.16.0.0/16, you need to
specify the following traffic selectors:
10.1.0.0/16 <====> 192.168.0.0/16
10.1.0.0/16 <====> 172.16.0.0/16
10.2.0.0/16 <====> 192.168.0.0/16
10.2.0.0/16 <====> 172.16.0.0/16
Refer to Connect multiple on-premises policy-based VPN devices for more details on how to use this option.
Does the custom policy replace the default IPsec/IKE policy sets for Azure VPN gateways?
Yes, once a custom policy is specified on a connection, Azure VPN gateway will only use the policy on the
connection, both as IKE initiator and IKE responder.
If I remove a custom IPsec/IKE policy, does the connection become unprotected?
No, the connection will still be protected by IPsec/IKE. Once you remove the custom policy from a connection, the
Azure VPN gateway will revert back to the default list of IPsec/IKE proposals and re-start the IKE handshake again
with your on-premises VPN device.
Would adding or updating an IPsec/IKE policy disrupt my VPN connection?
Yes, it could cause a small disruption (a few seconds) as the Azure VPN gateway will tear down the existing
connection and re-start the IKE handshake to re-establish the IPsec tunnel with the new cryptographic algorithms
and parameters. Please ensure your on-premises VPN device is also configured with the matching algorithms and
key strengths to minimize the disruption.
Can I use different policies on different connections?
Yes. Custom policy is applied on a per-connection basis. You can create and apply different IPsec/IKE policies on
different connections. You can also choose to apply custom policies on a subset of connections. The remaining
ones will use the Azure default IPsec/IKE policy sets.
Can I use the custom policy on VNet-to -VNet connection as well?
Yes, you can apply custom policy on both IPsec cross-premises connections or VNet-to-VNet connections.
Do I need to specify the same policy on both VNet-to -VNet connection resources?
Yes. A VNet-to-VNet tunnel consists of two connection resources in Azure, one for each direction. You need to
ensure both connection resources have the same policy, othereise the VNet-to-VNet connection will not establish.
Does custom IPsec/IKE policy work on ExpressRoute connection?
No. IPsec/IKE policy only works on S2S VPN and VNet-to-VNet connections via the Azure VPN gateways.
Next steps
See Configure IPsec/IKE policy for step-by-step instructions on configuring custom IPsec/IKE policy on a
connection.
See also Connect multiple policy-based VPN devices to learn more about the UsePolicyBasedTrafficSelectors
option.
Overview of BGP with Azure VPN Gateways
This article provides an overview of BGP (Border Gateway Protocol) support in Azure VPN Gateways.
BGP is the standard routing protocol commonly used in the Internet to exchange routing and reachability
information between two or more networks. When used in the context of Azure Virtual Networks, BGP enables the
Azure VPN Gateways and your on-premises VPN devices, called BGP peers or neighbors, to exchange "routes" that
will inform both gateways on the availability and reachability for those prefixes to go through the gateways or
routers involved. BGP can also enable transit routing among multiple networks by propagating routes a BGP
gateway learns from one BGP peer to all other BGP peers.
Why use BGP?

BGP is an optional feature you can use with Azure Route-Based VPN gateways. You should also make sure your
on-premises VPN devices support BGP before you enable the feature. You can continue to use Azure VPN
gateways and your on-premises VPN devices without BGP. It is the equivalent of using static routes (without BGP)
vs. using dynamic routing with BGP between your networks and Azure.
There are several advantages and new capabilities with BGP:
Support automatic and flexible prefix updates
With BGP, you only need to declare a minimum prefix to a specific BGP peer over the IPsec S2S VPN tunnel. It can
be as small as a host prefix (/32) of the BGP peer IP address of your on-premises VPN device. You can control
which on-premises network prefixes you want to advertise to Azure to allow your Azure Virtual Network to access.
You can also advertise a larger prefixes that may include some of your VNet address prefixes, such as a large
private IP address space (e.g., 10.0.0.0/8). Please note though the prefixes cannot be identical with any one of your
VNet prefixes. Those routes identical to your VNet prefixes will be rejected.
Support multiple tunnels between a VNet and an on-premises site with automatic failover based on BGP
You can establish multiple connections between your Azure VNet and your on-premises VPN devices in the same
location. This capability provides multiple tunnels (paths) between the two networks in an active-active
configuration. If one of the tunnels is disconnected, the corresponding routes will be withdrawn via BGP and the
traffic will automatically shift to the remaining tunnels.
The following diagram shows a simple example of this highly available setup:
Support transit routing between your on-premises networks and multiple Azure VNets
BGP enables multiple gateways to learn and propagate prefixes from different networks, whether they are directly
or indirectly connected. This can enable transit routing with Azure VPN gateways between your on-premises sites
or across multiple Azure Virtual Networks.
The following diagram shows an example of a multi-hop topology with multiple paths that can transit traffic
between the two on-premises networks through Azure VPN gateways within the Microsoft Networks:
BGP FAQ
Is BGP supported on all Azure VPN Gateway SKUs?
No, BGP is supported on Azure Standard and HighPerformance VPN gateways. Basic SKU is NOT supported.
Can I use BGP with Azure Policy-Based VPN gateways?
No, BGP is supported on Route-Based VPN gateways only.
Can I use private ASNs (Autonomous System Numbers)?
Yes, you can use your own public ASNs or private ASNs for both your on-premises networks and Azure virtual
networks.
Are there ASNs reserved by Azure?
Yes, the following ASNs are reserved by Azure for both internal and external peerings:
Public ASNs: 8075, 8076, 12076
Private ASNs: 65515, 65517, 65518, 65519, 65520
You cannot specify these ASNs for your on premises VPN devices when connecting to Azure VPN gateways.
Can I use the same ASN for both on-premises VPN networks and Azure VNets?
No, you must assign different ASNs between your on-premises networks and your Azure VNets if you are
connecting them together with BGP. Azure VPN Gateways have a default ASN of 65515 assigned, whether BGP is
enabled or not for your cross-premises connectivity. You can override this default by assigning a different ASN
when creating the VPN gateway, or change the ASN after the gateway is created. You will need to assign your on-
premises ASNs to the corresponding Azure Local Network Gateways.
What address prefixes will Azure VPN gateways advertise to me?
Azure VPN gateway will advertise the following routes to your on-premises BGP devices:
Your VNet address prefixes
Address prefixes for each Local Network Gateways connected to the Azure VPN gateway
Routes learned from other BGP peering sessions connected to the Azure VPN gateway, except default route
or routes overlapped with any VNet prefix.
Can I advertise default route (0.0.0.0/0) to Azure VPN gateways?
Yes.
Please note this will force all VNet egress traffic towards your on-premises site, and will prevent the VNet VMs
from accepting public communication from the Internet directly, such RDP or SSH from the Internet to the VMs.
Can I advertise the exact prefixes as my Virtual Network prefixes?
No, advertising the same prefixes as any one of your Virtual Network address prefixes will be blocked or filtered by
the Azure platform. However you can advertise a prefix that is a superset of what you have inside your Virtual
Network.
For example, if your virtual network used the address space 10.0.0.0/16, you could advertise 10.0.0.0/8. But you
cannot advertise 10.0.0.0/16 or 10.0.0.0/24.
Can I use BGP with my VNet-to -VNet connections?
Yes, you can use BGP for both cross-premises connections and VNet-to-VNet connections.
Can I mix BGP with non-BGP connections for my Azure VPN gateways?
Yes, you can mix both BGP and non-BGP connections for the same Azure VPN gateway.
Does Azure VPN gateway support BGP transit routing?
Yes, BGP transit routing is supported, with the exception that Azure VPN gateways will NOT advertise default
routes to other BGP peers. To enable transit routing across multiple Azure VPN gateways, you must enable BGP on
all intermediate VNet-to-VNet connections.
Can I have more than one tunnel between Azure VPN gateway and my on-premises network?
Yes, you can establish more than one S2S VPN tunnel between an Azure VPN gateway and your on-premises
network. Please note that all these tunnels will be counted against the total number of tunnels for your Azure VPN
gateways and you must enable BGP on both tunnels.
For example, if you have two redundant tunnels between your Azure VPN gateway and one of your on-premises
networks, they will consume 2 tunnels out of the total quota for your Azure VPN gateway (10 for Standard and 30
for HighPerformance).
Can I have multiple tunnels between two Azure VNets with BGP?
Yes, but at least one of the virtual network gateways must be in active-active configuration.
Can I use BGP for S2S VPN in an ExpressRoute/S2S VPN co -existence configuration?
Yes.
What address does Azure VPN gateway use for BGP Peer IP?
The Azure VPN gateway will allocate a single IP address from the GatewaySubnet range defined for the virtual
network. By default, it is the second last address of the range. For example, if your GatewaySubnet is
10.12.255.0/27, ranging from 10.12.255.0 to 10.12.255.31, the BGP Peer IP address on the Azure VPN gateway will
be 10.12.255.30. You can find this information when you list the Azure VPN gateway information.
What are the requirements for the BGP Peer IP addresses on my VPN device?
Your on-premises BGP peer address MUST NOT be the same as the public IP address of your VPN device. 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 Local Network Gateway representing the
location.
What should I specify as my address prefixes for the Local Network Gateway when I use BGP?
Azure Local Network Gateway specifies the initial address prefixes for the on-premises network. With BGP, you
must allocate the host prefix (/32 prefix) of your BGP Peer IP address as the address space for that on-premises
network. If your BGP Peer IP is 10.52.255.254, you should specify "10.52.255.254/32" as the
localNetworkAddressSpace of the Local Network Gateway representing this on-premises network. This is to ensure
that the Azure VPN gateway establishes the BGP session through the S2S VPN tunnel.
What should I add to my on-premises VPN device for the BGP peering session?
You should add a host route of the Azure BGP Peer IP address on your VPN device pointing to the IPsec S2S VPN
tunnel. For example, if the Azure VPN Peer IP is "10.12.255.30", you should add a host route for "10.12.255.30"
with a nexthop interface of the matching IPsec tunnel interface on your VPN device.
Next steps
See Getting started with BGP on Azure VPN gateways for steps to configure BGP for your cross-premises and
VNet-to-VNet connections.
Highly Available Cross-Premises and VNet-to-VNet
Connectivity
This article provides an overview of Highly Available configuration options for your cross-premises and VNet-to-
VNet connectivity using Azure VPN gateways.
About Azure VPN gateway redundancy

Every Azure VPN gateway consists of two instances in an active-standby configuration. For any planned
maintenance or unplanned disruption that happens to the active instance, the standby instance would take over
(failover) automatically, and resume the S2S VPN or VNet-to-VNet connections. The switch over will cause a brief
interruption. For planned maintenance, the connectivity should be restored within 10 to 15 seconds. For unplanned
issues, the connection recovery will be longer, about 1 minute to 1 and a half minutes in the worst case. For P2S
VPN client connections to the gateway, the P2S connections will be disconnected and the users will need to
reconnect from the client machines.
Highly Available Cross-Premises Connectivity

To provide better availability for your cross premises connections, there are a couple of options available:
Multiple on-premises VPN devices
Active-active Azure VPN gateway
Combination of both
Multiple on-premises VPN devices
You can use multiple VPN devices from your on-premises network to connect to your Azure VPN gateway, as
shown in the following diagram:
This configuration provides multiple active tunnels from the same Azure VPN gateway to your on-premises devices
in the same location. There are some requirements and constraints:
1. You need to create multiple S2S VPN connections from your VPN devices to Azure. When you connect multiple
VPN devices from the same on-premises network to Azure, you need to create one local network gateway for
each VPN device, and one connection from your Azure VPN gateway to the local network gateway.
2. The local network gateways corresponding to your VPN devices must have unique public IP addresses in the
"GatewayIpAddress" property.
3. BGP is required for this configuration. Each local network gateway representing a VPN device must have a
unique BGP peer IP address specified in the "BgpPeerIpAddress" property.
4. The AddressPrefix property field in each local network gateway must not overlap. You should specify the
"BgpPeerIpAddress" in /32 CIDR format in the AddressPrefix field, for example, 10.200.200.254/32.
5. You should use BGP to advertise the same prefixes of the same on-premises network prefixes to your Azure
VPN gateway, and the traffic will be forwarded through these tunnels simultaneously.
6. Each connection is counted against the maximum number of tunnels for your Azure VPN gateway, 10 for Basic
and Standard SKUs, and 30 for HighPerformance SKU.
In this configuration, the Azure VPN gateway is still in active-standby mode, so the same failover behavior and brief
interruption will still happen as described above. But this setup guards against failures or interruptions on your on-
premises network and VPN devices.
Active -active Azure VPN gateway
You can now create an Azure VPN gateway in an active-active configuration, where both instances of the gateway
VMs will establish S2S VPN tunnels to your on-premises VPN device, as shown the following diagram:
In this configuration, each Azure gateway instance will have a unique public IP address, and each will establish an
IPsec/IKE S2S VPN tunnel to your on-premises VPN device specified in your local network gateway and connection.
Note that both VPN tunnels are actually part of the same connection. You will still need to configure your on-
premises VPN device to accept or establish two S2S VPN tunnels to those two Azure VPN gateway public IP
addresses.
Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual network
to your on-premises network will be routed through both tunnels simultaneously, even if your on-premises VPN
device may favor one tunnel over the other. Note though the same TCP or UDP flow will always traverse the same
tunnel or path, unless a maintenance event happens on one of the instances.
When a planned maintenance or unplanned event happens to one gateway instance, the IPsec tunnel from that
instance to your on-premises VPN device will be disconnected. The corresponding routes on your VPN devices
should be removed or withdrawn automatically so that the traffic will be switched over to the other active IPsec
tunnel. On the Azure side, the switch over will happen automatically from the affected instance to the active
instance.
Dual-redundancy: active -active VPN gateways for both Azure and on-premises networks
The most reliable option is to combine the active-active gateways on both your network and Azure, as shown in the
diagram below.
Here you create and setup the Azure VPN gateway in an active-active configuration, and create two local network
gateways and two connections for your two on-premises VPN devices as described above. The result is a full mesh
connectivity of 4 IPsec tunnels between your Azure virtual network and your on-premises network.
All gateways and tunnels are active from the Azure side, so the traffic will be spread among all 4 tunnels
simultaneously, although each TCP or UDP flow will again follow the same tunnel or path from the Azure side. Even
though by spreading the traffic, you may see slightly better throughput over the IPsec tunnels, the primary goal of
this configuration is for high availability. And due to the statistical nature of the spreading, it is difficult to provide
the measurement on how different application traffic conditions will affect the aggregate throughput.
This topology will require two local network gateways and two connections to support the pair of on-premises VPN
devices, and BGP is required to allow the two connections to the same on-premises network. These requirements
are the same as the above.
Highly Available VNet-to-VNet Connectivity through Azure VPN

Gateways
The same active-active configuration can also apply to Azure VNet-to-VNet connections. You can create active-
active VPN gateways for both virtual networks, and connect them together to form the same full mesh connectivity
of 4 tunnels between the two VNets, as shown in the diagram below:
This ensures there are always a pair of tunnels between the two virtual networks for any planned maintenance
events, providing even better availability. Even though the same topology for cross-premises connectivity requires
two connections, the VNet-to-VNet topology shown above will need only one connection for each gateway.
Additionally, BGP is optional unless transit routing over the VNet-to-VNet connection is required.
Next steps
See Configuring Active-Active VPN Gateways for Cross-Premises and VNet-to-VNet Connections for steps to
configure active-active cross-premises and VNet-to-VNet connections.
Create a Site-to-Site connection in the Azure portal
This article shows you how to use the Azure portal to create a Site-to-Site VPN gateway connection from your on-
premises network to the VNet. The steps in this article apply to the Resource Manager deployment model. You
can also create this configuration using a different deployment tool or deployment model by selecting a different
option from the following list:
A Site-to-Site VPN gateway connection is used to connect your on-premises network to an Azure virtual network
over an IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. 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 VPN gateways, see
About VPN gateway.
Before you begin

Verify that you have met the following criteria before beginning your configuration:
Verify that you want to work with the Resource Manager deployment model. Azure currently works with two
deployment models: Resource Manager and classic. The two models are not completely compatible with each
other. Before you begin, you need to know which model that you want to work in. For information about the
deployment models, see Understanding deployment models. If you are new to Azure, we recommend that you
use the Resource Manager deployment model.
A compatible VPN device and someone who is able to configure it. For more information about compatible
VPN devices and device configuration, see About VPN Devices.
An externally facing public IPv4 IP address for your VPN device. This IP address cannot be located behind a
NAT.
If you are unfamiliar with the IP address ranges located in your on-premises network configuration, you need
to coordinate with someone who can provide those details for you. When you create this configuration, you
must specify the IP address range prefixes that Azure will route to your on-premises location. None of the
subnets of your on-premises network can over lap with the virtual network subnets that you want to connect
to.
Example values
The examples in this article use the following values. You can use these values to create a test environment, or
refer to them to better understand the examples in this article.
VNet Name: TestVNet1
Address Space:
10.11.0.0/16
10.12.0.0/16 (optional for this exercise)
Subnets:
FrontEnd: 10.11.0.0/24
BackEnd: 10.12.0.0/24 (optional for this exercise)
GatewaySubnet: 10.11.255.0/27
Resource Group: TestRG1
Location: East US
DNS Server: Optional. The IP address of your DNS server.
Virtual Network Gateway Name: VNet1GW
Public IP: VNet1GWIP
VPN Type: Route-based
Connection Type: Site-to-site (IPsec)
Gateway Type: VPN
Local Network Gateway Name: Site2
Connection Name: VNet1toSite2
1. Create a virtual network

To create a VNet in the Resource Manager deployment model by using the Azure portal, follow the steps below.
Use the example values if you are using these steps as a tutorial. If you are not doing these steps as a tutorial, be
sure to replace the values with your own. For more information about working with virtual networks, see the
Virtual Network Overview.
1. From a browser, navigate to the Azure portal and sign in with your Azure account.
2. Click New. In the Search the marketplace field, type 'Virtual Network'. Locate Virtual Network from the
returned list and click to open the Virtual Network blade.
3. Near the bottom of the Virtual Network blade, from the Select a deployment model list, select
Resource Manager, and then click Create. This opens the 'Create virtual network' blade.
4. On the Create virtual network blade, configure the VNet settings. When you fill in the fields, the red
exclamation mark becomes a green check mark when the characters entered in the field are valid.
Name: Enter the name for your virtual network. In this example, we use TestVNet1.
Address space: Enter the address space. If you have multiple address spaces to add, add your first
address space. You can add additional address spaces later, after creating the VNet. Make sure that the
address space that you specify does not overlap with the address space for your on-premises location.
Subnet name: Add the first subnet name and subnet address range. You can add additional subnets
and the gateway subnet later, after creating this VNet.
Subscription: Verify that the subscription listed is the correct one. You can change subscriptions by
using the drop-down.
Resource group: Select an existing resource group, or create a new one by typing a name for your new
resource group. If you are creating a new group, name the resource group according to your planned
configuration values. For more information about resource groups, visit Azure Resource Manager
Overview.
Location: Select the location for your VNet. The location determines where the resources that you
deploy to this VNet will reside.
5. Select Pin to dashboard if you want to be able to find your VNet easily on the dashboard, and then click
Create. After clicking Create, you will see a tile on your dashboard that will reflect the progress of your
VNet. The tile changes as the VNet is being created.
2. Specify a DNS server

DNS is not required to create a Site-to-Site connection. However, if you want to have name resolution for
resources that are deployed to your virtual network, you should specify a DNS server. This setting lets you specify
the DNS server that you want to use for name resolution for this virtual network. It does not create a DNS server.
For more information about name resolution, see Name Resolution for VMs and role instances.
1. On the Settings page for your virtual network, navigate to DNS Servers and click to open the DNS
servers blade.
DNS Servers: Select select Custom.

Add DNS server: Enter the IP address of the DNS server that you want to use for name resolution.
2. When you are done adding DNS servers, click Save at the top of the blade.
3. Create the gateway subnet

The virtual network gateway uses specific subnet called the 'GatewaySubnet'. The gateway subnet contains the IP
addresses that are used by the VPN gateway services. When you create a gateway subnet, it must be named
'GatewaySubnet'. Naming a subnet 'GatewaySubnet' tells Azure where to create the gateway services. If you
name the subnet something else, your VPN gateway configuration will fail.
The IP addresses in the GatewaySubnet are allocated to the gateway services. When you create the
GatewaySubnet, you specify the number of IP addresses that the subnet contains. The size of the GatewaySubnet
that you specify depends on the VPN gateway configuration that you want to create. While it is possible to create
a GatewaySubnet as small as /29, we recommend that you create a larger subnet that includes more addresses
by selecting /27 or /28. Using a larger gateway subnet allows for enough IP addresses to accommodate possible
future configurations.
1. In the portal, navigate to the virtual network for which you want to create a virtual network gateway.
2. In the Settings section of your VNet blade, click Subnets to expand the Subnets blade.
3. On the Subnets blade, click +Gateway subnet at the top. This will open the Add subnet blade.
4. The Name for your subnet will automatically be filled in with the value 'GatewaySubnet'. This value is
required in order for Azure to recognize the subnet as the GatewaySubnet. Adjust the auto-filled Address
range values to match your configuration requirements.
5. Click OK at the bottom of the blade to create the subnet.
4. Create the VPN gateway

1. On the left side of the portal page, click + and type 'Virtual Network Gateway' in search. In Results, locate and
click Virtual network gateway.
2. At the bottom of the 'Virtual network gateway' blade, click Create. This opens the Create virtual network
gateway blade.
3. On the Create virtual network gateway blade, specify the values for your virtual network gateway.
Name: Name your gateway. This is not the same as naming a gateway subnet. It's the name of the
gateway object you are creating.
Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
VPN type: Select the VPN type that is specified for your configuration. Most configurations require a
Route-based VPN type.
SKU: Select the gateway SKU from the dropdown. The SKUs listed in the dropdown depend on the VPN
type you select. For more information about gateway SKUs, see Gateway SKUs.
Location: You may need to scroll to see Location. Adjust the Location field to point to the location
where your virtual network is located. If the location is not pointing to the region where your virtual
network resides, the virtual network will not appear in the next step 'Choose a virtual network'
dropdown.
Virtual network: Choose the virtual network to which you want to add this gateway. Click Virtual
network to open the 'Choose a virtual network' blade. Select the VNet. If you don't see your VNet,
make sure the Location field is pointing to the region in which your virtual network is located.
Public IP address: The 'Create public IP address' blade creates a public IP address object. The
public IP address is dynamically assigned when the VPN gateway is created. VPN Gateway currently
only supports Dynamic Public IP address allocation. However, this does not mean that the IP
address changes after it has been assigned to your VPN gateway. The only time the Public IP
address changes is when the gateway is deleted and re-created. It doesn't change across resizing,
resetting, or other internal maintenance/upgrades of your VPN gateway.
First, click Public IP address to open the 'Choose public IP address' blade, then click +Create
New to open the 'Create public IP address' blade.
Next, input a Name for your public IP address, then click OK at the bottom of this blade to
save your changes.
4. Verify the settings. You can select Pin to dashboard at the bottom of the blade if you want your gateway
to appear on the dashboard.
5. Click Create to begin creating the VPN gateway. The settings will be validated and you'll see the "Deploying
Virtual network gateway" tile on the dashboard. Creating a gateway can take up to 45 minutes. You may need
to refresh your portal page to see the completed status.
After the gateway is created, view the IP address that has been assigned to it by looking at the virtual network in
the portal. The gateway will appear as a connected device. You can click the connected device (your virtual
network gateway) to view more information.
5. Create the local network gateway

The local network gateway typically refers to your on-premises location. You give the site a name by which Azure
can refer to it, then specify the IP address of the on-premises VPN device to which you will create a connection.
You also specify the IP address prefixes that will be routed through the VPN gateway to the VPN device. The
address prefixes you specify are the prefixes located on your on-premises network. If your on-premises network
changes or you need to change the public IP address for the VPN device, you can easily update the values later.
1. In the portal, from All resources, click +Add.
2. In the Everything blade search box, type Local network gateway, then click to search. This will return a
list. Click Local network gateway to open the blade, then click Create to open the Create local network
gateway blade.
3. On the Create local network gateway blade, specify the values for your local network gateway.
Name: Specify a name for your local network gateway object.
IP address: This is the public IP address of the VPN device that you want Azure to connect to. Specify a
valid public IP address. The IP address cannot be behind NAT and has to be reachable by Azure. If you
don't have the IP address right now, you can use the values shown in the screen shot, but you'll need to
go back and replace your placeholder IP address with the public IP address of your VPN device.
Otherwise, Azure will not be able to connect.
Address Space refers to the address ranges for the network that this local network represents. 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. Azure will route the address range that you
specify to the on-premises VPN device IP address. Use your own values here, not the values shown in
the screenshot.
Subscription: Verify that the correct subscription is showing.
Resource Group: Select the resource group that you want to use. You can either create a new resource
group, or select one that you have already created.
Location: Select the location that this object will be created in. You may want to select the same
location that your VNet resides in, but you are not required to do so.
4. When you have finished specifying the values, click Create at the bottom of the blade to create the local
network gateway.
6. Configure your VPN device

Site-to-Site connections to an on-premises network require a VPN device. In this step, you configure your VPN
device. When configuring your VPN device, you need the following:
A shared key. This is the same shared key that you specify when creating your Site-to-Site VPN connection. In
our examples, we use a basic shared key. We recommend that you generate a more complex key to use.
The Public IP address of your virtual network gateway. You can view the public IP address by using the Azure
portal, PowerShell, or CLI. To find the Public IP address of your VPN gateway using the Azure portal, navigate
to Virtual network gateways, then click the name of your gateway.
you want to use.
connections.
7. Create the VPN connection

Create the Site-to-Site VPN connection between your virtual network gateway and your on-premises VPN device.
1. Navigate to and open the blade for your virtual network gateway. There are multiple ways to navigate. In our
example, we navigated to the gateway 'VNet1GW' by going to TestVNet1 -> Overview -> Connected
devices -> VNet1GW.
2. On the blade for VNet1GW, click Connections. At the top of the Connections blade, click +Add to open
the Add connection blade.
3. On the Add connection blade, fill in the values to create your connection.
Name: Name your connection. We use VNet1toSite2 in our example.
Connection type: Select Site-to-site(IPSec).
Virtual network gateway: The value is fixed because you are connecting from this gateway.
Local network gateway: Click Choose a local network gateway and select the local network
gateway that you want to use. In our example, we use Site2.
Shared Key: the value here must match the value that you are using for your local on-premises VPN
device. In the example, we used 'abc123', but you can (and should) use something more complex. The
important thing is that the value you specify here must be the same value that you specified when
configuring your VPN device.
The remaining values for Subscription, Resource Group, and Location are fixed.
4. Click OK to create your connection. You'll see Creating Connection flash on the screen.
5. You can view the connection in the Connections blade of the virtual network gateway. The Status will go
from Unknown to Connecting, and then to Succeeded.
8. Verify the VPN connection

In the Azure portal, you can view the connection status of a Resource Manager VPN Gateway by navigating to the
connection. The following steps show one way to navigate to your connection and verify.
1. In the Azure portal, click All resources and navigate to your virtual network gateway.
2. On the blade for your virtual network gateway, click Connections. You can see the status of each connection.
3. Click the name of the connection that you want to verify to open Essentials. In Essentials, you can view
more information about your connection. The Status is 'Succeeded' and 'Connected' when you have made
a successful connection.
To connect to a virtual machine

You can connect to a VM that is deployed to your VNet by creating a Remote Desktop Connection to your VM.
The best way to initially verify that you can connect to your VM is to connect by using its private IP address, rather
than computer name. That way, you are testing to see if you can connect, not whether name resolution is
configured properly.
1. Locate the private IP address. You can find the private IP address of a VM in multiple ways. Below, we show
the steps for the Azure portal and for PowerShell.
Azure portal - Locate your virtual machine in the Azure portal. View the properties for the VM. The
private IP address is listed.
PowerShell - Use the example to view a list of VMs and private IP addresses from your resource
groups. You don't need to modify this example before using it.
$VMs = Get-AzureRmVM
$Nics = Get-AzureRmNetworkInterface | Where VirtualMachine -ne $null
foreach($Nic in $Nics)
{
$VM = $VMs | Where-Object -Property Id -eq $Nic.VirtualMachine.Id
$Prv = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAddress
$Alloc = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAllocationMethod
Write-Output "$($VM.Name): $Prv,$Alloc"
}
2. Verify that you are connected to your VNet using the VPN connection.
3. Open Remote Desktop Connection by typing "RDP" or "Remote Desktop Connection" in the search box on
the taskbar, then select Remote Desktop Connection. You can also open Remote Desktop Connection using
the 'mstsc' command in PowerShell.
4. In Remote Desktop Connection, enter the private IP address of the VM. You can click "Show Options" to adjust
additional settings, then connect.
To troubleshoot an RDP connection to a VM
Resolution for VMs.
For more information about RDP connections, see Troubleshoot Remote Desktop connections to a VM.
Next steps
For information about BGP, see the BGP Overview and How to configure BGP.
For information about Forced Tunneling, see About Forced Tunneling
For information about Highly Available Active-Active connections, see Highly Available cross-premises and
VNet-to-VNet connectivity.
Create a VNet with a Site-to-Site VPN connection
using PowerShell
This article shows you how to use PowerShell to create a Site-to-Site VPN gateway connection from your on-
premises network to the VNet. The steps in this article apply to the Resource Manager deployment model. You can
also create this configuration using a different deployment tool or deployment model by selecting a different
About VPN gateway.
Before you begin

Verify that you have met the following criteria before beginning your configuration:
An externally facing public IPv4 address for your VPN device. This IP address cannot be located behind a NAT.
to.
The latest version of the Azure Resource Manager PowerShell cmdlets. See How to install and configure Azure
PowerShell for more information about installing the PowerShell cmdlets.
Example values
#Example values
VnetName = testvnet
ResourceGroup = testrg
Location = West US
AddressSpace = 10.0.0.0/16
SubnetName = Subnet1
Subnet = 10.0.1.0/28
GatewaySubnet = 10.0.0.0/27
LocalNetworkGatewayName = LocalSite
LNG Public IP = <VPN device IP address>
Local Address Prefixes = 10.0.0.0/24','20.0.0.0/24
Gateway Name = vnetgw1
PublicIP = gwpip
Gateway IP Config = gwipconfig1
VPNType = RouteBased
GatewayType = Vpn
ConnectionName = myGWConnection
1. Connect to your subscription

Before beginning this configuration, you must log in to your Azure account. The cmdlet prompts you for the login
credentials for your Azure account. After logging in, it downloads your account settings so they are available to
Azure PowerShell. For more information, see Using Windows PowerShell with Resource Manager.
Open your PowerShell console with elevated privileges, and connect to your account. Use the following example
to help you connect:
Login-AzureRmAccount
If you have multiple Azure subscriptions, check the subscriptions for the account.
Get-AzureRmSubscription
Specify the subscription that you want to use.
Select-AzureRmSubscription -SubscriptionName "Replace_with_your_subscription_name"
2. Create a virtual network and a gateway subnet

If you don't already have a virtual network, create one. When creating a virtual network, make sure that the
address spaces you specify don't overlap any of the address spaces that you have on your on-premises network.
The virtual network gateway uses specific subnet called the 'GatewaySubnet'. The gateway subnet contains the IP
addresses that are used by the VPN gateway services. When you create a gateway subnet, it must be named
'GatewaySubnet'. Naming a subnet 'GatewaySubnet' tells Azure where to create the gateway services. If you name
the subnet something else, your VPN gateway configuration will fail.
The IP addresses in the GatewaySubnet are allocated to the gateway services. When you create the
GatewaySubnet, you specify the number of IP addresses that the subnet contains. The size of the GatewaySubnet
that you specify depends on the VPN gateway configuration that you want to create. While it is possible to create a
GatewaySubnet as small as /29, we recommend that you create a larger subnet that includes more addresses by
selecting /27 or /28. Using a larger gateway subnet allows for enough IP addresses to accommodate possible
future configurations.
IMPORTANT
To create a virtual network and a gateway subnet

This example creates a virtual network and a gateway subnet. If you already have a virtual network that you need
to add a gateway subnet to, see To add a gateway subnet to a virtual network you have already created.
Create a resource group:
New-AzureRmResourceGroup -Name testrg -Location 'West US'
Create your virtual network.

1. Set the variables.
$subnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.0.0/27

$subnet2 = New-AzureRmVirtualNetworkSubnetConfig -Name 'Subnet1' -AddressPrefix '10.0.1.0/28'
2. Create the VNet.
New-AzureRmVirtualNetwork -Name testvnet -ResourceGroupName testrg `

-Location 'West US' -AddressPrefix 10.0.0.0/16 -Subnet $subnet1, $subnet2
To add a gateway subnet to a virtual network you have already created

$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName testrg -Name testvnet
2. Create the gateway subnet.
Add-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.0.0/27 -VirtualNetwork

$vnet
3. Set the configuration.
Set-AzureRmVirtualNetwork -VirtualNetwork $vnet

changes, you can easily update the prefixes.
Use the following values:
The GatewayIPAddress is the IP address of your on-premises VPN device. Your VPN device cannot be located
behind a NAT.
The AddressPrefix is your on-premises address space.
To add a local network gateway with a single address prefix:

-Location 'West US' -GatewayIpAddress '23.99.221.164' -AddressPrefix '10.0.0.0/24'
To add a local network gateway with multiple address prefixes:

-Location 'West US' -GatewayIpAddress '23.99.221.164' -AddressPrefix @('10.0.0.0/24','20.0.0.0/24')
To modify IP address prefixes for your local network gateway:

Sometimes your local network gateway prefixes change. The steps you take to modify your IP address prefixes
depend on whether you have created a VPN gateway connection. See the Modify IP address prefixes for a local
network gateway section of this article.
4. Request a Public IP address

A VPN gateway must have a Public IP address. You first request the IP address resource, and then refer to it when
creating your virtual network gateway. The IP address is dynamically assigned to the resource when the VPN
gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. You cannot
request a Static Public IP address assignment. However, this does not mean that the IP address changes after it has
been assigned to your VPN gateway. The only time the Public IP address changes is when the gateway is deleted
and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN
gateway.
Request a Public IP address that will be assigned to your virtual network VPN gateway.
$gwpip= New-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName testrg -Location 'West US' -AllocationMethod
Dynamic
5. Create the gateway IP addressing configuration

The gateway configuration defines the subnet and the public IP address to use. Use the following example to
create your gateway configuration:
$vnet = Get-AzureRmVirtualNetwork -Name testvnet -ResourceGroupName testrg

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name gwipconfig1 -SubnetId $subnet.Id -
PublicIpAddressId $gwpip.Id

Create the virtual network VPN gateway. Creating a VPN gateway can take up to 45 minutes or more to complete.
The -GatewayType for a Site-to-Site configuration is Vpn. The gateway type is always specific to the
configuration that you are implementing. For example, other gateway configurations may require -
GatewayType ExpressRoute.
The -VpnType can be RouteBased (referred to as a Dynamic Gateway in some documentation), or PolicyBased
(referred to as a Static Gateway in some documentation). For more information about VPN gateway types, see
About VPN Gateway.
The -GatewaySku can be Basic, Standard, or HighPerformance. There are configuration limitations for certain
SKUs. For more information, see Gateway SKUs.

-Location 'West US' -IpConfigurations $gwipconfig -GatewayType Vpn `
-VpnType RouteBased -GatewaySku Standard

The Public IP address of your virtual network gateway. You can view the public IP address by using the
Azure portal, PowerShell, or CLI. To find the Public IP address of your virtual network gateway using
PowerShell, use the following example:
Get-AzureRmPublicIpAddress -Name GW1PublicIP -ResourceGroupName TestRG

you want to use.
connections.

Next, create the Site-to-Site VPN connection between your virtual network gateway and your VPN device. Be sure
to replace the values with your own. The shared key must match the value you used for your VPN device
configuration. Notice that the '-ConnectionType' for Site-to-Site is IPsec.
$gateway1 = Get-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg

$local = Get-AzureRmLocalNetworkGateway -Name LocalSite -ResourceGroupName testrg
2. Create the connection.

New-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName testrg `
-Location 'West US' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
After a short while, the connection will be established.

There are a few different ways to verify your VPN connection.
You can verify that your connection succeeded by using the 'Get-AzureRmVirtualNetworkGatewayConnection'
cmdlet, with or without '-Debug'.
1. Use the following cmdlet example, configuring the values to match your own. If prompted, select 'A' in
order to run 'All'. In the example, '-Name' refers to the name of the connection that you want to test.
Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName MyRG
2. After the cmdlet has finished, view the values. In the example below, the connection status shows as
'Connected' and you can see ingress and egress bytes.
"connectionStatus": "Connected",
"ingressBytesTransferred": 33509044,
"egressBytesTransferred": 4142431

You can connect to a VM that is deployed to your VNet by creating a Remote Desktop Connection to your VM. The
best way to initially verify that you can connect to your VM is to connect by using its private IP address, rather than
computer name. That way, you are testing to see if you can connect, not whether name resolution is configured
properly.
{
}
the taskbar, then select Remote Desktop Connection. You can also open Remote Desktop Connection using the
'mstsc' command in PowerShell.
Resolution for VMs.
Modify IP address prefixes for a local network gateway

If the IP address prefixes that you want routed to your on-premises location change, you can modify the local
network gateway. Two sets of instructions are provided. The instructions you choose depend on whether you have
already created your gateway connection.
To modify local network gateway IP address prefixes - no gateway connection
To add additional address prefixes:
$local = Get-AzureRmLocalNetworkGateway -Name MyLocalNetworkGWName -ResourceGroupName MyRGName `

Set-AzureRmLocalNetworkGateway -LocalNetworkGateway $local `
-AddressPrefix @('10.0.0.0/24','20.0.0.0/24','30.0.0.0/24')
To remove address prefixes:

Leave out the prefixes that you no longer need. In this example, we no longer need prefix 20.0.0.0/24 (from the
previous example), so we update the local network gateway, excluding that prefix.

-AddressPrefix @('10.0.0.0/24','30.0.0.0/24')
To modify local network gateway IP address prefixes - existing gateway connection

If you have a gateway connection and want to add or remove the IP address prefixes contained in your local
network gateway, you need to do the following steps, in order. This results in some downtime for your VPN
connection. When modifying IP address prefixes, you don't need to delete the VPN gateway. You only need to
remove the connection.
1. Remove the connection.
Remove-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName -ResourceGroupName MyRGName
2. Modify the address prefixes for your local network gateway.

Set the variable for the LocalNetworkGateway.
$local = Get-AzureRmLocalNetworkGateway -Name MyLocalNetworkGWName -ResourceGroupName MyRGName
Modify the prefixes.

-AddressPrefix @('10.0.0.0/24','20.0.0.0/24','30.0.0.0/24')
3. Create the connection. In this example, we configure an IPsec connection type. When you recreate your
connection, use the connection type that is specified for your configuration. For additional connection types,
see the PowerShell cmdlet page.
Set the variable for the VirtualNetworkGateway.
$gateway1 = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName MyRGName
Create the connection. This example uses the variable $local that you set in step 2.
New-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName `

-ResourceGroupName MyRGName -Location 'West US' `
-VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec `
-RoutingWeight 10 -SharedKey 'abc123'
Modify the gateway IP address for a local network gateway

To modify the local network gateway 'GatewayIpAddress' - no gateway connection
If the VPN device that you want to connect to has changed its public IP address, you need to modify the local
network gateway to reflect that change. Use the example to modify a local network gateway that does not have a
gateway connection.
When modifying this value, you can also modify the address prefixes at the same time. Be sure to use the existing
name of your local network gateway in order to overwrite the current settings. If you use a different name, you
create a new local network gateway, instead of overwriting the existing one.
New-AzureRmLocalNetworkGateway -Name MyLocalNetworkGWName `

-Location "West US" -AddressPrefix @('10.0.0.0/24','20.0.0.0/24','30.0.0.0/24') `
-GatewayIpAddress "5.4.3.2" -ResourceGroupName MyRGName
To modify the local network gateway 'GatewayIpAddress' - existing gateway connection

network gateway to reflect that change. If a gateway connection already exists, you first need to remove the
connection. After the connection is removed, you can modify the gateway IP address and recreate a new
connection. You can also modify the address prefixes at the same time. This results in some downtime for your
VPN connection. When modifying the gateway IP address, you don't need to delete the VPN gateway. You only
need to remove the connection.
1. Remove the connection. You can find the name of your connection by using the 'Get-
AzureRmVirtualNetworkGatewayConnection' cmdlet.
Remove-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName `

-ResourceGroupName MyRGName
2. Modify the 'GatewayIpAddress' value. You can also modify the address prefixes at the same time. Be sure to
use the existing name of your local network gateway to overwrite the current settings. If you don't, you
see the PowerShell cmdlet page. To obtain the VirtualNetworkGateway name, you can run the 'Get-
AzureRmVirtualNetworkGateway' cmdlet.
Set the variables.
$local = Get-AzureRMLocalNetworkGateway -Name MyLocalNetworkGWName -ResourceGroupName MyRGName `

$vnetgw = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName MyRGName
Create the connection.
New-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName -ResourceGroupName MyRGName `

-Location "West US" `
-VirtualNetworkGateway1 $vnetgw `
-LocalNetworkGateway2 $local `
Next steps
Once your connection is complete, you can add virtual machines to your virtual networks. For more
information, see Virtual Machines.
Create a virtual network with a Site-to-Site VPN
connection using CLI
This article shows you how to use the Azure CLI to create a Site-to-Site VPN gateway connection from your on-
premises network to the VNet. The steps in this article apply to the Resource Manager deployment model. You can
also create this configuration using a different deployment tool or deployment model by selecting a different
that has an externally facing public IP address assigned to it. For more information about VPN gateways, see About
VPN gateway.
Before you begin

Verify that you have met the following criteria before beginning configuration:
An externally facing public IPv4 address for your VPN device. This IP address cannot be located behind a NAT.
to.
The latest version of the CLI commands (2.0 or later). For information about installing the CLI commands, see
Install Azure CLI 2.0 and Get Started with Azure CLI 2.0.
Example values
You can use the following values to create a test environment, or refer to these values to better understand the
examples in this article:
#Example values
VnetName = TestVNet1
ResourceGroup = TestRG1
Location = eastus
AddressSpace = 10.12.0.0/16
SubnetName = Subnet1
Subnet = 10.12.0.0/24
LocalNetworkGatewayName = Site2
LNG Public IP = <VPN device IP address>
LocalAddrPrefix1 = 10.0.0.0/24
LocalAddrPrefix2 = 20.0.0.0/24
GatewayName = VNet1GW
PublicIP = VNet1GWIP
VPNType = RouteBased
GatewayType = Vpn
ConnectionName = VNet1toSite2
1. Connect to your subscription

Log in to your Azure subscription with the az login command and follow the on-screen directions. For more
information about logging in, see Get Started with Azure CLI 2.0.
az login
If you have more than one Azure subscription, list the subscriptions for the account.
az account list --all
az account set --subscription <replace_with_your_subscription_id>
2. Create a resource group

The following example creates a resource group named 'TestRG1' in the 'eastus' location. If you already have a
resource group in the region that you want to create your VNet, you can use that one instead.
az group create --name TestRG1 --location eastus

If you don't already have a virtual network, create one using the az network vnet create command. When creating
a virtual network, make sure that the address spaces you specify don't overlap any of the address spaces that you
have on your on-premises network.
The following example creates a virtual network named 'TestVNet1' and a subnet, 'Subnet1'.
az network vnet create --name TestVNet1 --resource-group TestRG1 --address-prefix 10.12.0.0/16 --location
eastus --subnet-name Subnet1 --subnet-prefix 10.12.0.0/24
4. Create the gateway subnet
IMPORTANT
For this configuration, you also need a gateway subnet. The virtual network gateway uses a gateway subnet that
contains the IP addresses that are used by the VPN gateway services. When you create a gateway subnet, it must
be named 'GatewaySubnet'. If you name it something else, you create a subnet, but Azure won't treat it as a
gateway subnet.
The size of the gateway subnet that you specify depends on the VPN gateway configuration that you want to
create. While it is possible to create a gateway subnet as small as /29, we recommend that you create a larger
subnet that includes more addresses by selecting /27 or /28. Using a larger gateway subnet allows for enough IP
addresses to accommodate possible future configurations.
Use the az network vnet subnet create command to create the gateway subnet.
az network vnet subnet create --address-prefix 10.12.255.0/27 --name GatewaySubnet --resource-group TestRG1 --
vnet-name TestVNet1

changes, you can easily update the prefixes.
The --gateway-ip-address is the IP address of your on-premises VPN device. Your VPN device cannot be
located behind a NAT.
The --local-address-prefixes are your on-premises address spaces.
Use the az network local-gateway create command to add a local network gateway with multiple address prefixes:
az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 --resource-group TestRG1 --

local-address-prefixes 10.0.0.0/24 20.0.0.0/24
6. Request a Public IP address

A VPN gateway must have a Public IP address. You first request the IP address resource, and then refer to it when
creating your virtual network gateway. The IP address is dynamically assigned to the resource when the VPN
gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. You cannot
request a Static Public IP address assignment. However, this does not mean that the IP address changes after it has
been assigned to your VPN gateway. The only time the Public IP address changes is when the gateway is deleted
and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN
gateway.
Use the az network public-ip create command to request a Dynamic Public IP address.
az network public-ip create --name VNet1GWIP --resource-group TestRG1 --allocation-method Dynamic

Create the virtual network VPN gateway. Creating a VPN gateway can take up to 45 minutes or more to complete.
The --gateway-type for a Site-to-Site configuration is Vpn. The gateway type is always specific to the
configuration that you are implementing. For more information, see Gateway types.
The --vpn-type can be RouteBased (referred to as a Dynamic Gateway in some documentation), or PolicyBased
(referred to as a Static Gateway in some documentation). The setting is specific to requirements of the device
that you are connecting to. For more information about VPN gateway types, see About VPN Gateway
configuration settings.
The --sku can be Basic, Standard, or HighPerformance. There are configuration limitations for certain SKUs. For
more information, see Gateway SKUs.
Create the VPN gateway using the az network vnet-gateway create command. If you run this command using the
'--no-wait' parameter, you don't see any feedback or output. This parameter allows the gateway to create in the
background. It takes around 45 minutes to create a gateway.
az network vnet-gateway create --name VNet1GW --public-ip-address VNet1GWIP --resource-group TestRG1 --vnet
TestVNet1 --gateway-type Vpn --vpn-type RouteBased --sku Standard --no-wait

The Public IP address of your virtual network gateway. You can view the public IP address by using the
Azure portal, PowerShell, or CLI. To find the public IP address of your virtual network gateway, use the az
network public-ip list command. For easy reading, the output is formatted to display the list of public IPs in
table format.
az network public-ip list --resource-group TestRG1 --output table

you want to use.
connections.

Create the Site-to-Site VPN connection between your virtual network gateway and your on-premises VPN device.
Pay particular attention to the shared key value, which must match the configured shared key value for your VPN
device.
Create the connection using the az network vpn-connection create command.
az network vpn-connection create --name VNet1toSite2 -resource-group TestRG1 --vnet-gateway1 VNet1GW -l eastus
--shared-key abc123 --local-gateway2 Site2
After a short while, the connection will be established.

You can verify that your connection succeeded by using the az network vpn-connection show command. In the
example,'--name'refers to the name of the connection that you want to test. When the connection is in the process
of being established, its connection status shows 'Connecting'. Once the connection is established, the status
changes to 'Connected'.
az network vpn-connection show --name VNet1toSite2 --resource-group TestRG1
If you want to use another method to verify your connection, see Verify a VPN Gateway connection.

best way to initially verify that you can connect to your VM is to connect by using its private IP address, rather than
computer name. That way, you are testing to see if you can connect, not whether name resolution is configured
properly.
{
}
Resolution for VMs.
Common tasks
This section contains common commands that are helpful when working with site-to-site configurations. For the
full list of CLI networking commands, see Azure CLI - Networking.
To view local network gateways
To view a list of the local network gateways, use the az network local-gateway list command.
az network local-gateway list --resource-group TestRG1

If you don't have a gateway connection and you want to add or remove IP address prefixes, you use the same
command that you use to create the local network gateway, az network local-gateway create. You can also use this
command to update the gateway IP address for the VPN device. To overwrite the current settings, use the existing
name of your local network gateway. If you use a different name, you create a new local network gateway, instead
of overwriting the existing one.
Each time you make a change, the entire list of prefixes must be specified, not just the prefixes that you want to
change. Specify only the prefixes that you want to keep. In this case, 10.0.0.0/24 and 20.0.0.0/24
az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 --connection-name TestRG1 --


If you have a gateway connection and want to add or remove IP address prefixes, you can update the prefixes
using az network local-gateway update. This results in some downtime for your VPN connection. When modifying
the IP address prefixes, you don't need to delete the VPN gateway.
change. In this example, 10.0.0.0/24 and 20.0.0.0/24 are already present. We add the prefixes 30.0.0.0/24 and
40.0.0.0/24 and specify all 4 of the prefixes when updating.
az network local-gateway update --local-address-prefixes 10.0.0.0/24 20.0.0.0/24 30.0.0.0/24 40.0.0.0/24 --

name VNet1toSite2 --connection-name TestRG1
To modify the local network gateway 'gatewayIpAddress'

network gateway to reflect that change. The gateway IP address can be changed without removing an existing VPN
gateway connection (if you have one). To modify the gateway IP address, replace the values 'Site2' and 'TestRG1'
with your own using the az network local-gateway update command.
az network local-gateway update --gateway-ip-address 23.99.222.170 --name Site2 --resource-group TestRG1
Verify that the IP address is correct in the output:
"gatewayIpAddress": "23.99.222.170",
To verify the shared key values

Verify that the shared key value is the same value that you used for your VPN device configuration. If it is not,
either run the connection again using the value from the device, or update the device with the value from the
return. The values must match. To view the shared key, use the az network vpn-connection-list.
az network vpn-connection shared-key show --connection-name VNet1toSite2 --resource-group TestRG1
To view the VPN gateway Public IP address

To find the public IP address of your virtual network gateway, use the az network public-ip list command. For easy
reading, the output for this example is formatted to display the list of public IPs in table format.
az network public-ip list --resource-group TestRG1 --output table
Next steps
information, see Virtual Machines.
For information about forced tunneling, see Configure forced tunneling.
For a list of networking Azure CLI commands, see Azure CLI.
Create a Site-to-Site connection using the Azure
portal (classic)
This article shows you how to use the Azure portal to create a Site-to-Site VPN gateway connection from your on-
premises network to the VNet. The steps in this article apply to the classic deployment model. You can also create
this configuration using a different deployment tool or deployment model by selecting a different option from the
following list:
About VPN gateway.
Before you begin

Verify that you have met the following criteria before beginning configuration:
Verify that you want to work with the classic deployment model. > [!NOTE] > Azure currently works with two
use the Resource Manager deployment model. > >
An externally facing public IPv4 IP address for your VPN device. This IP address cannot be located behind a
NAT.
to.
Currently, PowerShell is required to specify the shared key and create the VPN gateway connection. Install the
latest version of the Azure Service Management (SM) PowerShell cmdlets. For more information, see How to
install and configure Azure PowerShell. When working with PowerShell for this configuration, make sure that
you are running as administrator.
Sample configuration values for this exercise
Address Space:
10.11.0.0/16
10.12.0.0/16 (optional for this exercise)
Subnets:
FrontEnd: 10.11.0.0/24
BackEnd: 10.12.0.0/24 (optional for this exercise)
Location: East US
DNS Server: 8.8.8.8 (optional for this exercise)
Local site name: Site2

When you create a virtual network to use for a S2S connection, you need to make sure that the address spaces
that you specify do not overlap with any of the client address spaces for the local sites that you want to connect to.
If you have overlapping subnets, your connection won't work properly.
If you already have a VNet, verify that the settings are compatible with your VPN gateway design. Pay
particular attention to any subnets that may overlap with other networks.
If you don't already have a virtual network, create one. Screenshots are provided as examples. Be sure to
replace the values with your own.
To create a virtual network
1. From a browser, navigate to the Azure portal and, if necessary, sign in with your Azure account.
3. Near the bottom of the Virtual Network blade, from the Select a deployment model list, select Classic,
and then click Create.
4. On the Create virtual network blade, configure the VNet settings. In this blade, you add your first address
space and a single subnet address range. After you finish creating the VNet, you can go back and add
additional subnets and address spaces.
5. Verify that the Subscription is the correct one. You can change subscriptions by using the drop-down.
6. Click Resource group and either select an existing resource group, or create a new one by typing a name for
your new resource group. For more information about resource groups, visit Azure Resource Manager
Overview.
7. Next, select the Location settings for your VNet. The location determines where the resources that you deploy
to this VNet will reside.
Create.
9. After clicking 'Create', a tile appears on the dashboard that reflects the progress of your VNet. The tile
changes as the VNet is being created.
Once your virtual network has been created, you will see Created listed under Status on the networks page in the
Azure classic portal.
2. Add additional address space

After you create your virtual network, you can add additional address space. Adding additional address space is
not a required part of a S2S configuration, but if you require multiple address spaces, use the following steps:
1. Locate the virtual networks in the portal.
2. On the blade for your virtual network, under the Settings section, click Address space.
3. On the Address space blade, click +Add and enter additional address space.

DNS settings are not a required part of a S2S configuration, but DNS is necessary if you want name resolution.
After you create your virtual network, you can add the IP address of a DNS server to handle name resolution.
Open the settings for your virtual network, click DNS servers, and add the IP address of the DNS server that you
want to use for name resolution. This setting does not create a DNS server. In the example settings, we use a
public DNS server. Typically you'd want to use a private DNS server. Be sure to add a DNS server that your
resources can communicate with.
1. Locate the virtual networks in the portal.
2. On the blade for your virtual network, under the Settings section, click DNS servers.
3. Add a DNS server.
4. To save your settings, click Save at the top of the page.
4. Configure the local site

The local site typically refers to your on-premises location. It contains the IP address of the VPN device to which
you will create a connection, and the IP address ranges that will be routed through the VPN gateway to the VPN
device.
1. In the portal, navigate to the virtual network for which you want to create a gateway.
2. On the blade for your virtual network, on the Overview blade, in the VPN connections section, click
Gateway to open the New VPN Connection blade.
3. On the New VPN Connection blade, select Site-to-site.

4. Click Local site - Configure required settings to open the Local site blade. Configure the settings, and
then click OK to save the settings.
Name: Create a name for your local site to make it easy for you to identify.
VPN gateway IP address: This is the public IP address of the VPN device for your on-premises
network. The VPN device requires an IPv4 public IP address. Specify a valid public IP address for the VPN
device to which you want to connect. It cannot be behind NAT and has to be reachable by Azure.
Client Address space: List the IP address ranges that you want routed to the local on-premises
network through this gateway. You can add multiple address space ranges. Make sure that the
ranges you specify here do not overlap with ranges of other networks your virtual network connects
to, or with the address ranges of the virtual network itself.
5. Configure the gateway subnet

You must create a gateway subnet for your VPN gateway. The gateway subnet contains the IP addresses that the
VPN gateway services use.
1. On the New VPN Connection blade, select the checkbox Create gateway immediately. The 'Optional
gateway configuration' blade appears. If you don't select the checkbox, you won't see the blade to configure
the gateway subnet.
2. Click Optional gateway configuration - Subnet, size, and routing type to open the Gateway
configuration blade.
3. On the Gateway Configuration blade, click Subnet - Configure required settings to open the Add
subnet blade.
4. On the Add subnet blade, add the gateway subnet. The size of the gateway subnet that you specify
depends on the VPN gateway configuration that you want to create. While it is possible to create a gateway
subnet as small as /29, we recommend that you create a larger subnet that includes more addresses by
selecting /27 or /28. Using the larger gateway subnet allows for enough IP addresses to accommodate
possible future configurations.
6. Specify the SKU and VPN type

1. Select the gateway Size. This is the gateway SKU that you use to create your virtual network gateway. In the
portal, the 'Default SKU' = Basic. For more information about gateway SKUs, see About VPN Gateway
Settings.
2. Select the Routing Type for your gateway. This is also known as the VPN type. It's important to select the
correct gateway type because you cannot convert the gateway from one type to another. Your VPN device
must be compatible with the routing type you select. For more information about VPN type, see About VPN
Gateway Settings. You may see articles referring to 'RouteBased' and 'PolicyBased' VPN types. 'Dynamic'
corresponds to 'RouteBased', and 'Static' corresponds to' PolicyBased'.
3. Click OK to save the settings.
4. On the New VPN Connection blade, click OK at the bottom of the blade to begin creating your virtual
network gateway. This can take up to 45 minutes to complete.

The Public IP address of your virtual network gateway. You can view the public IP address by using the Azure
portal, PowerShell, or CLI.
you want to use.
connections.
8. Create the connection

In this step, you set the shared key and create the connection. The key you set is must be the same key that was
used in your VPN device configuration.
NOTE
Currently, this step is not available in the Azure portal. You must use the Service Management (SM) version of the Azure
PowerShell cmdlets.
Step 1. Connect to your Azure account

1. Open your PowerShell console with elevated rights and connect to your account. Use the following example
2. Check the subscriptions for the account.
3. If you have more than one subscription, select the subscription that you want to use.
4. Add the SM version of the PowerShell cmdlets.
Add-AzureAccount
Step 2. Set the shared key and create the connection

When working with PowerShell and the classic deployment model, sometimes the names of resources in the
portal are not the names the Azure expects to see when using PowerShell. The following steps help you export the
network configuration file to obtain the exact values for the names.
1. Create a directory on your computer and then export the network configuration file to the directory. In this
example, the network configuration file is exported to C:\AzureNet.
Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
2. Open the network configuration file with an xml editor and check the values for 'LocalNetworkSite name'
and 'VirtualNetworkSite name'. Modify the example to reflect the values. When specifying a name that
contains spaces, use single quotation marks around the value.
3. Set the shared key and create the connection. The '-SharedKey' is a value that you generate and specify. In
the example, we used 'abc123', but you can generate (and should) use something more complex. The
important thing is that the value you specify here must be the same value that you specified when
configuring your VPN device.
Set-AzureVNetGatewayKey -VNetName 'Group TestRG1 TestVNet1' `

-LocalNetworkSiteName 'D1BFC9CB_Site2' -SharedKey abc123
When the connection is created, the result is: Status: Successful.
9. Verify your connection

In the Azure portal, you can view the connection status for a classic VNet VPN Gateway by navigating to the
1. In the Azure portal, click All resources and navigate to your classic virtual network.
2. On the virtual network blade, click Overview to access the VPN connections section of the blade.
3. On the VPN connections graphic, click the site.
4. On the Site-to-site VPN connections blade, view the information about your site.
5. To view more information about the connection, click the name of the connection to open the Site-to-site
VPN Connection blade.
Next steps
Once your connection is complete, you can add virtual machines to your virtual networks. For more information,
see Virtual Machines.
Create a VNet with a Site-to-Site connection using
the classic portal (classic)
This article shows you how to use the classic portal to create a Site-to-Site VPN gateway connection from your
on-premises network to the VNet. The steps in this article apply to the classic deployment model. You can also
create this configuration using a different deployment tool or deployment model by selecting a different option
from the following list:
About VPN gateway.
Additional configurations
If you want to connect VNets together, see Configure a VNet-to-VNet connection for the classic deployment
model. If you want to add a Site-to-Site connection to a VNet that already has a connection, see Add a S2S
connection to a VNet with an existing VPN gateway connection.
Before you begin

NOTE
Azure currently works with two deployment models: Resource Manager and classic. The two models are not completely
compatible with each other. Before you begin, you need to know which model that you want to work in. For information
about the deployment models, see Understanding deployment models. If you are new to Azure, we recommend that you
Verify that you have the following items before beginning configuration:
A compatible VPN device and someone who is able to configure it. See About VPN Devices. If you aren't
familiar with configuring your VPN device, or are unfamiliar with the IP address ranges located in your on-
premises network configuration, you need to coordinate with someone who can provide those details for you.
An externally facing public IP address for your VPN device. This IP address cannot be located behind a NAT.
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.
Create your virtual network

1. Log in to the Azure classic portal.
2. In the lower left corner of the screen, click New. In the navigation pane, click Network Services, and then click
Virtual Network. Click Custom Create to begin the configuration wizard.
3. To create your VNet, enter your configuration settings on the following pages:
Virtual network details page

Enter the following information:
Name: Name your virtual network. For example, EastUSVNet. You use this virtual network name when you
deploy your VMs and PaaS instances, so you may not want to make the name too complicated.
Location: The location is directly related to the physical location (region) where you want your resources
(VMs) to reside. For example, if you want the VMs that you deploy to this virtual network to be physically
located in East US, select that location. You can't change the region associated with your virtual network after
you create it.
DNS servers and VPN connectivity page

Enter the following information, and then click the next arrow on the lower right.
DNS Servers: Enter the DNS server name and IP address, or select a previously registered DNS server from
the shortcut menu. This setting does not create a DNS server. It allows you to specify the DNS servers that you
want to use for name resolution for this virtual network.
Configure Site-To-Site VPN: Select the checkbox for Configure a site-to-site VPN.
Local Network: A local network represents your physical on-premises location. You can select a local network
that you've previously created, or you can create a new local network. However, if you select to use a local
network that you previously created, go to the Local Networks configuration page and verify that the VPN
Device IP address (public facing IPv4 address) for the VPN device is accurate.
Site-to-site connectivity page

If you're creating a new local network, you see the Site-To-Site Connectivity page. If you want to use a local
network that you previously created, this page will not appear in the wizard and you can move on to the next
section.
Enter the following information, and then click the next arrow.
Name: The name you want to call your local (on-premises) network site.
VPN Device IP Address: The public facing IPv4 address of your on-premises VPN device that you use to
connect to Azure. The VPN device cannot be located behind a NAT.
Address Space: Include Starting IP and CIDR (Address Count). You specify the address range(s) that you want
to be sent through the virtual network gateway to your local on-premises location. If a destination IP address
falls within the ranges that you specify here, it is routed through the virtual network gateway.
Add address space: If you have multiple address ranges that you want to be sent through the virtual network
gateway, specify each additional address range. You can add or remove ranges later on the Local Network
page.
Virtual network address spaces page

Specify the address range that you want to use for your virtual network. These are the dynamic IP addresses
(DIPS) that will be assigned to the VMs and other role instances that you deploy to this virtual network.
It's especially important to select a range that does not overlap with any of the ranges that are used for your on-
premises network. You need to coordinate with your network administrator. Your network administrator may
need to carve out a range of IP addresses from your on-premises network address space for you to use for your
virtual network.
Enter the following information, and then click the checkmark on the lower right to configure your network.
Address Space: Include Starting IP and Address Count. Verify that the address spaces you specify don't
overlap any of the address spaces that you have on your on-premises network.
Add subnet: Include Starting IP and Address Count. Additional subnets are not required, but you may want to
create a separate subnet for VMs that will have static DIPS. Or you might want to have your VMs in a subnet
that is separate from your other role instances.
Add gateway subnet: Click to add the gateway subnet. The gateway subnet is used only for the virtual
network gateway and is required for this configuration.
Click the checkmark on the bottom of the page to create your virtual network. When it completes, you see
Created listed under Status on the Networks page in the Azure Classic Portal. After the VNet has been created,
you can then configure your virtual network gateway.
IMPORTANT
Configure your virtual network gateway

Configure the virtual network gateway to create a secure site-to-site connection. See Configure a virtual network
gateway in the Azure classic portal.
Next steps
see Virtual Machines.
Configure a Point-to-Site connection to a VNet using
the Azure portal
This article shows you how to create a VNet with a Point-to-Site connection in the Resource Manager deployment
model using the Azure portal. You can also create this configuration using a different deployment tool or
deployment model by selecting a different option from the following list:
A Point-to-Site (P2S) configuration lets you create a secure connection from an individual client computer to a
virtual network. Point-to-Site connections are useful when you want to connect to your VNet from a remote
location, such as from home or a conference, or when you only have a few clients that need to connect to a virtual
network. The P2S VPN connection is initiated from the client computer using the native Windows VPN client.
Connecting clients use certificates to authenticate.
Point-to-Site connections do not require a VPN device or a public-facing IP address. P2S creates the VPN
connection over SSTP (Secure Socket Tunneling Protocol). On the server side, we support SSTP versions 1.0, 1.1,
and 1.2. The client decides which version to use. For Windows 8.1 and above, SSTP uses 1.2 by default. For more
information about Point-to-Site connections, see the Point-to-Site FAQ at the end of this article.
P2S connections require the following:
A RouteBased VPN gateway.
The public key (.cer file) for a root certificate, uploaded to Azure. This is considered a trusted certificate and is
used for authentication.
A client certificate generated from the root certificate, and installed on each client computer that will connect.
This certificate is used for client authentication.
A VPN client configuration package must be generated and installed on every client computer that connects.
The client configuration package configures the native VPN client that is already on the operating system with
the necessary information to connect to the VNet.
Example values
Name: VNet1
Address space: 192.168.0.0/16
For this example, we use only one address space. You can have more than one address space for your VNet.
Subnet name: FrontEnd
Subnet address range: 192.168.1.0/24
Subscription: If you have more than one subscription, verify that you are using the correct one.
Resource Group: TestRG
Location: East US
Virtual network gateway name: VNet1GW
Gateway type: VPN
VPN type: Route-based
Public IP address: VNet1GWpip
Connection type: Point-to-site
Client address pool: 172.16.201.0/24
VPN clients that connect to the VNet using this Point-to-Site connection receive an IP address from the client
address pool.
1 - Create a virtual network

Before beginning, 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. If you are creating this configuration as
an exercise, you can refer to the example values.
The screenshots are provided as examples. Be sure to replace the values with your own. For more information
about working with virtual networks, see the Virtual Network Overview.
2. Click New. In the Search the marketplace field, type "Virtual Network". Locate Virtual Network from the
3. Near the bottom of the Virtual Network blade, from the Select a deployment model list, select Resource
Manager, and then click Create.
exclamation mark will become a green check mark when the characters entered in the field are valid.
5. The Create virtual network blade looks similar to the following example. There may be values that are
auto-filled. If so, replace the values with your own.
6. Name: Enter the name for your Virtual Network.

7. Address space: Enter the address space. If you have multiple address spaces to add, add your first address
space. You can add additional address spaces later, after creating the VNet.
8. Subnet name: Add the subnet name and subnet address range. You can add additional subnets later, after
creating the VNet.
9. Subscription: Verify that the Subscription listed is the correct one. You can change subscriptions by using the
drop-down.
10. Resource group: Select an existing resource group, or create a new one by typing a name for your new
configuration values. For more information about resource groups, visit Azure Resource Manager Overview.
11. Location: Select the location for your VNet. The location determines where the resources that you deploy to
this VNet will reside.
Create.
13. After clicking Create, you will see a tile on your dashboard that will reflect the progress of your VNet. The
tile changes as the VNet is being created.
2 - Specify address space and subnets

You can add additional address space and subnets to your VNet once it has been created.
To add address space
1. To add additional address space, under the Settings section for your virtual network blade, click Address
space to open the Address space blade.
2. Add the additional address space, and then click Save at the top of the blade.
To create subnets
1. To create subnets, in the Settings section of your virtual network blade, click Subnets to open the Subnets
blade.
2. In the Subnets blade, click +Subnet to open the Add subnet blade. Name your new subnet and specify the
address range.
3. Click OK at the bottom of the blade to save your changes.

3 - Add a gateway subnet
Before connecting your virtual network to a gateway, you first need to create the gateway subnet for the virtual
network to which you want to connect. The gateway services use the IP addresses specified in the gateway subnet.
If possible, create a gateway subnet using a CIDR block of /28 or /27 to provide enough IP addresses to
accommodate additional future configuration requirements.
The screenshots in this section are provided as a reference example. Be sure to use the GatewaySubnet address
range that corresponds with the required values for your configuration.
To create a gateway subnet
1. In the portal, navigate to the Resource Manager virtual network for which you want to create a virtual network
gateway.
3. On the Subnets blade, click +Gateway subnet to open the Add subnet blade.
4. The Name for your subnet is automatically filled in with the value 'GatewaySubnet'. This value is required
in order for Azure to recognize the subnet as the gateway subnet. Adjust the auto-filled Address range
values to match your configuration requirements.
5. To create the subnet, click OK at the bottom of the blade.
4 - Specify a DNS server (optional)

After you create your virtual network, you can add the IP address of a DNS server to handle name resolution. The
DNS server specified should be a DNS server that can resolve the names for the resources you are connecting to.
The VPN client configuration package that you generate in a later step will contain the IP addresses of the DNS
servers that you specify in this setting. If you need to update the list of DNS servers in the future, you can generate
and install new VPN client configuration packages that reflect the new list.
1. On the Settings page for your virtual network, navigate to DNS Servers and click to open the DNS
servers blade.
5 - Create a virtual network gateway

Point-to-site connections require the following settings:
Gateway type: VPN
To create a virtual network gateway
1. In the portal, on the left side, click + and type 'Virtual Network Gateway' in search. Locate Virtual network
gateway in the search return and click the entry. On the Virtual network gateway blade, click Create at the
bottom of the blade. This opens the Create virtual network gateway blade.
2. On the Create virtual network gateway blade, fill in the values for your virtual network gateway.
3. Name: Name your gateway. This is not the same as naming a gateway subnet. It's the name of the gateway
object you are creating.
4. Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
5. VPN type: Select the VPN type that is specified for your configuration. Most configurations require a Route-
based VPN type.
6. SKU: Select the gateway SKU from the dropdown. The SKUs listed in the dropdown depend on the VPN type
you select.
7. Location: Adjust the Location field to point to the location where your virtual network is located. If the
location is not pointing to the region where your virtual network resides, the virtual network doesn't appear in
the 'Choose a virtual network' dropdown.
8. Choose the virtual network to which you want to add this gateway. Click Virtual network to open the Choose
a virtual network blade. Select the VNet. If you don't see your VNet, make sure the Location field is pointing
to the region in which your virtual network is located.
9. Public IP address: This blade creates a public IP address object to which a public IP address will be
dynamically assigned. Click Public IP address to open the Choose public IP address blade. Click +Create
New to open the Create public IP address blade. Input a name for your public IP address. Click OK to save
your changes to this blade. The IP address is dynamically assigned when the VPN gateway is created. VPN
Gateway currently only supports Dynamic Public IP address allocation. However, this does not mean that the IP
address changes after it has been assigned to your VPN gateway. The only time the Public IP address changes
is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal
maintenance/upgrades of your VPN gateway.
10. Subscription: Verify that the correct subscription is selected.
11. Resource group: This setting is determined by the Virtual Network that you select.
12. Don't adjust the Location after you've specified the previous settings.
13. Verify the settings. If you want your gateway to appear on the dashboard, you can select Pin to dashboard at
the bottom of the blade.
14. Click Create to begin creating the gateway. The settings are validated and the gateway will deploy. Creating a
gateway can take up to 45 minutes.
15. After the gateway is created, you can view the IP address that has been assigned to it by looking at the virtual
network in the portal. The gateway appears as a connected device. You can click the connected device (your
virtual network gateway) to view more information.
6 - Generate certificates
Certificates are used by Azure to authenticate VPN clients for Point-to-Site VPNs. You upload the public key
information of the root certificate to Azure. The public key is then considered 'trusted'. Client certificates must be
generated from the trusted root certificate, and then installed on each client computer in the Certificates-Current
User/Personal certificate store. The certificate is used to authenticate the client when it initiates a connection to the
VNet. For more information about generating and installing certificates, see Certificates for Point-to-Site.
Step 1 - Obtain the .cer file for the root certificate
You can use either a root certificate that was generated using an enterprise solution (recommended), or you can
generate a self-signed certificate. If you use a self-signed certificate, be sure to use the Create a self-signed root
certificate for Point-to-Site connections article. The article contains the specific settings necessary to generate a
P2S-compatible certificate.
After creating the root certificate, you export the public certificate data (not the private key) as a Base-64 encoded
X.509 .cer file. You then upload the public certificate data from the root certificate to Azure.
Enterprise certificate: If you are using an enterprise solution, you can use your existing certificate chain.
Obtain the .cer file for the root certificate that you want to use.
Self-signed root certificate: If you are not using an enterprise certificate solution, you need to create a self-
signed root certificate. The root certificate must contain specific values in order to work with a Point-to-Site
connection. See the following articles for instructions:
To create a self-signed root certificate, see Create a self-signed root certificate for Point-to-Site
connections.
To export the public key (.cer file), see Create a self-signed root certificate for Point-to-Site connections.
Step 2 - Generate a client certificate
Each client computer that connects to a VNet using Point-to-Site must have a client certificate installed. The client
certificate is generated from the root certificate and installed on each client computer. If a valid client certificate is
not installed and the client tries to connect to the VNet, authentication fails.
You can either generate a unique certificate for each client, or you can use the same certificate for multiple clients.
The advantage to generating unique client certificates is the ability to revoke a single certificate. Otherwise, if
multiple clients are using the same client certificate and you need to revoke it, you have to generate and install
new certificates for all the clients that use that certificate to authenticate.
You can generate client certificates using the following methods:
Enterprise certificate:
If you are using an enterprise certificate solution, generate a client certificate with the common name
value format 'name@yourdomain.com', rather than the 'domain name\username' format.
Make sure the client certificate is based on the 'User' certificate template that has 'Client Authentication'
as the first item in the use list, rather than Smart Card Logon, etc. You can check the certificate by
double-clicking the client certificate and viewing Details > Enhanced Key Usage.
Self-signed root certificate: If you generate a client certificate from a self-signed root certificate using
the Create a self-signed root certificate for Point-to-Site connections article instructions, it's automatically
installed on the computer that you used to generate it. If you want to install a client certificate on another
client computer, you need to export it. Follow the instructions in the article to export the certificate.
7 - Add the client address pool

The client address pool is a range of private IP addresses that you specify. The clients that connect over P2S
receive an IP address from this range. Use a private IP address range that does not overlap with the on-premises
location that you will connect from, or the VNet that you want to connect to.
1. Once the virtual network gateway has been created, navigate to the Settings section of the virtual network
gateway blade. In the Settings section, click Point-to-site configuration to open the Configuration
blade.
2. You can delete the auto-filled range, then add the private IP address range that you want to use. Click Save
to validate and save the setting.
8 - Upload the root certificate .cer file
After the gateway has been created, you can upload the .cer file (which contains the public key information) for a
trusted root certificate to Azure. Once a.cer file is uploaded, Azure can use it to authenticate clients that have
installed a client certificate generated from the trusted root certificate. You can upload additional trusted root
certificate files - up to a total of 20 - later, if needed.
1. Certificates are added on the Point-to-site configuration blade in the Root certificate section.
2. Make sure that you exported the root certificate as a Base-64 encoded X.509 (.cer) file. You need to export the
certificate in this format so you can open the certificate with text editor.
3. Open the certificate with a text editor, such as Notepad. When copying the certificate data, make sure that
you copy the text as one continuous line without carriage returns or line feeds. You may need to modify
your view in the text editor to 'Show Symbol/Show all characters' to see the carriage returns and line feeds.
Copy only the following section as one continuous line:
4. Paste the certificate data into the Public Certificate Data field. Name the certificate, and then click Save.
You can add up to 20 trusted root certificates.
9 - Install the VPN client configuration package

To connect to a VNet using a Point-to-Site VPN, each client must install a package to configure the native
Windows VPN client. The configuration package configures the native Windows VPN client with the settings
necessary to connect to the virtual network and, if you specified a DNS server for your VNet, it contains the DNS
server IP address the client will use for name resolution. If you change the specified DNS server later, after
generating the client configuration package, be sure to generate a new client configuration package to install on
your client computers.
You can use the same VPN client configuration package on each client computer, as long as the version matches
the architecture for the client. For the list of client operating systems that are supported, see the Point-to-Site
connections FAQ at the end of this article.
Step 1 - Download the client configuration package
1. On the Point-to-site configuration blade, click Download VPN client to open the Download VPN
client blade. It takes a minute or two for the package to generate.
2. Select the correct package for your client, and then click Download. Save the configuration package file.
You install the VPN client configuration package on each client computer that connects to the virtual
network.
Step 2 - Install the client configuration package

1. Copy the configuration file locally to the computer that you want to connect to your virtual network.
2. Double-click the .exe file to install the package on the client computer. Because you created the configuration
package, it is not signed and you may see a warning. If you get a Windows SmartScreen popup, click More
info (on the left), then Run anyway to install the package.
3. Install the package on the client computer. If you get a Windows SmartScreen popup, click More info (on the
left), then Run anyway to install the package.
4. On the client computer, navigate to Network Settings and click VPN. The VPN connection shows the name of
the virtual network that it connects to.
10 - Install the client certificate

If you want to create a P2S connection from a client computer other than the one you used to generate the client
certificates, you need to install a client certificate. When installing a client certificate, you need the password that
was created when the client certificate was exported. Typically, this is just a matter of double-clicking the
certificate and installing it. For more information see, Install an exported client certificate.
11 - Connect to Azure
1. To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN
connection that you created. It is named the same name as your virtual network. Click Connect. A pop-up
message may appear that refers to using the certificate. Click Continue to use elevated privileges.
2. On the Connection status page, click Connect to start the connection. If you see a Select Certificate
screen, verify that the client certificate showing is the one that you want to use to connect. If it is not, use
the drop-down arrow to select the correct certificate, and then click OK.
3. Your connection is established.
If you are having trouble connecting, check the following items:

Open Manage user certificates and navigate to Trusted Root Certification Authorities\Certificates.
Verify that the root certificate is listed. The root certificate must be present in order for authentication to
work. When you export a client certificate .pfx using the default value 'Include all certificates in the
certification path if possible', the root certificate information is also exported. When you install the client
certificate, the root certificate is then also installed on the client computer.
If you are using a certificate that was issued using an Enterprise CA solution and are having trouble
authenticating, check the authentication order on the client certificate. You can check the authentication list
order by double-clicking the client certificate, and going to Details > Enhanced Key Usage. Make sure
the list shows 'Client Authentication' as the first item. If not, you need to issue a client certificate based on
the User template that has Client Authentication as the first item in the list.
12 - Verify your connection

1. To verify that your VPN connection is active, open an elevated command prompt, and run ipconfig/all.
2. View the results. Notice that the IP address you received is one of the addresses within the Point-to-Site
VPN Client Address Pool that you specified in your configuration. The results are similar to this example:
PPP adapter VNet1:

Connection-specific DNS Suffix .:
Description.....................: VNet1
Physical Address................:
DHCP Enabled....................: No
Autoconfiguration Enabled.......: Yes
IPv4 Address....................: 172.16.201.3(Preferred)
Subnet Mask.....................: 255.255.255.255
Default Gateway.................:
NetBIOS over Tcpip..............: Enabled
If you are having trouble connecting to a virtual machine over P2S, use 'ipconfig' to check the IPv4 address
assigned to the Ethernet adapter on the computer from which you are connecting. If the IP address is within the
address range of the VNet that you are connecting to, or within the address range of your VPNClientAddressPool,
this is referred to as an overlapping address space. When your address space overlaps in this way, the network
traffic doesn't reach Azure, it stays on the local network. If your network address spaces don't overlap and you still
can't connect to your VM, see Troubleshoot Remote Desktop connections to a VM.
Connect to a virtual machine
best way to initially verify that you can connect to your VM is to connect by using its private IP address, rather
1. Locate the private IP address. You can find the private IP address of a VM by either looking at the
properties for the VM in the Azure portal, or by using PowerShell.
{
}
2. Verify that you are connected to your VNet using the Point-to-Site VPN connection.
Resolution for VMs.
Add or remove trusted root certificates

You can add and remove trusted root certificates from Azure. When you remove a root certificate, clients that
have a certificate generated from that root won't be able to authenticate, and thus will not be able to connect. If
you want a client to authenticate and connect, you need to install a new client certificate generated from a root
certificate that is trusted (uploaded) to Azure.
To add a trusted root certificate
You can add up to 20 trusted root certificate .cer files to Azure. For instructions, see the section Upload a trusted
root certificate in this article.
To remove a trusted root certificate
1. To remove a trusted root certificate, navigate to the Point-to-site configuration blade for your virtual
network gateway.
2. In the Root certificate section of the blade, locate the certificate that you want to remove.
3. Click the ellipsis next to the certificate, and then click 'Remove'.
Revoke a client certificate

You can revoke client certificates. The certificate revocation list allows you to selectively deny Point-to-Site
connectivity based on individual client certificates. This differs from removing a trusted root certificate. If you
remove a trusted root certificate .cer from Azure, it revokes the access for all client certificates generated/signed
by the revoked root certificate. Revoking a client certificate, rather than the root certificate, allows the other
certificates that were generated from the root certificate to continue to be used for authentication.
The common practice is to use the root certificate to manage access at team or organization levels, while using
revoked client certificates for fine-grained access control on individual users.
To revoke a client certificate
You can revoke a client certificate by adding the thumbprint to the revocation list.
1. Retrieve the client certificate thumbprint. For more information, see How to retrieve the Thumbprint of a
Certificate.
2. Copy the information to a text editor and remove all spaces so that it is a continuous string.
3. Navigate to the virtual network gateway Point-to-site-configuration blade. This is the same blade that you
used to upload a trusted root certificate.
4. In the Revoked certificates section, input a friendly name for the certificate (it doesn't have to be the
certificate CN).
5. Copy and paste the thumbprint string to the Thumbprint field.
6. The thumbprint will validate is automatically added to the revocation list. A message appears on the screen
that the list is updating.
7. After updating has completed, the certificate can no longer be used to connect. Clients that try to connect using
this certificate receive a message saying that the certificate is no longer valid.
Point-to-Site FAQ
Windows 10
HTTPs connection.
deployment model, you need a dynamic gateway. We do not support Point-to-Site for static routing VPN
gateways or gateways using the -VpnType PolicyBased cmdlet.
Next steps
see Virtual Machines. To understand more about networking and virtual machines, see Azure and Linux VM
network overview.
PowerShell
This article shows you how to create a VNet with a Point-to-Site connection in the Resource Manager deployment
model using PowerShell. You can also create this configuration using a different deployment tool or deployment
model by selecting a different option from the following list:
A RouteBased VPN gateway.
Before beginning
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.
Install the latest version of the Azure Resource Manager PowerShell cmdlets. For more information about
installing PowerShell cmdlets, see How to install and configure Azure PowerShell.
Example values
You can use the example values to create a test environment, or refer to these values to better understand the
examples in this article. We set the variables in section 1 of the article. You can either use the steps as a walk-
through and use the values without changing them, or change them to reflect your environment.
Name: VNet1
Address space: 192.168.0.0/16 and 10.254.0.0/16
For this example, we use more than one address space to illustrate that this configuration works with multiple
address spaces. However, multiple address spaces are not required for this configuration.
Subnet name: BackEnd
Subnet name: GatewaySubnet
The Subnet name GatewaySubnet is mandatory for the VPN gateway to work.
GatewaySubnet address range: 192.168.200.0/24
VPN client address pool: 172.16.201.0/24
VPN clients that connect to the VNet using this Point-to-Site connection receive an IP address from the VPN
client address pool.
Location: East US
DNS Server: IP address of the DNS server that you want to use for name resolution.
GW Name: Vnet1GW
Public IP name: VNet1GWPIP
VpnType: RouteBased
1 - Log in and set variables

In this section, you log in and declare the values used for this configuration. The declared values are used in the
sample scripts. Change the values to reflect your own environment. Or, you can use the declared values and go
through the steps as an exercise.
1. Open your PowerShell console with elevated privileges, and log in to your Azure account. This cmdlet
prompts you for the login credentials. After logging in, it downloads your account settings so that they are
available to Azure PowerShell.
2. Get a list of your Azure subscriptions.
3. Specify the subscription that you want to use.

Select-AzureRmSubscription -SubscriptionName "Name of subscription"
4. Declare the variables that you want to use. Use the following sample, substituting the values for your own
when necessary.
$VNetName = "VNet1"
$FESubName = "FrontEnd"
$BESubName = "Backend"
$GWSubName = "GatewaySubnet"
$VNetPrefix1 = "192.168.0.0/16"
$VNetPrefix2 = "10.254.0.0/16"
$FESubPrefix = "192.168.1.0/24"
$BESubPrefix = "10.254.1.0/24"
$GWSubPrefix = "192.168.200.0/26"
$VPNClientAddressPool = "172.16.201.0/24"
$RG = "TestRG"
$Location = "East US"
$DNS = "8.8.8.8"
$GWName = "VNet1GW"
$GWIPName = "VNet1GWPIP"
$GWIPconfName = "gwipconf"
2 - Configure a VNet
1. Create a resource group.
New-AzureRmResourceGroup -Name $RG -Location $Location
2. Create the subnet configurations for the virtual network, naming them FrontEnd, BackEnd, and
GatewaySubnet. These prefixes must be part of the VNet address space that you declared.
$fesub = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName -AddressPrefix $FESubPrefix

$besub = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName -AddressPrefix $BESubPrefix
$gwsub = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName -AddressPrefix $GWSubPrefix
3. Create the virtual network.

The DNS server is optional. Specifying this value does not create a new DNS server. The client configuration
package that you generate in a later step will contain the IP address of the DNS server that you specify in
this setting. If you need to update the list of DNS servers in the future, you can generate and install new
VPN client configuration packages that reflect the new list. The DNS server specified should be a DNS
server that can resolve the names for the resources you are connecting to. For this example, we used a
public IP address. Be sure to use your own values.
New-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG -Location $Location -AddressPrefix

$VNetPrefix1,$VNetPrefix2 -Subnet $fesub, $besub, $gwsub -DnsServer $DNS
4. Specify the variables for the virtual network you created.
$vnet = Get-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
5. A VPN gateway must have a Public IP address. You first request the IP address resource, and then refer to it
when creating your virtual network gateway. The IP address is dynamically assigned to the resource when
the VPN gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation.
You cannot request a Static Public IP address assignment. However, this does not mean that the IP address
changes after it has been assigned to your VPN gateway. The only time the Public IP address changes is
when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal
Request a dynamically assigned public IP address.
$pip = New-AzureRmPublicIpAddress -Name $GWIPName -ResourceGroupName $RG -Location $Location -

AllocationMethod Dynamic
$ipconf = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName -Subnet $subnet -PublicIpAddress
$pip
3 - Generate certificates
Step 1 - Obtain the .cer file for the root certificate
connections.
Step 2 - Generate a client certificate
Self-signed root certificate: If you generate a client certificate from a self-signed root certificate using the
Create a self-signed root certificate for Point-to-Site connections article instructions, it's automatically
4 - Prepare the root certificate .cer file for upload

Prepare to upload the .cer file (which contains the public key information) for a trusted root certificate to Azure.
You do not upload the private key for the root certificate to Azure. Once a.cer file is uploaded, Azure can use it to
authenticate clients that have installed a client certificate generated from the trusted root certificate. You can
upload additional trusted root certificate files - up to a total of 20 - later, if needed. In this section, you declare the
root certificate .cer file, which will be associated with your VPN gateway when you create it in the next section.
1. Declare the variable for your certificate name, replacing the value with your own.
$P2SRootCertName = "P2SRootCert.cer"
2. Replace the file path with your own, and then run the cmdlets.
$filePathForCert = "C:\cert\P2SRootCert.cer"
$cert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2($filePathForCert)
$CertBase64 = [system.convert]::ToBase64String($cert.RawData)
$p2srootcert = New-AzureRmVpnClientRootCertificate -Name $P2SRootCertName -PublicCertData $CertBase64
5 - Create the VPN gateway

Configure and create the virtual network gateway for your VNet.
The -GatewayType must be Vpn and the -VpnType must be RouteBased.
In this example, the public key for the root certificate gets associated with the VPN gateway using the variable
'$p2srootcert', specified in the previous section.
In this example, the VPN client address pool is declared as a variable in Step 1. The VPN client address pool is
the range from which the VPN clients receive an IP address when connecting. Use a private IP address range
that does not overlap with the on-premises location that you will connect from, or with the VNet that you want
to connect to.
A VPN gateway can take up to 45 minutes to complete, depending on the gateway sku you select.
New-AzureRmVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG `

-Location $Location -IpConfigurations $ipconf -GatewayType Vpn `
-VpnType RouteBased -EnableBgp $false -GatewaySku Standard `
-VpnClientAddressPool $VPNClientAddressPool -VpnClientRootCertificates $p2srootcert
6 - Download the VPN client configuration package

1. After the gateway has been created, you can generate and download the client configuration package. This
example downloads the package for 64-bit clients. If you want to download the 32-bit client, replace
'Amd64' with 'x86'. You can also download the VPN client by using the Azure portal.
Get-AzureRmVpnClientPackage -ResourceGroupName $RG `

-VirtualNetworkGatewayName $GWName -ProcessorArchitecture Amd64
2. Copy and paste the link that is returned to a web browser to download the package, taking care to remove the
quotes surrounding the link.
3. Download and install the package on the client computer. If you see a SmartScreen popup, click More info,
then Run anyway. You can also save the package to install on other client computers.
4. On the client computer, navigate to Network Settings and click VPN. The VPN connection shows the name of
the virtual network that it connects to.
7 - Install an exported client certificate

was created when the client certificate was exported. Typically, this is just a matter of double-clicking the certificate
and installing it. For more information see, Install an exported client certificate.
8 - Connect to Azure
1. To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN connection
that you created. It is named the same name as your virtual network. Click Connect. A pop-up message may
appear that refers to using the certificate. Click Continue to use elevated privileges.

If you are having trouble connecting, check the following things:
order by double-clicking the client certificate, and going to Details > Enhanced Key Usage. Make sure the
list shows 'Client Authentication' as the first item. If not, you need to issue a client certificate based on the
User template that has Client Authentication as the first item in the list.
9 - Verify your connection

VPN Client Address Pool that you specified in your configuration. The results are similar to this example:
PPP adapter VNet1:

DHCP Enabled....................: No
Subnet Mask.....................: 255.255.255.255

1. Locate the private IP address. You can find the private IP address of a VM by either looking at the properties
for the VM in the Azure portal, or by using PowerShell.
{
}
Resolution for VMs.
Add or remove a root certificate

You can add and remove trusted root certificates from Azure. When you remove a root certificate, clients that have
a certificate generated from that root won't be able to authenticate, and thus will not be able to connect. If you
want a client to authenticate and connect, you need to install a new client certificate generated from a root
You can add up to 20 root certificate .cer files to Azure. The following steps help you add a root certificate:
1. Create and prepare the new root certificate to add to Azure. Export the public key as a Base-64 encoded
X.509 (.CER) and open it with a text editor. Copy the values, as shown in the following example:
NOTE
When copying the certificate data, make sure that you copy the text as one continuous line without carriage returns
or line feeds. You may need to modify your view in the text editor to 'Show Symbol/Show all characters' to see the
carriage returns and line feeds.
2. Specify the certificate name and key information as a variable. Replace the information with your own, as
shown in the following example:
$P2SRootCertName2 = "ARMP2SRootCert2.cer"
$MyP2SCertPubKeyBase64_2 =
"MIIC/zCCAeugAwIBAgIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDU15UDJTUm9vdENlcnQwHhcNMTUxMj
E5MDI1MTIxWhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw1NeVAyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC
gKCAQEAyjIXoWy8xE/GF1OSIvUaA0bxBjZ1PJfcXkMWsHPzvhWc2esOKrVQtgFgDz4ggAnOUFEkFaszjiHdnXv3mjzE2SpmAVIZPf2/
yPWqkoHwkmrp6BpOvNVOpKxaGPOuK8+dql1xcL0eCkt69g4lxy0FGRFkBcSIgVTViS9wjuuS7LPo5+OXgyFkAY3pSDiMzQCkRGNFgw5
WGMHRDAiruDQF1ciLNojAQCsDdLnI3pDYsvRW73HZEhmOqRRnJQe6VekvBYKLvnKaxUTKhFIYwuymHBB96nMFdRUKCZIiWRIy8Hc8+s
QEsAML2EItAjQv4+fqgYiFdSWqnQCPf/7IZbotgQIDAQABo00wSzBJBgNVHQEEQjBAgBAkuVrWvFsCJAdK5pb/eoCNoRowGDEWMBQGA
1UEAxMNTXlQMlNSb290Q2VydIIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAA4IBAQA223veAZEIar9N12ubNH2+HwZASNzDVNqs
pkPKD97TXfKHlPlIcS43TaYkTz38eVrwI6E0yDk4jAuPaKnPuPYFRj9w540SvY6PdOUwDoEqpIcAVp+b4VYwxPL6oyEQ8wnOYuoAK1h
hh20lCbo8h9mMy9ofU+RP6HJ7lTqupLfXdID/XevI8tW6Dm+C/wCeV3EmIlO9KUoblD/e24zlo3YzOtbyXwTIh34T0fO/zQvUuBqZMc
IPfM1cDvqcqiEFLWvWKoAnxbzckye2uk1gHO52d8AVL3mGiX8wBJkjc/pMdxrEvvCzJkltBmqxTM6XjDJALuVh16qFlqgTWCIcb7ju"
3. Add the new root certificate. You can only add one certificate at a time.
Add-AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName2 -

VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG" -PublicCertData
$MyP2SCertPubKeyBase64_2
4. You can verify that the new certificate was added correctly by using the following example:
Get-AzureRmVpnClientRootCertificate -ResourceGroupName "TestRG" `

-VirtualNetworkGatewayName "VNet1GW"
To remove a root certificate

1. Declare the variables.
$GWName = "Name_of_virtual_network_gateway"
$RG = "Name_of_resource_group"
$P2SRootCertName2 = "ARMP2SRootCert2.cer"
$MyP2SCertPubKeyBase64_2 =
"MIIC/zCCAeugAwIBAgIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDU15UDJTUm9vdENlcnQwHhcNMTUxMj
E5MDI1MTIxWhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw1NeVAyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC
gKCAQEAyjIXoWy8xE/GF1OSIvUaA0bxBjZ1PJfcXkMWsHPzvhWc2esOKrVQtgFgDz4ggAnOUFEkFaszjiHdnXv3mjzE2SpmAVIZPf2/
yPWqkoHwkmrp6BpOvNVOpKxaGPOuK8+dql1xcL0eCkt69g4lxy0FGRFkBcSIgVTViS9wjuuS7LPo5+OXgyFkAY3pSDiMzQCkRGNFgw5
WGMHRDAiruDQF1ciLNojAQCsDdLnI3pDYsvRW73HZEhmOqRRnJQe6VekvBYKLvnKaxUTKhFIYwuymHBB96nMFdRUKCZIiWRIy8Hc8+s
QEsAML2EItAjQv4+fqgYiFdSWqnQCPf/7IZbotgQIDAQABo00wSzBJBgNVHQEEQjBAgBAkuVrWvFsCJAdK5pb/eoCNoRowGDEWMBQGA
1UEAxMNTXlQMlNSb290Q2VydIIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAA4IBAQA223veAZEIar9N12ubNH2+HwZASNzDVNqs
pkPKD97TXfKHlPlIcS43TaYkTz38eVrwI6E0yDk4jAuPaKnPuPYFRj9w540SvY6PdOUwDoEqpIcAVp+b4VYwxPL6oyEQ8wnOYuoAK1h
hh20lCbo8h9mMy9ofU+RP6HJ7lTqupLfXdID/XevI8tW6Dm+C/wCeV3EmIlO9KUoblD/e24zlo3YzOtbyXwTIh34T0fO/zQvUuBqZMc
IPfM1cDvqcqiEFLWvWKoAnxbzckye2uk1gHO52d8AVL3mGiX8wBJkjc/pMdxrEvvCzJkltBmqxTM6XjDJALuVh16qFlqgTWCIcb7ju"
2. Remove the certificate.
Remove-AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName2 -

VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -PublicCertData $MyP2SCertPubKeyBase64_2
3. Use the following example to verify that the certificate was removed successfully.
Get-AzureRmVpnClientRootCertificate -ResourceGroupName "TestRG" `

-VirtualNetworkGatewayName "VNet1GW"

certificates that were generated from the root certificate to continue to be used for authentication.
1. Retrieve the client certificate thumbprint. For more information, see How to retrieve the Thumbprint of a
Certificate.
2. Copy the information to a text editor and remove all spaces so that it is a continuous string. This is declared as
a variable in the next step.
3. Declare the variables. Make sure to declare the thumbprint you retrieved in the previous step.
$RevokedClientCert1 = "NameofCertificate"
$RevokedThumbprint1 = "51ab1edd8da4cfed77e20061c5eb6d2ef2f778c7"
4. Add the thumbprint to the list of revoked certificates. You see "Succeeded" when the thumbprint has been
added.
Add-AzureRmVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `

-VirtualNetworkGatewayName $GWName -ResourceGroupName $RG `
-Thumbprint $RevokedThumbprint1
5. Verify that the thumbprint was added to the certificate revocation list.
Get-AzureRmVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG
6. After the thumbprint has been added, the certificate can no longer be used to connect. Clients that try to
connect using this certificate receive a message saying that the certificate is no longer valid.
To reinstate a client certificate
You can reinstate a client certificate by removing the thumbprint from the list of revoked client certificates.
1. Declare the variables. Make sure you declare the correct thumbprint for the certificate that you want to
reinstate.
$RevokedClientCert1 = "NameofCertificate"
$RevokedThumbprint1 = "51ab1edd8da4cfed77e20061c5eb6d2ef2f778c7"
2. Remove the certificate thumbprint from the certificate revocation list.
Remove-AzureRmVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `

-VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -Thumbprint $RevokedThumbprint1
3. Check if the thumbprint is removed from the revoked list.

Get-AzureRmVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG
Point-to-Site FAQ
Windows 10
HTTPs connection.
Next steps
network overview.
the Azure portal (classic)
NOTE
This article is written for the classic deployment model. If you are new to Azure, we recommend that you use the Resource
Manager deployment model. For information about the deployment models, see Understanding deployment models. To
see the Resource Manager version of this article, select it from the drop-down list, or from the table of contents on the left.
This article shows you how to create a VNet with a Point-to-Site connection in the classic deployment model using
the Azure portal. You can also create this configuration using a different deployment tool or deployment model by
selecting a different option from the following list:
A Dynamic VPN gateway.
Example settings
Name: VNet1
For this example, we use only one address space. You can have more than one address space for your VNet.
Location: East US
Connection type: Point-to-site
Client Address Space: 172.16.201.0/24. VPN clients that connect to the VNet using this Point-to-Site
connection receive an IP address from the specified pool.
GatewaySubnet: 192.168.200.0/24. The Gateway subnet must use the name 'GatewaySubnet'.
Size: Select the gateway SKU that you want to use.
Routing Type: Dynamic
Section 1 - Create a virtual network and a VPN gateway

Before beginning, 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.
Part 1: Create a virtual network
If you don't already have a virtual network, create one. Screenshots are provided as examples. Be sure to replace
the values with your own. To create a VNet by using the Azure portal, use the following steps:
3. Near the bottom of the Virtual Network blade, from the Select a deployment model list, select Classic,
and then click Create.
4. On the Create virtual network blade, configure the VNet settings. In this blade, you add your first address
space and a single subnet address range. After you finish creating the VNet, you can go back and add
additional subnets and address spaces.
5. Verify that the Subscription is the correct one. You can change subscriptions by using the drop-down.
6. Click Resource group and either select an existing resource group, or create a new one by typing a name for
your new resource group. If you are creating a new resource group, name the resource group according to
your planned configuration values. For more information about resource groups, visit Azure Resource
Manager Overview.
7. Next, select the Location settings for your VNet. The location determines where the resources that you deploy
to this VNet will reside.
Create.
9. After clicking Create, a tile appears on your dashboard that will reflect the progress of your VNet. The tile
changes as the VNet is being created.
10. Once your virtual network has been created, you see Created listed under Status on the networks page in the
Azure classic portal.
11. Add a DNS server (optional). After you create your virtual network, you can add the IP address of a DNS server
for name resolution. The DNS server you specify should be one that can resolve the names for the resources in
your VNet.
To add a DNS server, open the settings for your virtual network, click DNS servers, and add the IP address of
the DNS server that you want to use. The client configuration package that you generate in a later step will
contain the IP addresses of the DNS servers that you specify in this setting. If you need to update the list of
DNS servers in the future, you can generate and install new VPN client configuration packages that reflect the
updated list.
Part 2: Create gateway subnet and a dynamic routing gateway
In this step, you create a gateway subnet and a Dynamic routing gateway. In the Azure portal for the classic
deployment model, creating the gateway subnet and the gateway can be done through the same configuration
blades.
1. In the portal, navigate to the virtual network for which you want to create a gateway.
2. On the blade for your virtual network, on the Overview blade, in the VPN connections section, click
Gateway.
3. On the New VPN Connection blade, select Point-to-site.

4. For Client Address Space, add the IP address range. This is the range from which the VPN clients receive
an IP address when connecting. Use a private IP address range that does not overlap with the on-premises
location that you will connect from, or with the VNet that you want to connect to. You can delete the auto-
filled range, then add the private IP address range that you want to use.
5. Select the Create gateway immediately checkbox.

6. Click Optional gateway configuration to open the Gateway configuration blade.
7. Click Subnet Configure required settings to add the gateway subnet. While it is possible to create a
gateway subnet as small as /29, we recommend that you create a larger subnet that includes more
addresses by selecting at least /28 or /27. This will allow for enough addresses to accommodate possible
additional configurations that you may want in the future. When working with gateway subnets, avoid
associating a network security group (NSG) to the gateway subnet. Associating a network security group to
this subnet may cause your VPN gateway to stop functioning as expected.
8. Select the gateway Size. The size is the gateway SKU for your virtual network gateway. In the portal, the
Default SKU is Basic. For more information about gateway SKUs, see About VPN Gateway Settings.
9. Select the Routing Type for your gateway. P2S configurations require a Dynamic routing type. Click OK
when you have finished configuring this blade.
10. On the New VPN Connection blade, click OK at the bottom of the blade to begin creating your virtual
network gateway. A VPN gateway can take up to 45 minutes to complete, depending on the gateway sku that
you select.
Section 2 - Create certificates

Part 1: Obtain the public key (.cer) for the root certificate
connections.
Part 2: Generate a client certificate
Self-signed root certificate: If you generate a client certificate from a self-signed root certificate using
the Create a self-signed root certificate for Point-to-Site connections article instructions, it's automatically
Section 3 - Upload the root certificate .cer file

After the gateway has been created, you can upload the .cer file (which contains the public key information) for a
trusted root certificate to Azure. You do not upload the private key for the root certificate to Azure. Once a.cer file
is uploaded, Azure can use it to authenticate clients that have installed a client certificate generated from the
trusted root certificate. You can upload additional trusted root certificate files - up to a total of 20 - later, if needed.
1. On the VPN connections section of the blade for your VNet, click the clients graphic to open the Point-
to-site VPN connection blade.
2. On the Point-to-site connection blade, click Manage certificates to open the Certificates blade.
3. On the Certificates blade, click Upload to open the Upload certificate blade.
4. Click the folder graphic to browse for the .cer file. Select the file, then click OK. Refresh the page to see the
uploaded certificate on the Certificates blade.
Section 4 - Configure the client

Part 1: Generate and install the VPN client configuration package
1. In the Azure portal, in the Overview blade for your VNet, in VPN connections, click the client graphic to open
the Point-to-site VPN connection blade.
2. At the top of the Point-to-site VPN connection blade, click the download package that corresponds to
the client operating system on which it will be installed:
For 64-bit clients, select VPN Client (64-bit).
For 32-bit clients, select VPN Client (32-bit).
3. Once the packaged generates, download and install it on your client computer. If you see a SmartScreen
popup, click More info, then Run anyway. You can also save the package to install on other client computers.
Part 2: Install the client certificate
was created when the client certificate was exported. Typically, this is just a matter of double-clicking the
certificate and installing it. For more information, see Install an exported client certificate.
Section 5 - Connect to Azure
Connect to your VNet
1. To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN connection
that you created. It is named the same name as your virtual network. Click Connect. A pop-up message may
appear that refers to using the certificate. If this happens, click Continue to use elevated privileges.
If you are having trouble connecting, check the following things:

order by double-clicking the client certificate, and going to Details > Enhanced Key Usage. Make sure
the list shows 'Client Authentication' as the first item. If not, you need to issue a client certificate based on
the User template that has Client Authentication as the first item in the list.
Verify the VPN connection
connectivity address range that you specified when you created your VNet. The results should be something
similar to this:
Example:
PPP adapter VNet1:
DHCP Enabled....................: No
Subnet Mask.....................: 255.255.255.255
If you are having trouble connecting to a virtual machine over P2S, use 'ipconfig' to check the IPv4 address
assigned to the Ethernet adapter on the computer from which you are connecting. If the IP address is within the
address range of the VNet that you are connecting to, or within the address range of your VPNClientAddressPool,
this is referred to as an overlapping address space. When your address space overlaps in this way, the network
traffic doesn't reach Azure, it stays on the local network. If your network address spaces don't overlap and you still
can't connect to your VM, see Troubleshoot Remote Desktop connections to a VM.

1. Locate the private IP address for your VM. You can find the private IP address of a VM by either looking at the
properties for the VM in the Azure portal, or by using PowerShell.
3. Open Remote Desktop Connection by typing "RDP" or "Remote Desktop Connection" in the search box on the
taskbar, then select Remote Desktop Connection. You can also open Remote Desktop Connection using the
If you are having trouble connecting to a virtual machine over your VPN connection, there are a few things you
can check. For more troubleshooting information, see Troubleshoot Remote Desktop connections to a VM.
Resolution for VMs.
Add or remove trusted root certificates

You can add and remove trusted root certificates from Azure. When you remove a root certificate, clients that
have a certificate generated from that root won't be able to authenticate, and thus will not be able to connect. If
you want a client to authenticate and connect, you need to install a new client certificate generated from a root
You can add up to 20 trusted root certificate .cer files to Azure. For instructions, see Section 3 - Upload the root
certificate .cer file.
To remove a trusted root certificate
1. On the VPN connections section of the blade for your VNet, click the clients graphic to open the Point-
to-site VPN connection blade.
2. On the Point-to-site connection blade, click Manage certificates to open the Certificates blade.
3. On the Certificates blade, click the ellipsis next to the certificate that you want to remove, then click
Delete.

certificates that were generated from the root certificate to continue to be used for authentication for the Point-to-
Site connection.
You can revoke a client certificate by adding the thumbprint to the revocation list.
1. Retrieve the client certificate thumbprint. For more information, see How to: Retrieve the Thumbprint of a
Certificate.
2. Copy the information to a text editor and remove all spaces so that it is a continuous string.
3. Navigate to the 'classic virtual network name' > Point-to-site VPN connection > Certificates blade and
then click Revocation list to open the Revocation list blade.
4. On the Revocation list blade, click +Add certificate to open the Add certificate to revocation list blade.
5. On the Add certificate to revocation list blade, paste the certificate thumbprint as one continuous line of
text, with no spaces. Click OK at the bottom of the blade.
6. After updating has completed, the certificate can no longer be used to connect. Clients that try to connect using
this certificate receive a message saying that the certificate is no longer valid.
Point-to-Site FAQ
Windows 10
HTTPs connection.
Next steps
network overview.
Generate and export certificates for Point-to-Site
connections using PowerShell on Windows 10
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. If you are looking for Point-to-Site
configuration steps, such as how to upload root certificates, select one of the 'Configure Point-to-Site' articles from
the following list:
You must perform the steps in this article on a computer running Windows 10. The PowerShell cmdlets that you
use to generate certificates are part of the Windows 10 operating system and do not work on other versions of
Windows. The Windows 10 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.
If you do not have access to a Windows 10 computer, you can use MakeCert to generate certificates. However,
MakeCert can't generate SHA-2 certificates, only SHA-1. SHA-1 certificates are still valid for Point-to-Site
connections, but SHA-1 uses an encryption hash that is not as strong as SHA-2. For this reason, we recommend
that you use these PowerShell steps, if at all possible. The certificates that you generate using either method can
be installed 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, open a Windows PowerShell console with elevated privileges.
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.
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `

-Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
Export the public key (.cer)

Point-to-Site connections require the certificate public key .cer file (not the private key) to be uploaded 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 certificates. Locate the self-signed root certificate,
typically in 'Certificates - Current User\Personal\Certificates', and right-click. Click All Tasks, and then click
Export. This opens the Certificate Export Wizard.
2. In the Wizard, click Next. Select No, do not export the private key, and then click Next.
3. On the Export File Format page, select Base-64 encoded X.509 (.CER)., and then click Next.
4. On the File to Export, Browse to the location to which you want to export the certificate. For File name, name
the certificate file. Then, click Next.
5. Click Finish to export the certificate. You see The export was successful. Click OK to close the wizard.
The exported.cer file must be uploaded to Azure. For instructions, see Configure a Point-to-Site connection. To add
an additional trusted root certificate, this section of the article.
Export the self-signed root certificate and public key to store it (optional)
You may want to export the self-signed root certificate and store it safely. If need be, you can later install it on
another computer and generate more client certificates, or export another .cer file. 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.
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
This example uses the declared '$cert' variable from the previous section. 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 -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
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 -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 a 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 certificates. 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 Export to open the Certificate Export Wizard.
2. In the Wizard, click Next, then select Yes, export the private key, and then click Next.
3. On the Export File Format page, leave the defaults selected. Make sure that Include all certificates in the
certification path if possible is selected. Selecting this also exports the root certificate information that is
required for successful authentication. Then, click Next.
4. 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. Click Finish to export the certificate.
Install an exported client certificate

was created when the client certificate was exported.
1. Locate and copy the .pfx file to the client computer. On the client computer, double-click the .pfx file to install.
Leave the Store Location as Current User, and then click Next.
2. On the File to import page, don't make any changes. Click Next.
3. On the Private key protection page, input the password for the certificate, or verify that the security principal
is correct, then click Next.
4. On the Certificate Store page, leave the default location, and then click Next.
5. Click Finish. On the Security Warning for the certificate installation, click Yes. You can feel comfortable
clicking 'Yes' because you generated the certificate. The certificate is now successfully imported.
Next steps
Continue with your Point-to-Site configuration.
For Resource Manager deployment model steps, see Configure a Point-to-Site connection to a VNet.
For classic deployment model steps, see Configure a Point-to-Site VPN connection to a VNet (classic).
Generate and export certificates for Point-to-Site
connections using MakeCert
NOTE
Use the instructions in this article to generate certificates only when you don't have access to a computer running Windows
10. Otherwise, we recommend that you use the Generate self-signed certificates using Windows 10 PowerShell article
instead.
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 MakeCert. If you are looking for Point-to-Site configuration steps,
such as how to upload root certificates, select one of the 'Configure Point-to-Site' articles from the following list:
While we recommend using the Windows 10 PowerShell steps to create your certificates, we provide these
MakeCert instructions as an optional method. The certificates that you generate using either method can be
installed on any supported client operating system. However, MakeCert has the following limitations:
MakeCert cannot generate SHA-2 certificates, only SHA-1. SHA-1 certificates are still valid for Point-to-Site
connections, but SHA-1 uses an encryption hash that is not as strong as SHA-2.
MakeCert is deprecated. This means that this tool could be removed at any point. Any certificates that you
already generated using MakeCert won't be affected if MakeCert is no longer available. MakeCert is only used
to generate the certificates, not as a validating mechanism.
Create a self-signed root certificate

The following steps show you how to create a self-signed certificate using MakeCert. These steps are not
deployment-model specific. They are valid for both Resource Manager and classic.
1. Download and install MakeCert.
2. After installation, you can find the makecert.exe utility under this path: 'C:\Program Files (x86)\Windows
Kits\10\bin<arch>'. Open a command prompt as administrator and navigate to the location of the
MakeCert utility. You can use the following example:
cd C:\Program Files (x86)\Windows Kits\10\bin\x64
3. Create and install a certificate in the Personal certificate store on your computer. The following example
creates a corresponding .cer file that you upload to Azure when configuring P2S. Replace 'P2SRootCert' and
'P2SRootCert.cer' with the name that you want to use for the certificate. The certificate will be located in
your 'Certificates - Current User\Personal\Certificates'.
makecert -sky exchange -r -n "CN=P2SRootCert" -pe -a sha1 -len 2048 -ss My "P2SRootCert.cer"
Export the public key (.cer)

Point-to-Site connections require the certificate public key .cer file (not the private key) to be uploaded 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 certificates. Locate the self-signed root certificate,
typically in 'Certificates - Current User\Personal\Certificates', and right-click. Click All Tasks, and then click
Export. This opens the Certificate Export Wizard.
2. In the Wizard, click Next. Select No, do not export the private key, and then click Next.
3. On the Export File Format page, select Base-64 encoded X.509 (.CER)., and then click Next.
5. Click Finish to export the certificate. You see The export was successful. Click OK to close the wizard.
The exported.cer file must be uploaded to Azure. For instructions, see Configure a Point-to-Site connection. To add
an additional trusted root certificate, see this section of the article.
Export the self-signed certificate and private key to store it (optional)
You may want to export the self-signed root certificate and store it safely. If need be, you can later install it on
another computer and generate more client certificates, or export another .cer file. 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.
Create and install client certificates

You don't install the self-signed certificate directly on the client computer. You need to generate a client certificate
from the self-signed certificate. You then export and install the client certificate to the client computer. The
following steps are not deployment-model specific. They are valid for both Resource Manager and classic.
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.
1. On the same computer that you used to create the self-signed certificate, open a command prompt as
administrator.
2. Modify and run the sample to generate a client certificate.
Change "P2SRootCert" to the name of the self-signed root that you are generating the client certificate
from. Make sure you are using the name of the root certificate, which is whatever the 'CN=' value was
that you specified when you created the self-signed root.
Change P2SChildCert to the name you want to generate a client certificate to be.
If you run the following example without modifying it, the result is a client certificate named P2SChildcert in
your Personal certificate store that was generated from root certificate P2SRootCert.
makecert.exe -n "CN=P2SChildCert" -pe -sky exchange -m 96 -ss My -in "P2SRootCert" -is my -a sha1
Export a 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 certificates. 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 Export to open the Certificate Export Wizard.
2. In the Wizard, click Next, then select Yes, export the private key, and then click Next.
3. On the Export File Format page, leave the defaults selected. Make sure that Include all certificates in the
certification path if possible is selected. Selecting this also exports the root certificate information that is
required for successful authentication. Then, click Next.
4. 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. Click Finish to export the certificate.
Install an exported client certificate
was created when the client certificate was exported.
1. Locate and copy the .pfx file to the client computer. On the client computer, double-click the .pfx file to install.
Leave the Store Location as Current User, and then click Next.
2. On the File to import page, don't make any changes. Click Next.
3. On the Private key protection page, input the password for the certificate, or verify that the security principal
is correct, then click Next.
4. On the Certificate Store page, leave the default location, and then click Next.
5. Click Finish. On the Security Warning for the certificate installation, click Yes. You can feel comfortable
clicking 'Yes' because you generated the certificate. The certificate is now successfully imported.
Next steps
Continue with your Point-to-Site configuration.
For Resource Manager deployment model steps, see Configure a Point-to-Site connection to a VNet.
For classic deployment model steps, see Configure a Point-to-Site VPN connection to a VNet (classic).
Configure a VNet-to-VNet VPN gateway connection
using the Azure portal
This article shows you how to create a VPN gateway connection between virtual networks. The virtual networks
can be in the same or different regions, and from the same or different subscriptions. The steps in this article apply
to the Resource Manager deployment model and the Azure portal. You can also create this configuration using a
different deployment tool or deployment model by selecting a different option from the following list:
premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. If
your VNets are in the same region, you may want to consider connecting them using VNet Peering. VNet peering
does not use a VPN gateway. For more information, see VNet peering.
VNet-to-VNet communication can be combined with multi-site configurations. This lets you establish network
topologies that combine cross-premises connectivity with inter-virtual network connectivity, as shown in the
following diagram:
Why connect virtual networks?

You may want to connect virtual networks for the following reasons:
Cross region geo-redundancy and geo-presence
You can set up your own geo-replication or synchronization with secure connectivity without going over
Internet-facing endpoints.
With Azure Traffic Manager and Load Balancer, you can set up highly available workload with geo-
redundancy across multiple Azure regions. One important example is to set up SQL Always On with
Availability Groups spreading across multiple Azure regions.
Regional multi-tier applications with isolation or administrative boundary
Within the same region, you can set up multi-tier applications with multiple virtual networks connected
together due to isolation or administrative requirements.
For more information about VNet-to-VNet connections, see the VNet-to-VNet FAQ at the end of this article. Note
that if your VNets are in different subscriptions, you can't create the connection in the portal. You can use
PowerShell.
Example settings
When using these steps as an exercise, you can use the example settings values. For example purposes, we use
multiple address spaces for each VNet. However, VNet-to-VNet configurations don't require multiple address
spaces.
Values for TestVNet1:
Location: East US
Address Space: 10.12.0.0/16
Gateway Subnet name: GatewaySubnet (this will auto-fill in the portal)
Gateway Subnet address range: 10.11.255.0/27
DNS Server: Use the IP address of your DNS Server
Virtual Network Gateway Name: TestVNet1GW
Gateway Type: VPN
SKU: Select the Gateway SKU you want to use
Public IP address name: TestVNet1GWIP
Connection values:
Name: TestVNet1toTestVNet4
Shared key: You can create the shared key yourself. For this example, we'll use abc123. The important
thing is that when you create the connection between the VNets, the value must match.
Location: West US
Address Space: 10.42.0.0/16
GatewaySubnet name: GatewaySubnet (this will auto-fill in the portal)
GatewaySubnet address range: 10.41.255.0/27
DNS Server: Use the IP address of your DNS Server
Virtual Network Gateway Name: TestVNet4GW
Gateway Type: VPN
SKU: Select the Gateway SKU you want to use
Public IP address name: TestVNet4GWIP
Connection values:
Name: TestVNet4toTestVNet1
Shared key: You can create the shared key yourself. For this example, we'll use abc123. The important
thing is that when you create the connection between the VNets, the value must match.
1. Create and configure TestVNet1

If you already have a VNet, verify that the settings are compatible with your VPN gateway design. Pay particular
attention to any subnets that may overlap with other networks. If you have overlapping subnets, your connection
won't work properly. If your VNet is configured with the correct settings, you can begin the steps in the Specify a
DNS server section.
To create a virtual network
The screenshots are provided as examples. Be sure to replace the values with your own. For more information
about working with virtual networks, see the Virtual Network Overview.
2. Click New. In the Search the marketplace field, type "Virtual Network". Locate Virtual Network from the
3. Near the bottom of the Virtual Network blade, from the Select a deployment model list, select Resource
Manager, and then click Create.
exclamation mark will become a green check mark when the characters entered in the field are valid.
5. The Create virtual network blade looks similar to the following example. There may be values that are
auto-filled. If so, replace the values with your own.
6. Name: Enter the name for your Virtual Network.

7. Address space: Enter the address space. If you have multiple address spaces to add, add your first address
space. You can add additional address spaces later, after creating the VNet.
8. Subnet name: Add the subnet name and subnet address range. You can add additional subnets later, after
creating the VNet.
9. Subscription: Verify that the Subscription listed is the correct one. You can change subscriptions by using the
drop-down.
10. Resource group: Select an existing resource group, or create a new one by typing a name for your new
configuration values. For more information about resource groups, visit Azure Resource Manager Overview.
11. Location: Select the location for your VNet. The location determines where the resources that you deploy to
this VNet will reside.
Create.
13. After clicking Create, you will see a tile on your dashboard that will reflect the progress of your VNet. The
tile changes as the VNet is being created.
2. Add additional address space and create subnets
You can add additional address space and create subnets once your VNet has been created.
To add address space
1. To add additional address space, under the Settings section for your virtual network blade, click Address
space to open the Address space blade.
2. Add the additional address space, and then click Save at the top of the blade.
To create subnets
1. To create subnets, in the Settings section of your virtual network blade, click Subnets to open the Subnets
blade.
2. In the Subnets blade, click +Subnet to open the Add subnet blade. Name your new subnet and specify the
address range.
3. Create a gateway subnet

Before connecting your virtual network to a gateway, you first need to create the gateway subnet for the virtual
network to which you want to connect. If possible, it's best to create a gateway subnet using a CIDR block of /28 or
/27 in order to provide enough IP addresses to accommodate additional future configuration requirements.
If you are creating this configuration as an exercise, refer to these Example settings when creating your gateway
subnet.
IMPORTANT
To create a gateway subnet

gateway.
4. Specify a DNS server (optional)

DNS is not required for VNet-to-VNet connections. However, if you want to have name resolution for resources
that are deployed to your virtual network, you should specify a DNS server. This setting lets you specify the DNS
server that you want to use for name resolution for this virtual network. It does not create a DNS server.
1. On the Settings page for your virtual network, navigate to DNS Servers and click to open the DNS servers
blade.

5. Create a virtual network gateway

In this step, you create the virtual network gateway for your VNet. Creating a gateway can often take 45 minutes
or more, depending on the selected gateway SKU. If you are creating this configuration as an exercise, you can
refer to the Example settings.
To create a virtual network gateway
based VPN type.
you select.
Gateway currently only supports Dynamic Public IP address allocation. However, this does not mean that the IP
address changes after it has been assigned to your VPN gateway. The only time the Public IP address changes
is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal
6. Create and configure TestVNet4

Once you've configured TestVNet1, create TestVNet4 by repeating the previous steps, replacing the values with
those of TestVNet4. You don't need to wait until the virtual network gateway for TestVNet1 has finished creating
before configuring TestVNet4. If you are using your own values, make sure that the address spaces don't overlap
with any of the VNets that you want to connect to.
7. Configure the TestVNet1 connection

When the virtual network gateways for both TestVNet1 and TestVNet4 have completed, you can create your
virtual network gateway connections. In this section, you will create a connection from VNet1 to VNet4. These
steps work only for VNets in the same subscription. If your VNets are in different subscriptions, you must use
PowerShell to make the connection. See the PowerShell article.
1. In All resources, navigate to the virtual network gateway for your VNet. For example, TestVNet1GW. Click
TestVNet1GW to open the virtual network gateway blade.
2. Click +Add to open the Add connection blade.
3. On the Add connection blade, in the name field, type a name for your connection. For example,
TestVNet1toTestVNet4.
4. For Connection type. select VNet-to-VNet from the dropdown.

5. The First virtual network gateway field value is automatically filled in because you are creating this
connection from the specified virtual network gateway.
6. The Second virtual network gateway field is the virtual network gateway of the VNet that you want to
create a connection to. Click Choose another virtual network gateway to open the Choose virtual
network gateway blade.
7. View the virtual network gateways that are listed on this blade. Notice that only virtual network gateways that
are in your subscription are listed. If you want to connect to a virtual network gateway that is not in your
subscription, please use the PowerShell article.
8. Click the virtual network gateway that you want to connect to.
9. In the Shared key field, type a shared key for your connection. You can generate or create this key yourself.
In a site-to-site connection, the key you use would be exactly the same for your on-premises device and
your virtual network gateway connection. The concept is similar here, except that rather than connecting to
a VPN device, you are connecting to another virtual network gateway.
8. Configure the TestVNet4 connection

Next, create a connection from TestVNet4 to TestVNet1. Use the same method that you used to create the
connection from TestVNet1 to TestVNet4. Make sure that you use the same shared key.
9. Verify your connection

Verify the connection. For each virtual network gateway, do the following:
1. Locate the blade for the virtual network gateway. For example, TestVNet4GW.
2. On the virtual network gateway blade, click Connections to view the connections blade for the virtual network
gateway.
View the connections and verify the status. Once the connection is created, you will see Succeeded and
Connected as the Status values.
You can double-click each connection separately to view more information about the connection.
VNet-to-VNet FAQ
View the FAQ details for additional information about VNet-to-VNet connections.
together.
Next steps
Once your connection is complete, you can add virtual machines to your virtual networks. See the Virtual
Machines documentation for more information.
using PowerShell
can be in the same or different regions, and from the same or different subscriptions. The steps in this article
apply to the Resource Manager deployment model and use PowerShell. You can also create this configuration
using a different deployment tool or deployment model by selecting a different option from the following list:
following diagram:

You can set up your own geo-replication or synchronization with secure connectivity without going
over Internet-facing endpoints.
For more information about VNet-to-VNet connections, see the VNet-to-VNet FAQ at the end of this article.
Which set of steps should I use?
In this article, you see two different sets of steps. One set of steps for VNets that reside in the same subscription,
and another for VNets that reside in different subscriptions. The key difference between the sets is whether you
can create and configure all virtual network and gateway resources within the same PowerShell session.
The steps in this article use variables that are declared at the beginning of each section. If you already are
working with existing VNets, modify the variables to reflect the settings in your own environment. If you want
name resolution for your virtual networks, see Name resolution.
How to connect VNets that are in the same subscription
Before you begin

Before beginning, you need to install the Azure Resource Manager PowerShell cmdlets. For more information
about installing the PowerShell cmdlets, see How to install and configure Azure PowerShell.
Step 1 - Plan your IP address ranges
In the following steps, we create two virtual networks along with their respective gateway subnets and
configurations. We then create a VPN connection between the two VNets. Its important to plan the IP address
ranges for your network configuration. Keep in mind that you must make sure that none of your VNet ranges or
local network ranges overlap in any way. In these examples, we do not include a DNS server. If you want name
resolution for your virtual networks, see Name resolution.
We use the following values in the examples:
Location: East US
TestVNet1: 10.11.0.0/16 & 10.12.0.0/16
FrontEnd: 10.11.0.0/24
BackEnd: 10.12.0.0/24
GatewayName: VNet1GW
VPNType: RouteBased
Connection(1to4): VNet1toVNet4
ConnectionType: VNet2VNet
TestVNet2: 10.41.0.0/16 & 10.42.0.0/16
FrontEnd: 10.41.0.0/24
BackEnd: 10.42.0.0/24
Location: West US
VPNType: RouteBased
Connection: VNet4toVNet1
Step 2 - Create and configure TestVNet1
1. Declare your variables. This example declares the variables using the values for this exercise. In most cases,
you should replace the values with your own. However, you can use these variables if you are running
through the steps to become familiar with this type of configuration. Modify the variables if needed, then
copy and paste them into your PowerShell console.
$Sub1 = "Replace_With_Your_Subcription_Name"
$RG1 = "TestRG1"
$Location1 = "East US"
$VNetName1 = "TestVNet1"
$FESubName1 = "FrontEnd"
$BESubName1 = "Backend"
$GWSubName1 = "GatewaySubnet"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$GWName1 = "VNet1GW"
$GWIPName1 = "VNet1GWIP"
$GWIPconfName1 = "gwipconf1"
$Connection14 = "VNet1toVNet4"
2. Connect to your account. Use the following example to help you connect:
Check the subscriptions for the account.
Select-AzureRmSubscription -SubscriptionName $Sub1
3. Create a new resource group.
New-AzureRmResourceGroup -Name $RG1 -Location $Location1
4. Create the subnet configurations for TestVNet1. This example creates a virtual network named TestVNet1
and three subnets, one called GatewaySubnet, one called FrontEnd, and one called Backend. When
substituting values, it's important that you always name your gateway subnet specifically GatewaySubnet.
If you name it something else, your gateway creation fails.
The following example uses the variables that you set earlier. In this example, the gateway subnet is using
a /27. While it is possible to create a gateway subnet as small as /29, we recommend that you create a
larger subnet that includes more addresses by selecting at least /28 or /27. This will allow for enough
addresses to accommodate possible additional configurations that you may want in the future.
$fesub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1

$besub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1
$gwsub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName1 -AddressPrefix $GWSubPrefix1
5. Create TestVNet1.
New-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1
6. Request a public IP address to be allocated to the gateway you will create for your VNet. Notice that the
AllocationMethod is Dynamic. You cannot specify the IP address that you want to use. It's dynamically
allocated to your gateway.
$gwpip1 = New-AzureRmPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 `

-Location $Location1 -AllocationMethod Dynamic
7. Create the gateway configuration. The gateway configuration defines the subnet and the public IP address
to use. Use the example to create your gateway configuration.
$vnet1 = Get-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1

$subnet1 = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet1
$gwipconf1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 `
-Subnet $subnet1 -PublicIpAddress $gwpip1
8. Create the gateway for TestVNet1. In this step, you create the virtual network gateway for your TestVNet1.
VNet-to-VNet configurations require a RouteBased VpnType. Creating a gateway can often take 45
minutes or more, depending on the selected gateway SKU.
New-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `

Once you've configured TestVNet1, create TestVNet4. Follow the steps below, replacing the values with your own
when needed. This step can be done within the same PowerShell session because it is in the same subscription.
1. Declare your variables. Be sure to replace the values with the ones that you want to use for your
configuration.
$RG4 = "TestRG4"
$Location4 = "West US"
$VnetName4 = "TestVNet4"
$VnetPrefix41 = "10.41.0.0/16"
$VnetPrefix42 = "10.42.0.0/16"
$FESubPrefix4 = "10.41.0.0/24"
$BESubPrefix4 = "10.42.0.0/24"
$GWSubPrefix4 = "10.42.255.0/27"
3. Create the subnet configurations for TestVNet4.

New-AzureRmVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4 `

-Location $Location4 -AddressPrefix $VnetPrefix41,$VnetPrefix42 -Subnet $fesub4,$besub4,$gwsub4
5. Request a public IP address.

6. Create the gateway configuration.
$vnet4 = Get-AzureRmVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4

$gwipconf4 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName4 -Subnet $subnet4 -
PublicIpAddress $gwpip4
7. Create the TestVNet4 gateway. Creating a gateway can often take 45 minutes or more, depending on the
selected gateway SKU.
New-AzureRmVirtualNetworkGateway -Name $GWName4 -ResourceGroupName $RG4 `

-Location $Location4 -IpConfigurations $gwipconf4 -GatewayType Vpn `
Step 4 - Create the connections

1. Get both virtual network gateways. If both of the gateways are in the same subscription, as they are in the
example, you can complete this step in the same PowerShell session.
$vnet1gw = Get-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
2. Create the TestVNet1 to TestVNet4 connection. In this step, you create the connection from TestVNet1 to
TestVNet4. You'll see a shared key referenced in the examples. You can use your own values for the shared
key. The important thing is that the shared key must match for both connections. Creating a connection
can take a short while to complete.
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection14 -ResourceGroupName $RG1 `

-VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet4gw -Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
3. Create the TestVNet4 to TestVNet1 connection. This step is similar to the one above, except you are
creating the connection from TestVNet4 to TestVNet1. Make sure the shared keys match. The connection
will be established after a few minutes.
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection41 -ResourceGroupName $RG4 `

-VirtualNetworkGateway1 $vnet4gw -VirtualNetworkGateway2 $vnet1gw -Location $Location4 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
4. Verify your connection. See the section How to verify your connection.
How to connect VNets that are in different subscriptions
In this scenario, we connect TestVNet1 and TestVNet5. TestVNet1 and TestVNet5 reside in a different
subscription. The difference between these steps and the previous set is that some of the configuration steps
need to be performed in a separate PowerShell session in the context of the second subscription. Especially when
the two subscriptions belong to different organizations.
You must complete Step 1 and Step 2 from the previous section to create and configure TestVNet1 and the VPN
Gateway for TestVNet1. For this configuration, you are not required to create TestVNet4 from the previous
section, although if you do create it, it will not conflict with these steps. Once you complete Step 1 and Step 2,
continue with Step 6 to create TestVNet5.
Step 6 - Verify the IP address ranges
It is important to make sure that the IP address space of the new virtual network, TestVNet5, does not overlap
with any of your VNet ranges or local network gateway ranges. In this example, the virtual networks may belong
to different organizations. For this exercise, you can use the following values for the TestVNet5:
Location: Japan East
TestVNet5: 10.51.0.0/16 & 10.52.0.0/16
FrontEnd: 10.51.0.0/24
BackEnd: 10.52.0.0/24
GatewaySubnet: 10.52.255.0.0/27
VPNType: RouteBased
This step must be done in the context of the new subscription. This part may be performed by the administrator
in a different organization that owns the subscription.
1. Declare your variables. Be sure to replace the values with the ones that you want to use for your
configuration.
$Sub5 = "Replace_With_the_New_Subcription_Name"
$RG5 = "TestRG5"
$Location5 = "Japan East"
$VnetName5 = "TestVNet5"
$VnetPrefix51 = "10.51.0.0/16"
$VnetPrefix52 = "10.52.0.0/16"
$FESubPrefix5 = "10.51.0.0/24"
$BESubPrefix5 = "10.52.0.0/24"
$GWSubPrefix5 = "10.52.255.0/27"
2. Connect to subscription 5. Open your PowerShell console and connect to your account. Use the following
sample to help you connect:
4. Create the subnet configurations for TestVNet5.

New-AzureRmVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5 -Location $Location5 `

-AddressPrefix $VnetPrefix51,$VnetPrefix52 -Subnet $fesub5,$besub5,$gwsub5

7. Create the gateway configuration.
$vnet5 = Get-AzureRmVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5

$gwipconf5 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName5 -Subnet $subnet5 -
8. Create the TestVNet5 gateway.
New-AzureRmVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5 -Location $Location5 `

-IpConfigurations $gwipconf5 -GatewayType Vpn -VpnType RouteBased -GatewaySku Standard

In this example, because the gateways are in the different subscriptions, we've split this step into two PowerShell
sessions marked as [Subscription 1] and [Subscription 5].
1. [Subscription 1] Get the virtual network gateway for Subscription 1. Log in and connect to Subscription 1
before running the following example:
Copy the output of the following elements and send these to the administrator of Subscription 5 via email
or another method.
$vnet1gw.Name
$vnet1gw.Id
These two elements will have values similar to the following example output:
PS D:\> $vnet1gw.Name
VNet1GW
PS D:\> $vnet1gw.Id
/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroupsTestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW
2. [Subscription 5] Get the virtual network gateway for Subscription 5. Log in and connect to Subscription 5
before running the following example:
Copy the output of the following elements and send these to the administrator of Subscription 1 via email
or another method.
$vnet5gw.Name
$vnet5gw.Id
These two elements will have values similar to the following example output:
PS C:\> $vnet5gw.Name
VNet5GW
PS C:\> $vnet5gw.Id
/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW
3. [Subscription 1] Create the TestVNet1 to TestVNet5 connection. In this step, you create the connection
from TestVNet1 to TestVNet5. The difference here is that $vnet5gw cannot be obtained directly because it
is in a different subscription. You will need to create a new PowerShell object with the values
communicated from Subscription 1 in the steps above. Use the example below. Replace the Name, Id, and
shared key with your own values. The important thing is that the shared key must match for both
connections. Creating a connection can take a short while to complete.
Connect to Subscription 1 before running the following example:
$vnet5gw = New-Object Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway

$vnet5gw.Name = "VNet5GW"
$vnet5gw.Id = "/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW"
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection15 -ResourceGroupName $RG1 -
VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet5gw -Location $Location1 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'
4. [Subscription 5] Create the TestVNet5 to TestVNet1 connection. This step is similar to the one above,
except you are creating the connection from TestVNet5 to TestVNet1. The same process of creating a
PowerShell object based on the values obtained from Subscription 1 applies here as well. In this step, be
sure that the shared keys match.
Connect to Subscription 5 before running the following example:
$vnet1gw = New-Object Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway

$vnet1gw.Name = "VNet1GW"
$vnet1gw.Id = "/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW "
Vnet2Vnet -SharedKey 'AzureA1b2C3'
How to verify a connection

IMPORTANT
VNet-to-VNet FAQ
Cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on
the source regions. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using
VNet Peering, rather than VPN Gateway, see the Virtual Network pricing page.
together.
Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the
same VPN gateway uptime SLA in Azure.
Next steps
Once your connection is complete, you can add virtual machines to your virtual networks. See the Virtual
Machines documentation for more information.
using Azure CLI
This article shows you how to create a VPN gateway connection between virtual networks. The virtual networks can
be in the same or different regions, and from the same or different subscriptions. The steps in this article apply to
the Resource Manager deployment model and uses the Azure CLI. You can also create this configuration using a
different deployment tool or deployment model by selecting a different option from the following list:
following diagram:

For more information about VNet-to-VNet connections, see the VNet-to-VNet FAQ at the end of this article.
Which set of steps should I use?
In this article, you see two different sets of steps. One set of steps for VNets that reside in the same subscription,
and another for VNets that reside in different subscriptions.
Connect VNets that are in the same subscription
Before you begin

Before beginning, install the latest version of the CLI commands (2.0 or later). For information about installing the
CLI commands, see Install Azure CLI 2.0.
Plan your IP address ranges
In the following steps, we create two virtual networks along with their respective gateway subnets and
configurations. We then create a VPN connection between the two VNets. Its important to plan the IP address
ranges for your network configuration. Keep in mind that you must make sure that none of your VNet ranges or
local network ranges overlap in any way. In these examples, we do not include a DNS server. If you want name
resolution for your virtual networks, see Name resolution.
We use the following values in the examples:
Location: East US
TestVNet1: 10.11.0.0/16 & 10.12.0.0/16
FrontEnd: 10.11.0.0/24
BackEnd: 10.12.0.0/24
VPNType: RouteBased
TestVNet2: 10.41.0.0/16 & 10.42.0.0/16
FrontEnd: 10.41.0.0/24
BackEnd: 10.42.0.0/24
Location: West US
VPNType: RouteBased
Step 1 - Connect to your subscription
1. Log in to your Azure subscription with the az login command and follow the on-screen directions. For more
az login
2. If you have more than one Azure subscription, list the subscriptions for the account.

az group create -n TestRG1 -l eastus
2. Create TestVNet1 and the subnets for TestVNet1. This example creates a virtual network named TestVNet1
and a subnet named FrontEnd.
az network vnet create -n TestVNet1 -g TestRG1 --address-prefix 10.11.0.0/16 -l eastus --subnet-name

FrontEnd --subnet-prefix 10.11.0.0/24
3. Create an additional address space for the backend subnet. Notice that in this step, we specify both the
address space that we created earlier, and the additional address space that we want to add. This is because
the az network vnet update command overwrites the previous settings. Make sure to specify all of the
address prefixes when using this command.
az network vnet update -n TestVNet1 --address-prefixes 10.11.0.0/16 10.12.0.0/16 -g TestRG1
4. Create the backend subnet.
az network vnet subnet create --vnet-name TestVNet1 -n BackEnd -g TestRG1 --address-prefix 10.12.0.0/24
5. Create the gateway subnet. Notice that the gateway subnet is named 'GatewaySubnet'. This name is
required. In this example, the gateway subnet is using a /27. While it is possible to create a gateway subnet
as small as /29, we recommend that you create a larger subnet that includes more addresses by selecting at
least /28 or /27. This will allow for enough addresses to accommodate possible additional configurations
that you may want in the future.
az network vnet subnet create --vnet-name TestVNet1 -n GatewaySubnet -g TestRG1 --address-prefix
10.12.255.0/27
6. Request a public IP address to be allocated to the gateway you will create for your VNet. Notice that the
AllocationMethod is Dynamic. You cannot specify the IP address that you want to use. It's dynamically
allocated to your gateway.
az network public-ip create -n VNet1GWIP -g TestRG1 --allocation-method Dynamic
7. Create the virtual network gateway for TestVNet1. VNet-to-VNet configurations require a RouteBased
VpnType. If you run this command using the '--no-wait' parameter, you don't see any feedback or output.
The '--no-wait' parameter allows the gateway to create in the background. It does not mean that the VPN
gateway finishes creating immediately. Creating a gateway can often take 45 minutes or more, depending
on the gateway SKU that you use.
az network vnet-gateway create -n VNet1GW -l eastus --public-ip-address VNet1GWIP -g TestRG1 --vnet

TestVNet1 --gateway-type Vpn --sku Standard --vpn-type RouteBased --no-wait

az group create -n TestRG4 -l westus
az network vnet create -n TestVNet4 -g TestRG4 --address-prefix 10.41.0.0/16 -l westus --subnet-name

3. Create additional subnets for TestVNet4.

4. Create the gateway subnet.

10.42.255.0/27
5. Request a Public IP address.
6. Create the TestVNet4 virtual network gateway.
az network vnet-gateway create -n VNet4GW -l westus --public-ip-address VNet4GWIP -g TestRG4 --vnet


You now have two VNets with VPN gateways. The next step is to create VPN gateway connections between the
virtual network gateways. If you used the examples above, your VNet gateways are in different resource groups.
When gateways are in different resource groups, you need to identify and specify the resource IDs for each
gateway when making a connection. If your VNets are in the same resource group, you can use the second set of
instructions because you don't need to specify the resource IDs.
To connect VNets that reside in different resource groups
1. Get the Resource ID of VNet1GW from the output of the following command:
az network vnet-gateway show -n VNet1GW -g TestRG1
In the output, find the "id:" line. The values within the quotes are needed to create the connection in the next
section. Copy these values to a text editor, such as Notepad, so that you can easily paste them when creating
your connection.
Example output:
"activeActive": false,
"bgpSettings": {
"asn": 65515,
"bgpPeeringAddress": "10.12.255.30",
"peerWeight": 0
},
"enableBgp": false,
"etag": "W/\"ecb42bc5-c176-44e1-802f-b0ce2962ac04\"",
"gatewayDefaultSite": null,
"gatewayType": "Vpn",
"id": "/subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW",
"ipConfigurations":
Copy the values after "id": within the quotes.
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW"
2. Get the Resource ID of VNet4GW and copy the values to a text editor.
TestVNet4. There is a shared key referenced in the examples. You can use your own values for the shared
key. The important thing is that the shared key must match for both connections. Creating a connection
takes a short while to complete.
az network vpn-connection create -n VNet1ToVNet4 -g TestRG1 --vnet-gateway1 /subscriptions/d6ff83d6-

713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW -l eastus
--shared-key "aabbcc" --vnet-gateway2 /subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG4/providers/Microsoft.Network/virtualNetworkGateways/VNet4GW
4. Create the TestVNet4 to TestVNet1 connection. This step is similar to the one above, except you are creating
the connection from TestVNet4 to TestVNet1. Make sure the shared keys match. It takes a few minutes to
establish the connection.
713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG4/providers/Microsoft.Network/virtualNetworkGateways/VNet4GW -l westus
--shared-key "aabbcc" --vnet-gateway2 /subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1G
5. Verify your connections. See Verify your connection.

To connect VNets that reside in the same resource group
TestVNet4. Notice the resource groups are the same in the examples. You also see a shared key referenced
in the examples. You can use your own values for the shared key, however, the shared key must match for
both connections. Creating a connection takes a short while to complete.
az network vpn-connection create -n VNet1ToVNet4 -g TestRG1 --vnet-gateway1 VNet1GW -l eastus --shared-

key "eeffgg" --vnet-gateway2 VNet4GW
2. Create the TestVNet4 to TestVNet1 connection. This step is similar to the one above, except you are creating
the connection from TestVNet4 to TestVNet1. Make sure the shared keys match. It takes a few minutes to
establish the connection.
az network vpn-connection create -n VNet4ToVNet1 -g TestRG1 --vnet-gateway1 VNet4GW -l eastus --shared-

key "eeffgg" --vnet-gateway2 VNet1GW
3. Verify your connections. See Verify your connection.
Connect VNets that are in different subscriptions
In this scenario, we connect TestVNet1 and TestVNet5. The VNets reside different subscriptions. The steps for this
configuration add an additional VNet-to-VNet connection in order to connect TestVNet1 to TestVNet5.
These instructions continue from the steps in the preceding sections. You must complete Step 1 and Step 2 to
create and configure TestVNet1 and the VPN Gateway for TestVNet1. For this configuration, you are not required
to create TestVNet4 from the previous section, although if you do create it, it will not conflict with these steps. Once
you complete Step 1 and Step 2, continue with Step 6 (below).
Step 6 - Verify the IP address ranges
When creating additional connections, it's important to verify that the IP address space of the new virtual network
does not overlap with any of your other VNet ranges or local network gateway ranges. For this exercise, you can
use the following values for the TestVNet5:
Location: Japan East
TestVNet5: 10.51.0.0/16 & 10.52.0.0/16
FrontEnd: 10.51.0.0/24
BackEnd: 10.52.0.0/24
GatewaySubnet: 10.52.255.0.0/27
VPNType: RouteBased
This step must be done in the context of the new subscription, Subscription 5. This part may be performed by the
administrator in a different organization that owns the subscription. To switch between subscriptions use 'az
account list --all' to list the subscriptions available to your account, then use 'az account set --subscription ' to
switch to the subscription that you want to use.
1. Make sure you are connected to Subscription 5, then create a resource group.
az group create -n TestRG5 -l japaneast
az network vnet create -n TestVNet5 -g TestRG5 --address-prefix 10.51.0.0/16 -l japaneast --subnet-name

3. Add subnets.

4. Add the gateway subnet.

10.52.255.0/27
6. Create the TestVNet5 gateway
az network vnet-gateway create -n VNet5GW -l japaneast --public-ip-address VNet5GWIP -g TestRG5 --vnet


We split this step into two CLI sessions marked as [Subscription 1], and [Subscription 5] because the gateways
are in the different subscriptions. To switch between subscriptions use 'az account list --all' to list the subscriptions
available to your account, then use 'az account set --subscription ' to switch to the subscription that you want to
use.
1. [Subscription 1] Log in and connect to Subscription 1. Run the following command to get the name and ID
of the Gateway from the output:
Copy the output for "id:". Send the ID and the name of the VNet gateway (VNet1GW) to the administrator of
Subscription 5 via email or another method.
Example output:
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW"
2. [Subscription 5] Log in and connect to Subscription 5. Run the following command to get the name and ID
of the Gateway from the output:
Copy the output for "id:". Send the ID and the name of the VNet gateway (VNet5GW) to the administrator of
Subscription 1 via email or another method.
3. [Subscription 1] In this step, you create the connection from TestVNet1 to TestVNet5. You can use your
own values for the shared key, however, the shared key must match for both connections. Creating a
connection can take a short while to complete. Make sure you connect to Subscription 1.

713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW -l eastus
--shared-key "eeffgg" --vnet-gateway2 /subscriptions/e7e33b39-fe28-4822-b65c-
a4db8bbff7cb/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW
4. [Subscription 5] This step is similar to the one above, except you are creating the connection from
TestVNet5 to TestVNet1. Make sure that the shared keys match and that you connect to Subscription 5.
az network vpn-connection create -n VNet5ToVNet1 -g TestRG5 --vnet-gateway1 /subscriptions/e7e33b39-

fe28-4822-b65c-
a4db8bbff7cb/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW -l
japaneast --shared-key "eeffgg" --vnet-gateway2 /subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW
Verify the connections

IMPORTANT
When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a
network security group to this subnet may cause your VPN gateway to stop functioning as expected. For more information
about network security groups, see What is a network security group?
VNet-to-VNet FAQ
together.
Next steps
information, see the Virtual Machines documentation.
Configure a VNet-to-VNet connection (classic)
can be in the same or different regions, and from the same or different subscriptions. The steps in this article apply
to the classic deployment model and the Azure portal. You can also create this configuration using a different
deployment tool or deployment model by selecting a different option from the following list:
About VNet-to-VNet connections

Connecting a virtual network to another virtual network (VNet-to-VNet) in the classic deployment model using a
VPN gateway is similar to connecting a virtual network to an on-premises site location. Both connectivity types use
a VPN gateway to provide a secure tunnel using IPsec/IKE.
The VNets you connect can be in different subscriptions and different regions. You can combine VNet to VNet
communication with multi-site configurations. This lets you establish network topologies that combine cross-
premises connectivity with inter-virtual network connectivity.

With Azure Load Balancer and Microsoft or third-party clustering technology, you can set up highly
available workload with geo-redundancy across multiple Azure regions. One important example is to set
up SQL Always On with Availability Groups spreading across multiple Azure regions.
Regional multi-tier applications with strong isolation boundary
Within the same region, you can set up multi-tier applications with multiple VNets connected together
with strong isolation and secure inter-tier communication.
Cross subscription, inter-organization communication in Azure
If you have multiple Azure subscriptions, you can connect workloads from different subscriptions
together securely between virtual networks.
For enterprises or service providers, you can enable cross-organization communication with secure VPN
technology within Azure.
For more information about VNet-to-VNet connections, see VNet-to-VNet considerations at the end of this article.
Before you begin
Before beginning this exercise, download and install the latest version of the Azure Service Management (SM)
PowerShell cmdlets. For more information, see How to install and configure Azure PowerShell. We use the portal
for most of the steps, but you must use PowerShell to create the connections between the VNets. You can't create
the connections using the Azure portal.
Step 1 - Plan your IP address ranges

Its important to decide the ranges that youll use to configure your virtual networks. For this configuration, you
must make sure that none of your VNet ranges overlap with each other, or with any of the local networks that they
connect to.
The following table shows an example of how to define your VNets. Use the ranges as a guideline only. Write
down the ranges for your virtual networks. You need this information for later steps.
Example
CONNECTS TO LOCAL
VIRTUAL NETWORK ADDRESS SPACE REGION NETWORK SITE
TestVNet1 TestVNet1 East US VNet4Local

(10.11.0.0/16) (10.41.0.0/16)
(10.12.0.0/16) (10.42.0.0/16)
TestVNet4 TestVNet4 West US VNet1Local

(10.41.0.0/16) (10.11.0.0/16)
(10.42.0.0/16) (10.12.0.0/16)
Step 2 - Create the virtual networks

Create two virtual networks in the Azure portal. For the steps to create classic virtual networks, see Create a classic
virtual network. If you are using this article as an exercise, you can use the following example values:
Values for TestVNet1
Name: TestVNet1
Address space: 10.11.0.0/16, 10.12.0.0/16 (optional)
Subnet name: default
Resource group: ClassicRG
Location: East US
Values for TestVNet4
Name: TestVNet4
Address space: 10.41.0.0/16, 10.42.0.0/16 (optional)
Subnet name: default
Resource group: ClassicRG
Location: West US
When creating your VNets, keep in mind the following settings:
Virtual Network Address Spaces On the Virtual Network Address Spaces page, specify the address
range that you want to use for your virtual network. These are the dynamic IP addresses that will be
assigned to the VMs and other role instances that you deploy to this virtual network.
The address spaces you select cannot overlap with the address spaces for any of the other VNets or on-
premises locations that this VNet will connect to.
Location When you create a virtual network, you associate it with an Azure location (region). For
example, if you want your VMs that are deployed to your virtual network to be physically located in West
US, select that location. You cant change the location associated with your virtual network after you create
it.
After creating your VNets, you can add the following settings:
Address space Additional address space is not required for this configuration, but you can add additional
address space after creating the VNet.
Subnets Additional subnets are not required for this configuration, but you might want to have your VMs
in a subnet that is separate from your other role instances.
DNS servers Enter the DNS server name and IP address. This setting does not create a DNS server. It
allows you to specify the DNS servers that you want to use for name resolution for this virtual network.
In this section, you configure the connection type, the local site, and create the gateway.
Step 3 - Configure the local site

Azure uses the settings specified in each local network site to determine how to route traffic between the VNets.
Each VNet must point to the respective local network that you want to route traffic to. You determine the name
you want to use to refer to each local network site. It's best to use something descriptive.
For example, TestVNet1 connects to a local network site that you create named 'VNet4Local'. The settings for
VNet4Local contain the address prefixes for TestVNet4.
The local site for each VNet is the other VNet. The following example values are used for our configuration:
CONNECTS TO LOCAL
TestVNet1 TestVNet1 East US VNet4Local

(10.11.0.0/16) (10.41.0.0/16)
(10.12.0.0/16) (10.42.0.0/16)
TestVNet4 TestVNet4 West US VNet1Local

(10.41.0.0/16) (10.11.0.0/16)
(10.42.0.0/16) (10.12.0.0/16)
1. Locate TestVNet1 in the Azure portal. In the VPN connections section of the blade, click Gateway.
2. On the New VPN Connection page, select Site-to-Site.
3. Click Local site to open the Local site page and configure the settings.
4. On the Local site page, name your local site. In our example, we name the local site 'VNet4Local'.
5. For VPN gateway IP address, you can use any IP address that you want, as long as it's in a valid format.
Typically, youd use the actual external IP address for a VPN device. But, for a classic VNet-to-VNet
configuration, you use the public IP address that is assigned to the gateway for your VNet. Given that youve
not yet created the virtual network gateway, you specify any valid public IP address as a placeholder.
Don't leave this blank - it's not optional for this configuration. In a later step, you go back into these settings
and configure them with the corresponding virtual network gateway IP addresses once Azure generates it.
6. For Client Address Space, use the address space of the other VNet. Refer to your planning example. Click
OK to save your settings and return back to the New VPN Connection blade.
Step 4 - Create the virtual network gateway

Each virtual network must have a virtual network gateway. The virtual network gateway routes and encrypts traffic.
1. On the New VPN Connection blade, select the checkbox Create gateway immediately.
2. Click Subnet, size and routing type. On the Gateway configuration blade, click Subnet.
3. The gateway subnet name is filled in automatically with the required name 'GatewaySubnet'. The Address
range contains the IP addresses that are allocated to the VPN gateway services. Some configurations allow a
gateway subnet of /29, but it's best to use a /28 or /27 to accommodate future configurations that may require
more IP addresses for the gateway services. In our example settings, we use 10.11.1.0/27. Adjust the address
space, then click OK.
4. Configure the Gateway Size. This setting refers to the Gateway SKU.
5. Configure the Routing Type. The routing type for this configuration must be Dynamic. You can't change the
routing type later unless you tear down the gateway and create a new one.
6. Click OK.
7. On the New VPN Connection blade, click OK to begin creating the virtual network gateway. Creating a
gateway can often take 45 minutes or more, depending on the selected gateway SKU.
Step 5 - Configure TestVNet4 settings

Repeat the steps to Create a local site and Create the virtual network gateway to configure TestVNet4, substituting
the values when necessary. If you are doing this as an exercise, use the Example values.
Step 6 - Update the local sites

After your virtual network gateways have been created for both VNets, you must adjust the local sites VPN
gateway IP address values.
VNET NAME CONNECTED SITE GATEWAY IP ADDRESS
TestVNet1 VNet4Local VPN gateway IP address for TestVNet4
TestVNet4 VNet1Local VPN gateway IP address for TestVNet1
Part 1 - Get the virtual network gateway public IP address

1. Locate your virtual network in the Azure portal.
2. Click to open the VNet Overview blade. On the blade, in VPN connections, you can view the IP address
for your virtual network gateway.
3. Copy the IP address. You will use it in the next section.

4. Repeat these steps for TestVNet4
Part 2 - Modify the local sites
1. Locate your virtual network in the Azure portal.
2. On the VNet Overview blade, click the local site.
3. On the Site-to-Site VPN Connections blade, click the name of the local site that you want to modify.
4. Click the Local site that you want to modify.
5. Update the VPN gateway IP address and click OK to save the settings.
6. Close the other blades.

7. Repeat these steps for TestVNet4.
Step 7 - Retrieve values from the network configuration file

When you create classic VNets in the Azure portal, the name that you view is not the full name that you use for
PowerShell. For example, a VNet that appears to be named TestVNet1 in the portal, may have a much longer
name in the network configuration file. The name might look something like: Group ClassicRG TestVNet1. When
you create your connections, it's important to use the values that you see in the network configuration file.
In the following steps, you will connect to your Azure account and download and view the network configuration
file to obtain the values that are required for your connections.
1. Download and install the latest version of the Azure Service Management (SM) PowerShell cmdlets. For
more information, see How to install and configure Azure PowerShell.
2. Open your PowerShell console with elevated rights and connect to your account. Use the following example
If you have more than one subscription, select the subscription that you want to use.
Next, use the following cmdlet to add your Azure subscription to PowerShell for the classic deployment
model.
Add-AzureAccount
3. Export and view the network configuration file. Create a directory on your computer and then export the
network configuration file to the directory. In this example, the network configuration file is exported to
C:\AzureNet.
4. Open the file with a text editor and view the names for your VNets and sites. These will be the name you use
when you create your connections.
VNet names are listed as VirtualNetworkSite name =
Site names are listed as LocalNetworkSiteRef name =
Step 8 - Create the VPN gateway connections

When all the previous steps have been completed, you can set the IPsec/IKE pre-shared keys and create the
connection. This set of steps uses PowerShell. VNet-to-VNet connections for the classic deployment model cannot
be configured in the Azure portal.
In the examples, notice that the shared key is exactly the same. The shared key must always match. Be sure to
replace the values in these examples with the exact names for your VNets and Local Network Sites.
1. Create the TestVNet1 to TestVNet4 connection.
Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet1' `

-LocalNetworkSiteName '17BE5E2C_VNet4Local' -SharedKey A1b2C3D4
2. Create the TestVNet4 to TestVNet1 connection.
Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet4' `

-LocalNetworkSiteName 'F7F7BFC7_VNet1Local' -SharedKey A1b2C3D4
3. Wait for the connections to initialize. Once the gateway has initialized, the Status is 'Successful'.
Error :
HttpStatusCode : OK
Id :
Status : Successful
RequestId :
StatusCode : OK
VNet-to-VNet considerations for classic VNets

The virtual networks can be in the same or different subscriptions.
The virtual networks can be in the same or different Azure regions (locations).
A cloud service or a load balancing endpoint can't span across virtual networks, even if they are connected
together.
Connecting multiple virtual networks together doesn't require any VPN devices.
VNet-to-VNet supports connecting Azure Virtual Networks. It does not support connecting virtual machines or
cloud services that are not deployed to a virtual network.
VNet-to-VNet requires dynamic routing gateways. Azure static routing gateways are not supported.
Virtual network connectivity can be used simultaneously with multi-site VPNs. There is a maximum of 10 VPN
tunnels for a virtual network VPN gateway connecting to either other virtual networks, or on-premises sites.
The address spaces of the virtual networks and on-premises local network sites must not overlap. Overlapping
address spaces will cause the creation of virtual networks or uploading netcfg configuration files to fail.
Redundant tunnels between a pair of virtual networks are not supported.
All VPN tunnels for the VNet, including P2S VPNs, share the available bandwidth for the VPN gateway, and the
VNet-to-VNet traffic travels across the Azure backbone.
Next steps
Verify your connections. See Verify a VPN Gateway connection.
Connect virtual networks from different deployment
models using the portal
This article shows you how to connect classic VNets to Resource Manager VNets to allow the resources located in
the separate deployment models to communicate with each other. The steps in this article primarily use the Azure
portal, but you can also create this configuration using the PowerShell by selecting the article from this list.
Connecting a classic VNet to a Resource Manager VNet is similar to connecting a VNet to an on-premises site
location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. You can create a
connection between VNets that are in different subscriptions and in different regions. You can also connect VNets
that already have connections to on-premises networks, as long as the gateway that they have been configured
with is dynamic or route-based. For more information about VNet-to-VNet connections, see the VNet-to-VNet
FAQ at the end of this article.
If your VNets are in the same region, you may want to instead consider connecting them using VNet Peering.
VNet peering does not use a VPN gateway. For more information, see VNet peering.
Prerequisites
These steps assume that both VNets have already been created. If you are using this article as an exercise and
don't have VNets, there are links in the steps to help you create them.
Verify that the address ranges for the VNets do not overlap with each other, or overlap with any of the ranges
for other connections that the gateways may be connected to.
Install the latest PowerShell cmdlets for both Resource Manager and Service Management (classic). In this
article, we use both the Azure portal and PowerShell. PowerShell is required to create the connection from the
classic VNet to the Resource Manager VNet. For more information, see How to install and configure Azure
PowerShell.
Example settings
You can use these values to create a test environment, or refer to them to better understand the examples in this
article.
Classic VNet
VNet name = ClassicVNet
Address space = 10.0.0.0/24
Subnet-1 = 10.0.0.0/27
Resource Group = ClassicRG
Location = West US
Local site = RMVNetLocal
Resource Manager VNet
VNet name = RMVNet
Address space = 192.168.0.0/16
Subnet-1 = 192.168.1.0/24
Resource Group = RG1
Location = East US
Virtual network gateway name = RMGateway
Gateway type = VPN
VPN type = Route-based
Gateway Public IP address name = rmgwpip
Local network gateway = ClassicVNetLocal
Connection name = RMtoClassic
Connection overview
For this configuration, you create a VPN gateway connection over an IPsec/IKE VPN tunnel between the virtual
networks. Make sure that none of your VNet ranges overlap with each other, or with any of the local networks
that they connect to.
The following table shows an example of how the example VNets and local sites are defined:
CONNECTS TO LOCAL
ClassicVNet (10.0.0.0/24) West US RMVNetLocal

(192.168.0.0/16)
RMVNet (192.168.0.0/16) East US ClassicVNetLocal

(10.0.0.0/24)
1. Configure the classic VNet settings

In this section, you create the local network (local site) and the virtual network gateway for your classic VNet. If
you don't have a classic VNet and are running these steps as an exercise, you can create a VNet by using this
article and the Example settings values from above. If you already have a VNet with a VPN gateway, verify that the
gateway is Dynamic. If it's Static, you must first delete the VPN gateway, then proceed.
Screenshots are provided as examples. Be sure to replace the values with your own, or use the Example values.
Part 1 - Configure the local site
Open the Azure portal and sign in with your Azure account.
1. Navigate to All resources and locate the ClassicVNet in the list.
2. On the Overview blade, in the VPN connections section, click the Gateway graphic to create a gateway.
3. On the New VPN Connection blade, for Connection type, select Site-to-site.
4. For Local site, click Configure required settings. This opens the Local site blade.
5. On the Local site blade, create a name to refer to the Resource Manager VNet. For example, 'RMVNetLocal'.
6. If the VPN gateway for the Resource Manager VNet already has a Public IP address, use the value for the VPN
gateway IP address field. If you are doing these steps as an exercise, or don't yet have a virtual network
gateway for your Resource Manager VNet, you can make up a placeholder IP address. Make sure that the
placeholder IP address uses a valid format. Later, you replace the placeholder IP address with the Public IP
address of the Resource Manager virtual network gateway.
7. For Client Address Space, use the values for the virtual network IP address spaces for the Resource Manager
VNet. This setting is used to specify the address spaces to route to the Resource Manager virtual network.
8. Click OK to save the values and return to the New VPN Connection blade.
Part 2 - Create the virtual network gateway
1. On the New VPN Connection blade, select the Create gateway immediately checkbox and click
Optional gateway configuration to open the Gateway configuration blade.
2. Click Subnet - Configure required settings to open the Add subnet blade. The Name is already configured
with the required value GatewaySubnet.
3. The Address range refers to the range for the gateway subnet. Although you can create a gateway subnet
with a /29 address range (3 addresses), we recommend creating a gateway subnet that contains more IP
addresses. This will accommodate future configurations that may require more available IP addresses. If
possible, use /27 or /28. If you are using these steps as an exercise, you can refer to the Example values. Click
OK to create the gateway subnet.
4. On the Gateway configuration blade, Size refers to the gateway SKU. Select the gateway SKU for your VPN
gateway.
5. Verify the Routing Type is Dynamic, then click OK to return to the New VPN Connection blade.
6. On the New VPN Connection blade, click OK to begin creating your VPN gateway. Creating a VPN gateway
can take up to 45 minutes to complete.
Part 3 - Copy the virtual network gateway Public IP address
After the virtual network gateway has been created, you can view the gateway IP address.
1. Navigate to your classic VNet, and click Overview.
2. Click VPN connections to open the VPN connections blade. On the VPN connections blade, you can view the
Public IP address. This is the Public IP address assigned to your virtual network gateway.
3. Write down or copy the IP address. You use it in later steps when you work with your Resource Manager local
network gateway configuration settings. You can also view the status of your gateway connections. Notice the
local network site you created is listed as 'Connecting'. The status will change after you have created your
connections.
4. Close the blade after copying the gateway IP address.
2. Configure the Resource Manager VNet settings

In this section, you create the virtual network gateway and the local network gateway for your Resource Manager
VNet. If you don't have a Resource Manager VNet and are running these steps as an exercise, you can create a
VNet by using this article and the Example settings values from above.
Screenshots are provided as examples. Be sure to replace the values with your own, or use the Example values.
Part 1 - Create a gateway subnet
Before creating a virtual network gateway, you first need to create the gateway subnet. Create a gateway subnet
with CIDR count of /28 or larger. (/27, /26, etc.)
IMPORTANT
gateway.

Part 2 - Create a virtual network gateway
based VPN type.
you select.
Gateway currently only supports Dynamic Public IP address allocation. However, this does not mean that the
IP address changes after it has been assigned to your VPN gateway. The only time the Public IP address
changes is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other
internal maintenance/upgrades of your VPN gateway.
Part 3 - Create a local network gateway
The local network gateway specifies the address range and the Public IP address associated with your classic VNet
and its virtual network gateway.
If you are doing these steps as an exercise, refer to these settings:
CONNECTS TO LOCAL GATEWAY PUBLIC IP

VIRTUAL NETWORK ADDRESS SPACE REGION NETWORK SITE ADDRESS
ClassicVNet (10.0.0.0/24) West US RMVNetLocal The Public IP address

(192.168.0.0/16) that is assigned to
the ClassicVNet
gateway
RMVNet (192.168.0.0/16) East US ClassicVNetLocal The Public IP address

(10.0.0.0/24) that is assigned to
the RMVNet gateway.
1. In the portal, from All resources, click +Add. In the Everything blade search box, type Local network
gateway, then click to return a list of resources. Click Local network gateway to open the blade, then
click Create to open the Create local network gateway blade.
2. On the Create local network gateway blade, specify a Name for your local network gateway object. If
possible, use something intuitive, such as ClassicVNetLocal or TestVNet1Local. This makes it easier for
you to identify the local network gateway in the portal.
3. Specify a valid Public IP address for the VPN device or virtual network gateway to which you want to connect.
If this local network represents an on-premises location: Specify the Public IP address of the VPN device
that you want to connect to. It cannot be behind NAT and has to be reachable by Azure.
If this local network represents another VNet: Specify the Public IP address that was assigned to the
virtual network gateway for that VNet.
If you don't yet have the IP address: You can make up a valid placeholder IP address, and then come back
and modify this setting before connecting.
4. Address Space refers to the address ranges for the network that this local network represents. You can add
multiple address space ranges. Make sure that the ranges you specify here do not overlap with ranges of other
networks to which you connect.
5. For Subscription, verify that the correct subscription is showing.
6. For Resource Group, select the resource group that you want to use. You can either create a new resource
group, or select one that you have already created.
7. For Location, select the location in which this resource will be created. You may want to select the same
location that your VNet resides in, but you are not required to do so.
8. Click Create to create the local network gateway.
3. Modify the classic VNet local site settings

In this section, you replace the placeholder IP address that you used when specifying the local site settings, with
the Resource Manager VPN gateway IP address. This section uses the classic (SM) PowerShell cmdlets.
1. In the Azure portal, navigate to the classic virtual network.
2. On the blade for your virtual network, click Overview.
3. In the VPN connections section, click the name of your local site in the graphic.
4. On the Site-to-site VPN connections blade, click the name of the site.
5. On the connection blade for your local site, click the name of the local site to open the Local site blade.
6. On the Local site blade, replace the VPN gateway IP address with the IP address of the Resource
Manager gateway.
7. Click OK to update the IP address.
4. Create Resource Manager to classic connection

In these steps, you configure the connection from the Resource Manager VNet to the classic VNet using the Azure
portal.
1. In All resources, locate the local network gateway. In our example, the local network gateway is
ClassicVNetLocal.
2. Click Configuration and verify that the IP address value is the VPN gateway for the classic VNet. Update, if
needed, then click Save. Close the blade.
3. In All resources, click the local network gateway.
4. Click Connections to open the Connections blade.
5. On the Connections blade, click + to add a connection.
6. On the Add connection blade, name the connection. For example, 'RMtoClassic'.
7. Site-to-Site is already selected on this blade.
8. Select the virtual network gateway that you want to associate with this site.
9. Create a shared key. This key is also used in the connection that you create from the classic VNet to the
Resource Manager VNet. You can generate the key or make one up. In our example, we use 'abc123', but you
can (and should) use something more complex.
10. Click OK to create the connection.
5. Create classic to Resource Manager connection

In these steps, you configure the connection from the classic VNet to the Resource Manager VNet. These steps
require PowerShell. You can't create this connection in the portal. Make sure you have downloaded and installed
both the classic (SM) and Resource Manager (RM) PowerShell cmdlets.
1. Connect to your Azure account
Open the PowerShell console with elevated rights and log in to your Azure account. The following cmdlet
prompts you for the login credentials for your Azure Account. After logging in, your account settings are
downloaded so that they are available to Azure PowerShell.
Get a list of your Azure subscriptions if you have more than one subscription.

Add your Azure Account to use the classic PowerShell cmdlets (SM). To do so, you can use the following
command:
Add-AzureAccount
2. View the network configuration file values

When you create a VNet in the Azure portal, the full name that Azure uses is not visible in the Azure portal. For
example, a VNet that appears to be named 'ClassicVNet' in the Azure portal may have a much longer name in the
network configuration file. The name might look something like: 'Group ClassicRG ClassicVNet'. In these steps,
you download the network configuration file and view the values.
Create a directory on your computer and then export the network configuration file to the directory. In this
example, the network configuration file is exported to C:\AzureNet.
Open the file with a text editor and view the name for your classic VNet. Use the names in the network
configuration file when running your PowerShell cmdlets.
VNet names are listed as VirtualNetworkSite name =
Site names are listed as LocalNetworkSite name=
3. Create the connection
Set the shared key and create the connection from the classic VNet to the Resource Manager VNet. You cannot set
the shared key using the portal. Make sure you run these steps while logged in using the classic version of the
PowerShell cmdlets. To do so, use Add-AzureAccount. Otherwise, you will not be able to set the '-
AzureVNetGatewayKey'.
In this example, -VNetName is the name of the classic VNet as found in your network configuration file.
The -LocalNetworkSiteName is the name you specified for the local site, as found in your network
configuration file.
The -SharedKey is a value that you generate and specify. For this example, we used abc123, but you can
generate something more complex. The important thing is that the value you specify here must be the same
value that you specified when creating your Resource Manager to classic connection.
Set-AzureVNetGatewayKey -VNetName "Group ClassicRG ClassicVNet" `

-LocalNetworkSiteName "172B9E16_RMVNetLocal" -SharedKey abc123
6. Verify your connections

You can verify your connections by using the Azure portal or PowerShell. When verifying, you may need to wait a
minute or two as the connection is being created. When a connection is successful, the connectivity state changes
from 'Connecting' to 'Connected'.
To verify the connection from your classic VNet to your Resource Manager VNet
To verify the connection from your Resource Manager VNet to your classic VNet
VNet-to-VNet FAQ
Cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on
the source regions. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using
VNet Peering, rather than VPN Gateway, see the Virtual Network pricing page.
together.
Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the
Connect virtual networks from different deployment
models using PowerShell
This article shows you how to connect classic VNets to Resource Manager VNets to allow the resources located in
the separate deployment models to communicate with each other. The steps in this article use PowerShell, but you
can also create this configuration using the Azure portal by selecting the article from this list.
Connecting a classic VNet to a Resource Manager VNet is similar to connecting a VNet to an on-premises site
location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. You can create a
connection between VNets that are in different subscriptions and in different regions. You can also connect VNets
that already have connections to on-premises networks, as long as the gateway that they have been configured
with is dynamic or route-based. For more information about VNet-to-VNet connections, see the VNet-to-VNet
FAQ at the end of this article.
If your VNets are in the same region, you may want to instead consider connecting them using VNet Peering.
VNet peering does not use a VPN gateway. For more information, see VNet peering.
Before beginning
The following steps walk you through the settings necessary to configure a dynamic or route-based gateway for
each VNet and create a VPN connection between the gateways. This configuration does not support static or
policy-based gateways.
Prerequisites
Both VNets have already been created.
The address ranges for the VNets do not overlap with each other, or overlap with any of the ranges for other
connections that the gateways may be connected to.
You have installed the latest PowerShell cmdlets. See How to install and configure Azure PowerShell for more
information. Make sure you install both the Service Management (SM) and the Resource Manager (RM)
cmdlets.
Example settings
You can use these values to create a test environment, or refer to them to better understand the examples in this
article.
Classic VNet settings
VNet Name = ClassicVNet
Location = West US
Virtual Network Address Spaces = 10.0.0.0/24
Subnet-1 = 10.0.0.0/27
Local Network Name = RMVNetLocal
GatewayType = DynamicRouting
Resource Manager VNet settings
VNet Name = RMVNet
Resource Group = RG1
Virtual Network IP Address Spaces = 192.168.0.0/16
Subnet-1 = 192.168.1.0/24
Location = East US
Gateway public IP name = gwpip
Local Network Gateway = ClassicVNetLocal
Virtual Network Gateway name = RMGateway
Gateway IP addressing configuration = gwipconfig
Section 1 - Configure the classic VNet

Part 1 - Download your network configuration file
1. Log in to your Azure account in the PowerShell console with elevated rights. The following cmdlet prompts
you for the login credentials for your Azure Account. After logging in, it downloads your account settings so
that they are available to Azure PowerShell. You use the SM PowerShell cmdlets to complete this part of the
configuration.
Add-AzureAccount
2. Export your Azure network configuration file by running the following command. You can change the
location of the file to export to a different location if necessary.
3. Open the .xml file that you downloaded to edit it. For an example of the network configuration file, see the
Network Configuration Schema.
Part 2 -Verify the gateway subnet
In the VirtualNetworkSites element, add a gateway subnet to your VNet if one has not already been created.
When working with the network configuration file, the gateway subnet MUST be named "GatewaySubnet" or
Azure cannot recognize and use it as a gateway subnet.
IMPORTANT
Example:
<VirtualNetworkSites>
<VirtualNetworkSite name="ClassicVNet" Location="West US">
<AddressSpace>
<AddressPrefix>10.0.0.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
</Subnet>
<Subnet name="GatewaySubnet">
</Subnet>
</Subnets>
</VirtualNetworkSite>
</VirtualNetworkSites>
Part 3 - Add the local network site
The local network site you add represents the RM VNet to which you want to connect. Add a LocalNetworkSites
element to the file if one doesn't already exist. At this point in the configuration, the VPNGatewayAddress can be
any valid public IP address because we haven't yet created the gateway for the Resource Manager VNet. Once we
create the gateway, we replace this placeholder IP address with the correct public IP address that has been
assigned to the RM gateway.
<LocalNetworkSites>
<LocalNetworkSite name="RMVNetLocal">
<AddressSpace>
</AddressSpace>
<VPNGatewayAddress>13.68.210.16</VPNGatewayAddress>
</LocalNetworkSite>
</LocalNetworkSites>
Part 4 - Associate the VNet with the local network site

In this section, we specify the local network site that you want to connect the VNet to. In this case, it is the
Resource Manager VNet that you referenced earlier. Make sure the names match. This step does not create a
gateway. It specifies the local network that the gateway will connect to.
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="RMVNetLocal">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
Part 5 - Save the file and upload

Save the file, then import it to Azure by running the following command. Make sure you change the file path as
necessary for your environment.
Set-AzureVNetConfig -ConfigurationPath C:\AzureNet\NetworkConfig.xml
You will see a similar result showing that the import succeeded.
OperationDescription OperationId OperationStatus

-------------------- ----------- ---------------
Set-AzureVNetConfig e0ee6e66-9167-cfa7-a746-7casb9 Succeeded
Part 6 - Create the gateway

Before running this example, refer to the network configuration file that you downloaded for the exact names that
Azure expects to see. The network configuration file contains the values for your classic virtual networks.
Sometimes the names for classic VNets are changed in the network configuration file when creating classic VNet
settings in the Azure portal due to the differences in the deployment models. For example, if you used the Azure
portal to create a classic VNet named 'Classic VNet' and created it in a resource group named 'ClassicRG', the
name that is contained in the network configuration file is converted to 'Group ClassicRG Classic VNet'. When
specifying the name of a VNet that contains spaces, use quotation marks around the value.
Use the following example to create a dynamic routing gateway:
New-AzureVNetGateway -VNetName ClassicVNet -GatewayType DynamicRouting
You can check the status of the gateway by using the Get-AzureVNetGateway cmdlet.
Section 2: Configure the RM VNet gateway

To create a VPN gateway for the RM VNet, follow the following instructions. Don't start the steps until after you
have retrieved the public IP address for the classic VNet's gateway.
1. Log in to your Azure account in the PowerShell console. The following cmdlet prompts you for the login
credentials for your Azure Account. After logging in, your account settings are downloaded so that they are
available to Azure PowerShell.
Get a list of your Azure subscriptions if you have more than one subscription.
2. Create a local network gateway. In a virtual network, the local network gateway typically refers to your on-
premises location. In this case, the local network gateway refers to your Classic VNet. Give it a name by
which Azure can refer to it, and also specify the address space prefix. Azure uses the IP address prefix you
specify to identify which traffic to send to your on-premises location. If you need to adjust the information
here later, before creating your gateway, you can modify the values and run the sample again.
-Name is the name you want to assign to refer to the local network gateway.
-AddressPrefix is the Address Space for your classic VNet.
-GatewayIpAddress is the public IP address of the classic VNet's gateway. Be sure to change the following
sample to reflect the correct IP address.
New-AzureRmLocalNetworkGateway -Name ClassicVNetLocal `

-Location "West US" -AddressPrefix "10.0.0.0/24" `
-GatewayIpAddress "n.n.n.n" -ResourceGroupName RG1
3. Request a public IP address to be allocated to the virtual network gateway for the Resource Manager VNet.
You can't specify the IP address that you want to use. The IP address is dynamically allocated to the virtual
network gateway. However, this does not mean the IP address changes. The only time the virtual network
gateway IP address changes is when the gateway is deleted and recreated. It doesn't change across resizing,
resetting, or other internal maintenance/upgrades of the gateway.
In this step, we also set a variable that is used in a later step.
$ipaddress = New-AzureRmPublicIpAddress -Name gwpip `

-ResourceGroupName RG1 -Location 'EastUS' `
-AllocationMethod Dynamic
4. Verify that your virtual network has a gateway subnet. If no gateway subnet exists, add one. Make sure the
gateway subnet is named GatewaySubnet.
5. Retrieve the subnet used for the gateway by running the following command. In this step, we also set a
variable to be used in the next step.
-Name is the name of your Resource Manager VNet.
-ResourceGroupName is the resource group that the VNet is associated with. The gateway subnet must
already exist for this VNet and must be named GatewaySubnet to work properly.
$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name GatewaySubnet `

-VirtualNetwork (Get-AzureRmVirtualNetwork -Name RMVNet -ResourceGroupName RG1)
6. Create the gateway IP addressing configuration. The gateway configuration defines the subnet and the
public IP address to use. Use the following sample to create your gateway configuration.
In this step, the -SubnetId and -PublicIpAddressId parameters must be passed the id property from the
subnet, and IP address objects, respectively. You can't use a simple string. These variables are set in the step
to request a public IP and the step to retrieve the subnet.
$gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig `
-Name gwipconfig -SubnetId $subnet.id `
-PublicIpAddressId $ipaddress.id
7. Create the Resource Manager virtual network gateway by running the following command. The -VpnType
must be RouteBased. It can take 45 minutes or more for the gateway to create.
New-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1 `

-Location "EastUS" -GatewaySKU Standard -GatewayType Vpn `
-IpConfigurations $gwipconfig `
-EnableBgp $false -VpnType RouteBased
8. Copy the public IP address once the VPN gateway has been created. You use it when you configure the
local network settings for your Classic VNet. You can use the following cmdlet to retrieve the public IP
address. The public IP address is listed in the return as IpAddress.
Get-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName RG1
Section 3: Modify the classic VNet local site settings

In this section, you work with the classic VNet. You replace the placeholder IP address that you used when
specifying the local site settings that will be used to connect to the Resource Manager VNet gateway.
1. Export the network configuration file.
2. Using a text editor, modify the value for VPNGatewayAddress. Replace the placeholder IP address with the
public IP address of the Resource Manager gateway and then save the changes.
3. Import the modified network configuration file to Azure.

Section 4: Create a connection between the gateways

Creating a connection between the gateways requires PowerShell. You may need to add your Azure Account to
use the classic version of the PowerShell cmdlets. To do so, use Add-AzureAccount.
1. In the PowerShell console, set your shared key. Before running the cmdlets, refer to the network
configuration file that you downloaded for the exact names that Azure expects to see. When specifying the
name of a VNet that contains spaces, use single quotation marks around the value.
In following example, -VNetName is the name of the classic VNet and -LocalNetworkSiteName is the
name you specified for the local network site. The -SharedKey is a value that you generate and specify. In
the example, we used 'abc123', but you can generate and use something more complex. The important
thing is that the value you specify here must be the same value that you specify in the next step when you
create your connection. The return should show Status: Successful.
Set-AzureVNetGatewayKey -VNetName ClassicVNet `

-LocalNetworkSiteName RMVNetLocal -SharedKey abc123
2. Create the VPN connection by running the following commands:

Set the variables.
$vnet01gateway = Get-AzureRMLocalNetworkGateway -Name ClassicVNetLocal -ResourceGroupName RG1

$vnet02gateway = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1
Create the connection. Notice that the -ConnectionType is IPsec, not Vnet2Vnet.
New-AzureRmVirtualNetworkGatewayConnection -Name RM-Classic -ResourceGroupName RG1 `

-Location "East US" -VirtualNetworkGateway1 `
$vnet02gateway -LocalNetworkGateway2 `
$vnet01gateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Section 5: Verify your connections

To verify the connection from your classic VNet to your Resource Manager VNet
PowerShell
You can verify that your connection succeeded by using the 'Get-AzureVNetConnection' cmdlet.
1. Use the following cmdlet example, configuring the values to match your own. The name of the virtual
network must be in quotes if it contains spaces.
Get-AzureVNetConnection "Group ClassicRG ClassicVNet"
2. After the cmdlet has finished, view the values. In the example below, the Connectivity State shows as
ConnectivityState : Connected
EgressBytesTransferred : 181664
IngressBytesTransferred : 182080
LastConnectionEstablished : 1/7/2016 12:40:54 AM
LastEventID : 24401
LastEventMessage : The connectivity state for the local network site 'RMVNetLocal' changed
from Connecting to
Connected.
LastEventTimeStamp : 1/7/2016 12:40:54 AM
LocalNetworkSiteName : RMVNetLocal
Azure portal
To verify the connection from your Resource Manager VNet to your classic VNet
PowerShell
Azure portal
VNet-to-VNet FAQ
together.
Configure ExpressRoute and Site-to-Site coexisting
connections
Configuring Site-to-Site VPN and ExpressRoute coexisting connections has several advantages. You can configure
a Site-to-Site VPN as a secure failover path for ExressRoute, or use Site-to-Site VPNs to connect to sites that are
not connected through ExpressRoute. We cover the steps to configure both scenarios in this article. This article
applies to the Resource Manager deployment model and uses PowerShell. This configuration is not available in the
Azure portal.
IMPORTANT
ExpressRoute circuits must be pre-configured before you follow the instructions below. Make sure that you have followed
the guides to create an ExpressRoute circuit and configure routing before you proceed.
Limits and limitations

Transit routing is not supported. You cannot route (via Azure) between your local network connected via
Site-to-Site VPN and your local network connected via ExpressRoute.
Basic SKU gateway is not supported. You must use a non-Basic SKU gateway for both the ExpressRoute
gateway and the VPN gateway.
Only route-based VPN gateway is supported. You must use a route-based VPN Gateway.
Static route should be configured for your VPN gateway. If your local network is connected to both
ExpressRoute and a Site-to-Site VPN, you must have a static route configured in your local network to route the
Site-to-Site VPN connection to the public Internet.
ExpressRoute gateway must be configured first and linked to a circuit. You must create the ExpressRoute
gateway first and link it to a circuit before you add the Site-to-Site VPN gateway.
Configuration designs
Configure a Site -to -Site VPN as a failover path for ExpressRoute
You can configure a Site-to-Site VPN connection as a backup for ExpressRoute. This applies only to virtual
networks linked to the Azure private peering path. There is no VPN-based failover solution for services accessible
through Azure public and Microsoft peerings. The ExpressRoute circuit is always the primary link. Data flows
through the Site-to-Site VPN path only if the ExpressRoute circuit fails.
NOTE
While ExpressRoute circuit is preferred over Site-to-Site VPN when both routes are the same, Azure will use the longest prefix
match to choose the route towards the packet's destination.
Configure a Site -to -Site VPN to connect to sites not connected through ExpressRoute
You can configure your network where some sites connect directly to Azure over Site-to-Site VPN, and some sites
connect through ExpressRoute.
NOTE
You cannot configure a virtual network as a transit router.
Selecting the steps to use

There are two different sets of procedures to choose from. The configuration procedure that you select depends on
whether you have an existing virtual network that you want to connect to, or you want to create a new virtual
network.
I don't have a VNet and need to create one.
If you dont already have a virtual network, this procedure walks you through creating a new virtual network
using Resource Manager deployment model and creating new ExpressRoute and Site-to-Site VPN
connections. To configure a virtual network, follow the steps in To create a new virtual network and
coexisting connections.
I already have a Resource Manager deployment model VNet.
You may already have a virtual network in place with an existing Site-to-Site VPN connection or
ExpressRoute connection. The To configure coexisting connections for an already existing VNet section
walks you through deleting the gateway, and then creating new ExpressRoute and Site-to-Site VPN
connections. When creating the new connections, the steps must be completed in a specific order. Don't use
the instructions in other articles to create your gateways and connections.
In this procedure, creating connections that can coexist requires you to delete your gateway, and then
configure new gateways. You will have downtime for your cross-premises connections while you delete and
recreate your gateway and connections, but you will not need to migrate any of your VMs or services to a
new virtual network. Your VMs and services will still be able to communicate out through the load balancer
while you configure your gateway if they are configured to do so.
To create a new virtual network and coexisting connections

This procedure walks you through creating a VNet and Site-to-Site and ExpressRoute connections that will coexist.
1. Install the latest version of the Azure PowerShell cmdlets. For information about installing the cmdlets, see How
to install and configure Azure PowerShell. The cmdlets that you use for this configuration may be slightly
different than what you might be familiar with. Be sure to use the cmdlets specified in these instructions.
2. Log in to your account and set up the environment.
login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionName 'yoursubscription'
$location = "Central US"
$resgrp = New-AzureRmResourceGroup -Name "ErVpnCoex" -Location $location
$VNetASN = 65010
3. Create a virtual network including Gateway Subnet. For more information about the virtual network
configuration, see Azure Virtual Network configuration.
IMPORTANT
The Gateway Subnet must be /27 or a shorter prefix (such as /26 or /25).
Create a new VNet.
$vnet = New-AzureRmVirtualNetwork -Name "CoexVnet" -ResourceGroupName $resgrp.ResourceGroupName -

Location $location -AddressPrefix "10.200.0.0/16"
Add subnets.
Add-AzureRmVirtualNetworkSubnetConfig -Name "App" -VirtualNetwork $vnet -AddressPrefix "10.200.1.0/24"

Add-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet -AddressPrefix
"10.200.255.0/24"
Save the VNet configuration.
$vnet = Set-AzureRmVirtualNetwork -VirtualNetwork $vnet
4. Create an ExpressRoute gateway. For more information about the ExpressRoute gateway configuration, see
ExpressRoute gateway configuration. The GatewaySKU must be Standard, HighPerformance, or
UltraPerformance.
$gwSubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
$gwIP = New-AzureRmPublicIpAddress -Name "ERGatewayIP" -ResourceGroupName $resgrp.ResourceGroupName -
Location $location -AllocationMethod Dynamic
$gwConfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name "ERGatewayIpConfig" -SubnetId $gwSubnet.Id -
PublicIpAddressId $gwIP.Id
$gw = New-AzureRmVirtualNetworkGateway -Name "ERGateway" -ResourceGroupName $resgrp.ResourceGroupName -
Location $location -IpConfigurations $gwConfig -GatewayType "ExpressRoute" -GatewaySku Standard
5. Link the ExpressRoute gateway to the ExpressRoute circuit. After this step has been completed, the
connection between your on-premises network and Azure, through ExpressRoute, is established. For more
information about the link operation, see Link VNets to ExpressRoute.
$ckt = Get-AzureRmExpressRouteCircuit -Name "YourCircuit" -ResourceGroupName "YourCircuitResourceGroup"

New-AzureRmVirtualNetworkGatewayConnection -Name "ERConnection" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -VirtualNetworkGateway1 $gw -PeerId $ckt.Id -
ConnectionType ExpressRoute
6. Next, create your Site-to-Site VPN gateway. For more information about the VPN gateway configuration,
see Configure a VNet with a Site-to-Site connection. The GatewaySKU must be Standard, HighPerformance,
or UltraPerformance. The VpnType must RouteBased.
$gwSubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet

$gwIP = New-AzureRmPublicIpAddress -Name "VPNGatewayIP" -ResourceGroupName $resgrp.ResourceGroupName -
Location $location -AllocationMethod Dynamic
$gwConfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name "VPNGatewayIpConfig" -SubnetId $gwSubnet.Id
-PublicIpAddressId $gwIP.Id
New-AzureRmVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName $resgrp.ResourceGroupName -
Location $location -IpConfigurations $gwConfig -GatewayType "Vpn" -VpnType "RouteBased" -GatewaySku
"Standard"
Azure VPN gateway supports BGP routing protocol. You can specify ASN (AS Number) for that Virtual
Network by adding the -Asn switch in the following command. Not specifying that parameter will default to
AS number 65515.
$azureVpn = New-AzureRmVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName

$resgrp.ResourceGroupName -Location $location -IpConfigurations $gwConfig -GatewayType "Vpn" -VpnType
"RouteBased" -GatewaySku "Standard" -Asn $VNetASN
You can find the BGP peering IP and the AS number that Azure uses for the VPN gateway in
$azureVpn.BgpSettings.BgpPeeringAddress and $azureVpn.BgpSettings.Asn. For more information, see
Configure BGP for Azure VPN gateway.
7. Create a local site VPN gateway entity. This command doesnt configure your on-premises VPN gateway.
Rather, it allows you to provide the local gateway settings, such as the public IP and the on-premises
address space, so that the Azure VPN gateway can connect to it.
If your local VPN device only supports static routing, you can configure the static routes in the following
way:
$MyLocalNetworkAddress = @("10.100.0.0/16","10.101.0.0/16","10.102.0.0/16")
$localVpn = New-AzureRmLocalNetworkGateway -Name "LocalVPNGateway" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -GatewayIpAddress *<Public IP>* -AddressPrefix
$MyLocalNetworkAddress
If your local VPN device supports the BGP and you want to enable dynamic routing, you need to know the
BGP peering IP and the AS number that your local VPN device uses.
$localVPNPublicIP = "<Public IP>"

$localBGPPeeringIP = "<Private IP for the BGP session>"
$localBGPASN = "<ASN>"
$localAddressPrefix = $localBGPPeeringIP + "/32"
$localVpn = New-AzureRmLocalNetworkGateway -Name "LocalVPNGateway" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -GatewayIpAddress $localVPNPublicIP -AddressPrefix
$localAddressPrefix -BgpPeeringAddress $localBGPPeeringIP -Asn $localBGPASN
8. Configure your local VPN device to connect to the new Azure VPN gateway. For more information about VPN
device configuration, see VPN Device Configuration.
9. Link the Site-to-Site VPN gateway on Azure to the local gateway.
$azureVpn = Get-AzureRmVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName

$resgrp.ResourceGroupName
New-AzureRmVirtualNetworkGatewayConnection -Name "VPNConnection" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -VirtualNetworkGateway1 $azureVpn -LocalNetworkGateway2
$localVpn -ConnectionType IPsec -SharedKey <yourkey>
To configure coexisting connections for an already existing VNet

If you have an existing virtual network, check the gateway subnet size. If the gateway subnet is /28 or /29, you
must first delete the virtual network gateway and increase the gateway subnet size. The steps in this section show
you how to do that.
If the gateway subnet is /27 or larger and the virtual network is connected via ExpressRoute, you can skip the steps
below and proceed to "Step 6 - Create a Site-to-Site VPN gateway" in the previous section.
NOTE
When you delete the existing gateway, your local premises will lose the connection to your virtual network while you are
working on this configuration.
1. You'll need to install the latest version of the Azure PowerShell cmdlets. For more information about installing
cmdlets, see How to install and configure Azure PowerShell. The cmdlets that you use for this configuration
may be slightly different than what you might be familiar with. Be sure to use the cmdlets specified in these
instructions.
2. Delete the existing ExpressRoute or Site-to-Site VPN gateway.
Remove-AzureRmVirtualNetworkGateway -Name <yourgatewayname> -ResourceGroupName <yourresourcegroup>
3. Delete Gateway Subnet.
$vnet = Get-AzureRmVirtualNetwork -Name <yourvnetname> -ResourceGroupName <yourresourcegroup> Remove-

AzureRmVirtualNetworkSubnetConfig -Name GatewaySubnet -VirtualNetwork $vnet
4. Add a Gateway Subnet that is /27 or larger.

NOTE
If you don't have enough IP addresses left in your virtual network to increase the gateway subnet size, you need to
add more IP address space.
$vnet = Get-AzureRmVirtualNetwork -Name <yourvnetname> -ResourceGroupName <yourresourcegroup>

Add-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet -AddressPrefix
"10.200.255.0/24"
Save the VNet configuration.
$vnet = Set-AzureRmVirtualNetwork -VirtualNetwork $vnet
5. At this point, you have a VNet with no gateways. To create new gateways and complete your connections, you
can proceed with Step 4 - Create an ExpressRoute gateway, found in the preceding set of steps.
To add point-to-site configuration to the VPN gateway

You can follow the steps below to add Point-to-Site configuration to your VPN gateway in a co-existence setup.
1. Add VPN Client address pool.
$azureVpn = Get-AzureRmVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName

$resgrp.ResourceGroupName
Set-AzureRmVirtualNetworkGatewayVpnClientConfig -VirtualNetworkGateway $azureVpn -VpnClientAddressPool
"10.251.251.0/24"
2. Upload the VPN root certificate to Azure for your VPN gateway. In this example, it's assumed that the root
certificate is stored in the local machine where the following PowerShell cmdlets are run.
$p2sCertFullName = "RootErVpnCoexP2S.cer"
$p2sCertMatchName = "RootErVpnCoexP2S"
$p2sCertToUpload=get-childitem Cert:\CurrentUser\My | Where-Object {$_.Subject -match
$p2sCertMatchName}
if ($p2sCertToUpload.count -eq 1){write-host "cert found"} else {write-host "cert not found" exit}
$p2sCertData = [System.Convert]::ToBase64String($p2sCertToUpload.RawData) Add-
AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $p2sCertFullName -
VirtualNetworkGatewayname $azureVpn.Name -ResourceGroupName $resgrp.ResourceGroupName -PublicCertData
$p2sCertData
For more information on Point-to-Site VPN, see Configure a Point-to-Site connection.
Next steps
For more information about ExpressRoute, see the ExpressRoute FAQ.
Add a Site-to-Site connection to a VNet with an
existing VPN gateway connection
This article walks you through using the Azure portal to add Site-to-Site (S2S) connections to a VPN gateway that
has an existing connection. This type of connection is often referred to as a "multi-site" configuration. You can add
a S2S connection to a VNet that already has a S2S connection, Point-to-Site connection, or VNet-to-VNet
connection. There are some limitations when adding connections. Check the Before you begin section in this article
to verify before you start your configuration.
This article applies to VNets created using the Resource Manager deployment model that have a RouteBased VPN
gateway. These steps do not apply to ExpressRoute/Site-to-Site coexisting connection configurations. See
ExpressRoute/S2S coexisting connections for information about coexisting connections.
Deployment models and methods
Azure currently works with two deployment models: Resource Manager and classic. The two models are not
completely compatible with each other. Before you begin, you need to know which model that you want to work
in. For information about the deployment models, see Understanding deployment models. If you are new to Azure,
we recommend that you use the Resource Manager deployment model.
We update this table as new articles and additional tools become available for this configuration. When an article
is available, we link directly to it from this table.
DEPLOYMENT
Resource Manager Article Not Supported Supported
Classic Not Supported Not Supported Article
Before you begin

Verify the following items:
You are not creating an ExpressRoute/S2S coexisting connection.
You have a virtual network that was created using the Resource Manager deployment model with an existing
connection.
The virtual network gateway for your VNet is RouteBased. If you have a PolicyBased VPN gateway, you must
delete the virtual network gateway and create a new VPN gateway as RouteBased.
None of the address ranges overlap for any of the VNets that this VNet is connecting to.
You have compatible VPN device and someone who is able to configure it. See About VPN Devices. If you aren't
familiar with configuring your VPN device, or are unfamiliar with the IP address ranges located in your on-
premises network configuration, you need to coordinate with someone who can provide those details for you.
You have an externally facing public IP address for your VPN device. This IP address cannot be located behind a
NAT.
Part 1 - Configure a connection

2. Click All resources and locate your virtual network gateway from the list of resources and click it.
3. On the Virtual network gateway blade, click Connections.
4. On the Connections blade, click +Add.
5. On the Add connection blade, fill out the following fields:

Name: The name you want to give to the site you are creating the connection to.
Connection type: Select Site-to-site (IPsec).
Part 2 - Add a local network gateway
1. Click Local network gateway Choose a local network gateway. This will open the Choose local
network gateway blade.
2. Click Create new to open the Create local network gateway blade.
3. On the Create local network gateway blade, fill out the following fields:
Name: The name you want to give to the local network gateway resource.
IP address: The public IP address of the VPN device on the site that you want to connect to.
Address space: The address space that you want to be routed to the new local network site.
4. Click OK on the Create local network gateway blade to save the changes.
Part 3 - Add the shared key and create the connection

1. On the Add connection blade, add the shared key that you want to use to create your connection. You can
either get the shared key from your VPN device, or make one up here and then configure your VPN device
to use the same shared key. The important thing is that the keys are exactly the same.
2. At the bottom of the blade, click OK to create the connection.
Part 4 - Verify the VPN connection

Next steps
Once your connection is complete, you can add virtual machines to your virtual networks. See the virtual machines
learning path for more information.
Add a Site-to-Site connection to a VNet with an
existing VPN gateway connection (classic)
This article walks you through using PowerShell to add Site-to-Site (S2S) connections to a VPN gateway that has
an existing connection. This type of connection is often referred to as a "multi-site" configuration. The steps in this
article apply to virtual networks created using the classic deployment model (also known as Service
Management). These steps do not apply to ExpressRoute/Site-to-Site coexisting connection configurations.
Deployment models and methods
in. For information about the deployment models, see Understanding deployment models. If you are new to
Azure, we recommend that you use the Resource Manager deployment model.
We update this table as new articles and additional tools become available for this configuration. When an article
is available, we link directly to it from this table.
DEPLOYMENT
Resource Manager Article Not Supported Supported
Classic Not Supported Not Supported Article
About connecting
You can connect multiple on-premises sites to a single virtual network. This is especially attractive for building
hybrid cloud solutions. Creating a multi-site connection to your Azure virtual network gateway is similar to
creating other Site-to-Site connections. In fact, you can use an existing Azure VPN gateway, as long as the gateway
is dynamic (route-based).
If you already have a static gateway connected to your virtual network, you can change the gateway type to
dynamic without needing to rebuild the virtual network in order to accommodate multi-site. Before changing the
routing type, make sure that your on-premises VPN gateway supports route-based VPN configurations.
Points to consider
You won't be able to use the portal to make changes to this virtual network. You need to make changes to
the network configuration file instead of using the portal. If you make changes in the portal, they'll overwrite your
multi-site reference settings for this virtual network.
You should feel comfortable using the network configuration file by the time you've completed the multi-site
procedure. However, if you have multiple people working on your network configuration, you'll need to make
sure that everyone knows about this limitation. This doesn't mean that you can't use the portal at all. You can use
it for everything else, except making configuration changes to this particular virtual network.
Before you begin

Before you begin configuration, verify that you have the following:
Compatible VPN hardware for each on-premises location. Check About VPN Devices for Virtual Network
Connectivity to verify if the device that you want to use is something that is known to be compatible.
An externally facing public IPv4 IP address for each VPN device. The IP address cannot be located behind a
NAT. This is requirement.
You'll need to install the latest version of the Azure PowerShell cmdlets. Make sure you install the Service
Management (SM) version in addition to the Resource Manager version. See How to install and configure
Azure PowerShell for more information.
Someone who is proficient at configuring your VPN hardware. You'll have to have a strong understanding of
how to configure your VPN device, or work with someone who does.
The IP address ranges that you want to use for your virtual network (if you haven't already created one).
The IP address ranges for each of the local network sites that you'll be connecting to. You'll need to make sure
that the IP address ranges for each of the local network sites that you want to connect to do not overlap.
Otherwise, the portal or the REST API will reject the configuration being uploaded.
For example, if you have two local network sites that both contain the IP address range 10.2.3.0/24 and you
have a package with a destination address 10.2.3.3, Azure wouldn't know which site you want to send the
package to because the address ranges are overlapping. To prevent routing issues, Azure doesn't allow you to
upload a configuration file that has overlapping ranges.
1. Create a Site-to-Site VPN

If you already have a Site-to-Site VPN with a dynamic routing gateway, great! You can proceed to Export the
virtual network configuration settings. If not, do the following:
If you already have a Site -to -Site virtual network, but it has a static (policy-based) routing gateway:
1. Change your gateway type to dynamic routing. A multi-site VPN requires a dynamic (also known as route-
based) routing gateway. To change your gateway type, you'll need to first delete the existing gateway, then
create a new one. For instructions, see How to change the VPN routing type for your gateway.
2. Configure your new gateway and create your VPN tunnel. For instructions, see Configure a VPN Gateway in
the Azure Classic Portal. First, change your gateway type to dynamic routing.
If you don't have a Site -to -Site virtual network:
1. Create your Site-to-Site virtual network using these instructions: Create a Virtual Network with a Site-to-Site
VPN Connection in the Azure Classic Portal.
2. Configure a dynamic routing gateway using these instructions: Configure a VPN Gateway. Be sure to select
dynamic routing for your gateway type.
2. Export the network configuration file

Export your Azure network configuration file by running the following command. You can change the location of
the file to export to a different location if necessary.
3. Open the network configuration file

Open the network configuration file that you downloaded in the last step. Use any xml editor that you like. The file
should look similar to the following:
<NetworkConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<LocalNetworkSites>
<LocalNetworkSite name="Site1">
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
<VirtualNetworkSites>
<VirtualNetworkSite name="VNet1" AffinityGroup="USWest">
<AddressSpace>
</AddressSpace>
<Subnets>
<Subnet name="FE">
</Subnet>
<Subnet name="BE">
</Subnet>
</Subnet>
</Subnets>
<Gateway>
<LocalNetworkSiteRef name="Site1">
</Gateway>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>
4. Add multiple site references

When you add or remove site reference information, you'll make configuration changes to the
ConnectionsToLocalNetwork/LocalNetworkSiteRef. Adding a new local site reference triggers Azure to create a
new tunnel. In the example below, the network configuration is for a single-site connection. Save the file once you
have finished making your changes.
<Gateway>
<LocalNetworkSiteRef name="Site1"><Connection type="IPsec" /></LocalNetworkSiteRef>
</Gateway>
To add additional site references (create a multi-site configuration), simply add additional "LocalNetworkSiteRef"
lines, as shown in the example below:
<Gateway>
</Gateway>
5. Import the network configuration file

Import the network configuration file. When you import this file with the changes, the new tunnels will be added.
The tunnels will use the dynamic gateway that you created earlier. You can either use the classic portal, or
PowerShell to import the file.
6. Download keys
Once your new tunnels have been added, use the PowerShell cmdlet 'Get-AzureVNetGatewayKey' to get the
IPsec/IKE pre-shared keys for each tunnel.
For example:
Get-AzureVNetGatewayKey VNetName "VNet1" LocalNetworkSiteName "Site1"

Get-AzureVNetGatewayKey VNetName "VNet1" LocalNetworkSiteName "Site2"
If you prefer, you can also use the Get Virtual Network Gateway Shared Key REST API to get the pre-shared keys.
7. Verify your connections

Check the multi-site tunnel status. After downloading the keys for each tunnel, you'll want to verify connections.
Use 'Get-AzureVnetConnection' to get a list of virtual network tunnels, as shown in the example below. VNet1 is
the name of the VNet.
Get-AzureVnetConnection -VNetName VNET1
Example return:
LastConnectionEstablished : 5/2/2014 2:51:40 PM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site 'Site1' changed from Not
Connected to Connected.
LastEventTimeStamp : 5/2/2014 2:51:40 PM
LocalNetworkSiteName : Site1
OperationDescription : Get-AzureVNetConnection
OperationId : 7f68a8e6-51e9-9db4-88c2-16b8067fed7f
OperationStatus : Succeeded
LastConnectionEstablished : 5/2/2014 3:20:40 PM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site 'Site2' changed from Not
Connected to Connected.
LastEventTimeStamp : 5/2/2014 2:51:40 PM
LocalNetworkSiteName : Site2
OperationDescription : Get-AzureVNetConnection
OperationId : 7893b329-51e9-9db4-88c2-16b8067fed7f
OperationStatus : Succeeded
Next steps
To learn more about VPN Gateways, see About VPN Gateways.
Connect Azure VPN gateways to multiple on-
premises policy-based VPN devices using PowerShell
This article walks you through the steps to configure an Azure route-based VPN gateway to connect to multiple
on-premises poilcy-based VPN devices leveraging custom IPsec/IKE policies on S2S VPN connections.
About policy-based and route-based VPN gateways

Policy- vs. route-based VPN devices differ in how the IPsec traffic selectors are set on a connection:
Policy-based VPN devices use the combinations of prefixes from both networks to define how traffic is
encrypted/decrypted through IPsec tunnels. It is typically built on firewall devices that perform packet filtering.
IPsec tunnel encryption and decryption are added to the packet filtering and processing engine.
Route-based VPN devices use any-to-any (wildcard) traffic selectors, and let routing/forwarding tables direct
traffic to different IPsec tunnels. It is typically built on router platforms where each IPsec tunnel is modeled as a
network interface or VTI (virtual tunnel interface).
The following diagrams highlight the two models:
Policy-based VPN example
Route -based VPN example
Azure support for policy-based VPN

Currently, Azure supports both modes of VPN gateways: route-based VPN gateways and policy-based VPN
gateways. They are built on different internal platforms which result in different specifications:
POLICYBASED VPN GATEWAY ROUTEBASED VPN GATEWAY
Azure Gateway SKU Basic Basic, Standard, HighPerformance
IKE version IKEv1 IKEv2
Max. S2S connections 1 Basic/Standard:10

HighPerformance:30
With the custom IPsec/IKE policy, you can now configure Azure route-based VPN gateways to use prefix-based
traffic selectors with option "PolicyBasedTrafficSelectors", to connect to on-premises policy-based VPN devices.
This capability allows you to connect from an Azure virtual network and VPN gateway to multiple on-premises
policy-based VPN/firewall devices, removing the single connection limit from the current Azure policy-based VPN
gateways.
IMPORTANT
1. To enable this connectivity, your on-premises policy-based VPN devices must support IKEv2 to connect to the Azure
route-based VPN gateways. Please check with your VPN device specifications.
2. The on-premises networks connecting through policy-based VPN devices with this mechanism can only connect to the
Azure virtual network; cannot transit to other on-premises networks or virtual networks via the same Azure VPN
gateway.
3. The configuration option is part of the custom IPsec/IKE connection policy. You must specify the complete policy
(IPsec/IKE encryption and integrity algorithms, key strengths, and SA lifetimes) if you enable the policy-based traffic
selector option.
The diagram below shows why transit routing via Azure VPN gateway will not work with the policy-based option.
As shown in the diagram, the Azure VPN gateway will have traffic selectors from the virtual network to each on-
premises network prefixes, but not the cross-connection prefixes. E.g., on-premises site 2, site 3, and site 4 can
each communicate to VNet1 respectively, but cannot connect via the Azure VPN gateway to each other. The
diagram shows the cross-connect traffic selectors that are not available in the Azure VPN gateway under this
configuration.
Configure policy-based traffic selectors on a connection

The instructions in this article follow the same example as described in Configure IPsec/IKE policy for S2S or VNet-
to-VNet connections, to establish a S2S VPN connection as shown in the diagram below:
The workflow to enable this conectivity:
1. Create the virtual network, VPN gateway, and local network gateway for your cross-premises connection
3. Apply the policy when you create a S2S or VNet-to-VNet connection, and enable the policy-based traffic
selectors on the connection
4. If the connection is already created, you can apply or update the policy to an existing connection
Enable policy-based traffic selectors on a connection

Please make sure you have completed Part 3 of the Configure IPsec/IKE policy article for this section. The sample
below uses the same parameters and steps.
Step 1 - Create the virtual network, VPN gateway, and local network gateway
1. Declare your variables & connect to your subscription
For this exercise, we'll start by declaring our variables. Be sure to replace the values with your own when
configuring for production.
$Sub1 = "<YourSubscriptionName>"
$RG1 = "TestPolicyRG1"
$Location1 = "East US 2"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$DNS1 = "8.8.8.8"
$GW1IPName1 = "VNet1GWIP1"
$GW1IPconf1 = "gw1ipconf1"
$Connection16 = "VNet1toSite6"
$LNGName6 = "Site6"
$LNGPrefix61 = "10.61.0.0/16"
$LNGPrefix62 = "10.62.0.0/16"
$LNGIP6 = "131.107.72.22"
Make sure you switch to PowerShell mode to use the Resource Manager cmdlets. For more information, see Using
Windows PowerShell with Resource Manager.
Open your PowerShell console and connect to your account. Use the following sample to help you connect:
2. Create the virtual network, VPN gateway, and local network gateway
The sample below creates the virtual network, TestVNet1, with three subnets, and the VPN gateway. When
substituting values, it's important that you always name your gateway subnet specifically GatewaySubnet. If you
name it something else, your gateway creation will fail.

New-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 -Location $Location1 -AddressPrefix

$VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1
$gw1pip1 = New-AzureRmPublicIpAddress -Name $GW1IPName1 -ResourceGroupName $RG1 -Location $Location1 -

$gw1ipconf1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GW1IPconf1 -Subnet $subnet1 -PublicIpAddress
$gw1pip1
New-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 -Location $Location1 -IpConfigurations

$gw1ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance
New-AzureRmLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1 -Location $Location1 -GatewayIpAddress

$LNGIP6 -AddressPrefix $LNGPrefix61,$LNGPrefix62
Step 2 - Creat a S2S VPN connection with an IPsec/IKE policy

IMPORTANT
You need to create an IPsec/IKE policy in order to enable "UsePolicyBasedTrafficSelectors" option on the connection.
The sample script below creates an IPsec/IKE policy with the following algorithms and parameters:
IKEv2: AES256, SHA384, DHGroup24
IPsec: AES256, SHA256, PFS24, SA Lifetime 3600 seconds & 2048KB
$ipsecpolicy6 = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA384 -DhGroup DHGroup24 -

IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup PFS24 -SALifeTimeSeconds 3600 -SADataSizeKilobytes
2048
2. Create the S2S VPN connection with policy-based traffic selectors and IPsec/IKE policy
Create an S2S VPN connection and apply the IPsec/IKE policy created above. Note the additional parameter "-
UsePolicyBasedTrafficSelectors $True" to enable poicy-based traffic selectors on the connection.

$lng6 = Get-AzureRmLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1 -VirtualNetworkGateway1

$vnet1gw -LocalNetworkGateway2 $lng6 -Location $Location1 -ConnectionType IPsec -
UsePolicyBasedTrafficSelectors $True -IpsecPolicies $ipsecpolicy6 -SharedKey 'AzureA1b2C3'
After completing the steps, the S2S VPN connection will use the IPsec/IKE policy defined above, and enable policy-
based traffic selectors on the connection. You can repeat the same steps to add more connections to additional on-
premises policy-based VPN devices from the same Azure VPN gateway.
Update policy-based traffic selectors for a connection

The last section will show you how to update the policy-based traffic selectors option for an existing S2S VPN
connection.
1. Get the connection
Get the connection resource.
$connection6 = Get-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1
2. Check the policy-based traffic selectors option

The following line will show whether the policy-based traffic selectors are used for the connection:
$connection6.UsePolicyBasedTrafficSelectors
If the line returns "True", then policy-based traffic selectors are configured on the connection; otherwise it will
return "False."
3. Update the policy-based traffic selectors on a connection
Once you obtain the connection resource, you can enable or disable the option.
Disable UsePolicyBasedTrafficSelectors
The example below disables the policy-based traffic selectors option, but leaves the IPsec/IKE policy unchanged:
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -

UsePolicyBasedTrafficSelectors $False
Enable UsePolicyBasedTrafficSelectors
The example below enables the policy-based traffic selectors option, but leaves the IPsec/IKE policy unchanged:
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -

UsePolicyBasedTrafficSelectors $True
Next steps
Once your connection is complete, you can add virtual machines to your virtual networks. See Create a Virtual
Machine for steps.
Also review Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections for more details on custom
IPsec/IKE policies.
Configure IPsec/IKE policy for S2S VPN or VNet-to-
VNet connections
This article walks you through the steps to configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections
using the Resource Manager deployment model and PowerShell.
About IPsec and IKE policy parameters for Azure VPN gateways
IPsec and IKE protocol standard supports a wide range of cryptographic algorithms in various combinations.
Refer to About cryptographic requirements and Azure VPN gateways to see how this can help ensuring cross-
premises and VNet-to-VNet connectivity satisfy your compliance or security requirements.
This article provides instructions to create and configure an IPsec/IKE policy and apply to a new or existing
connection:
Part 1 - Workflow to create and set IPsec/IKE policy
Part 2 - Supported cryptographic algorithms and key strengths
Part 3 - Create a new S2S VPN connection with IPsec/IKE policy
Part 4 - Create a new VNet-to-VNet connection with IPsec/IKE policy
Part 5 - Manage (create, add, remove) IPsec/IKE policy for a connection
IMPORTANT
1. Please note that IPsec/IKE policy only works on Standard and HighPerformance Route-Based VPN gateways.
2. You can only specify one policy combination for a given connection.
3. You must specify all algorithms and parameters for both IKE (Main Mode) and IPsec (Quick Mode). Partial policy
specification is not allowed.
4. Please consult with your VPN device vendor specifications to ensure the policy is supported on your on-premises VPN
devices. S2S or VNet-to-VNet connections cannot establish if the policies are incompatible.
Part 1 - Workflow to create and set IPsec/IKE policy

This section outlines the workflow to create and update IPsec/IKE policy on a S2S VPN or VNet-to-VNet
connection:
1. Create a virtual network and a VPN gateway
2. Create a local network gateway for cross premises connection, or another virtual network and gateway for
VNet-to-VNet connection
3. Create an IPsec/IKE policy with selected algorithms and parameters
4. Create a connection (IPsec or VNet2VNet) with the IPsec/IKE policy
5. Add/update/remove an IPsec/IKE policy for an existing connection
The instructions in this article will setup and configure IPsec/IKE policies as shown in the diagram:
Part 2 - Supported cryptographic algorithms & key strengths
IPSEC/IKEV2 OPTIONS


IPsec Integrity GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1,

MD5
Traffic Selector UsePolicyBasedTrafficSelectors** ($True/$False - default

$False)
NOTE
(**) Setting "UsePolicyBasedTrafficSelectors" to $True on a connection will configure the Azure VPN gateway to connect
to policy-based VPN firewall on premises. If you enable PolicyBasedTrafficSelectors, you need to ensure your VPN device
has the matching traffic selectors defined with all combinations of your on-premises network (local network gateway)
prefixes to/from the Azure virtual network prefixes, instead of any-to-any. For example, if your on-premises network
prefixes are 10.1.0.0/16 and 10.2.0.0/16, and your virtual network prefixes are 192.168.0.0/16 and 172.16.0.0/16, you
need to specify the following traffic selectors:
10.1.0.0/16 <====> 192.168.0.0/16
10.1.0.0/16 <====> 172.16.0.0/16
10.2.0.0/16 <====> 192.168.0.0/16
10.2.0.0/16 <====> 172.16.0.0/16
See Connect multiple on-premises policy-based VPN devices for more details regarding policy-based traffic
selectors.
Part 3 - Create a new S2S VPN connection with IPsec/IKE policy

This section walks you through the steps of creating a S2S VPN connection with an IPsec/IKE policy. The steps
below will create the connection as shown in the diagram:
Please see Create a S2S VPN connection for more detailed step-by-step instructions for creating a S2S VPN
connection.
Before you begin
You'll need to install the Azure Resource Manager PowerShell cmdlets. See Overview of Azure PowerShell for
more information about installing the PowerShell cmdlets.
Step 1 - Create the virtual network, VPN gateway, and local network gateway
1. Declare your variables
For this exercise, we'll start by declaring our variables. Be sure to replace the values with your own when
configuring for production.
$Sub1 = "<YourSubscriptionName>"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$DNS1 = "8.8.8.8"
$LNGName6 = "Site6"
$LNGPrefix61 = "10.61.0.0/16"
$LNGPrefix62 = "10.62.0.0/16"
$LNGIP6 = "131.107.72.22"
2. Connect to your subscription and create a new resource group

Make sure you switch to PowerShell mode to use the Resource Manager cmdlets. For more information, see
Using Windows PowerShell with Resource Manager.
3. Create the virtual network, VPN gateway, and local network gateway
The sample below creates the virtual network, TestVNet1, with three subnets, and the VPN gateway. When
substituting values, it's important that you always name your gateway subnet specifically GatewaySubnet. If you
name it something else, your gateway creation will fail.



$gw1pip1
New-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 -Location $Location1 -

IpConfigurations $gw1ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance

$LNGIP6 -AddressPrefix $LNGPrefix61,$LNGPrefix62
Step 2 - Creat a S2S VPN connection with an IPsec/IKE policy

The sample script below creates an IPsec/IKE policy with the following algorithms and parameters:
IPsec: AES256, SHA256, PFS24, SA Lifetime 7200 seconds & 2048KB

IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup PFS24 -SALifeTimeSeconds 7200 -SADataSizeKilobytes
2048
2. Create the S2S VPN connection with the IPsec/IKE policy

Create an S2S VPN connection and apply the IPsec/IKE policy created above.

$lng6 = Get-AzureRmLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1

VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng6 -Location $Location1 -ConnectionType IPsec -
IpsecPolicies $ipsecpolicy6 -SharedKey 'AzureA1b2C3'
You can optionally add "-UsePolicyBasedTrafficSelectors $True" to the create connection cmdlet to enable Azure
VPN gateway to connect to policy-based VPN devices on premises, as described above.
IMPORTANT
Once an IPsec/IKE policy is specified on a connection, the Azure VPN gateway will only send or accept the IPsec/IKE
proposal with specified cryptographic algorithms and key strengths on that particular connection. You must ensure your
on-premises VPN device for the connection uses or accepts the exact policy combination, otherwise the S2S VPN tunnel
will not establish.
Part 4 - Create a new VNet-to-VNet connection with IPsec/IKE policy

The steps of creating a VNet-to-VNet connection with an IPsec/IKE policy are similar to that of a S2S VPN
connection. The sample scripts below will create the connection as shown in the diagram:
Please see Create a VNet-to-VNet connection for more detailed steps for creating a VNet-to-VNet connection.
You must complete Part 3 to create and configure TestVNet1 and the VPN Gateway.
Step 1 - Create the second virtual network and VPN gateway
Be sure to replace the values with the ones that you want to use for your configuration.
$VNetPrefix21 = "10.21.0.0/16"
$VNetPrefix22 = "10.22.0.0/16"
$FESubPrefix2 = "10.21.0.0/24"
$BESubPrefix2 = "10.22.0.0/24"
$GWSubPrefix2 = "10.22.255.0/27"
$DNS2 = "8.8.8.8"
2. Create the second virtual network and VPN gateway in the new resource group



$gw2pip1

IpConfigurations $gw2ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance
Step 2 - Creat a VNet-toVNet connection with the IPsec/IKE policy

Similar to the S2S VPN connection, create an IPsec/IKE policy then apply to policy to the new connection.
The sample script below creates a different IPsec/IKE policy with the following algorithms and parameters:
IPsec: GCMAES128, GCMAES128, PFS14, SA Lifetime 7200 seconds & 4096KB

IpsecEncryption GCMAES128 -IpsecIntegrity GCMAES128 -PfsGroup PFS14 -SALifeTimeSeconds 7200 -
SADataSizeKilobytes 4096
2. Create VNet-to-VNet connections with the IPsec/IKE policy

Create a VNet-to-VNet connection and apply the IPsec/IKE policy created above. In this example, both gateways
are in the same subscription. So it is possible to create and configure both connections with the same IPsec/IKE
policy in the same PowerShell session.


Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey 'AzureA1b2C3'

Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey 'AzureA1b2C3'
IMPORTANT
Once an IPsec/IKE policy is specified on a connection, the Azure VPN gateway will only send or accept the IPsec/IKE
proposal with specified cryptographic algorithms and key strengths on that particular connection. You must ensure the
IPsec policies for both connections are the same, otherwise the VNet-to-VNet connection will not establish.
After completing these steps, the connection will be establish in a few minutes, and you will have the following
network topology as shown in the beginning:
Part 5 - Update IPsec/IKE policy for a connection

The last section will show you how to manage IPsec/IKE policy for an existing S2S or VNet-to-VNet connection.
The exercise below walks you through the following operations on a connection:
1. Show the IPsec/IKE pocliy of a connection
2. Add or update the IPsec/IKE policy to a connection
3. Remove the IPsec/IKE policy from a connection
The same steps apply to both S2S and VNet-to-VNet connections.
IMPORTANT
IPsec/IKE policy is supported on Standard and HighPerformance route-based VPN gateways only. It does not work on the
Basic gateway SKU or the policy-based VPN gateway.
1. Show the IPsec/IKE policy of a connection

The following example shows how to get the IPsec/IKE policy configured on a connection. The scripts also
continue from the exercises above.
$connection6.IpsecPolicies
The last command will list the current IPsec/IKE policy configured on the connection if there is any. The sample
output shown below for the connection:
SALifeTimeSeconds : 3600
SADataSizeKilobytes : 2048
IpsecEncryption : AES256
IpsecIntegrity : SHA256
IkeEncryption : AES256
IkeIntegrity : SHA384
DhGroup : DHGroup24
PfsGroup : PFS24
If there is no IPsec/IKE policy configured, the command (PS> $connection6.policy) will get an empty return. It
does not mean IPsec/IKE is not configured on the connection, but that there is no custom IPsec/IKE policy. The
actual connection will be using the default polilcy negotiated between your on-premises VPN device and the
Azure VPN gateway .
2. Add or update an IPsec/IKE policy for a connection
The steps to add a new policy or updateg an existing policy on a connection are the same: create a new policy
then apply the new policy to the connection.
$newpolicy6 = New-AzureRmIpsecPolicy -IkeEncryption AES128 -IkeIntegrity SHA1 -DhGroup DHGroup14 -

IpsecEncryption GCMAES128 -IpsecIntegrity GCMAES128 -PfsGroup None -SALifeTimeSeconds 3600 -
SADataSizeKilobytes 2048
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies

$newpolicy6
To enable "UsePolicyBasedTrafficSelectors" when connecting to an on-premises policy-based VPN device, add

the "-UsePolicyBaseTrafficSelectors" parameter to the cmdlet, or set it to $False to disable the option:
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies

$newpolicy6 -UsePolicyBasedTrafficSelectors $True
You can get the connection again to check if the policy is updated.

$connection6.IpsecPolicies
You should see the output from the last line as shown below:
SALifeTimeSeconds : 3600
SADataSizeKilobytes : 2048
IpsecEncryption : GCMAES128
IpsecIntegrity : GCMAES128
IkeEncryption : AES128
IkeIntegrity : SHA1
DhGroup : DHGroup14--
PfsGroup : None
3. Remove an IPsec/IKE policy from a connection

Once you remove the custom policy from a connection, the Azure VPN gateway will revert back to the default list
of IPsec/IKE proposals and re-negotiate again with your on-premises VPN device.
$currentpolicy = $connection6.IpsecPolicies[0]
$connection6.IpsecPolicies.Remove($currentpolicy)
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6
Again, you can use the same script above to check if the policy has been removed from the connection.
Next steps
See Connect multiple on-premises policy-based VPN devices for more details regarding policy-based traffic
selectors.
Machine for steps.
Configure active-active S2S VPN connections with
Azure VPN Gateways
This article walks you through the steps to create active-active cross-premises and VNet-to-VNet connections using
the Resource Manager deployment model and PowerShell.
About Highly Available Cross-Premises Connections

To achieve high availability for cross-premises and VNet-to-VNet connectivity, you should deploy multiple VPN
gateways and establish multiple parallel connections between your networks and Azure. Please see Highly
Available Cross-Premises and VNet-to-VNet Connectivity for an overview of connectivity options and topology.
This article provides the instructions to set up an active-active cross-premises VPN connection, and active-active
connection between two virtual networks:
Part 1 - Create and configure your Azure VPN gateway in active-active mode
Part 2 - Establish active-active cross-premises connections
Part 3 - Establish active-active VNet-to-VNet connections
Part 4 - Update existing gateway between active-active and active-standby
You can combine these together to build a more complex, highly available network topology that meets your
needs.
IMPORTANT
Please note that the active-active mode only works in HighPerformance SKU
Part 1 - Create and configure active-active VPN gateways

The following steps will configure your Azure VPN gateway in active-active modes. The key differences between
the active-active and active-standby gateways:
You need to create two Gateway IP configurations with two public IP addresses
You need set the EnableActiveActiveFeature flag
The gateway SKU must be HighPerformance
The other properties are the same as the non-active-active gateways.
Before you begin
You'll need to install the Azure Resource Manager PowerShell cmdlets. See Overview of Azure PowerShell for
Step 1 - Create and configure VNet1
For this exercise, we'll start by declaring our variables. The example below declares the variables using the values
for this exercise. Be sure to replace the values with your own when configuring for production. You can use these
variables if you are running through the steps to become familiar with this type of configuration. Modify the
variables, and then copy and paste into your PowerShell console.
$Sub1 = "Ross"
$RG1 = "TestAARG1"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$VNet1ASN = 65010
$DNS1 = "8.8.8.8"
$Connection151 = "VNet1toSite5_1"
$Connection152 = "VNet1toSite5_2"

Make sure you switch to PowerShell mode to use the Resource Manager cmdlets. For more information, see Using
Windows PowerShell with Resource Manager.
3. Create TestVNet1
The sample below creates a virtual network named TestVNet1 and three subnets, one called GatewaySubnet, one
called FrontEnd, and one called Backend. When substituting values, it's important that you always name your
gateway subnet specifically GatewaySubnet. If you name it something else, your gateway creation will fail.


Step 2 - Create the VPN gateway for TestVNet1 with active -active mode
1. Create the public IP addresses and gateway IP configurations
Request two public IP addresses to be allocated to the gateway you will create for your VNet. You'll also define the
subnet and IP configurations required.

$gw1pip1
$gw1pip2
2. Create the VPN gateway with active-active configuration

Create the virtual network gateway for TestVNet1. Note that there are two GatewayIpConfig entries, and the
EnableActiveActiveFeature flag is set. Active-active mode requires a Route-Based VPN gateway of
HighPerformance SKU. Creating a gateway can take a while (30 minutes or more to complete).

$gw1ipconf1,$gw1ipconf2 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance -Asn $VNet1ASN -
EnableActiveActiveFeature -Debug
3. Obtain the gateway public IP addresses and the BGP Peer IP address
Once the gateway is created, you will need to obtain the BGP Peer IP address on the Azure VPN Gateway. This
address is needed to configure the Azure VPN Gateway as a BGP Peer for your on-premises VPN devices.
$gw1pip1 = Get-AzureRmPublicIpAddress -Name $GW1IPName1 -ResourceGroupName $RG1

$gw1pip2 = Get-AzureRmPublicIpAddress -Name $GW1IPName2 -ResourceGroupName $RG1
Use the following cmdlets to show the two public IP addresses allocated for your VPN gateway, and their
corresponding BGP Peer IP addresses for each gateway instance:
PS D:\> $gw1pip1.IpAddress
40.112.190.5
PS D:\> $gw1pip2.IpAddress
138.91.156.129
PS D:\> $vnet1gw.BgpSettingsText
{
"Asn": 65010,
"BgpPeeringAddress": "10.12.255.4,10.12.255.5",
"PeerWeight": 0
}
The order of the public IP addresses for the gateway instances and the corresponding BGP Peering Addresses are
the same. In this example, the gateway VM with public IP of 40.112.190.5 will use 10.12.255.4 as its BGP Peering
Address, and the gateway with 138.91.156.129 will use 10.12.255.5. This information is needed when you set up
your on premises VPN devices connecting to the active-active gateway. The gateway is shown in the diagram
below with all addresses:
Once the gateway is created, you can use this gateway to establish active-active cross-premises or VNet-to-VNet
connection. The following sections will walk through the steps to complete the exercise.
Part 2 - Establish an active-active cross-premises connection

To establish a cross-premises connection, you need to create a Local Network Gateway to represent your on-
premises VPN device, and a Connection to connect the Azure VPN gateway with the local network gateway. In this
example, the Azure VPN gateway is in active-active mode. As a result, even though there is only one on-premises
VPN device (local network gateway) and one connection resource, both Azure VPN gateway instances will establish
S2S VPN tunnels with the on-premises device.
Before proceeding, please make sure you have completed Part 1 of this exercise.
Step 1 - Create and configure the local network gateway
This exercise will continue to build the configuration shown in the diagram. Be sure to replace the values with the
ones that you want to use for your configuration.
$RG5 = "TestAARG5"
$LNGName51 = "Site5_1"
$LNGPrefix51 = "10.52.255.253/32"
$LNGIP51 = "131.107.72.22"
$LNGASN5 = 65050
$BGPPeerIP51 = "10.52.255.253"
A couple of things to note regarding the local network gateway parameters:

The local network gateway can be in the same or different location and resource group as the VPN gateway.
This example shows them in different resource groups but in the same Azure location.
If there is only one on-premises VPN device as shown above, the active-active connection can work with or
without BGP protocol. This example uses BGP for the cross-premises connection.
If BGP is enabled, the prefix you need to declare for the local network gateway is the host address of your BGP
Peer IP address on your VPN device. In this case, it's a /32 prefix of "10.52.255.253/32".
As a reminder, you must use different BGP ASNs between your on-premises networks and Azure VNet. If they
are the same, you need to change your VNet ASN if your on-premises VPN device already uses the ASN to peer
with other BGP neighbors.
2. Create the local network gateway for Site5
Before you continue, please make sure you are still connected to Subscription 1. Create the resource group if it is
not yet created.

$LNGIP51 -AddressPrefix $LNGPrefix51 -Asn $LNGASN5 -BgpPeeringAddress $BGPPeerIP51
Step 2 - Connect the VNet gateway and local network gateway
1. Get the two gateways

$lng5gw1 = Get-AzureRmLocalNetworkGateway -Name $LNGName51 -ResourceGroupName $RG5
2. Create the TestVNet1 to Site5 connection

In this step, you will create the connection from TestVNet1 to Site5_1 with "EnableBGP" set to $True.

VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng5gw1 -Location $Location1 -ConnectionType IPsec -
SharedKey 'AzureA1b2C3' -EnableBGP True
3. VPN and BGP parameters for your on-premises VPN device

The example below lists the parameters you will enter into the BGP configuration section on your on-premises VPN
device for this exercise:
- Site5 ASN : 65050

- Site5 BGP IP : 10.52.255.253
- Prefixes to announce : (for example) 10.51.0.0/16 and 10.52.0.0/16
- Azure VNet ASN : 65010
- Azure VNet BGP IP 1 : 10.12.255.4 for tunnel to 40.112.190.5
- Static routes : Destination 10.12.255.4/32, nexthop the VPN tunnel interface to 40.112.190.5
Destination 10.12.255.5/32, nexthop the VPN tunnel interface to 138.91.156.129
- eBGP Multihop : Ensure the "multihop" option for eBGP is enabled on your device if needed
The connection should be established after a few minutes, and the BGP peering session will start once the IPsec
connection is established. This example so far has configured only one on-premises VPN device, resulting in the
diagram shown below:
Step 3 - Connect two on-premises VPN devices to the active -active VPN gateway
If you have two VPN devices at the same on-premises network, you can achieve dual redundancy by connecting
the Azure VPN gateway to the second VPN device.
1. Create the second local network gateway for Site5
Note that the gateway IP address, address prefix, and BGP peering address for the second local network gateway
must not overlap with the previous local network gateway for the same on-premises network.
$LNGName52 = "Site5_2"
$LNGPrefix52 = "10.52.255.254/32"
$LNGIP52 = "131.107.72.23"
$BGPPeerIP52 = "10.52.255.254"

2. Connect the VNet gateway and the second local network gateway
Create the connection from TestVNet1 to Site5_2 with "EnableBGP" set to $True
$lng5gw2 = Get-AzureRmLocalNetworkGateway -Name $LNGName52 -ResourceGroupName $RG5

VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng5gw2 -Location $Location1 -ConnectionType IPsec -
SharedKey 'AzureA1b2C3' -EnableBGP True
3. VPN and BGP parameters for your second on-premises VPN device
Similarly, below lists the parameters you will enter into the second VPN device:
- Site5 ASN : 65050

- Site5 BGP IP : 10.52.255.254
- Static routes : Destination 10.12.255.4/32, nexthop the VPN tunnel interface to 40.112.190.5
Destination 10.12.255.5/32, nexthop the VPN tunnel interface to 138.91.156.129
Once the connection (tunnels) are established, you will have dual redundant VPN devices and tunnels connecting
your on-premises network and Azure:
Part 3 - Establish an active-active VNet-to-VNet connection

This section creates an active-active VNet-to-VNet connection with BGP.
The instructions below continue from the previous steps listed above. You must complete Part 1 to create and
configure TestVNet1 and the VPN Gateway with BGP.
Step 1 - Create TestVNet2 and the VPN gateway
It is important to make sure that the IP address space of the new virtual network, TestVNet2, does not overlap with
any of your VNet ranges.
In this example, the virtual networks belong to the same subscription. You can set up VNet-to-VNet connections
between different subscriptions; please refer to Configure a VNet-to-VNet connection to learn more details. Make
sure you add the "-EnableBgp $True" when creating the connections to enable BGP.
$RG2 = "TestAARG2"
$VNetPrefix21 = "10.21.0.0/16"
$VNetPrefix22 = "10.22.0.0/16"
$FESubPrefix2 = "10.21.0.0/24"
$BESubPrefix2 = "10.22.0.0/24"
$GWSubPrefix2 = "10.22.255.0/27"
$VNet2ASN = 65020
$DNS2 = "8.8.8.8"
2. Create TestVNet2 in the new resource group


3. Create the active-active VPN gateway for TestVNet2

Request two public IP addresses to be allocated to the gateway you will create for your VNet. You'll also define the


$gw2pip1
$gw2pip2
Create the VPN gateway with the AS number and the "EnableActiveActiveFeature" flag. Note that you must
override the default ASN on your Azure VPN gateways. The ASNs for the connected VNets must be different to
enable BGP and transit routing.

$gw2ipconf1,$gw2ipconf2 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance -Asn $VNet2ASN -
EnableActiveActiveFeature
Step 2 - Connect the TestVNet1 and TestVNet2 gateways

In this example, both gateways are in the same subscription. You can complete this step in the same PowerShell
session.
1. Get both gateways
Make sure you log in and connect to Subscription 1.

2. Create both connections

In this step, you will create the connection from TestVNet1 to TestVNet2, and the connection from TestVNet2 to
TestVNet1.

$vnet1gw -VirtualNetworkGateway2 $vnet2gw -Location $Location1 -ConnectionType Vnet2Vnet -SharedKey
'AzureA1b2C3' -EnableBgp $True

$vnet2gw -VirtualNetworkGateway2 $vnet1gw -Location $Location2 -ConnectionType Vnet2Vnet -SharedKey
'AzureA1b2C3' -EnableBgp $True
IMPORTANT
Be sure to enable BGP for BOTH connections.
After completing these steps, the connection will be establish in a few minutes, and the BGP peering session will be
up once the VNet-to-VNet connection is completed with dual redundancy:
Part 4 - Update existing gateway between active-active and active-

standby
The last section will describe how you can configure an existing Azure VPN gateway from active-standby to active-
active mode, or vice versa.
IMPORTANT
Please note that the active-active mode only works in HighPerformance SKU
Configure an active -standby gateway to active -active gateway

1. Gateway parameters
The following example converts an active-standby gateway into an active-active gateway. You need to create
another public IP address, then add a second Gateway IP configuration. Below shows the parameters used:
$GWName = "TestVNetAA1GW"
$VNetName = "TestVNetAA1"
$RG = "TestVPNActiveActive01"
$GWIPName2 = "gwpip2"
$GWIPconf2 = "gw1ipconf2"
$vnet = Get-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$gw = Get-AzureRmVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG
$location = $gw.Location
2. Create the public IP address, then add the second gateway IP configuration
$gwpip2 = New-AzureRmPublicIpAddress -Name $GWIPName2 -ResourceGroupName $RG -Location $location -

Add-AzureRmVirtualNetworkGatewayIpConfig -VirtualNetworkGateway $gw -Name $GWIPconf2 -Subnet $subnet -
3. Enable active-active mode and update the gateway

You must set the gateway object in PowerShell to trigger the actual update. The SKU of the gateway object must
also be changed to HighPerformance since it was created previously as Standard.
Set-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $gw -EnableActiveActiveFeature -GatewaySku

HighPerformance
This update can take 30 to 45 minutes.

Configure an active -active gateway to active -standby gateway
1. Gateway parameters
Use the same parameters as above, get the name of the IP configuration you want to remove.
$GWName = "TestVNetAA1GW"
$RG = "TestVPNActiveActive01"
$gw = Get-AzureRmVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG

$ipconfname = $gw.IpConfigurations[1].Name
2. Remove the gateway IP configuration and disable the active-active mode

Similarly, you must set the gateway object in PowerShell to trigger the actual update.
Remove-AzureRmVirtualNetworkGatewayIpConfig -Name $ipconfname -VirtualNetworkGateway $gw

Set-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $gw -DisableActiveActiveFeature
This update can take up to 30 to 45 minutes.
Next steps
Machine for steps.
How to configure BGP on Azure VPN Gateways
using PowerShell
This article walks you through the steps to enable BGP on a cross-premises Site-to-Site (S2S) VPN connection and
a VNet-to-VNet connection using the Resource Manager deployment model and PowerShell.
About BGP
BGP is the standard routing protocol commonly used in the Internet to exchange routing and reachability
information between two or more networks. BGP enables the Azure VPN Gateways and your on-premises VPN
devices, called BGP peers or neighbors, to exchange "routes" that will inform both gateways on the availability and
reachability for those prefixes to go through the gateways or routers involved. BGP can also enable transit routing
among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers.
Please see Overview of BGP with Azure VPN Gateways for more discussion on benefits of BGP and to understand
the technical requirements and considerations of using BGP.
Getting started with BGP on Azure VPN gateways

This article will walk you through the steps to do the following tasks:
Part 1 - Enable BGP on your Azure VPN gateway
Part 2 - Establish a cross-premises connection with BGP
Part 3 - Establish a VNet-to-VNet connection with BGP
Each part of the instructions forms a basic building block for enabling BGP in your network connectivity. If you
complete all three parts, you will build the topology as shown in the following diagram:
You can combine these together to build a more complex, multi-hop, transit network that meet your needs.
Part 1 - Configure BGP on the Azure VPN Gateway

The following configuration steps will setup the BGP parameters of the Azure VPN gateway as shown in the
following diagram:
Before you begin
You'll need to install the Azure Resource Manager PowerShell cmdlets. See How to install and configure Azure
PowerShell for more information about installing the PowerShell cmdlets.
Step 1 - Create and configure VNet1
For this exercise, we'll start by declaring our variables. The example below declares the variables using the values
for this exercise. Be sure to replace the values with your own when configuring for production. You can use these
variables if you are running through the steps to become familiar with this type of configuration. Modify the
variables, and then copy and paste into your PowerShell console.
$Sub1 = "Replace_With_Your_Subcription_Name"
$RG1 = "TestBGPRG1"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$VNet1ASN = 65010
$DNS1 = "8.8.8.8"

Make sure you switch to PowerShell mode to use the Resource Manager cmdlets. For more information, see
Using Windows PowerShell with Resource Manager.
3. Create TestVNet1
The sample below creates a virtual network named TestVNet1 and three subnets, one called GatewaySubnet, one
called FrontEnd, and one called Backend. When substituting values, it's important that you always name your
gateway subnet specifically GatewaySubnet. If you name it something else, your gateway creation will fail.
$fesub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1 $besub1 = New-
AzureRmVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1

Step 2 - Create the VPN Gateway for TestVNet1 with BGP parameters
1. Create the IP and subnet configurations
Request a public IP address to be allocated to the gateway you will create for your VNet. You'll also define the
$gwpip1 = New-AzureRmPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 -Location $Location1 -


$gwipconf1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 -Subnet $subnet1 -PublicIpAddress
$gwpip1
2. Create the VPN gateway with the AS number

Create the virtual network gateway for TestVNet1. Note that BGP requires a Route-Based VPN gateway, and also
the addition parameter, -Asn, to set the ASN (AS Number) for TestVNet1. If you do not set the ASN parameter,
ASN 65515 will be assigned. Creating a gateway can take a while (30 minutes or more to complete).

IpConfigurations $gwipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance -Asn $VNet1ASN
3. Obtain the Azure BGP Peer IP address

Once the gateway is created, you will need to obtain the BGP Peer IP address on the Azure VPN Gateway. This
address is needed to configure the Azure VPN Gateway as a BGP Peer for your on-premises VPN devices.

$vnet1gw.BgpSettingsText
The last command will show the corresponding BGP configurations on the Azure VPN Gateway; for example:
$vnet1gw.BgpSettingsText
{
"Asn": 65010,
"BgpPeeringAddress": "10.12.255.30",
"PeerWeight": 0
}
Once the gateway is created, you can use this gateway to establish cross-premises connection or VNet-to-VNet
connection with BGP. The following sections will walk through the steps to complete the exercise.
Part 2 - Establish a cross-premises connection with BGP

To establish a cross-premises connection, you need to create a Local Network Gateway to represent your on-
premises VPN device, and a Connection to connect the Azure VPN gateway with the local network gateway. The
difference between the instructions in this article is the additional properties required to specify the BGP
configuration parameters.
Before proceeding, please make sure you have completed Part 1 of this exercise.
Step 1 - Create and configure the local network gateway
This exercise will continue to build the configuration shown in the diagram. Be sure to replace the values with the
ones that you want to use for your configuration.
$RG5 = "TestBGPRG5"
$LNGName5 = "Site5"
$LNGPrefix50 = "10.52.255.254/32"
$LNGIP5 = "Your_VPN_Device_IP"
$LNGASN5 = 65050
$BGPPeerIP5 = "10.52.255.254"
A couple of things to note regarding the local network gateway parameters:

The local network gateway can be in the same or different location and resource group as the VPN gateway.
This example shows them in different resource groups in different locations.
The minimum prefix you need to declare for the local network gateway is the host address of your BGP Peer IP
address on your VPN device. In this case, it's a /32 prefix of "10.52.255.254/32".
As a reminder, you must use different BGP ASNs between your on-premises networks and Azure VNet. If they
are the same, you need to change your VNet ASN if your on-premises VPN device already use the ASN to peer
with other BGP neighbors.
Before you continue, please make sure you are still connected to Subscription 1.
2. Create the local network gateway for Site5
Be sure to create the resource group if it is not created, before you create the local network gateway. Notice the
two additional parameters for the local network gateway: Asn and BgpPeerAddress.

Step 2 - Connect the VNet gateway and local network gateway

1. Get the two gateways

$lng5gw = Get-AzureRmLocalNetworkGateway -Name $LNGName5 -ResourceGroupName $RG5
2. Create the TestVNet1 to Site5 connection

In this step, you will create the connection from TestVNet1 to Site5. You must specify "-EnableBGP $True" to
enable BGP for this connection. As discussed earlier, it is possible to have both BGP and non-BGP connections for
the same Azure VPN Gateway. Unless BGP is enabled in the connection property, Azure will not enable BGP for
this connection even though BGP parameters are already configured on both gateways.

VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng5gw -Location $Location1 -ConnectionType IPsec -
SharedKey 'AzureA1b2C3' -EnableBGP $True
The example below lists the parameters you will enter into the BGP configuration section on your on-premises
VPN device for this exercise:
- Site5 ASN : 65050

- Site5 BGP IP : 10.52.255.254
- Azure VNet BGP IP : 10.12.255.30
- Static route : Add a route for 10.12.255.30/32, with nexthop being the VPN tunnel interface on your
device
The connection should be established after a few minutes, and the BGP peering session will start once the IPsec
connection is established.
Part 3 - Establish a VNet-to-VNet connection with BGP

This section adds a VNet-to-VNet connection with BGP, as shown in the diagram below.
The instructions below continue from the previous steps listed above. You must complete Part I to create and
configure TestVNet1 and the VPN Gateway with BGP.
Step 1 - Create TestVNet2 and the VPN gateway
It is important to make sure that the IP address space of the new virtual network, TestVNet2, does not overlap with
any of your VNet ranges.
In this example, the virtual networks belong to the same subscription. You can setup VNet-to-VNet connections
between different subscriptions; please refer to Configure a VNet-to-VNet connection to learn more details. Make
sure you add the "-EnableBgp $True" when creating the connections to enable BGP.
$RG2 = "TestBGPRG2"
$VNetPrefix21 = "10.21.0.0/16"
$VNetPrefix22 = "10.22.0.0/16"
$FESubPrefix2 = "10.21.0.0/24"
$BESubPrefix2 = "10.22.0.0/24"
$GWSubPrefix2 = "10.22.255.0/27"
$VNet2ASN = 65020
$DNS2 = "8.8.8.8"
2. Create TestVNet2 in the new resource group


3. Create the VPN gateway for TestVNet2 with BGP parameters

Request a public IP address to be allocated to the gateway you will create for your VNet. You'll also define the
$gwpip2 = New-AzureRmPublicIpAddress -Name $GWIPName2 -ResourceGroupName $RG2 -Location $Location2 -


$gwipconf2 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName2 -Subnet $subnet2 -PublicIpAddress
$gwpip2
Create the VPN gateway with the AS number. Note that you must override the default ASN on your Azure VPN
gateways. The ASNs for the connected VNets must be different to enable BGP and transit routing.

IpConfigurations $gwipconf2 -GatewayType Vpn -VpnType RouteBased -GatewaySku Standard -Asn $VNet2ASN
Step 2 - Connect the TestVNet1 and TestVNet2 gateways

In this example, both gateways are in the same subscription. You can complete this step in the same PowerShell
session.
1. Get both gateways
Make sure you login and connect to Subscription 1.

2. Create both connections
In this step, you will create the connection from TestVNet1 to TestVNet2, and the connection from TestVNet2 to
TestVNet1.

Vnet2Vnet -SharedKey 'AzureA1b2C3' -EnableBgp $True

Vnet2Vnet -SharedKey 'AzureA1b2C3' -EnableBgp $True
IMPORTANT
Be sure to enable BGP for BOTH connections.
After completing these steps, the connection will be establish in a few minutes, and the BGP peering session will
be up once the VNet-to-VNet connection is completed.
If you have completed all three parts of this exercise, you will have established a network topology as shown
below:
Next steps
Machine for steps.
Configure forced tunneling using the Azure Resource
Manager deployment model
Forced tunneling lets you redirect or "force" all Internet-bound traffic back to your on-premises location via a Site-
to-Site VPN tunnel for inspection and auditing. This is a critical security requirement for most enterprise IT policies.
Unauthorized Internet access can potentially lead to information disclosure or other types of security breaches
This article walks you through configuring forced tunneling for virtual networks created using the Resource
Manager deployment model. Forced tunneling can be configured by using PowerShell, not through the portal. If
you want to configure forced tunneling for the classic deployment model, select classic article from the following
dropdown list:
About forced tunneling

The following diagram illustrates how forced tunneling works.
In the example above, the Frontend subnet is not forced tunneled. The workloads in the Frontend subnet can
continue to accept and respond to customer requests from the Internet directly. The Mid-tier and Backend subnets
are forced tunneled. Any outbound connections from these two subnets to the Internet will be forced or redirected
back to an on-premises site via one of the S2S VPN tunnels.
This allows you to restrict and inspect Internet access from your virtual machines or cloud services in Azure, while
continuing to enable your multi-tier service architecture required. You also can apply forced tunneling to the entire
virtual networks if there are no Internet-facing workloads in your virtual networks.
Requirements and considerations

Forced tunneling in Azure is configured via virtual network user defined routes. Redirecting traffic to an on-
premises site is expressed as a Default Route to the Azure VPN gateway. For more information about user defined
routing and virtual networks, see User defined routes and IP forwarding.
Each virtual network subnet has a built-in, system routing table. The system routing table has the following
three groups of routes:
Local VNet routes: Directly to the destination VMs in the same virtual network
On-premises routes: To the Azure VPN gateway
Default route: Directly to the Internet. Packets destined to the private IP addresses not covered by the
previous two routes will be dropped.
This procedure uses user defined routes (UDR) to create a routing table to add a default route, and then
associate the routing table to your VNet subnet(s) to enable forced tunneling on those subnets.
Forced tunneling must be associated with a VNet that has a route-based VPN gateway. You need to set a
"default site" among the cross-premises local sites connected to the virtual network.
ExpressRoute forced tunneling is not configured via this mechanism, but instead, is enabled by advertising a
default route via the ExpressRoute BGP peering sessions. Please see the ExpressRoute Documentation for more
information.
Configuration overview
The following procedure helps you create a resource group and a VNet. You'll then create a VPN gateway and
configure forced tunneling. In this procedure, the virtual network "MultiTier-VNet" has 3 subnets: Frontend,
Midtier, and Backend, with 4 cross-premises connections: DefaultSiteHQ, and 3 Branches.
The procedure steps set the DefaultSiteHQ as the default site connection for forced tunneling, and configure the
Midtier and Backend subnets to use forced tunneling.
Before you begin

Verify that you have the following items before beginning your configuration.
You'll need to install the latest version of the Azure Resource Manager PowerShell cmdlets (1.0 or later). See
How to install and configure Azure PowerShell for more information about installing the PowerShell cmdlets.

1. In the PowerShell console, log in to your Azure account. This cmdlet prompts you for the login credentials
for your Azure Account. After logging in, it downloads your account settings so they are available to Azure
PowerShell.
2. Get a list of your Azure subscriptions.

New-AzureRmResourceGroup -Name "ForcedTunneling" -Location "North Europe"
5. Create a virtual network and specify subnets.
$s1 = New-AzureRmVirtualNetworkSubnetConfig -Name "Frontend" -AddressPrefix "10.1.0.0/24"

$s2 = New-AzureRmVirtualNetworkSubnetConfig -Name "Midtier" -AddressPrefix "10.1.1.0/24"
$s3 = New-AzureRmVirtualNetworkSubnetConfig -Name "Backend" -AddressPrefix "10.1.2.0/24"
$s4 = New-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix "10.1.200.0/28"
$vnet = New-AzureRmVirtualNetwork -Name "MultiTier-VNet" -Location "North Europe" -ResourceGroupName
"ForcedTunneling" -AddressPrefix "10.1.0.0/16" -Subnet $s1,$s2,$s3,$s4
6. Create the local network gateways.
$lng1 = New-AzureRmLocalNetworkGateway -Name "DefaultSiteHQ" -ResourceGroupName "ForcedTunneling" -

Location "North Europe" -GatewayIpAddress "111.111.111.111" -AddressPrefix "192.168.1.0/24"
$lng2 = New-AzureRmLocalNetworkGateway -Name "Branch1" -ResourceGroupName "ForcedTunneling" -Location
"North Europe" -GatewayIpAddress "111.111.111.112" -AddressPrefix "192.168.2.0/24"
7. Create the route table and route rule.
New-AzureRmRouteTable Name "MyRouteTable" -ResourceGroupName "ForcedTunneling" Location "North

Europe"
$rt = Get-AzureRmRouteTable Name "MyRouteTable" -ResourceGroupName "ForcedTunneling"
Add-AzureRmRouteConfig -Name "DefaultRoute" -AddressPrefix "0.0.0.0/0" -NextHopType
VirtualNetworkGateway -RouteTable $rt
Set-AzureRmRouteTable -RouteTable $rt
8. Associate the route table to the Midtier and Backend subnets.
$vnet = Get-AzureRmVirtualNetwork -Name "MultiTier-Vnet" -ResourceGroupName "ForcedTunneling"

Set-AzureRmVirtualNetworkSubnetConfig -Name "MidTier" -VirtualNetwork $vnet -AddressPrefix
"10.1.1.0/24" -RouteTable $rt
Set-AzureRmVirtualNetworkSubnetConfig -Name "Backend" -VirtualNetwork $vnet -AddressPrefix
"10.1.2.0/24" -RouteTable $rt
Set-AzureRmVirtualNetwork -VirtualNetwork $vnet
9. Create the Gateway with a default site. This step takes some time to complete, sometimes 45 minutes or
more, because you are creating and configuring the gateway.
The -GatewayDefaultSite is the cmdlet parameter that allows the forced routing configuration to work, so
take care to configure this setting properly. This parameter is available in PowerShell 1.0 or later.
$pip = New-AzureRmPublicIpAddress -Name "GatewayIP" -ResourceGroupName "ForcedTunneling" -Location
"North Europe" -AllocationMethod Dynamic
$gwsubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
$ipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name "gwIpConfig" -SubnetId $gwsubnet.Id -
PublicIpAddressId $pip.Id
New-AzureRmVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName "ForcedTunneling" -Location "North
Europe" -IpConfigurations $ipconfig -GatewayType Vpn -VpnType RouteBased -GatewayDefaultSite $lng1 -
EnableBgp $false
10. Establish the Site-to-Site VPN connections.
$gateway = Get-AzureRmVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName "ForcedTunneling"

$lng1 = Get-AzureRmLocalNetworkGateway -Name "DefaultSiteHQ" -ResourceGroupName "ForcedTunneling"
$lng2 = Get-AzureRmLocalNetworkGateway -Name "Branch1" -ResourceGroupName "ForcedTunneling"
New-AzureRmVirtualNetworkGatewayConnection -Name "Connection1" -ResourceGroupName "ForcedTunneling" -

Location "North Europe" -VirtualNetworkGateway1 $gateway -LocalNetworkGateway2 $lng1 -ConnectionType
IPsec -SharedKey "preSharedKey"
Get-AzureRmVirtualNetworkGatewayConnection -Name "Connection1" -ResourceGroupName "ForcedTunneling"

Configure forced tunneling using the classic
deployment model
Forced tunneling lets you redirect or "force" all Internet-bound traffic back to your on-premises location via a Site-
to-Site VPN tunnel for inspection and auditing. This is a critical security requirement for most enterprise IT policies.
Unauthorized Internet access can potentially lead to information disclosure or other types of security breaches
This article walks you through configuring forced tunneling for virtual networks created using the classic
deployment model. Forced tunneling can be configured by using PowerShell, not through the portal. If you want to
configure forced tunneling for the Resource Manager deployment model, select classic article from the following
dropdown list:
Requirements and considerations

Forced tunneling in Azure is configured via virtual network user defined routes (UDR). Redirecting traffic to an on-
premises site is expressed as a Default Route to the Azure VPN gateway. The following section lists the current
limitation of the routing table and routes for an Azure Virtual Network:
Each virtual network subnet has a built-in, system routing table. The system routing table has the following
three groups of routes:
Local VNet routes: Directly to the destination VMs in the same virtual network
On premises routes: To the Azure VPN gateway
Default route: Directly to the Internet. Packets destined to the private IP addresses not covered by the
previous two routes will be dropped.
With the release of user defined routes, you can create a routing table to add a default route, and then associate
the routing table to your VNet subnet(s) to enable forced tunneling on those subnets.
You need to set a "default site" among the cross-premises local sites connected to the virtual network.
Forced tunneling must be associated with a VNet that has a dynamic routing VPN gateway (not a static
gateway).
ExpressRoute forced tunneling is not configured via this mechanism, but instead, is enabled by advertising a
default route via the ExpressRoute BGP peering sessions. Please see the ExpressRoute Documentation for more
information.
In the following example, the Frontend subnet is not forced tunneled. The workloads in the Frontend subnet can
continue to accept and respond to customer requests from the Internet directly. The Mid-tier and Backend subnets
are forced tunneled. Any outbound connections from these two subnets to the Internet will be forced or redirected
back to an on-premises site via one of the S2S VPN tunnels.
This allows you to restrict and inspect Internet access from your virtual machines or cloud services in Azure, while
continuing to enable your multi-tier service architecture required. You also can apply forced tunneling to the entire
virtual networks if there are no Internet-facing workloads in your virtual networks.
Before you begin

Verify that you have the following items before beginning configuration.
A configured virtual network.
The latest version of the Azure PowerShell cmdlets. See How to install and configure Azure PowerShell for

The following procedure will help you specify forced tunneling for a virtual network. The configuration steps
correspond to the VNet network configuration file.
<VirtualNetworkSite name="MultiTier-VNet" Location="North Europe">
<AddressSpace>
</AddressSpace>
<Subnets>
<Subnet name="Frontend">
</Subnet>
<Subnet name="Midtier">
</Subnet>
<Subnet name="Backend">
</Subnet>
</Subnet>
</Subnets>
<Gateway>
<LocalNetworkSiteRef name="DefaultSiteHQ">
<LocalNetworkSiteRef name="Branch1">
</Gateway>
In this example, the virtual network "MultiTier-VNet" has three subnets: Frontend, Midtier, and Backend subnets,
with four cross premises connections: DefaultSiteHQ, and three Branches.
The steps will set the DefaultSiteHQ as the default site connection for forced tunneling, and configure the Midtier
and Backend subnets to use forced tunneling.
1. Create a routing table. Use the following cmdlet to create your route table.
New-AzureRouteTable Name "MyRouteTable" Label "Routing Table for Forced Tunneling" Location "North
Europe"
2. Add a default route to the routing table.

The following example adds a default route to the routing table created in Step 1. Note that the only route
supported is the destination prefix of "0.0.0.0/0" to the "VPNGateway" NextHop.
Get-AzureRouteTable -Name "MyRouteTable" | Set-AzureRoute RouteTable "MyRouteTable" RouteName

"DefaultRoute" AddressPrefix "0.0.0.0/0" NextHopType VPNGateway
3. Associate the routing table to the subnets.

After a routing table is created and a route added, use the following example to add or associate the route
table to a VNet subnet. The example adds the route table "MyRouteTable" to the Midtier and Backend
subnets of VNet MultiTier-VNet.
Set-AzureSubnetRouteTable -VirtualNetworkName "MultiTier-VNet" -SubnetName "Midtier" -RouteTableName
"MyRouteTable"
Set-AzureSubnetRouteTable -VirtualNetworkName "MultiTier-VNet" -SubnetName "Backend" -RouteTableName
"MyRouteTable"
4. Assign a default site for forced tunneling.

In the preceding step, the sample cmdlet scripts created the routing table and associated the route table to
two of the VNet subnets. The remaining step is to select a local site among the multi-site connections of the
virtual network as the default site or tunnel.
$DefaultSite = @("DefaultSiteHQ")
Set-AzureVNetGatewayDefaultSite VNetName "MultiTier-VNet" DefaultSite "DefaultSiteHQ"
Additional PowerShell cmdlets

To delete a route table
Remove-AzureRouteTable -Name <routeTableName>
To list a route table
Get-AzureRouteTable [-Name <routeTableName> [-DetailLevel <detailLevel>]]
To delete a route from a route table
Remove-AzureRouteTable Name <routeTableName>
To remove a route from a subnet
Remove-AzureSubnetRouteTable VirtualNetworkName <virtualNetworkName> -SubnetName <subnetName>
To list the route table associated with a subnet
Get-AzureSubnetRouteTable -VirtualNetworkName <virtualNetworkName> -SubnetName <subnetName>
To remove a default site from a VNet VPN gateway
Remove-AzureVnetGatewayDefaultSite -VNetName <virtualNetworkName>

Modify local network gateway settings using
PowerShell
Sometimes the settings for your local network gateway AddressPrefix or GatewayIPAddress change. This article
shows you how to modify your local network gateway settings. You can also modify these settings in the Azure
portal or using the Azure CLI.
Before you begin

Install the latest version of the Azure Resource Manager PowerShell cmdlets. See How to install and configure
Azure PowerShell for more information about installing the PowerShell cmdlets.
Modify IP address prefixes

To add additional address prefixes:

-AddressPrefix @('10.0.0.0/24','20.0.0.0/24','30.0.0.0/24')
To remove address prefixes:

Leave out the prefixes that you no longer need. In this example, we no longer need prefix 20.0.0.0/24 (from the
previous example), so we update the local network gateway, excluding that prefix.

-AddressPrefix @('10.0.0.0/24','30.0.0.0/24')

If you have a gateway connection and want to add or remove the IP address prefixes contained in your local
network gateway, you need to do the following steps, in order. This results in some downtime for your VPN
connection. When modifying IP address prefixes, you don't need to delete the VPN gateway. You only need to
remove the connection.
1. Remove the connection.
Remove-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName -ResourceGroupName MyRGName
2. Modify the address prefixes for your local network gateway.

Set the variable for the LocalNetworkGateway.
$local = Get-AzureRmLocalNetworkGateway -Name MyLocalNetworkGWName -ResourceGroupName MyRGName
Modify the prefixes.

-AddressPrefix @('10.0.0.0/24','20.0.0.0/24','30.0.0.0/24')
see the PowerShell cmdlet page.
Set the variable for the VirtualNetworkGateway.
$gateway1 = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName MyRGName
Create the connection. This example uses the variable $local that you set in step 2.
New-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName `

-ResourceGroupName MyRGName -Location 'West US' `
-VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec `
-RoutingWeight 10 -SharedKey 'abc123'
Modify the gateway IP address

To modify the local network gateway 'GatewayIpAddress' - no gateway connection
network gateway to reflect that change. Use the example to modify a local network gateway that does not have a
gateway connection.
When modifying this value, you can also modify the address prefixes at the same time. Be sure to use the existing
name of your local network gateway in order to overwrite the current settings. If you use a different name, you

To modify the local network gateway 'GatewayIpAddress' - existing gateway connection

network gateway to reflect that change. If a gateway connection already exists, you first need to remove the
connection. After the connection is removed, you can modify the gateway IP address and recreate a new
connection. You can also modify the address prefixes at the same time. This results in some downtime for your
VPN connection. When modifying the gateway IP address, you don't need to delete the VPN gateway. You only
need to remove the connection.
1. Remove the connection. You can find the name of your connection by using the 'Get-
AzureRmVirtualNetworkGatewayConnection' cmdlet.
Remove-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName `

-ResourceGroupName MyRGName
2. Modify the 'GatewayIpAddress' value. You can also modify the address prefixes at the same time. Be sure to
use the existing name of your local network gateway to overwrite the current settings. If you don't, you
see the PowerShell cmdlet page. To obtain the VirtualNetworkGateway name, you can run the 'Get-
AzureRmVirtualNetworkGateway' cmdlet.
Set the variables.
$local = Get-AzureRMLocalNetworkGateway -Name MyLocalNetworkGWName -ResourceGroupName MyRGName `

$vnetgw = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName MyRGName
Create the connection.
New-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnectionName -ResourceGroupName MyRGName `

-Location "West US" `
-VirtualNetworkGateway1 $vnetgw `
-LocalNetworkGateway2 $local `
Next steps
You can verify your gateway connection. See Verify a gateway connection.
Modify local network gateway settings using the
Azure CLI
Sometimes the settings for your local network gateway AddressPrefix or GatewayIPAddress change. This article
shows you how to modify your local network gateway settings. You can also modify these settings in the Azure
portal or PowerShell.
Before you begin

Install the latest version of the CLI commands (2.0 or later). For information about installing the CLI commands, see
Install Azure CLI 2.0.
Log in to your Azure subscription with the az login command and follow the on-screen directions. For more
az login
If you have more than one Azure subscription, list the subscriptions for the account.
Modify IP address prefixes

If you don't have a gateway connection and you want to add or remove IP address prefixes, you use the same
command that you use to create the local network gateway, az network local-gateway create. You can also use this
command to update the gateway IP address for the VPN device. To overwrite the current settings, use the existing
name of your local network gateway. If you use a different name, you create a new local network gateway, instead
of overwriting the existing one.
change. Specify only the prefixes that you want to keep. In this case, 10.0.0.0/24 and 20.0.0.0/24
az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 --connection-name TestRG1 --


If you have a gateway connection and want to add or remove IP address prefixes, you can update the prefixes using
az network local-gateway update. This results in some downtime for your VPN connection. When modifying the IP
address prefixes, you don't need to delete the VPN gateway.
change. In this example, 10.0.0.0/24 and 20.0.0.0/24 are already present. We add the prefixes 30.0.0.0/24 and
40.0.0.0/24 and specify all 4 of the prefixes when updating.
az network local-gateway update --local-address-prefixes 10.0.0.0/24 20.0.0.0/24 30.0.0.0/24 40.0.0.0/24 --name

VNet1toSite2 --connection-name TestRG1
Modify the gateway IP address

To modify the local network gateway 'gatewayIpAddress'
network gateway to reflect that change. The gateway IP address can be changed without removing an existing VPN
gateway connection (if you have one). To modify the gateway IP address, replace the values 'Site2' and 'TestRG1'
with your own using the az network local-gateway update command.
az network local-gateway update --gateway-ip-address 23.99.222.170 --name Site2 --resource-group TestRG1
Verify that the IP address is correct in the output:
"gatewayIpAddress": "23.99.222.170",
Next steps
You can verify your gateway connection. See Verify a gateway connection.
Verify a VPN Gateway connection
This article shows you how to verify a VPN gateway connection for both the classic and Resource Manager
deployment models.
Azure portal
PowerShell
To verify a VPN gateway connection for the Resource Manager deployment model using PowerShell, install the
latest version of the Azure Resource Manager PowerShell cmdlets.
Azure CLI
To verify a VPN gateway connection for the Resource Manager deployment model using Azure CLI, install the
latest version of the CLI commands (2.0 or later).

To verify your VPN gateway connection for the classic deployment model using PowerShell, install the latest
versions of the Azure PowerShell cmdlets. Be sure to download and install the Service Management module. Use
'Add-AzureAccount' to log in to the classic deployment model.
You can verify that your connection succeeded by using the 'Get-AzureVNetConnection' cmdlet.
1. Use the following cmdlet example, configuring the values to match your own. The name of the virtual
network must be in quotes if it contains spaces.
Get-AzureVNetConnection "Group ClassicRG ClassicVNet"
2. After the cmdlet has finished, view the values. In the example below, the Connectivity State shows as
LastConnectionEstablished : 1/7/2016 12:40:54 AM
LastEventID : 24401
LastEventMessage : The connectivity state for the local network site 'RMVNetLocal' changed
from Connecting to
Connected.
LastEventTimeStamp : 1/7/2016 12:40:54 AM
LocalNetworkSiteName : RMVNetLocal
Next steps
You can add virtual machines to your virtual networks. See Create a Virtual Machine for steps.
Reset a VPN Gateway
Resetting an Azure VPN gateway is helpful if you lose cross-premises VPN connectivity on one or more Site-to-Site
VPN tunnels. In this situation, your on-premises VPN devices are all working correctly, but are not able to establish
IPsec tunnels with the Azure VPN gateways. This article helps you reset your VPN gateway.
What happens during a reset?
A VPN gateway is composed of two VM instances running in an active-standby configuration. When you reset the
gateway, it reboots the gateway, and then reapplies the cross-premises configurations to it. The gateway keeps the
public IP address it already has. This means you wont need to update the VPN router configuration with a new
public IP address for Azure VPN gateway.
When you issue the command to reset the gateway, the current active instance of the Azure VPN gateway is
rebooted immediately. There will be a brief gap during the failover from the active instance (being rebooted), to the
standby instance. The gap should be less than one minute.
If the connection is not restored after the first reboot, issue the same command again to reboot the second VM
instance (the new active gateway). If the two reboots are requested back to back, there will be a slightly longer
period where both VM instances (active and standby) are being rebooted. This will cause a longer gap on the VPN
connectivity, up to 2 to 4 minutes for VMs to complete the reboots.
After two reboots, if you are still experiencing cross-premises connectivity problems, please open a support request
from the Azure portal.
Before you begin

Before you reset your gateway, verify the key items listed below for each IPsec Site-to-Site (S2S) VPN tunnel. Any
mismatch in the items will result in the disconnect of S2S VPN tunnels. Verifying and correcting the configurations
for your on-premises and Azure VPN gateways saves you from unnecessary reboots and disruptions for the other
working connections on the gateways.
Verify the following items before resetting your gateway:
The Internet IP addresses (VIPs) for both the Azure VPN gateway and the on-premises VPN gateway are
configured correctly in both the Azure and the on-premises VPN policies.
The pre-shared key must be the same on both Azure and on-premises VPN gateways.
If you apply specific IPsec/IKE configuration, such as encryption, hashing algorithms, and PFS (Perfect Forward
Secrecy), ensure both the Azure and on-premises VPN gateways have the same configurations.
Azure portal
You can reset a Resource Manager VPN gateway using the Azure portal. If you want to reset a classic gateway, see
the PowerShell steps.
1. Open the Azure portal and navigate to the Resource Manager virtual network gateway that you want to reset.
2. On the blade for the virtual network gateway, click 'Reset'.
3. On the Reset blade, click the Reset button.
PowerShell
The cmdlet for resetting a gateway is Reset-AzureRmVirtualNetworkGateway. Before performing a reset, make
sure you have the latest version of the Resource Manager PowerShell cmdlets. The following example resets a
virtual network gateway named VNet1GW in the TestRG1 resource group:
$gw = Get-AzureRmVirtualNetworkGateway -Name VNet1GW -ResourceGroup TestRG1

Reset-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $gw
Result:
When you receive a return result, you can assume the gateway reset was successful. However, there is nothing in
the return result that indicates explicitly that the reset was successful. If you want to look closely at the history to
see exactly when the gateway reset occurred, you can view that information in the Azure portal. In the portal,
navigate to 'GatewayName' -> Resource Health.
The cmdlet for resetting a gateway is Reset-AzureVNetGateway. Before performing a reset, make sure you have
the latest version of the Service Management (SM) PowerShell cmdlets. The following example resets the gateway
for a virtual network named "ContosoVNet":
Reset-AzureVNetGateway VnetName ContosoVNet
Result:
Error :
HttpStatusCode : OK
Id : f1600632-c819-4b2f-ac0e-f4126bec1ff8
Status : Successful
RequestId : 9ca273de2c4d01e986480ce1ffa4d6d9
StatusCode : OK
Azure CLI
To reset the gateway, use the az network vnet-gateway reset command. The following example resets a virtual
network gateway named VNet5GW in the TestRG5 resource group:
az network vnet-gateway reset -n VNet5GW -g TestRG5
Result:
When you receive a return result, you can assume the gateway reset was successful. However, there is nothing in
the return result that indicates explicitly that the reset was successful. If you want to look closely at the history to
see exactly when the gateway reset occurred, you can view that information in the Azure portal. In the portal,
navigate to 'GatewayName' -> Resource Health.
Delete a virtual network gateway using the portal
There are a couple of different approaches you can take when you want to delete a virtual network gateway for a
VPN gateway configuration.
If you want to delete everything and start over, as in the case of a test environment, you can delete the
resource group. When you delete a resource group, it deletes all the resources within the group. This is
method is only recommended if you don't want to keep any of the resources in the resource group. You
can't selectively delete only a few resources using this approach.
If you want to keep some of the resources in your resource group, deleting a virtual network gateway
becomes slightly more complicated. Before you can delete the virtual network gateway, you must first
delete any resources that are dependent on the gateway. The steps you follow depend on the type of
connections that you created and the dependent resources for each connection.
Delete a VPN gateway

To delete a virtual network gateway, you must first delete each resource that pertains to the virtual network
gateway. Resources must be deleted in a certain order due to dependencies.
Step 1: Navigate to the virtual network gateway
In the Azure portal, in All resources, click the virtual network gateway that you want to delete. The graphic for a
gateway is:
Step 2: Delete connections

1. On the blade for your virtual network gateway, click Connections to view all connections to the gateway.
2. Click the ... on the row of the name of the connection, then select Delete from the dropdown.
3. Click Yes to confirm that you want to delete the connection. If you have multiple connections, delete each
connection.
Step 3: Delete the local network gateways
1. In All resources, locate the local network gateways that were associated with each connection. The graphic
for a local network gateway is:
2. On the Overview blade for the local network gateway, click Delete.
Step 4: Delete the virtual network gateway
1. In All resources, locate the virtual network gateway that you want to delete.
2. On the Overview blade, click Delete to delete the gateway.
NOTE
If you have a P2S configuration to this VNet in addition to your S2S configuration, deleting the virtual network gateway will
automatically disconnect all P2S clients without warning.
Step 5: Delete the Public IP address for the gateway

1. In All resources, locate the Public IP address that was assigned to the gateway. If the virtual network
gateway was active-active, you will see two Public IP addresses. The graphic for a Public IP address is:
2. On the Overview page for the Public IP address, click Delete, then Yes to confirm.
Step 6: Delete the gateway subnet
1. In All resources, locate the virtual network.
2. On the Subnets blade, click the GatewaySubnet, then click Delete.
3. Click Yes to confirm that you want to delete the gateway subnet.
Delete a VPN gateway by deleting the resource group

If you are not concerned about keeping any of your resources in the resource group and you just want to start
over, you can delete an entire resource group. This is a quick way to remove everything. The following steps apply
only to the Resource Manager deployment model.
1. In All resources, locate the resource group and click to open the blade.
2. Click Delete. On the Delete blade, view the affected resources. Make sure that you want to delete all of these
resources. If not, use the steps in Delete a VPN gateway at the top of this article.
3. To proceed, type the name of the resource group that you want to delete, then click Delete.
Delete a virtual network gateway using PowerShell
There are a couple of different approaches you can take when you want to delete a virtual network gateway for a
VPN gateway configuration.
If you want to delete everything and start over, as in the case of a test environment, you can delete the
resource group. When you delete a resource group, it deletes all the resources within the group. This is
method is only recommended if you don't want to keep any of the resources in the resource group. You
can't selectively delete only a few resources using this approach.
If you want to keep some of the resources in your resource group, deleting a virtual network gateway
becomes slightly more complicated. Before you can delete the virtual network gateway, you must first
delete any resources that are dependent on the gateway. The steps you follow depend on the type of
connections that you created and the dependent resources for each connection.
Before beginning
1. Download the latest Azure Resource Manager PowerShell cmdlets.
Download and install the latest version of the Azure Resource Manager PowerShell cmdlets. For more information
about downloading and installing PowerShell cmdlets, see How to install and configure Azure PowerShell.
2. Connect to your Azure account.
Open your PowerShell console and connect to your account. Use the following example to help you connect:
If you have more than one subscription, specify the subscription that you want to use.
Delete a Site-to-Site VPN gateway

To delete a virtual network gateway for a S2S configuration, you must first delete each resource that pertains to
the virtual network gateway. Resources must be deleted in a certain order due to dependencies. When working
with the examples below, some of the values must be specified, while other values are an output result. We use the
following specific values in the examples for demonstration purposes:
VNet name: VNet1
Resource Group name: RG1
Virtual network gateway name: GW1
The following steps apply to the Resource Manager deployment model.
1. Get the virtual network gateway that you want to delete.
$Gateway=get-azurermvirtualnetworkgateway -Name "GW1" -ResourceGroupName "RG1"
2. Check to see if the virtual network gateway has any connections.
get-azurermvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object

{$_.VirtualNetworkGateway1.Id -eq $GW.Id}
$Conns=get-azurermvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object
3. Delete all connections.

You may be prompted to confirm the deletion of each of the connections.
$Conns | ForEach-Object {Remove-AzureRmVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName

$_.ResourceGroupName}
4. Get the list of the corresponding local network gateways.
$LNG=Get-AzureRmLocalNetworkGateway -ResourceGroupName "RG1" | where-object {$_.Id -In

$Conns.LocalNetworkGateway2.Id}
5. Delete the local network gateways.

You may be prompted to confirm the deletion of each of the local network gateway.
$LNG | ForEach-Object {Remove-AzureRmLocalNetworkGateway -Name $_.Name -ResourceGroupName

6. Delete the virtual network gateway.

You may be prompted to confirm the deletion of the gateway.
NOTE
If you have a P2S configuration to this VNet in addition to your S2S configuration, deleting the virtual network gateway will
automatically disconnect all P2S clients without warning.
Remove-AzureRmVirtualNetworkGateway -Name "GW1" -ResourceGroupName "RG1"
7. Get the IP configurations of the virtual network gateway.
$GWIpConfigs = $Gateway.IpConfigurations
8. Get the list of Public IP addresses used for this virtual network gateway
If the virtual network gateway was active-active, you will see two Public IP addresses.
$PubIP=Get-AzureRmPublicIpAddress | where-object {$_.Id -In $GWIpConfigs.PublicIpAddress.Id}
9. Delete the Public IPs.
$PubIP | foreach-object {remove-azurermpublicIpAddress -Name $_.Name -ResourceGroupName "RG1"}

10. Delete the gateway subnet and set the configuration.
$GWSub = Get-AzureRmVirtualNetwork -ResourceGroupName "RG1" -Name "VNet1" | Remove-

AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet"
Set-AzureRmVirtualNetwork -VirtualNetwork $GWSub
Delete a VNet-to-VNet VPN gateway

To delete a virtual network gateway for a V2V configuration, you must first delete each resource that pertains to
VNet name: VNet1
2. Check to see if the virtual network gateway has any connections.

There may be other connections to the virtual network gateway that are part of a different resource group. Check
for additional connections in each additional resource group. In this example, we are checking for connections
from RG2. Run this for each resource group that you have which may have a connection to the virtual network
gateway.

3. Get the list of connections in both directions.

Because this is a VNet-to-VNet configuration, you need the list of connections in both directions.
$ConnsL=get-azurermvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object

In this example, we are checking for connections from RG2. Run this for each resource group that you have which
may have a connection to the virtual network gateway.
$ConnsR=get-azurermvirtualnetworkgatewayconnection -ResourceGroupName "<NameOfResourceGroup2>" | where-object

4. Delete all connections.

You may be prompted to confirm the deletion of each of the connections.
$ConnsL | ForEach-Object {Remove-AzureRmVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName
$ConnsR | ForEach-Object {Remove-AzureRmVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName

You may be prompted to confirm the deletion of the virtual network gateway.
NOTE
If you have P2S configurations to your VNets in addition to your V2V configuration, deleting the virtual network gateways
will automatically disconnect all P2S clients without warning.
7. Get the list of Public IP addresses used for this virtual network gateway.

You may be prompted to confirm the deletion of the Public IP.
$PubIP | foreach-object {remove-azurermpublicIpAddress -Name $_.Name -ResourceGroupName "

<NameOfResourceGroup1>"}

Delete a Point-to-Site VPN gateway

To delete a virtual network gateway for a P2S configuration, you must first delete each resource that pertains to
VNet name: VNet1
NOTE
When you delete the VPN gateway, all connected clients will be disconnected from the VNet without warning.

You may be prompted to confirm the deletion of the virtual network gateway.
4. Get the list of Public IP addresses used for this virtual network gateway.

You may be prompted to confirm the deletion of the Public IP.
$PubIP | foreach-object {remove-azurermpublicIpAddress -Name $_.Name -ResourceGroupName "

<NameOfResourceGroup1>"}

Delete a VPN gateway by deleting the resource group

If you are not concerned about keeping any of your resources in the resource group and you just want to start
over, you can delete an entire resource group. This is a quick way to remove everything. The following steps apply
only to the Resource Manager deployment model.
1. Get a list of all the resource groups in your subscription.
Get-AzureRmResourceGroup
2. Locate the resource group that you want to delete.

Locate the resource group that you want to delete and view the list of resources in that resource group. In the
example, the name of the resource group is RG1. Modify the example to retrieve a list of all the resources.
Find-AzureRmResource -ResourceGroupNameContains RG1
3. Verify the resources in the list.

When the list is returned, review it to verify that you want to delete all the resources in the resource group, as well
as the resource group itself. If you want to keep some of the resources in the resource group, use the steps in the
earlier sections of this article to delete your gateway.
4. Delete the resource group and resources.
To delete the resource group and all the resource contained in the resource group, modify the example and run.
Remove-AzureRmResourceGroup -Name RG1
5. Check the status.

It takes some time for Azure to delete all the resources. You can check the status of your resource group by using
this cmdlet.
Get-AzureRmResourceGroup -ResourceGroupName RG1
The result that is returned shows 'Succeeded'.
ResourceGroupName : RG1
Location : eastus
ProvisioningState : Succeeded
Delete a virtual network gateway using PowerShell
(classic)
This article helps you delete a VPN gateway in the classic deployment model by using PowerShell. After the virtual
network gateway has been deleted, modify the network configuration file to remove elements that you are no
longer using.
Step 1: Connect to Azure

1. Install the latest PowerShell cmdlets.
Download and install the latest version of the Azure Service Management (SM) PowerShell cmdlets. For more
information, see How to install and configure Azure PowerShell.
2. Connect to your Azure account.
Open your PowerShell console with elevated rights and connect to your account. Use the following example to
help you connect:
Add-AzureAccount
Step 2: Export and view the network configuration file

Create a directory on your computer and then export the network configuration file to the directory. You use this
file to both view the current configuration information, and also to modify the network configuration.
In this example, the network configuration file is exported to C:\AzureNet.
Open the file with a text editor and view the name for your classic VNet. When you create a VNet in the Azure
portal, the full name that Azure uses is not visible in the portal. For example, a VNet that appears to be named
'ClassicVNet1' in the Azure portal, may have a much longer name in the network configuration file. The name
might look something like: 'Group ClassicRG1 ClassicVNet1'. Virtual network names are listed as
'VirtualNetworkSite name ='. Use the names in the network configuration file when running your PowerShell
cmdlets.
Step 3: Delete the virtual network gateway

When you delete a virtual network gateway, all connections to the VNet through the gateway are disconnected. If
you have P2S clients connected to the VNet, they will be disconnected without warning.
This example deletes the virtual network gateway. Make sure to use the full name of the virtual network from the
network configuration file.
Remove-AzureVNetGateway -VNetName "Group ClassicRG1 ClassicVNet1"
If successful, the return shows:

Status : Successful
Step 4: Modify the network configuration file

When you delete a virtual network gateway, the cmdlet does not modify the network configuration file. You need
to modify the file to remove the elements that are no longer being used. The following sections help you modify
the network configuration file that you downloaded.
Local Network Site References
To remove site reference information, make configuration changes to
ConnectionsToLocalNetwork/LocalNetworkSiteRef. Removing a local site reference triggers Azure to delete a
tunnel. Depending on the configuration that you created, you may not have a LocalNetworkSiteRef listed.
<Gateway>
<LocalNetworkSiteRef name="D1BFC9CB_Site2">
</Gateway>
Example:
<Gateway>
</Gateway>
Local Network Sites

Remove any local sites that you are no longer using. Depending on the configuration you created, it is possible
that you don't have a LocalNetworkSite listed.
<LocalNetworkSites>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
In this example, we removed only Site3.

<LocalNetworkSites>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
Client AddressPool
If you had a P2S connection to your VNet, you will have a VPNClientAddressPool. Remove the client address
pools that correspond to the virtual network gateway that you deleted.
<Gateway>
<VPNClientAddressPool>
</VPNClientAddressPool>
<ConnectionsToLocalNetwork />
</Gateway>
Example:
<Gateway>
<ConnectionsToLocalNetwork />
</Gateway>
GatewaySubnet
Delete the GatewaySubnet that corresponds to the VNet.
<Subnets>
<Subnet name="FrontEnd">
</Subnet>
</Subnet>
</Subnets>
Example:
<Subnets>
<Subnet name="FrontEnd">
</Subnet>
</Subnets>
Step 5: Upload the network configuration file

Save your changes and upload the network configuration file to Azure. Make sure you change the file path as
necessary for your environment.
If successful, the return shows something similar to this example:

OperationDescription OperationId OperationStatus
-------------------- ----------- ---------------
Set-AzureVNetConfig e0ee6e66-9167-cfa7-a746-7casb9 Succeeded
Configure a VPN gateway in the classic portal
If you want to create a secure cross-premises connection between Azure and your on-premises location, you need
to create a virtual network gateway. A VPN gateway is a specific type of virtual network gateway. In the classic
deployment model, a VPN gateway can be one of two VPN routing types: static, or dynamic. The VPN type you
choose depends on both your network design plan, and the on-premises VPN device you want to use. For more
information about VPN devices, see About VPN Devices.
About Azure deployment models
The following steps walk you through configuring your VPN gateway in the classic portal. These steps apply to
gateways for virtual networks that were created using the classic deployment model. Currently, not all of the
configuration settings for gateways are available in the Azure portal. When they are, we will create a new set of
instructions that apply to the Azure portal.
Before you begin
Before you configure your gateway, you first need to create your virtual network. For steps to create a virtual
network for cross-premises connectivity, see Configure a virtual network with a site-to-site VPN connection, or
Configure a virtual network with a point-to-site VPN connection. Then, use the following steps to configure the
VPN gateway and gather the information you need to configure your VPN device.
If you already have a VPN gateway and you want to change the VPN routing type, see How to change the VPN
routing type for your gateway.
Create a VPN gateway

1. In the Azure classic portal, on the Networks page, verify that the status column for your virtual network is
Created.
2. In the Name column, click the name of your virtual network.
3. On the Dashboard page, notice that this VNet doesn't have a gateway configured yet. You'll see this status as
you go through the steps to configure your gateway.
Next, at the bottom of the page, click Create Gateway. You can select either Static Routing or Dynamic Routing.
The VPN routing type you select depends on few factors. For example, what your VPN device supports and
whether you need to support point-to-site connections. Check About VPN Devices for Virtual Network
Connectivity to verify the VPN routing type that you need. Once the gateway has been created, you can't change
between gateway VPN routing types without deleting and re-creating the gateway. When the system prompts you
to confirm that you want the gateway created, click Yes.
When your gateway is creating, notice the gateway graphic on the page changes to yellow and says Creating
Gateway. It may take up to 45 minutes for the gateway to create. Wait until the gateway is complete before you
can move forward with other configuration settings.
When the gateway changes to Connecting, you can gather the information you'll need for your VPN device.
Site-to-Site connections
Step 1. Gather information for your VPN device configuration
If you are creating a Site-to-Site connection, after the gateway has been created, gather information for your VPN
device configuration. This information is located on the Dashboard page for your virtual network:
1. Gateway IP address - The IP address can be found on the Dashboard page. You won't be able to see it until
after your gateway has finished creating.
2. Shared key - Click Manage Key at the bottom of the screen. Click the icon next to the key to copy it to your
clipboard, and then paste and save the key. This button only works when there is a single S2S VPN tunnel. If
you have multiple S2S VPN tunnels, use the Get Virtual Network Gateway Shared Key API or PowerShell
cmdlet.
Step 2. Configure your VPN device

Site-to-Site connections to an on-premises network require a VPN device. While we don't provide configuration
steps for all VPN devices, you may find the information in the following links helpful:
For links to device configuration settings, see Validated VPN Devices. These links are provided on a best-effort
basis. It's always best to check with your device manufacturer for the latest configuration information.
For IPsec/IKE parameters, see Parameters.
you want to use.
When configuring your VPN device, you will need the following items:
The Public IP address of your virtual network gateway. You can locate this by going to the Overview blade for
your virtual network.
our examples, we use a very basic shared key. You should generate a more complex key to use.
After the VPN device has been configured, you can view your updated connection information on the Dashboard
page for your VNet.
Step 3. Verify your local network ranges and VPN gateway IP address
Verify your VPN gateway IP address
For gateway to connect properly, the IP address for your VPN device must be correctly configured for the Local
Network that you specified for your cross-premises configuration. Typically, this is configured during the site-to-
site configuration process. However, if you previously used this local network with a different device, or the IP
address has changed for this local network, edit the settings to specify the correct Gateway IP address.
1. To verify your gateway IP address, click Networks on the left portal pane and then select Local Networks at
the top of the page. You'll see the VPN Gateway Address for each local network that you have created. To edit
the IP address, select the VNet and click Edit at the bottom of the page.
2. On the Specify your local network details page, edit the IP address, and then click the next arrow at the
bottom of the page.
3. On the Specify the address space page, click the checkmark on the lower right to save your settings.
Verify the address ranges for your local networks
For the correct traffic to flow through the gateway to your on-premises location, you need to verify that each IP
address range is specified. Each range must be listed in your Azure Local Networks configuration. Depending on
the network configuration of your on-premises location, this can be a somewhat large task. Traffic that is bound
for an IP address that is contained within the listed ranges will be sent through the virtual network VPN gateway.
The ranges that you list don't have to be private ranges, although you will want to verify that your on-premises
configuration can receive the inbound traffic.
To add or edit the ranges for a Local Network, use the following steps:
1. To edit the IP address ranges for a local network, click Networks on the left portal pane and then select Local
Networks at the top of the page. In the portal, the easiest way to view the ranges that you've listed is on the
Edit page. To see your ranges, select the VNet and click Edit at the bottom of the page.
2. On the Specify your local network details page, don't make any changes. Click the next arrow at the bottom
of the page.
3. On the Specify the address space page, make your network address space changes. Then click the checkmark
to save your configuration.
How to view gateway traffic

You can view your gateway and gateway traffic from your Virtual Network Dashboard page.
On the Dashboard page you can view the following:
The amount of data that is flowing through your gateway, both data in and data out.
The names of the DNS servers that are specified for your virtual network.
The connection between your gateway and your VPN device.
The shared key that is used to configure your gateway connection to your VPN device.
How to change the VPN routing type for your gateway
Because some connectivity configurations are only available for certain gateway routing types, you may find that
you need to change the gateway VPN routing type of an existing VPN gateway. For example, you may want to add
point-to-site connectivity to an already existing site-to-site connection that has a static gateway. Point-to-site
connections require a dynamic gateway. This means to configure a P2S connection, you have to change your
gateway VPN routing type from static to dynamic.
If you need to change a gateway VPN routing type, you'll delete the existing gateway, and then create a new
gateway with the new routing type. You don't need to delete the entire virtual network to change the gateway
routing type.
Before changing your gateway VPN routing type, be sure to verify that your VPN device supports the routing type
that you want to use. To download new routing configuration samples and check VPN device requirements, see
About VPN Devices for Virtual Network Connectivity.
IMPORTANT
When you delete a virtual network VPN gateway, the VIP assigned to the gateway is released. When you recreate the
gateway, a new VIP is assigned to it.
1. Delete the existing VPN gateway.

On the Dashboard page for your virtual network, navigate to the bottom of the page and click Delete
Gateway. Wait for the notification that the gateway has been deleted. Once you receive the notification on
the screen that your gateway has been deleted, you can create a new gateway.
2. Create a new VPN gateway.
Use the procedure at the top of the page to create a new gateway: Create a VPN gateway.
Next steps
You can add virtual machines to your virtual network. See How to create a custom virtual machine.
If you want to configure a point-to-site VPN connection, see Configure a point-to-site VPN connection.
Working with virtual network gateway SKUs (old
SKUs)
This article contains information about the old virtual network gateway SKUs. For information on the current SKUs,
see About VPN Gateway.
Gateway SKUs
The old VPN gateway SKUs are:
Basic
Standard
HighPerformance
VPN Gateway does not use the UltraPerformance gateway SKU. For information about the UltraPerformance SKU,
see the ExpressRoute documentation.
When working with the old SKUs, consider the following:
If you want to use a PolicyBased VPN type, you must use the Basic SKU. PolicyBased VPNs (previously called
Static Routing) are not supported on any other SKU.
BGP is not supported on the Basic SKU.
ExpressRoute-VPN Gateway coexist configurations are not supported on the Basic SKU.
Active-active S2S VPN Gateway connections can be configured on the HighPerformance SKU only.
Estimated aggregate throughput by SKU

The following table shows the gateway types and the estimated aggregate throughput by gateway SKU. This table
applies to the Resource Manager and classic deployment models.
Pricing differs between gateway SKUs. For more information, see VPN Gateway Pricing.
Note that the UltraPerformance gateway SKU is not represented in this table. For information about the
UltraPerformance SKU, see the ExpressRoute documentation.
EXPRESSROUTE VPN GATEWAY AND

VPN GATEWAY VPN GATEWAY MAX GATEWAY EXPRESSROUTE
THROUGHPUT (1) IPSEC TUNNELS (2) THROUGHPUT COEXIST
Basic SKU (3)(5)(6) 100 Mbps 10 500 Mbps (6) No
Standard SKU (4)(5) 100 Mbps 10 1000 Mbps Yes
High Performance 200 Mbps 30 2000 Mbps Yes

SKU (4)
(1) The VPN throughput is a rough estimate based on the measurements between VNets in the same Azure region.
It is not a guaranteed throughput for cross-premises connections across the Internet. It is the maximum possible
throughput measurement.
(2) The number of tunnels refer to RouteBased VPNs. A PolicyBased VPN can only support one Site-to-Site VPN
tunnel.
(3) BGP is not supported for the Basic SKU.
(4) PolicyBased VPNs are not supported for this SKU. They are supported for the Basic SKU only.
(5) Active-active S2S VPN Gateway connections are not supported for this SKU. Active-active is supported on the
HighPerformance SKU only.
(6) Basic SKU is deprecated for use with ExpressRoute.
Supported configurations by SKU and VPN type

The following table lists the requirements for PolicyBased and RouteBased VPN gateways. This table applies to
both the Resource Manager and classic deployment models. For the classic model, PolicyBased VPN gateways are
the same as Static gateways, and Route-based gateways are the same as Dynamic gateways.
ROUTEBASED ROUTEBASED HIGH

POLICYBASED BASIC ROUTEBASED BASIC STANDARD VPN PERFORMANCE VPN
VPN GATEWAY VPN GATEWAY GATEWAY GATEWAY
Site-to-Site PolicyBased VPN RouteBased VPN RouteBased VPN RouteBased VPN

connectivity (S2S) configuration configuration configuration configuration
Point-to-Site Not supported Supported (Can Supported (Can Supported (Can

connectivity (P2S) coexist with S2S) coexist with S2S) coexist with S2S)
Authentication Pre-shared key Pre-shared key for Pre-shared key for Pre-shared key for
method S2S connectivity, S2S connectivity, S2S connectivity,
Certificates for P2S Certificates for P2S Certificates for P2S
connectivity connectivity connectivity
Maximum number 1 10 10 30
of S2S connections
Maximum number Not supported 128 128 128

of P2S connections
Active routing Not supported Not supported Supported Supported

support (BGP)
Migrating to the new gateway SKUs

new (VpnGw1/VpnGw2/VpnGw3) SKU families. You need to delete the existing (Basic/Standard/HighPerformance)
gateway and create a new (VpnGw1/VpnGw2/VpnGw3) gateway with the new SKUs. Note that your Azure
Gateway public IP address will change as a result.
For more information about the new Gateway SKUs, see Gateway SKUs.
How to validate VPN throughput to a virtual network
A VPN gateway connection enables you to establish secure, cross-premises connectivity between your Virtual
Network within Azure and your on-premises IT infrastructure.
This article shows how to validate network throughput from the on-premises resources to an Azure virtual
machine. It also provides troubleshooting guidance.
NOTE
This article is intended to help diagnose and fix common issues. If you're unable to solve the issue by using the following
information, contact support.
Overview
The VPN gateway connection involves the following components:
On-premises VPN device (view a list of validated VPN devices).
Public Internet
Azure VPN gateway
Azure virtual machine
The following diagram shows the logical connectivity of an on-premises network to an Azure virtual network
through VPN.
Calculate the maximum expected ingress/egress

1. Determine your application's baseline throughput requirements.
2. Determine your Azure VPN gateway throughput limits. For help, see the "Aggregate throughput by SKU and
VPN type" section of Planning and design for VPN Gateway.
3. Determine the Azure VM throughput guidance for your VM size.
4. Determine your Internet Service Provider (ISP) bandwidth.
5. Calculate your expected throughput - Least bandwidth of (VM, Gateway, ISP) * 0.8.
If your calculated throughput does not meet your application's baseline throughput requirements, you need to
increase the bandwidth of the resource that you identified as the bottleneck. To resize an Azure VPN Gateway, see
Changing a gateway SKU. To resize a virtual machine, see Resize a VM. If you are not experiencing expected Internet
bandwidth, you may also want to contact your ISP.
Validate network throughput by using performance tools

This validation should be performed during non-peak hours, as VPN tunnel throughput saturation during testing
does not give accurate results.
The tool we use for this test is iPerf, which works on both Windows and Linux and has both client and server
modes. It is limited to 3 Gbps for Windows VMs.
This tool does not perform any read/write operations to disk. It solely produces self-generated TCP traffic from one
end to the other. It generated statistics based on experimentation that measures the bandwidth available between
client and server nodes. When testing between two nodes, one acts as the server and the other as a client. Once this
test is completed, we recommend that you reverse the roles to test both upload and download throughput on both
nodes.
Download iPerf
Download iPerf. For details, see iPerf documentation.
NOTE
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft.
Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
Run iPerf (iperf3.exe )

1. Enable an NSG/ACL rule allowing the traffic (for public IP address testing on Azure VM).
2. On both nodes, enable a firewall exception for port 5001.
Windows: Run the following command as an administrator:
netsh advfirewall firewall add rule name="Open Port 5001" dir=in action=allow protocol=TCP
localport=5001
To remove the rule when testing is complete, run this command:
netsh advfirewall firewall delete rule name="Open Port 5001" protocol=TCP localport=5001
Azure Linux: Azure Linux images have permissive firewalls. If there is an application listening on a port, the
traffic is allowed through. Custom images that are secured may need ports opened explicitly. Common Linux
OS-layer firewalls include iptables , ufw , or firewalld .
3. On the server node, change to the directory where iperf3.exe is extracted. Then run iPerf in server mode and
set it to listen on port 5001 as the following commands:
cd c:\iperf-3.1.2-win65
iperf3.exe -s -p 5001
4. On the client node, change to the directory where iperf tool is extracted and then run the following
command:
iperf3.exe -c <IP of the iperf Server> -t 30 -p 5001 -P 32
The client is inducing traffic on port 5001 to the server for 30 seconds. The flag '-P ' that indicates we are
using 32 simultaneous connections to the server node.
The following screen shows the output from this example:
5. (OPTIONAL) To preserve the testing results, run this command:
iperf3.exe -c IPofTheServerToReach -t 30 -p 5001 -P 32 >> output.txt
6. After completing the previous steps, execute the same steps with the roles reversed, so that the server node
will now be the client and vice-versa.
Address slow file copy issues

You may experience slow file coping when using Windows Explorer or dragging and dropping through an RDP
session. This problem is normally due to one or both of the following factors:
File copy applications, such as Windows Explorer and RDP, do not use multiple threads when copying files. For
better performance, use a multi-threaded file copy application such as Richcopy to copy files by using 16 or 32
threads. To change the thread number for file copy in Richcopy, click Action > Copy options > File copy.
Insufficient VM disk read/write speed. For more information, see Azure Storage Troubleshooting.
On-premises device external facing interface

If the on-premises VPN device Internet-facing IP address is included in the local network definition in Azure, you
may experience inability to bring up the VPN, sporadic disconnects, or performance issues.
Checking latency
Use tracert to trace to Microsoft Azure Edge device to determine if there are any delays exceeding 100 ms between
hops.
From the on-premises network, run tracert to the VIP of the Azure Gateway or VM. Once you see only * returned,
you know you have reached the Azure edge. When you see DNS names that include "MSN" returned, you know
you have reached the Microsoft backbone.
Next steps
For more information or help, check out the following links:
Optimize network throughput for Azure virtual machines
Microsoft Support

Configure VPN Gateway Connections

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Configure VPN Gateway Connections

Caricato da

Copyright:

Formati disponibili

Table of Contents

S2S/VNET-TO-VNET P2S AGGREGATE

VpnGw1 Max. 30 Max. 128 500 Mbps

VpnGw2 Max. 30 Max. 128 1 Gbps

VpnGw3 Max. 30 Max. 128 1.25 Gbps

Basic Max. 10 Max. 128 100 Mbps

Production, critical workloads VpnGw1, VpnGw2, VpnGw3

Dev-test or proof of concept Basic

VpnGw1 Route- and policy-based VPN up to 30 tunnels

Basic Route-based: 10 tunnels with P2S

Resizing gateway SKUs

Migrating from old SKUs to VpnGw1/VpnGw2/VpnGw3

Configuring a VPN Gateway

Connection topology diagrams

Site-to-Site and Multi-Site (IPsec/IKE VPN tunnel)

Resource Manager Article Not Supported Article Article

Classic Article** Article* Article+ Not Supported

Point-to-Site (VPN over SSTP)

Classic Article Supported Supported

Resource Manager Article Not Supported Article

VNet-to-VNet connections (IPsec/IKE VPN tunnel)

Connections between deployment models

Classic Article* Article* Supported Not Supported

Resource Manager Article+ Not Supported Article Article

Connections Article* Supported* Article Not Supported

ExpressRoute (dedicated private connection)

Site-to-Site and ExpressRoute coexisting connections

Classic Portal Not Supported Not Supported

Azure Portal Not Supported Not Supported

PowerShell Article Article

Connecting to virtual networks

Virtual network gateways

Site-to-Site connections and VPN devices

VNet-to-VNet and Multi-Site connections

IKEv2 Encryption AES256, AES192, AES128, DES3, DES

IKEv2 Integrity SHA384, SHA256, SHA1, MD5

DH Group ECP384, ECP256, DHGroup24, DHGroup14, DHGroup2048,

IPsec Encryption GCMAES256, GCMAES192, GCMAES128, AES256, AES192,

IPsec Integrity GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1,

QM SA Lifetime* Seconds (integer) and KBytes (integer)

Traffic Selector UsePolicyBasedTrafficSelectors** ($True/$False)

Cross-premises connectivity and VMs

Virtual Network FAQ

Limits and the Azure Resource Manager

Cores per subscription 1 20 10,000

Co-administrators per subscription 200 200

Storage accounts per subscription2 200 250

Cloud services per subscription 20 200

Local networks per subscription 10 500

SQL Database servers per subscription 6 150

DNS servers per subscription 9 100

Reserved IPs per subscription 20 100

Hosted service certificates per 400 400

Affinity groups per subscription 256 256

Alert rules per subscription 250 250

RESOURCE DEFAULT LIMIT MAXIMUM LIMIT

VMs per subscription 201 per Region 10,000 per Region

VM total cores per subscription 201 per Region Contact support

Co-administrators per subscription Unlimited Unlimited

Storage accounts per subscription 200 2002

Resource Groups per subscription 800 800

Resource Manager API request size 4194304 bytes 4194304 bytes

Tags per subscription 10000 10000