About VPN Gateway configuration settings

VPN gateway connection architecture 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 VPN Gateway topology and design article.

The values in this article specifically apply to VPN gateways (virtual network gateways that use the -GatewayType Vpn). If you're looking for information about the following types of gateways, see the following articles:

Gateways and gateway types

A virtual network gateway is composed of two or more Azure-managed VMs that are automatically configured and deployed to a specific subnet that you create called the gateway subnet. The gateway VMs contain routing tables and run specific gateway services.

When you create a virtual network gateway, the gateway VMs are automatically deployed to the gateway subnet (always named GatwaySubnet), and configured with the settings that you specified. This process can take 45 minutes or more to complete, depending on the gateway SKU that you selected.

One of the settings that you specify when creating a virtual network gateway is the gateway type. The gateway type determines how the virtual network gateway is used and the actions that the gateway takes. A virtual network can have two virtual network gateways; one VPN gateway and one ExpressRoute gateway. The gateway type 'Vpn' specifies that the type of virtual network gateway created is a VPN gateway. This distinguishes it from an ExpressRoute gateway, which uses a different gateway 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.


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

Gateway SKUs and performance

See About Gateway SKUs article for the latest information about gateway SKUs, performance, and supported features.

VPN types

Azure supports two different VPN types for VPN gateways: policy-based and route-based. Route-based VPN gateways are built on a different platform than policy-based VPN gateways. This results in different gateway specifications.

In most cases, you'll create a route-based VPN gateway. Previously, the older gateway SKUs didn't support IKEv1 for route-based gateways. Now, most of the current gateway SKUs support both IKEv1 and IKEv2. If you already have a policy-based gateway, you aren't required to upgrade your gateway to route-based.

If you want to create a policy-based gateway, use PowerShell or CLI. As of Oct 1, 2023, you can't create a policy-based VPN gateway through Azure portal, only route-based gateways are available.

Gateway VPN type Gateway SKU IKE versions supported
Policy-based gateway Basic IKEv1
Route-based gateway Basic IKEv2
Route-based gateway VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 and IKEv2
Route-based gateway VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 and IKEv2

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.

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, more 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 might 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


  • User-defined routes with a 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.

Local network gateways

A local network gateway is different than a virtual network gateway. When you're working with a VPN gateway site-to-site architecture, the local network gateway usually represents your on-premises network and the corresponding VPN device. In the classic deployment model, the local network gateway is 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 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 '' -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. For more information, see Modify local network gateway settings.

REST APIs, PowerShell cmdlets, and CLI

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