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.
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?
The following table can help you decide the best connectivity option for your solution.
|Azure Supported Services||Cloud Services and Virtual Machines||Cloud Services and Virtual Machines||Services list|
|Typical Bandwidths||Typically < 100 Mbps aggregate||Typically < 100 Mbps aggregate||50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps|
|Protocols Supported||Secure Sockets Tunneling Protocol (SSTP)||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|
|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|
|Technical Documentation||VPN Gateway Documentation||VPN Gateway Documentation||ExpressRoute Documentation|
|FAQ||VPN Gateway FAQ||VPN Gateway FAQ||ExpressRoute FAQ|
When you create a virtual network gateway, you need to specify the gateway SKU that you want to use. When you select a higher gateway SKU, more CPUs and network bandwidth are allocated to the gateway, and as a result, the gateway can support higher network throughput to the virtual network.
VPN Gateway can use the following SKUs:
VPN Gateway does not use the UltraPerformance gateway SKU. For information about the UltraPerformance SKU, see the ExpressRoute documentation.
When selecting a SKU, 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.
For more information about gateway SKUs, see VPN Gateway settings.
Aggregate throughput by SKU and VPN type
The following table shows the gateway types and the estimated aggregate throughput by gateway SKU. This table applies to both 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.
|VPN Gateway throughput (1)||VPN Gateway max IPsec tunnels (2)||ExpressRoute Gateway throughput||VPN Gateway and ExpressRoute coexist|
|Basic SKU (3)(5)||100 Mbps||10||500 Mbps||No|
|Standard SKU (4)(5)||100 Mbps||10||1000 Mbps||Yes|
|High Performance SKU (4)||200 Mbps||30||2000 Mbps||Yes|
- (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.
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.
|PolicyBased Basic VPN Gateway||RouteBased Basic VPN Gateway||RouteBased Standard VPN Gateway||RouteBased High Performance VPN Gateway|
|Site-to-Site connectivity (S2S)||PolicyBased VPN configuration||RouteBased VPN configuration||RouteBased VPN configuration||RouteBased VPN configuration|
|Point-to-Site connectivity (P2S)||Not supported||Supported (Can coexist with S2S)||Supported (Can coexist with S2S)||Supported (Can coexist with S2S)|
|Authentication method||Pre-shared key||Pre-shared key for S2S connectivity, Certificates for P2S connectivity||Pre-shared key for S2S connectivity, Certificates for P2S connectivity||Pre-shared key for S2S connectivity, Certificates for P2S connectivity|
|Maximum number of S2S connections||1||10||10||30|
|Maximum number of P2S connections||Not supported||128||128||128|
|Active routing support (BGP)||Not supported||Not supported||Supported||Supported|
The following list outlines the common workflow for cloud connectivity:
- Design and plan your connectivity topology and list the address spaces for all networks you want to connect.
- Create an Azure virtual network.
- Create a VPN gateway for the virtual network.
- Create and configure connections to on-premises networks or other virtual networks (as needed).
- Create and configure a Point-to-Site connection for your Azure VPN gateway (as needed).
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.
The following sections discuss the VPN gateway basics. Also, consider networking services limitations.
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.
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.
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:
Each configuration requires a specific connection type. The connection types are:
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
|S2S and ExpressRoute coexist||Supported||Not Supported|
|Classic to Resource Manager||Supported||Not Supported|
VPN type - classic deployment model
|S2S and ExpressRoute coexist||Supported||Not Supported|
|Classic to Resource Manager||Supported||Not Supported|
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.
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.
Forced tunneling diagram
A forced tunneling connection can be configured in both deployment models and by using different tools. See the following table for more information. We update this table as new articles, new deployment models, and additional tools become available for this configuration. When an article is available, we link directly to it from the table.
|Deployment Model/Method||Azure Portal||Classic Portal||PowerShell|
|Classic||Not Supported||Not Supported||Article|
|Resource Manager||Not Supported||Not Supported||Article|
For more information about specific gateway settings, see About VPN Gateway Settings.