Share via

Azure Virtual Networks - Transit Routing - Between IPsec & VNet Peering

  • Article

Scenario / Environment

  • 1 On-Premise Location & 2 Virtual Networks on Azure.
  • On-Premise Network connects to VNet 1 over Site-Site using Dynamic Routing.
  • VNet 1 is connected to VNet 2 via VNet Peering.

Requirement

Need the On-Premise Network to talk with VNet 2 via VNet 1 and vice-versa.

I created a Lab environment within my Azure subscription with the below-mentioned configuration just to test and demonstrate the working. Since we do not have an On-Premise VPN Device for testing, I created a new VNet named TestVNet3-Local in a new Resource Group. TestVNet3-Local is a representation of the On-Premise Network in this example. 

VNet 1 Name: TestVNet1 Address Space: 10.1.0.0/16 Subnet: 10.1.1.0/24 TestVNet1LNG: Configured with IP of TestVNet3-Local Gateway and address space of TestVNet3-Local IPsec Connection object created binding TestVNet3-Local Gateway and TestVNet3-LocalLNG with a pre-shared key. VNet Peering enabled with TestVNet2

VNet 2 Name: TestVNet2 Address Space: 10.2.0.0/16 Subnet: 10.2.1.0/24 VNet Peering enabled with TestVNet1

VNet 3 Name: TestVNet3-Local Address Space: 10.3.0.0/16 Subnet: 10.3.1.0/24 TestVNet3-LocalLNG: Configured with IP of TestVNet1 Gateway and address space of TestVNet1 IPsec Connection object created binding TestVNet3-Local Gateway and TestVNet3-LocalLNG with a pre-shared key

With the above VNet Configuration we could achieve the following:

  • IPsec Connectivity between TestVNet1 & TestVNet3-Local
  • VNet Peering between TestVNet1 & TestVNet2

Now that the requirement is to have TestVNet3-Local talk to TestVNet2 via TestVNet1, we need to update the Local Network Gateway manually. The traffic flow is demonstrated below:

TestVNet3-Local <-----------------> TestVNet1 <---------------------> TestVNet2
                                   IPsec VPN                              VNet Peering
                                     Tunnel                                               

Below mentioned is the configuration that needs to be updated manually and this is a one-time configuration change that is needed to achieve this requirement:

  1. Update TestVNet3-LocalLNG with the address space of TestVNet2 - This will ensure that all traffic destined to TestVNet2 is passed on the existing IPsec Tunnel of TestVNet1.

Note: In this example, it is TestVNet3-LocalLNG, however in customer's scenario this would need to be done on the VPN Device which is located at On-Premise network and we do not have any control over that.

  1. Update TestVNet1 with "Allow Gateway Transit" option which you find in VNet Peering Properties. This is needed to accept and forward the received traffic from peer virtual network. Without this, the data won’t be forwarded.

  2. Update TestVNet3-Local with "Use Remote Gateways" option which you can find in VNet Peering Properties. This option needs to be enabled to ensure that the VNet forwards the traffic to the Gateway which is present in the other VNet when needed.   

Note: Even before enabling "Use Remote Gateways" option, Allow Gateway Transit option on the peer VNet must be enabled. You cannot use this setting if you already have a Gateway in your Virtual Network. One virtual network can have only one gateway. It can either be a local gateway (Gateway in that VNet) or a remote gateway (in the peered virtual network)

More Info

  • AllowVirtualNetworkAccess: Whether or not the address space of a peer VNet is included as part of the virtual network tag. This option is enabled by default.
  • AllowForwardedTraffic: Whether traffic not originating from a peered VNet is accepted or dropped.
  • AllowGatewayTransit: Allows the peer VNet to use your VNet gateway.
  • UseRemoteGateways: Use your peer’s VNet gateway. The peer VNet must have a gateway configured and AllowGatewayTransit selected. You cannot use this option if you have a gateway configured.