-
10/19/2018 -
11 minutes to read -
Contributors
In this article
A VPN gateway is a specific type of virtual network gateway that is used to send encrypted traffic between an Azure virtual network and an on-premises location over the public Internet. You can also use a VPN gateway to send encrypted traffic between Azure virtual networks over the Microsoft network. Each virtual network can have only one VPN gateway. However, you can create multiple connections to the same VPN gateway. When you create multiple connections to the same VPN gateway, all VPN tunnels share the available gateway bandwidth.
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 you create, which is called the gateway subnet. The VMs that are located in the gateway subnet 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 gateway subnet.
Creating a virtual network gateway can take up to 45 minutes to complete. When you create a virtual network gateway, gateway VMs are deployed to the gateway subnet and configured with the settings that you specify. One of the settings you configure is the gateway type. The gateway type ‘vpn’ specifies that the type of virtual network gateway created is a VPN gateway. After you create a VPN gateway, you can create an IPsec/IKE VPN tunnel connection between that VPN gateway and another VPN gateway (VNet-to-VNet), or create a cross-premises IPsec/IKE VPN tunnel connection between the VPN gateway and an on-premises VPN device (Site-to-Site). You can also create a Point-to-Site VPN connection (VPN over IKEv2 or SSTP), which lets you connect to your virtual network from a remote location, such as from a conference or from home.
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 some resources must be configured in a certain order.
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. The article contains information to help you understand gateway types, gateway SKUs, 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 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
There are currently two deployment models for Azure. 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.
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 Machines | Cloud Services and Virtual Machines | Services list |
| Typical Bandwidths | Based on the gateway SKU | Typically < 1 Gbps aggregate | 50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps |
| Protocols Supported | Secure Sockets Tunneling Protocol (SSTP) and IPsec | IPsec | Direct connection over VLANs, NSP’s VPN technologies (MPLS, VPLS,…) |
| Routing | RouteBased (dynamic) | We support PolicyBased (static routing) and RouteBased (dynamic routing VPN) | BGP |
| Connection resiliency | active-passive | active-passive or active-active | active-active |
| Typical use case | Prototyping, dev / test / lab scenarios for cloud services and virtual machines | Dev / test / lab scenarios and small scale production workloads for cloud services and virtual machines | Access to all Azure services (validated list), Enterprise-class and mission critical workloads, Backup, Big Data, Azure as a DR site |
| SLA | SLA | SLA | SLA |
| Pricing | Pricing | Pricing | Pricing |
| Technical Documentation | VPN Gateway Documentation | VPN Gateway Documentation | ExpressRoute Documentation |
| FAQ | VPN Gateway FAQ | VPN Gateway FAQ | ExpressRoute FAQ |
Gateway SKUs
When you create a virtual network gateway, you specify the gateway SKU that you want to use. Select the SKU that satisfies your requirements based on the types of workloads, throughputs, features, and SLAs. For more information about gateway SKUs, including supported features, production and dev-test, and configuration steps, see Gateway SKUs.
Gateway SKUs by tunnel, connection, and throughput
| SKU | S2S/VNet-to-VNet Tunnels |
P2S SSTP Connections |
P2S IKEv2 Connections |
Aggregate Throughput Benchmark |
BGP |
|---|---|---|---|---|---|
| Basic | Max. 10 | Max. 128 | Not Supported | 100 Mbps | Not Supported |
| VpnGw1 | Max. 30* | Max. 128 | Max. 250 | 650 Mbps | Supported |
| VpnGw2 | Max. 30* | Max. 128 | Max. 500 | 1 Gbps | Supported |
| VpnGw3 | Max. 30* | Max. 128 | Max. 1000 | 1.25 Gbps | Supported |
(*) Use Virtual WAN if you need more than 30 S2S VPN tunnels.
-
Aggregate Throughput Benchmark is based on measurements of multiple tunnels aggregated through a single gateway. The Aggregate Throughput Benchmark for a VPN Gateway is S2S + P2S combined. If you have a lot of P2S connections, it can negatively impact a S2S connection due to throughput limitations. The Aggregate Throughput Benchmark is not a guaranteed throughput due to Internet traffic conditions and your application behaviors.
-
These connection limits are separate. For example, you can have 128 SSTP connections and also 250 IKEv2 connections on a VpnGw1 SKU.
-
Pricing information can be found on the Pricing page.
-
SLA (Service Level Agreement) information can be found on the SLA page.
-
VpnGw1, VpnGw2, and VpnGw3 are supported for VPN gateways using the Resource Manager deployment model only.
-
The Basic SKU is considered a legacy SKU. The Basic SKU has certain feature limitations. You can’t resize a gateway that uses a Basic SKU to one of the new gateway SKUs, you must instead change to a new SKU, which involves deleting and recreating your VPN gateway. Verify that the feature that you need is supported before you use the Basic SKU.
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. S2S connections can be used for cross-premises and hybrid configurations. 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. For information about selecting a VPN device, see the VPN Gateway FAQ – VPN devices.
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 type of connection is often called a “multi-site” connection.
Deployment models and methods for Site-to-Site and Multi-Site
(**) denotes that this method contains steps that require PowerShell.
(+) denotes that this article is written for multi-site connections.
Point-to-Site (VPN over IKEv2 or SSTP)
A Point-to-Site (P2S) VPN gateway connection lets you create a secure connection to your virtual network from an individual client computer. A P2S connection is established by starting it from the client computer. This solution is useful for telecommuters who want to connect to Azure VNets from a remote location, such as from home or a conference. P2S VPN is also a useful solution to use instead of S2S 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. For more information about Point-to-Site connections, see About Point-to-Site VPN.
Deployment models and methods for P2S
Azure native certificate authentication
| Deployment model/method | Azure portal | PowerShell |
|---|---|---|
| Resource Manager | Article | Article |
| Classic | Article | Supported |
RADIUS authentication
| Deployment model/method | Azure portal | PowerShell |
|---|---|---|
| Resource Manager | Supported | Article |
| Classic | Not Supported | Not Supported |
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
(+) denotes this deployment method is available only for VNets in the same subscription.
(*) denotes that this deployment method also requires PowerShell.
ExpressRoute (private connection)
ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a 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 uses 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’. While traffic that travels over an ExpressRoute circuit is not encrypted by default, it is possible create a solution that allows you to send encrypted traffic over an ExpressRoute circuit. For more information about ExpressRoute, see the ExpressRoute technical overview.
Site-to-Site and ExpressRoute coexisting connections
ExpressRoute is a direct, private 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 coexist
| Deployment Model/Method | Azure Portal | PowerShell |
|---|---|---|
| Resource Manager | Not Supported | Article |
| Classic | Not Supported | 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 on 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.
- Learn about some of the other key networking capabilities of Azure.
Leave a Reply