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.
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?
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||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|
|Technical Documentation||VPN Gateway Documentation||VPN Gateway Documentation||ExpressRoute Documentation|
|FAQ||VPN Gateway FAQ||VPN Gateway FAQ||ExpressRoute FAQ|
|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|
*Contact support if additional connections are needed
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.
VpnGw1, VpnGw2, and VpnGw3 are supported for VPN gateways using the Resource Manager deployment model only.
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, and the available deployment tools you can use to deploy your configuration.
The following sections discuss the VPN gateway basics.
Networking services limits
Scroll through the tables to view networking services limits. The limits listed may impact your design.
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 the 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:
About connection types
Each configuration requires a specific connection type. The connection types are:
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
|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|
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.
To download VPN device configuration scripts:
Depending on the VPN device that you have, you may be able to download a VPN device configuration script. For more information, see Download VPN device configuration scripts.
See the following links for additional 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. The list shows the versions we have tested. If your OS is not on that list, it is still possible that the version is compatible. Check with your device manufacturer to verify that OS version for your VPN device is compatible.
For an overview of VPN device configuration, see Overview of 3rd party VPN device configurations.
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. This link shows information about IKE version, Diffie-Hellman Group, Authentication method, encryption and hashing algorithms, SA lifetime, PFS, and DPD, in addition to other parameter information that you need to complete your configuration.
For IPsec/IKE policy configuration steps, see Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections.
To connect multiple policy-based VPN devices, see Connect Azure VPN gateways to multiple on-premises policy-based VPN devices using PowerShell.
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
For more information about specific gateway settings, see About VPN Gateway Settings.