About VPN Gateway configuration settings

A VPN gateway is a type of virtual network gateway that sends encrypted traffic between your virtual network and your on-premises location across a public connection. You can also use a VPN gateway to send traffic between virtual networks across the Azure backbone.

A VPN gateway connection relies on the configuration of multiple resources, each of which contains configurable settings. The sections in this article discuss the resources and settings that relate to a VPN gateway for a virtual network created in Resource Manager deployment model. You can find descriptions and topology diagrams for each connection solution in the About VPN Gateway article.

Gateway types

Each virtual network can only have one virtual network gateway of each type. When you are creating a virtual network gateway, you must make sure that the gateway type is correct for your configuration.

The available values for -GatewayType are:

  • Vpn
  • ExpressRoute

A VPN gateway requires the -GatewayType Vpn.


New-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg `
-Location 'West US' -IpConfigurations $gwipconfig -GatewayType Vpn `
-VpnType RouteBased

Gateway SKUs

When you create a virtual network gateway, you need to specify the gateway SKU that you want to use. Select the SKUs that satisfy your requirements based on the types of workloads, throughputs, features, and SLAs.


The new VPN gateway SKUs (VpnGw1, VpnGw2, and VpnGw3) are supported for the Resource Manager deployment model only. Classic virtual networks should continue to use the old SKUs. For more information about the old gateway SKUs, see Working with virtual network gateway SKUs (old).

Azure offers the following VPN gateway SKUs:

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

Production vs. Dev-Test Workloads

Due to the differences in SLAs and feature sets, we recommend the following SKUs for production vs. dev-test:

Workload SKUs
Production, critical workloads VpnGw1, VpnGw2, VpnGw3
Dev-test or proof of concept Basic

If you are using the old SKUs, the production SKU recommendations are Standard and HighPerformance SKUs. For information on the old SKUs, see Gateway SKUs (legacy SKUs).

Gateway SKU feature sets

The new gateway SKUs streamline the feature sets offered on the gateways:

SKU Features
Basic Route-based VPN: 10 tunnels with P2S; no RADIUS authentication for P2S; no IKEv2 for P2S
Policy-based VPN: (IKEv1): 1 tunnel; no P2S
VpnGw1, VpnGw2, and VpnGw3 Route-based VPN: up to 30 tunnels (*), P2S, BGP, active-active, custom IPsec/IKE policy, ExpressRoute/VPN co-existence

(*) You can configure "PolicyBasedTrafficSelectors" to connect a route-based VPN gateway (VpnGw1, VpnGw2, VpnGw3) to multiple on-premises policy-based firewall devices. Refer to Connect VPN gateways to multiple on-premises policy-based VPN devices using PowerShell for details.

Resizing gateway SKUs

  1. You can resize between VpnGw1, VpnGw2, and VpnGw3 SKUs.
  2. When working with the old gateway SKUs, you can resize between Basic, Standard, and HighPerformance SKUs.
  3. You cannot resize from Basic/Standard/HighPerformance SKUs to the new VpnGw1/VpnGw2/VpnGw3 SKUs. You must, instead, migrate to the new SKUs.

Migrating from old SKUs to the new SKUs


  • The VPN gateway Public IP address will change when migrating from an old SKU to a new SKU.
  • You can't migrate classic VPN gateways to the new SKUs. Classic VPN gateways can only use the legacy (old) SKUs.

You can't resize your Azure VPN gateways between the old SKUs and the new SKU families. If you have VPN gateways in the Resource Manager deployment model that are using the older version of the SKUs, you can migrate to the new SKUs. To migrate, you delete the existing VPN gateway for your virtual network, then create a new one.

Migration workflow:

  1. Remove any connections to the virtual network gateway.
  2. Delete the old VPN gateway.
  3. Create the new VPN gateway.
  4. Update your on-premises VPN devices with the new VPN gateway IP address (for Site-to-Site connections).
  5. Update the gateway IP address value for any VNet-to-VNet local network gateways that will connect to this gateway.
  6. Download new client VPN configuration packages for P2S clients connecting to the virtual network through this VPN gateway.
  7. Recreate the connections to the virtual network gateway.

Configure the gateway SKU

Azure portal

If you use the Azure portal to create a Resource Manager virtual network gateway, you can select the gateway SKU by using the dropdown. The options you are presented with correspond to the Gateway type and VPN type that you select.


The following PowerShell example specifies the -GatewaySku as VpnGw1.

New-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg `
-Location 'West US' -IpConfigurations $gwipconfig -GatewaySku VpnGw1 `
-GatewayType Vpn -VpnType RouteBased

Change (resize) a gateway SKU

If you want to upgrade your gateway SKU to a more powerful SKU, you can use the Resize-AzureRmVirtualNetworkGateway PowerShell cmdlet. You can also downgrade the gateway SKU size using this cmdlet.

The following PowerShell example shows a gateway SKU being resized to VpnGw2.

$gw = Get-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg
Resize-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $gw -GatewaySku VpnGw2

Connection types

In the Resource Manager deployment model, each configuration requires a specific virtual network gateway connection type. The available Resource Manager PowerShell values for -ConnectionType are:

  • IPsec
  • Vnet2Vnet
  • ExpressRoute
  • VPNClient

In the following PowerShell example, we create a S2S connection that requires the connection type IPsec.

New-AzureRmVirtualNetworkGatewayConnection -Name localtovon -ResourceGroupName testrg `
-Location 'West US' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'

VPN types

When you create the virtual network gateway for a VPN gateway configuration, you must specify a VPN type. The VPN type that you choose depends on the connection topology that you want to create. For example, a P2S connection requires a RouteBased VPN type. A VPN type can also depend on the hardware that you are using. S2S configurations require a VPN device. Some VPN devices only support a certain VPN type.

The VPN type you select must satisfy all the connection requirements for the solution you want to create. For example, if you want to create a S2S VPN gateway connection and a P2S VPN gateway connection for the same virtual network, you would use VPN type RouteBased because P2S requires a RouteBased VPN type. You would also need to verify that your VPN device supported a RouteBased VPN connection.

Once a virtual network gateway has been created, you can't change the VPN type. You have to delete the virtual network gateway and create a new one. There are two VPN types:

  • 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 PowerShell example specifies the -VpnType as RouteBased. When you are creating a gateway, you must make sure that the -VpnType is correct for your configuration.

New-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg `
-Location 'West US' -IpConfigurations $gwipconfig `
-GatewayType Vpn -VpnType RouteBased

Gateway requirements

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

Gateway subnet

Before you create a VPN gateway, you must create a gateway subnet. The gateway subnet contains the IP addresses that the virtual network gateway VMs and services use. When you create your virtual network gateway, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings. You must never deploy anything else (for example, additional VMs) to the gateway subnet. The gateway subnet must be named 'GatewaySubnet' to work properly. Naming the gateway subnet 'GatewaySubnet' lets Azure know that this is the subnet to deploy the virtual network gateway VMs and services to.

When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The IP addresses in the gateway subnet are allocated to the gateway VMs and gateway services. Some configurations require more IP addresses than others. Look at the instructions for the configuration that you want to create and verify that the gateway subnet you want to create meets those requirements. Additionally, you may want to make sure your gateway subnet contains enough IP addresses to accommodate possible future additional configurations. While you can create a gateway subnet as small as /29, we recommend that you create a gateway subnet of /28 or larger (/28, /27, /26 etc.). That way, if you add functionality in the future, you won't have to tear your gateway, then delete and recreate the gateway subnet to allow for more IP addresses.

The following Resource Manager PowerShell example shows a gateway subnet named GatewaySubnet. You can see the CIDR notation specifies a /27, which allows for enough IP addresses for most configurations that currently exist.

Add-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix


When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your VPN gateway to stop functioning as expected. For more information about network security groups, see What is a network security group?

Local network gateways

When creating a VPN gateway configuration, the local network gateway often represents your on-premises location. In the classic deployment model, the local network gateway was referred to as a Local Site.

You give the local network gateway a name, the public IP address of the on-premises VPN device, and specify the address prefixes that are located on the on-premises location. Azure looks at the destination address prefixes for network traffic, consults the configuration that you have specified for your local network gateway, and routes packets accordingly. You also specify local network gateways for VNet-to-VNet configurations that use a VPN gateway connection.

The following PowerShell example creates a new local network gateway:

New-AzureRmLocalNetworkGateway -Name LocalSite -ResourceGroupName testrg `
-Location 'West US' -GatewayIpAddress '' -AddressPrefix ''

Sometimes you need to modify the local network gateway settings. For example, when you add or modify the address range, or if the IP address of the VPN device changes. See Modify local network gateway settings using PowerShell.

REST APIs and PowerShell cmdlets

For additional technical resources and specific syntax requirements when using REST APIs, PowerShell cmdlets, or Azure CLI for VPN Gateway configurations, see the following pages:

Classic Resource Manager
PowerShell PowerShell
Not supported Azure CLI

Next steps

For more information about available connection configurations, see About VPN Gateway.