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. A VPN gateway can take up to 45 minutes to create. This is because the VMs for the VPN gateway are being deployed to the GatewaySubnet and configured with the settings that you specified. The Gateway SKU that you select determines how powerful the VMs are.
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.
The new VPN gateway SKUs (VpnGw1, VpnGw2, and VpnGw3) are supported for the Resource Manager deployment model only. Classic virtual networks should continue to use the old SKUs. For more information about the old gateway SKUs, see Working with virtual network gateway SKUs (old).
Azure offers the following VPN gateway SKUs:
|VpnGw1||Max. 30||Max. 128||650 Mbps|
|VpnGw2||Max. 30||Max. 128||1 Gbps|
|VpnGw3||Max. 30||Max. 128||1.25 Gbps|
|Basic||Max. 10||Max. 128||100 Mbps|
Aggregate Throughput Benchmark 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:
|Production, critical workloads||VpnGw1, VpnGw2, VpnGw3|
|Dev-test or proof of concept||Basic|
If you are using the old SKUs, the production SKU recommendations are Standard and HighPerformance SKUs. For information on the old SKUs, see Gateway SKUs (legacy SKUs).
Gateway SKU feature sets
The new gateway SKUs streamline the feature sets offered on the gateways:
|Basic||For Route-based VPN type: 10 tunnels with P2S
For Policy-based VPN type: (IKEv1): 1 tunnel; no P2S
|VpnGw1, VpnGw2, and VpnGw3||Route-based VPN up to 30 tunnels (*), P2S, BGP, active-active, custom IPsec/IKE policy, ExpressRoute/VPN co-existence|
(*) You can configure "PolicyBasedTrafficSelectors" to connect a route-based VPN gateway (VpnGw1, VpnGw2, VpnGw3) to multiple on-premises policy-based firewall devices. Refer to Connect VPN gateways to multiple on-premises policy-based VPN devices using PowerShell for details.
Resizing gateway SKUs
- You can resize between VpnGw1, VpnGw2, and VpnGw3 SKUs.
- When working with the old gateway SKUs, you can resize between Basic, Standard, and HighPerformance SKUs.
- You cannot resize from Basic/Standard/HighPerformance SKUs to the new VpnGw1/VpnGw2/VpnGw3 SKUs. You must, instead, migrate to the new SKUs.
Migrating from old SKUs to the new SKUs
- The VPN gateway Public IP address will change when migrating from an old SKU to a new SKU.
- You can't migrate classic VPN gateways to the new SKUs. Classic VPN gateways can only use the legacy (old) SKUs.
You can't resize your Azure VPN gateways between the old SKUs and the new SKU families. If you have VPN gateways in the Resource Manager deployment model that are using the older version of the SKUs, you can migrate to the new SKUs. To migrate, you delete the existing VPN gateway for your virtual network, then create a new one.
- Remove any connections to the virtual network gateway.
- Delete the old VPN gateway.
- Create the new VPN gateway.
- Update your on-premises VPN devices with the new VPN gateway IP address (for Site-to-Site connections).
- Update the gateway IP address value for any VNet-to-VNet local network gateways that will connect to this gateway.
- Download new client VPN configuration packages for P2S clients connecting to the virtual network through this VPN gateway.
- Recreate the connections to the virtual network gateway.
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.
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. The article contains 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.
You can start out creating and configuring resources using one configuration tool, such as the Azure portal. You can 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.
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)
A Site-to-Site (S2S) VPN gateway connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. A S2S 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.
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|
(*) 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 lets you create a secure connection to your virtual network from an individual client computer. Point-to-Site VPN connections are useful when you want to connect to your VNet from a remote location, such when you are telecommuting from home or a conference. A P2S VPN is also a useful solution to use instead of a Site-to-Site VPN when you have only a few clients that need to connect to a VNet.
Unlike S2S connections, P2S connections do not require an on-premises public-facing IP address or a VPN device. 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.
P2S uses the Secure Socket Tunneling Protocol (SSTP), which is an SSL-based VPN protocol. A P2S VPN connection is established by starting it from the client computer.
Deployment models and methods for Point-to-Site
|Deployment Model/Method||Azure Portal||Classic Portal||PowerShell|
|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.
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|
|Resource Manager||Article+||Not Supported||Article||Article|
|Connections between different deployment models||Article*||Supported*||Article||Not Supported|
(+) 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|
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.
For frequently asked questions about VPN gateway, see the VPN Gateway FAQ.