VNet Peering and Gateway Transit with S2S VPN

VNet Peering in Azure enables 2 VNets within the same region to be connected directly through the Azure backbone fabric network. Previously there was a requirement to use a VNet gateway and establish a VNet-VNet VPN connection. One of the major downsides to this was the requirement to enable to use a VNet Gateway which has bandwidth limits (depending on SKU) and additional network devices in the path will inevitably increase latency as well, regardless if the 2 VNets were in the same region.

With VNet Peering you can now enable high bandwidth and low latency direct connections across VNets in the same region, you can also peer with VNets across subscriptions if both VNets are ARM based and both subscriptions are linked to the same Azure AD Tenant. If you peer an ARM Vnet with an ASM VNet then they must be within the same subscription, and it is not possible to peer 2 ASM VNets.

Gateway Transit

In this blog we will use the Gateway Transit feature to provide connectivity from on-premises network through a Site-to-Site (S2S) VPN to a second VNet that is peered with the VNet that is connected to the S2S VPN. In this configuration the on-premises network and VNet 2 will have network connectivity via the Gateway Transit configured in the peering configuration in VNet 1.

VNet Peering Gateway Transit

VNet Peering Gateway Transit

Note: Gateway Transit requires that both VNets in the peering relationship are ARM based

In the example shown in the diagram above, we have an S2S VPN connection established between an on-premises VPN device (in this case 2012 RRAS) and an Azure VNet using a VNet Gateway, and configured to allow gateway transit. The second VNet will be set up to peer with the first VNet, and configured to use the remote gateway.


VNet Peering can be configured from or via PowerShell. A peering requires a configuration on both sides of the peering relationship.


  1. Configure the Peering configuration on VNet1. VNet 1 is connected to the on-premises network and will be enabled for Gateway Transit. Select the VNet and Select Peerings, and +Add.
  2. Select the Peer VNet, if it is across subscriptions you can use the Resource ID or select it from the list. Choose “Allow Gateway Transit”
  3. In Peerings now there will be an entry with the status Iniated
  4. Configure the Peering on VNet 2. VNet 2 is the second VNet that will use the first VNets gateway. Select the VNet and Select Peerings, and +Add. Select the Peer VNet, if it is across subscriptions you can use the Resource ID or select it from the list. Choose “Use remote gateways”
  5. After both sides of the peering are added they will show as connected


In this example we are setting up peering across VNets in different subscriptions. The remote Virtual Network is the second VNet Resource ID. Since this is the first VNet where the S2S VPN is intiated we enable AllowGatewayTransit.

Since our VNets are in different subscriptions, change to the second subscription and configure the peering. The remote Virtual Network is the first VNet Resource ID. On this peering we enable UseRemoteGateways


If required update your network devices to add the new route to the second VNet. In this case there is a Windows Server 2012 R2 VM used to connect to the S2S VPN.

  1. We need to add a new Static Route in RRAS

That’s it after this is done you will have connectivity to the second VNet using the first VNet as Gateway Transit.

Block Virtual Network Access

When VNets are peered by default there will be unrestricted network access between the VNets. All traffic will be allowed by the VirtualNetwork default NSG Tag rule. This can be overridden when you create the peering with the Add-AzureRmVirtualNetworkPeering –BlockVirtualNetworkAccess switch.

If the peering has already been established you can modify the properties with these commands

When AllowVirtualNetworkAccess = False specified, all traffic will be blocked between the peered VNets. The VNets are still connected and peered, and you can create specific allow NSGs to enable the required traffic between the VNets.

Important to note, this does not prevent access from the on-premises network. In this example AllowVirtualNetwork access has been disabled on VNet 2. All traffic is still allowed by default from the on-premises network to VNet2 via the Gateway Transit.