Question concerning forward traffic on Azure Virtual Networks

1
votes

I have a routing problem which I am struggling to solve in the Azure cloud platform concerning traffic that needs to be routed from one vnet to another vnet via another vnet and two VPN tunnels.

Here is a description of the set-up: I do have two Azure Virtual Networks (VNET1 and VNET2) that each one has its own route-based Azure VPN Gateway and one 3rd party virtual network (VNET3) which is connected to the first Azure virtual network VNTE1 via an IPsec VPN tunnel. Below are the address spaces of all 3 virtual networks.

  • VNET1 10.20.0.0/16 (Azure vnet)
  • VNET2 10.30.0.0/16 (Azure vnet)
  • VNET3 10.0.0.0/12 (3rd party vnet)

Here is what I can do:

  • The VNET1 is connected via an IPsec VPN tunnel with the VNET3. Thus I am able to ping from a VM in the VNET1 10.20.10.5 a VM in the VNET3 10.0.0.1 and they can ping me back.
  • The VNET1 is connected via an IPsec VPN tunnel with VNET2. Thus, I am able to ping from a VM in the VNET1 10.20.10.5 a VM in the VNET2 10.30.10.5

Here what i cannot do:

  • I cannot ping from a VM in the VNET2 10.30.10.5 the VM in VNET3 10.0.0.1.

Here is what I tried to do to solve the problem without any success so far:

  • My assumption is that the network VNET2 does not know how to route the traffic to the network VNET3. Thus, I created an Azure Route table and I assigned the route table to the subnet 10.30.10.0/24 and I created the rule that all the traffic to the network 10.0.0.0/12 should be routed to the VPN GateWay of the VNTE2. My expectation is that once the traffic will go to the GW it will reach the VNET1 which knows how to route it to the VNET3. This didn't work.
  • Although I think is not needed since VNET1 already knows how to route the traffic to the VNET3 I have also created a routing table for 10.0.0.0/12 similar to the one above. This didn't help either.

Am I missing a route somewhere, If so which rule and where? Or do I even need to have a VM acting as a router? (I hope not)

1
azureazure-virtual-networkazure-vpnvnetvirtual-network
If possible, can you, please, share screenshots from Effective Routes tab of Network Interfaces of your VMs? – Ivan Ignatiev
What you meen by IPSec VPN Tunnel between VNET1 and VNET3? Is it the same VPN Gateway of VNET1 that also used for connection with VNET2? – Ivan Ignatiev
You can also use Azure Network Watcher IP Flow verify functionality to test your configuration docs.microsoft.com/en-us/azure/network-watcher/… – Ivan Ignatiev
In your 3rd party virtual network (VNET3), Is there any route to the VNet2 from VNet3? – Nancy Xiong
@IvanIgnatiev: I am answering your questions 1) No unfortunately I am not allowed to share the effective routes tab. However it is weird that the routes that I see in the tab if I go to the vm and do a >route PRINT I do not see them all. 2) Yes the same VPN GW of VNET1 which is used to connect with VNET3 is used to connect VNET2 as well. – aragorn

1 Answers

1
votes

I think your issue is the limitation of Azure Virtual Gateway:

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.

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps

So, even if you use the same VPN Gateway to connect with VNET 3 and VNET 2, by design VNET 3 and VNET 2 cannot communicate.

To resolve this issue, I recommend to use peering. Your configuration is similar to classic Hub-Spoke topology. Your VNET1 is Hub, VNET2 is Spoke, VNET3 is kind of "on-prem".

No changes needed to configuration between VNET1 and VNET3. You need to establish peering between VNET1 and VNET2 and backwards and apply following configuration:

  • Configure the peering connection in the hub to allow gateway transit.
  • Configure the peering connection in each spoke to use remote gateways.
  • Configure all peering connections to allow forwarded traffic.

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

In this case, VNET3 will be able to communicate with HUB (VNET1) and all spokes (VNET2 and any others connected to VNET1). VNET2 can communication with HUB (VNET1) and on-prem (VNET3) when the tunnel is up.

Warning: Spokes are not able to communicate between each other without a forwarding gateway in HUB, i.e. if you add VNET4 with peering to and from VNET1, VNET4 will not able to ping VMs in VNET2. But they could communicate with HUB and on-prem without any additional appliances.