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.
The values in this article apply to virtual network gateways that use the -GatewayType 'Vpn'. This is why these particular virtual network gateways are referred to as VPN gateways. The values for ExpressRoute gateways are not the same values that you use for VPN gateways.
For values that apply to -GatewayType 'ExpressRoute', see Virtual Network Gateways for ExpressRoute.
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:
A VPN gateway requires the
New-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg ` -Location 'West US' -IpConfigurations $gwipconfig -GatewayType Vpn ` -VpnType RouteBased
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, throughputs, features, and SLAs.
Gateway SKUs by tunnel, connection, and throughput
|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|
*Contact support if additional connections are needed
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.
VpnGw1, VpnGw2, and VpnGw3 are supported for VPN gateways using the Resource Manager deployment model only.
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 (legacy) SKUs.
Gateway SKUs by feature set
The new VPN gateway SKUs streamline the feature sets offered on the gateways:
|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 coexistence|
(*) 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.
(**) 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.
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:
|Production, critical workloads||VpnGw1, VpnGw2, VpnGw3|
|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
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. 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-AzureRmVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1 ` -Location 'US East' -IpConfigurations $gwipconfig -GatewaySku VpnGw1 ` -GatewayType Vpn -VpnType RouteBased
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. This could take up to 45 minutes to build. In comparison, when you resize a gateway SKU, you will have very little downtime because you do not have to delete and rebuild the gateway. If you have the option to resize your gateway SKU, rather than change it, you will want to do that. However, there are rules regarding resizing:
- You can resize between VpnGw1, VpnGw2, and VpnGw3 SKUs.
- When working with the old gateway SKUs, you can resize between Basic, Standard, and HighPerformance SKUs.
- You cannot resize from Basic/Standard/HighPerformance SKUs to the new VpnGw1/VpnGw2/VpnGw3 SKUs. You must instead, change to the new SKUs.
To resize a gateway
For the current SKUs (VpnGw1, VpnGw2, and VPNGW3) you want to resize your gateway SKU to upgrade to a more powerful one, you can use the
Resize-AzureRmVirtualNetworkGateway PowerShell cmdlet. You can also downgrade the gateway SKU size using this cmdlet. 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-AzureRmVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg Resize-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $gw -GatewaySku VpnGw2
You can also resize a gateway in the Azure portal by going to the Configuration page for your virtual network gateway and selecting a different SKU from the dropdown.
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.
- 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 will 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.
- 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.
In the Resource Manager deployment model, each configuration requires a specific virtual network gateway connection type. The available Resource Manager PowerShell values for
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'
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
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|
(*) BGP is not supported for the classic deployment model.
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.
Do not associate a route table that includes a route with a destination of 0.0.0.0/0 to the gateway subnet. Doing so prevents the gateway from functioning properly.
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 10.0.3.0/27
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 '18.104.22.168' -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:
|REST API||REST API|
|Not supported||Azure CLI|
For more information about available connection configurations, see About VPN Gateway.