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?

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 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
Connection resiliency active-passive active-passive 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 requirements by VPN type and SKU

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:

  • Basic
  • Standard
  • HighPerformance

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)(6) 100 Mbps 10 500 Mbps (6) 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.
  • (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.

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

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

Azure VPN Gateway 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.