About VPN Gateway configuration settings

• Article
• 03/01/2023
• 16 minutes to read

In this article

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.

The values in this article apply VPN gateways (virtual network gateways that use the -GatewayType Vpn). This article doesn’t cover all gateway types or zone-redundant gateways.

Gateway types

Each virtual network can only have one virtual network gateway of each type. When you’re 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.

Example:

New-AzVirtualNetworkGateway -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 SKU that satisfies your requirements based on the types of workloads, throughput, features, and SLAs. For virtual network gateway SKUs in Azure Availability Zones, see Azure Availability Zones gateway SKUs.

Gateway SKUs by tunnel, connection, and throughput

VPN
Gateway
Generation
SKU
S2S/VNet-to-VNet
Tunnels
P2S
SSTP Connections
P2S
IKEv2/OpenVPN Connections
Aggregate
Throughput Benchmark
BGP
Zone-redundant
Generation1
Basic
Max. 10
Max. 128
Not Supported
100 Mbps
Not Supported
No

Generation1
VpnGw1
Max. 30
Max. 128
Max. 250
650 Mbps
Supported
No

Generation1
VpnGw2
Max. 30
Max. 128
Max. 500
1 Gbps
Supported
No

Generation1
VpnGw3
Max. 30
Max. 128
Max. 1000
1.25 Gbps
Supported
No

Generation1
VpnGw1AZ
Max. 30
Max. 128
Max. 250
650 Mbps
Supported
Yes

Generation1
VpnGw2AZ
Max. 30
Max. 128
Max. 500
1 Gbps
Supported
Yes

Generation1
VpnGw3AZ
Max. 30
Max. 128
Max. 1000
1.25 Gbps
Supported
Yes

Generation2
VpnGw2
Max. 30
Max. 128
Max. 500
1.25 Gbps
Supported
No

Generation2
VpnGw3
Max. 30
Max. 128
Max. 1000
2.5 Gbps
Supported
No

Generation2
VpnGw4
Max. 100*
Max. 128
Max. 5000
5 Gbps
Supported
No

Generation2
VpnGw5
Max. 100*
Max. 128
Max. 10000
10 Gbps
Supported
No

Generation2
VpnGw2AZ
Max. 30
Max. 128
Max. 500
1.25 Gbps
Supported
Yes

Generation2
VpnGw3AZ
Max. 30
Max. 128
Max. 1000
2.5 Gbps
Supported
Yes

Generation2
VpnGw4AZ
Max. 100*
Max. 128
Max. 5000
5 Gbps
Supported
Yes

Generation2
VpnGw5AZ
Max. 100*
Max. 128
Max. 10000
10 Gbps
Supported
Yes

(*) Use Virtual WAN if you need more than 100 S2S VPN tunnels.

• The resizing of VpnGw SKUs is allowed within the same generation, except resizing of the Basic SKU. The Basic SKU is a legacy SKU and has feature limitations. In order to move from Basic to another SKU, you must delete the Basic SKU VPN gateway and create a new gateway with the desired Generation and SKU size combination. (see Working with Legacy SKUs).

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

• If you have a lot of P2S connections, it can negatively impact your S2S connections. The Aggregate Throughput Benchmarks were tested by maximizing a combination of S2S and P2S connections. A single P2S or S2S connection can have a much lower throughput.

• Note that all benchmarks aren’t guaranteed due to Internet traffic conditions and your application behaviors

To help our customers understand the relative performance of SKUs using different algorithms, we used publicly available iPerf and CTSTraffic tools to measure performances for site-to-site connections. The table below lists the results of performance tests for VpnGw SKUs. As you can see, the best performance is obtained when we used GCMAES256 algorithm for both IPsec Encryption and Integrity. We got average performance when using AES256 for IPsec Encryption and SHA256 for Integrity. When we used DES3 for IPsec Encryption and SHA256 for Integrity we got lowest performance.

A VPN tunnel connects to a VPN gateway instance. Each instance throughput is mentioned in the above throughput table and is available aggregated across all tunnels connecting to that instance.

The table below shows the observed bandwidth and packets per second throughput per tunnel for the different gateway SKUs. All testing was performed between gateways (endpoints) within Azure across different regions with 100 connections and under standard load conditions.

Generation
SKU
Algorithms
used
Throughput
observed per tunnel
Packets per second per tunnel
observed
Generation1
VpnGw1
GCMAES256
AES256 & SHA256
DES3 & SHA256
650 Mbps
500 Mbps
130 Mbps
62,000
47,000
12,000

Generation1
VpnGw2
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.2 Gbps
650 Mbps
140 Mbps
100,000
61,000
13,000

Generation1
VpnGw3
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.25 Gbps
700 Mbps
140 Mbps
120,000
66,000
13,000

Generation1
VpnGw1AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
650 Mbps
500 Mbps
130 Mbps
62,000
47,000
12,000

Generation1
VpnGw2AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.2 Gbps
650 Mbps
140 Mbps
110,000
61,000
13,000

Generation1
VpnGw3AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.25 Gbps
700 Mbps
140 Mbps
120,000
66,000
13,000

Generation2
VpnGw2
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.25 Gbps
550 Mbps
130 Mbps
120,000
52,000
12,000

Generation2
VpnGw3
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.5 Gbps
700 Mbps
140 Mbps
140,000
66,000
13,000

Generation2
VpnGw4
GCMAES256
AES256 & SHA256
DES3 & SHA256
2.3 Gbps
700 Mbps
140 Mbps
220,000
66,000
13,000

Generation2
VpnGw5
GCMAES256
AES256 & SHA256
DES3 & SHA256
2.3 Gbps
700 Mbps
140 Mbps
220,000
66,000
13,000

Generation2
VpnGw2AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.25 Gbps
550 Mbps
130 Mbps
120,000
52,000
12,000

Generation2
VpnGw3AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
1.5 Gbps
700 Mbps
140 Mbps
140,000
66,000
13,000

Generation2
VpnGw4AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
2.3 Gbps
700 Mbps
140 Mbps
220,000
66,000
13,000

Generation2
VpnGw5AZ
GCMAES256
AES256 & SHA256
DES3 & SHA256
2.3 Gbps
700 Mbps
140 Mbps
220,000
66,000
13,000

Note

VpnGw SKUs (VpnGw1, VpnGw1AZ, VpnGw2, VpnGw2AZ, VpnGw3, VpnGw3AZ, VpnGw4, VpnGw4AZ, VpnGw5, and VpnGw5AZ) are supported for the Resource Manager deployment model only. Classic virtual networks should continue to use the old (legacy) SKUs.

• For information about working with the legacy gateway SKUs (Basic, Standard, and HighPerformance), see Working with VPN gateway SKUs (legacy SKUs).
• For ExpressRoute gateway SKUs, see Virtual Network Gateways for ExpressRoute.

Gateway SKUs by feature set

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

SKU
Features
Basic (**)
Route-based VPN: 10 tunnels for S2S/connections; no RADIUS authentication for P2S; no IKEv2 for P2S
Policy-based VPN: (IKEv1): 1 S2S/connection tunnel; no P2S

All Generation1 and Generation2 SKUs except Basic
Route-based VPN: up to 100 tunnels (*), P2S, BGP, active-active, custom IPsec/IKE policy, ExpressRoute/VPN coexistence

(*) You can configure “PolicyBasedTrafficSelectors” to connect a route-based VPN gateway 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.

(**) 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 another SKU, you must instead change to a new SKU, which involves deleting and recreating your VPN gateway. You can’t deploy a Basic SKU to a VNet that uses IPv6 address space.

Gateway SKUs – 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
All Generation1 and Generation2 SKUs except Basic

Dev-test or proof of concept
Basic (**)

(**) The Basic SKU is considered a legacy SKU and has feature limitations. Verify that the feature that you need is supported before you use the Basic SKU.

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

Configure a 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’re presented with correspond to the Gateway type and VPN type that you select.

PowerShell

The following PowerShell example specifies the -GatewaySku as VpnGw1. When using PowerShell to create a gateway, you have to first create the IP configuration, then use a variable to refer to it. In this example, the configuration variable is $gwipconfig.

New-AzVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1 `
-Location 'US East' -IpConfigurations $gwipconfig -GatewaySku VpnGw1 `
-GatewayType Vpn -VpnType RouteBased

Azure CLI

az network vnet-gateway create --name VNet1GW --public-ip-address VNet1GWPIP --resource-group TestRG1 --vnet VNet1 --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1 --no-wait

Resizing or changing a SKU

If you have a VPN gateway and you want to use a different gateway SKU, your options are to either resize your gateway SKU, or to change to another SKU. When you change to another gateway SKU, you delete the existing gateway entirely and build a new one. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU. In comparison, when you resize a gateway SKU, there isn’t much downtime because you don’t have to delete and rebuild the gateway. If you have the option to resize your gateway SKU, rather than change it, you’ll want to do that. However, there are rules regarding resizing:

1. Except for the Basic SKU, you can resize a VPN gateway SKU to another VPN gateway SKU within the same generation (Generation1 or Generation2). For example, VpnGw1 of Generation1 can be resized to VpnGw2 of Generation1 but not to VpnGw2 of Generation2.
2. When working with the old gateway SKUs, you can resize between Standard and HighPerformance SKUs.
3. You cannot resize from Basic/Standard/HighPerformance SKUs to VpnGw SKUs. You must instead, change to the new SKUs.

To resize a gateway

Azure portal

1. Go to the Configuration page for your virtual network gateway.

2. On the right side of the page, click the dropdown arrow to show the available gateway SKUs.

   

3. Select the SKU from the dropdown.

PowerShell

You can use the Resize-AzVirtualNetworkGateway PowerShell cmdlet to upgrade or downgrade a Generation1 or Generation2 SKU (all VpnGw SKUs can be resized except Basic SKUs). If you are using the Basic gateway SKU, use these instructions instead to resize your gateway.

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

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

To change from an old (legacy) SKU to a new SKU

If you are working with the Resource Manager deployment model, you can change to the new gateway SKUs. When you change from a legacy gateway SKU to a new SKU, you delete the existing VPN gateway and create a new VPN gateway.

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.

Considerations:

• To move to the new SKUs, your VPN gateway must be in the Resource Manager deployment model.
• If you have a classic VPN gateway, you must continue using the older legacy SKUs for that gateway, however, you can resize between the legacy SKUs. You cannot change to the new SKUs.
• You will have connectivity downtime when you change from a legacy SKU to a new SKU.
• When changing to a new gateway SKU, the public IP address for your VPN gateway will change. This happens even if you specify the same public IP address object that you used previously.

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-AzVirtualNetworkGatewayConnection -Name localtovon -ResourceGroupName testrg `
-Location 'West US' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec -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’re 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’re creating a gateway, you must make sure that the -VpnType is correct for your configuration.

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

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

Note

User-defined routes with a 0.0.0.0/0 destination and NSGs on the GatewaySubnet are not supported. Gateways created with this configuration will be blocked from creation. Gateways require access to the management controllers in order to function properly. BGP Route Propagation should be set to “Enabled” on the GatewaySubnet to ensure availability of the gateway. If this is set to disabled, the gateway will not function.

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.

When you’re planning your gateway subnet size, refer to the documentation for the configuration that you’re planning to create. For example, the ExpressRoute/VPN Gateway coexist configuration requires a larger gateway subnet than most other configurations. 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 (applicable to Basic SKU only), we recommend that you create a gateway subnet of /27 or larger (/27, /26 etc.). This will accommodate most configurations.

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-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.3.0/27

Important

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 virtual network gateway (VPN and Express Route gateways) to stop functioning as expected. For more information about network security groups, see What is a network security group?.

Local network gateways

A local network gateway is different than a virtual network gateway. When creating a VPN gateway configuration, the local network gateway usually represents your on-premises network and the corresponding VPN device. 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 or the fully qualified domain name (FQDN) 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’ve specified for your local network gateway, and routes packets accordingly. If you use Border Gateway Protocol (BGP) on your VPN device, you’ll provide the BGP peer IP address of your VPN device and the autonomous system number (ASN) of your on-premises network. 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-AzLocalNetworkGateway -Name LocalSite -ResourceGroupName testrg `
-Location 'West US' -GatewayIpAddress '23.99.221.164' -AddressPrefix '10.5.51.0/24'

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, PowerShell cmdlets, and CLI

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:

Next steps

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