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.
VPN gateway connections rely 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 VPN Gateway design article.
The values in this article apply VPN gateways (virtual network gateways that use the -GatewayType Vpn). Additionally, this article covers many, but not all, gateway types and SKUs. See the following articles for information regarding gateways that use these specified settings:
For values that apply to -GatewayType 'ExpressRoute', see Virtual Network Gateways for ExpressRoute.
For zone-redundant gateways, see About zone-redundant gateways.
For active-active gateways, see About highly available connectivity.
For Virtual WAN, see About Virtual WAN.
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 specify the gateway SKU that you want to use. This section describes the factors that you should take into consideration when selecting a gateway SKU for the current deployment model (Resource Manager).
If you're looking for SKU information about legacy SKUs, ExpressRoute gateway SKUs, or more information about Availability Zone SKUs, see the following articles:
- 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.
- For more information about Availability Zone SKU (*AZ SKUs), see About Zone redundant gateway SKUs.
When selecting a virtual network gateway SKU, select the SKU that satisfies your requirements based on the types of workloads, throughput, features, and SLAs. The following sections show the relevant information that you should use when deciding.
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 |
(*) If you need more than 100 S2S VPN tunnels, use Virtual WAN instead of VPN Gateway.
Additional information
You can resize a gateway SKU as long as it is in the same generation, except for the Basic SKU. The Basic SKU is a legacy SKU and has feature limitations. To change from the Basic SKU to another SKU, you first delete the Basic SKU VPN gateway, then create a new gateway with the desired generation and SKU size combination. See Working with Legacy SKUs.
The Basic SKU doesn't support IPv6 and can only be configured using PowerShell or Azure CLI. Additionally, the Basic SKU doesn't support RADIUS authentication.
These connection limits are separate. For example, you can have 128 SSTP connections and also 250 IKEv2 connections on a VpnGw1 SKU.
If you have numerous 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.
See the Pricing page for pricing information.
See the SLA page for SLA (Service Level Agreement) information.
All benchmarks aren't guaranteed due to Internet traffic conditions and your application behaviors.
Gateway SKU by performance
To help you 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 in this section lists the results of performance tests for VpnGW SKUs. A VPN tunnel connects to a VPN gateway instance. Each instance throughput is mentioned in the throughput table in the previous section and is available aggregated across all tunnels connecting to that instance. The table 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.
- The best performance was obtained when we used the GCMAES256 algorithm for both IPsec Encryption and Integrity.
- Average performance was obtained when using AES256 for IPsec Encryption and SHA256 for Integrity.
- The lowest performance was obtained when we used DES3 for IPsec Encryption and SHA256 for Integrity.
| 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 |
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. Verify that the feature that you need is supported before you use the Basic SKU. The Basic SKU doesn't support IPv6 and can only be configured using PowerShell or Azure CLI. Additionally, the Basic SKU doesn't support RADIUS authentication.
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. The Basic SKU has certain feature limitations. Verify that the feature that you need is supported before you use the Basic SKU. The Basic SKU doesn't support IPv6 and can only be configured using PowerShell or Azure CLI. Additionally, the Basic SKU doesn't support RADIUS authentication.
If you're 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. For steps, see Create and manage a VPN gateway.
PowerShell
The following PowerShell example specifies the -GatewaySku as VpnGw1. When using PowerShell to create a gateway, you must 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. While it's faster to resize your gateway SKU, there are rules regarding resizing:
- Except for the Basic SKU, you can resize a VPN gateway SKU to another VPN gateway SKU within the same generation (Generation1 or Generation2) and SKU family (VpnGwx or VpnGwxAZ).
- Example: VpnGw1 of Generation1 can be resized to VpnGw2 of Generation1, but can't be resized to VpnGw2 of Generation2. The gateway must instead be changed (deleted and rebuilt).
- Example: VpnGw2 of Generation2 can't be resized to VpnGw2AZ of either Generation1 or Generation2 because the "AZ" gateways are zone redundant. To change to an AZ SKU, delete the gateway and rebuild it using the desired AZ SKU.
- When working with older legacy SKUs:
- You can resize between Standard and HighPerformance SKUs.
- 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
Go to the Configuration page for your virtual network gateway.
On the right side of the page, click the dropdown arrow to show the available SKUs list.
Select the SKU from the dropdown. The list only includes SKUs you can resize your SKU to. If you don't see the SKU you want to use, instead of resizing, you have to change a SKU.
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're 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:
- Remove any connections to the virtual network gateway.
- Delete the old VPN gateway.
- Create the new VPN gateway.
- Update your on-premises VPN devices with the new VPN gateway IP address (for Site-to-Site connections).
- Update the gateway IP address value for any VNet-to-VNet local network gateways that connect to this gateway.
- Download new client VPN configuration packages for P2S clients connecting to the virtual network through this VPN gateway.
- 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 can't change to the new SKUs.
- When you change from a legacy SKU to a new SKU, you'll have connectivity downtime.
- When changing to a new gateway SKU, the public IP address for your VPN gateway changes. 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'
Connection modes
The Connection Mode property only applies to route-based VPN gateways that use IKEv2 connections. Connection modes define the connection initiation direction and apply only to the initial IKE connection establishment. Any party can initiate rekeys and further messages. InitiatorOnly means the connection needs to be initiated by Azure. ResponderOnly means the connection needs to be initiated by the on-premises device. The Default behavior is to accept and dial whichever connects first.
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, use the VPN type RouteBased because P2S requires a RouteBased VPN type. You 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. If you want a different VPN type, first delete the virtual network gateway, and then create a new gateway.
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 isn't 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 which it should deploy the virtual network gateway VMs and services.
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. While it's possible to create a gateway subnet as small as /29 (applicable to the Basic SKU only), all other SKUs require a gateway subnet of size /27 or larger (/27, /26, /25 etc.). You may want to create a gateway subnet larger than /27 so that the subnet has enough IP addresses to accommodate possible future 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
Considerations:
User-defined routes with a 0.0.0.0/0 destination and NSGs on the GatewaySubnet are not supported. Gateways with this configuration are blocked from being created. 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 BGP route propagation is set to disabled, the gateway won't function.
Diagnostics, data path, and control path can be affected if a user-defined route overlaps with the Gateway subnet range or the gateway public IP range.
- 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.
When you configure a local network gateway, you specify the name, the public IP address or the fully qualified domain name (FQDN) of the on-premises VPN device, and 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 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:
| Classic | Resource Manager |
|---|---|
| PowerShell | PowerShell |
| REST API | REST API |
| Not supported | Azure CLI |
Next steps
For more information about available connection configurations, see About VPN Gateway.
Feedback
Submit and view feedback for