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?

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
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

SKU S2S/VNet-to-VNet
SSTP Connections
IKEv2 Connections
Throughput Benchmark
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.


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).


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, and the available deployment tools you can use to deploy your configuration.

Design basics

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.

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 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:

  • 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.

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:

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.