Connect Azure VPN gateways to multiple on-premises policy-based VPN devices using PowerShell

This article helps you configure an Azure route-based VPN gateway to connect to multiple on-premises policy-based VPN devices leveraging custom IPsec/IKE policies on S2S VPN connections.

About policy-based and route-based VPN gateways

Policy- vs. route-based VPN devices differ in how the IPsec traffic selectors are set on a connection:

  • Policy-based VPN devices use the combinations of prefixes from both networks to define how traffic is encrypted/decrypted through IPsec tunnels. It is typically built on firewall devices that perform packet filtering. IPsec tunnel encryption and decryption are added to the packet filtering and processing engine.
  • Route-based VPN devices use any-to-any (wildcard) traffic selectors, and let routing/forwarding tables direct traffic to different IPsec tunnels. It is typically built on router platforms where each IPsec tunnel is modeled as a network interface or VTI (virtual tunnel interface).

The following diagrams highlight the two models:

Policy-based VPN example


Route-based VPN example


Azure support for policy-based VPN

Currently, Azure supports both modes of VPN gateways: route-based VPN gateways and policy-based VPN gateways. They are built on different internal platforms, which result in different specifications:

PolicyBased VPN Gateway RouteBased VPN Gateway
Azure Gateway SKU Basic Basic, Standard, HighPerformance, VpnGw1, VpnGw2, VpnGw3
IKE version IKEv1 IKEv2
Max. S2S connections 1 Basic/Standard: 10
HighPerformance: 30

With the custom IPsec/IKE policy, you can now configure Azure route-based VPN gateways to use prefix-based traffic selectors with option "PolicyBasedTrafficSelectors", to connect to on-premises policy-based VPN devices. This capability allows you to connect from an Azure virtual network and VPN gateway to multiple on-premises policy-based VPN/firewall devices, removing the single connection limit from the current Azure policy-based VPN gateways.


  1. To enable this connectivity, your on-premises policy-based VPN devices must support IKEv2 to connect to the Azure route-based VPN gateways. Check your VPN device specifications.
  2. The on-premises networks connecting through policy-based VPN devices with this mechanism can only connect to the Azure virtual network; they cannot transit to other on-premises networks or virtual networks via the same Azure VPN gateway.
  3. The configuration option is part of the custom IPsec/IKE connection policy. If you enable the policy-based traffic selector option, you must specify the complete policy (IPsec/IKE encryption and integrity algorithms, key strengths, and SA lifetimes).

The following diagram shows why transit routing via Azure VPN gateway doesn't work with the policy-based option:

policy-based transit

As shown in the diagram, the Azure VPN gateway has traffic selectors from the virtual network to each of the on-premises network prefixes, but not the cross-connection prefixes. For example, on-premises site 2, site 3, and site 4 can each communicate to VNet1 respectively, but cannot connect via the Azure VPN gateway to each other. The diagram shows the cross-connect traffic selectors that are not available in the Azure VPN gateway under this configuration.

Configure policy-based traffic selectors on a connection

The instructions in this article follow the same example as described in Configure IPsec/IKE policy for S2S or VNet-to-VNet connections to establish a S2S VPN connection. This is shown in the following diagram:


The workflow to enable this connectivity:

  1. Create the virtual network, VPN gateway, and local network gateway for your cross-premises connection
  2. Create an IPsec/IKE policy
  3. Apply the policy when you create a S2S or VNet-to-VNet connection, and enable the policy-based traffic selectors on the connection
  4. If the connection is already created, you can apply or update the policy to an existing connection

Before you begin

Verify that you have an Azure subscription. If you don't already have an Azure subscription, you can activate your MSDN subscriber benefits or sign up for a free account.

This article uses PowerShell cmdlets. To run the cmdlets, you can use Azure Cloud Shell, a free interactive shell. It has common Azure tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into the Cloud Shell, and then press enter to run it. There are a few ways to launch the Cloud Shell:

Click Try It in the upper right corner of a code block. Cloud Shell in this article
Open Cloud Shell in your browser.
Click the Cloud Shell button on the menu in the upper right of the Azure portal. Cloud Shell in the portal

If you don't want to use Azure Cloud Shell, you can install PowerShell locally instead. If you choose to install and use PowerShell locally, be sure to install the latest version of the Azure Resource Manager PowerShell cmdlets to get the latest feature functionality.

To find the version of PowerShell that you are running locally, use the 'Get-Module -ListAvailable AzureRM' cmdlet. To update, see Install the Azure PowerShell module. For more information, see How to install and configure Azure PowerShell.

Enable policy-based traffic selectors on a connection

Make sure you have completed Part 3 of the Configure IPsec/IKE policy article for this section. The following example uses the same parameters and steps:

Step 1 - Create the virtual network, VPN gateway, and local network gateway

1. Connect to your subscription and declare your variables

Open your PowerShell console with elevated privileges.

If you are running Azure PowerShell locally, connect to your Azure account. The Connect-AzureRmAccount cmdlet prompts you for credentials. After authenticating, it downloads your account settings so that they are available to Azure PowerShell. If you are not running PowerShell locally and are instead using the Azure Cloud Shell 'Try it' in the browser, skip this first step. You will connect to your Azure account automatically.


If you have more than one subscription, get a list of your Azure subscriptions.


Specify the subscription that you want to use.

Select-AzureRmSubscription -SubscriptionName "Name of subscription"

Declare your variables. For this exercise, we use the following variables:

$Sub1          = "<YourSubscriptionName>"
$RG1           = "TestPolicyRG1"
$Location1     = "East US 2"
$VNetName1     = "TestVNet1"
$FESubName1    = "FrontEnd"
$BESubName1    = "Backend"
$GWSubName1    = "GatewaySubnet"
$VNetPrefix11  = ""
$VNetPrefix12  = ""
$FESubPrefix1  = ""
$BESubPrefix1  = ""
$GWSubPrefix1  = ""
$DNS1          = ""
$GWName1       = "VNet1GW"
$GW1IPName1    = "VNet1GWIP1"
$GW1IPconf1    = "gw1ipconf1"
$Connection16  = "VNet1toSite6"

$LNGName6      = "Site6"
$LNGPrefix61   = ""
$LNGPrefix62   = ""
$LNGIP6        = ""

2. Create the virtual network, VPN gateway, and local network gateway

Create a resource group.

New-AzureRmResourceGroup -Name $RG1 -Location $Location1

Use the following example to create the virtual network TestVNet1 with three subnets, and the VPN gateway. If you want to substitute values, it's important that you always name your gateway subnet specifically 'GatewaySubnet'. If you name it something else, your gateway creation fails.

$fesub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1
$besub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1
$gwsub1 = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName1 -AddressPrefix $GWSubPrefix1

New-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 -Location $Location1 -AddressPrefix $VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1

$gw1pip1    = New-AzureRmPublicIpAddress -Name $GW1IPName1 -ResourceGroupName $RG1 -Location $Location1 -AllocationMethod Dynamic
$vnet1      = Get-AzureRmVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1
$subnet1    = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet1
$gw1ipconf1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GW1IPconf1 -Subnet $subnet1 -PublicIpAddress $gw1pip1

New-AzureRmVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 -Location $Location1 -IpConfigurations $gw1ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance

New-AzureRmLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1 -Location $Location1 -GatewayIpAddress $LNGIP6 -AddressPrefix $LNGPrefix61,$LNGPrefix62

Step 2 - Create a S2S VPN connection with an IPsec/IKE policy

1. Create an IPsec/IKE policy


You need to create an IPsec/IKE policy in order to enable "UsePolicyBasedTrafficSelectors" option on the connection.

The following example creates an IPsec/IKE policy with these algorithms and parameters:

  • IKEv2: AES256, SHA384, DHGroup24
  • IPsec: AES256, SHA256, PFS24, SA Lifetime 3600 seconds & 2048KB
$ipsecpolicy6 = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA384 -DhGroup DHGroup24 -IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup PFS24 -SALifeTimeSeconds 3600 -SADataSizeKilobytes 2048

2. Create the S2S VPN connection with policy-based traffic selectors and IPsec/IKE policy

Create an S2S VPN connection and apply the IPsec/IKE policy created in the previous step. Be aware of the additional parameter "-UsePolicyBasedTrafficSelectors $True" which enables policy-based traffic selectors on the connection.

$vnet1gw = Get-AzureRmVirtualNetworkGateway -Name $GWName1  -ResourceGroupName $RG1
$lng6 = Get-AzureRmLocalNetworkGateway  -Name $LNGName6 -ResourceGroupName $RG1

New-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1 -VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng6 -Location $Location1 -ConnectionType IPsec -UsePolicyBasedTrafficSelectors $True -IpsecPolicies $ipsecpolicy6 -SharedKey 'AzureA1b2C3'

After completing the steps, the S2S VPN connection will use the IPsec/IKE policy defined, and enable policy-based traffic selectors on the connection. You can repeat the same steps to add more connections to additional on-premises policy-based VPN devices from the same Azure VPN gateway.

Update policy-based traffic selectors for a connection

The last section shows you how to update the policy-based traffic selectors option for an existing S2S VPN connection.

1. Get the connection

Get the connection resource.

$RG1          = "TestPolicyRG1"
$Connection16 = "VNet1toSite6"
$connection6  = Get-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1

2. Check the policy-based traffic selectors option

The following line shows whether the policy-based traffic selectors are used for the connection:


If the line returns "True", then policy-based traffic selectors are configured on the connection; otherwise it returns "False."

3. Enable/Disable the policy-based traffic selectors on a connection

Once you obtain the connection resource, you can enable or disable the option.

To Enable UsePolicyBasedTrafficSelectors

The following example enables the policy-based traffic selectors option, but leaves the IPsec/IKE policy unchanged:

$RG1          = "TestPolicyRG1"
$Connection16 = "VNet1toSite6"
$connection6  = Get-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1

Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -UsePolicyBasedTrafficSelectors $True

To Disable UsePolicyBasedTrafficSelectors

The following example disables the policy-based traffic selectors option, but leaves the IPsec/IKE policy unchanged:

$RG1          = "TestPolicyRG1"
$Connection16 = "VNet1toSite6"
$connection6  = Get-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1

Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -UsePolicyBasedTrafficSelectors $False

Next steps

Once your connection is complete, you can add virtual machines to your virtual networks. See Create a Virtual Machine for steps.

Also review Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections for more details on custom IPsec/IKE policies.