14 min to read.

Abstract

In earlier blog I talked about solving transitive routing problem in 3 VNETs. Recently I came across a situation where transitive routing was required across 4 layers.

A (On-premises DC) < site to site VPN> B (VNET with VPN GW) < peered to> C (Firewall VNET) < peered to> D (server app VNET).

Interested to know how to achieve transitive routing across 4 VNETs? Read on.

Problem Statement

Let us understand the problem better by using example. [Click to get better view]-

Requirements are as below -

1. Contoso company has on-premises DC connected to Azure Landing Zone VNET using Site to Site VNET.

2. Server Deployment should be done in separate VNET and all traffic should be monitored using Firewall

3. The firewall must be placed in separate VNET for logical separation and more granular control.

4. Communication between OnPremises DC server to Azure Server VNET must pass through S2S VPN, Firewall in both directions.

This is classic Transitive routing scenario in Azure, but a complex one. There are 4 networks and you need connectivity between first and fourth; without having them connecting directly.

Let us solve this one by one.

Solving on premises DC connectivity to Azure Landing Zone VNET

I don’t have any on premises site for demo. Therefore I created Azure VNET only and will be treating it as on premises site.

So we have 2 Azure VNETs across which we need connectivity. You can easily set it up using VNET to VNET connection or using VPN Gateway connection. However to replicate real world scenario we will create Site to Site VPN between On premises DC and Contoso Landing Zone Azure VNETs; using Azure VPN Gateway in each.

Connection between Server VNET to Firewall VNET

Server VNET needs to send data [ in our case we will just try RDP] to on premises DC VM. However they are not connected directly.

Also traffic to/ from server VNET has to be filtered through firewall. Therefore we created separate VNET for Server and firewall. I decided to use Azure firewall and the VNET is called as Transit VNET below.

As Server VNET just receive / send data to/ from Azure firewall; we need Standard VNET Peering between Server and Transit VNET.

Connection between Firewall VNET to Landing Zone VNET

Data from Server VNET VMs need to be sent to on premises. However it has to be passed from Azure firewall. Therefore we need Transit VNET to send data to on premises in reality.

So we want traffic from firewall VNET to reach to contoso on premises DC VNET using S2S VPN Gateways present in both VNETs.

For this we will need to setup VNET Peering with Remote Gateway option between Transit VNET and Landing Zone VNET. Only Standard VNET peering won’t work in this scenario.

Final Solution Architecture looks like below

[click to get better view].

Setting up Site to Site between Azure VNETs

We need to create two Local network gateway as shown in above diagram. You need to take care of below when you create S2S between Azure VNETs using Azure VPN Gateways.

1. Create Contoso DC Local network gateway and assign public IP of Contoso DC VPN GW. Assign range of on premises DC private VNET.

2. Create Contoso Zone Local Network Gateway and assign public IP of Contoso Zone VPN GW. Assign ranges of Server, Transit and Zone private VNET.

Refer below screenshots – [click to get better view]

Then to setup Site to Site IPSec tunnel follow the guide as describe here - Tutorial- Connect on-premises network to virtual network: Azure portal - Azure VPN Gateway | Microsoft Docs

Refer below screenshots – [click to get better view]

This completes the S2S connection between 2 Azure VNETs using Azure VPN Gateway.

Provision Azure Firewall and Add Network Rules

Create dedicated subnet for Azure Firewall in Transit VNET and then create Azure Firewall in Transit VNET.

We want RDP traffic from Server VNET to DC VNET and vice versa to allow through Azure Firewall. Therefore add below rules in Azure Firewall network rules. [click to get better view]

Setup VNET Peering between Server, Transit and Zone VNETs

First configure server VNET to Transit VNET peering as shown below. Here as both VNETs to dot have Azure VPN Gateway; so this will be standard VNET peering. [click to get better view]

Then configure Transit VNET to Zone VNET peering. Here Zone VNET has Azure VPN Gateway and we want traffic filtered from Transit VNET firewall to pass to on premises DC VNET over S2S.

Therefore use remote gateway setting in Transit VNET peer, and “Use this VNETs Gateway or Route server” setting in Zone VNET peer as shown. [click to get better view].

This step completes all the required peering setting as per architecture diagram.

Configure Azure Route Tables

From Server subnet we want traffic to go to Contoso DC and pass through Azure Firewall. Therefore we need to add below rules on server subnet –

1. If destination is Contoso DC VNET then next hop is firewall IP

2. If destination is Zone VNET then next hop is firewall IP

Then assign route table to server subnet as shown below. [click to get better view].

The traffic received on Contoso Zone GW and destined to server vnet should also be passed always to firewall. Therefore we need to add below rules on Zone Gateway Subnet route table –

1. If destination is server VNET then net hop is firewall IP.

Then assign route table to Gateway subnet of Zone VNET. [click to get better view.]

This completes configuration of all Route tables.

Confirm the connectivity between Server and On Premises DC VNET

Login to Server VM using public IP. Then simply ping to on premises Dc VM. The ping should be successful as shown below. If we try to take RDP to On Premises DC VM over private IP from server VM; it should be successful as shown below. [click to get better view].

You can view the source address of server VM from event viewer as below – [click to get better view]

Similarly RDP from On Premises DC server to Server VM over private IP should also be successful.

Conclusion

Hope this article helped to design Transitive Routing across 4 VNETs.

Happy Peering!!

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefited, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.

Next Related Posts

Transitive routing across 3 VNETs using Ubuntu VM

Azure Virtual Machines – real world frequently asked questions – not easily answered.

Azure Migration frequently asked questions, not easily answered!

Azure VM disk encryption, what should be my approach!

Bypass onpremises firewall to RDP or SSH into Azure VM