Azure Routing Experiences | Scenario 3

Designing the network routing, cloud & hybrid, on a Hyperscaler like Microsoft Azure can get a real pain. I got an idea, to start playing with some common scenarios and make some notes, in order to have it as a reference. I end up with three scenarios. Those scenarios are referring to internal network topology, without public access, and I focus more on the routing aspect, the DNS configuration & inspection through Azure Firewall.

• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

At the previews posts, we covered the basics of routing traffic from/to on-premises, inspecting all traffic through Azure Firewall, and configuring the DNS for accessing the Private Endpoints. In this scenario, I am experimenting with connectivity between on-premises, the Hub & Spoke networks and a second level peered network (a network that is peered behind the Spoke network).

Recap of Scenario 1 & 2: We have a Hub network, two Spoke networks and an IPSec VPN connection with my on-premises network. We established routing all traffic through the Azure Firewall for inspection & configured DNS for accessing the Private Endpoint from on-premises & all Azure VNets.

In the third scenario, I am adding a new Spoke VNet, the “Azure 2” peered with my hub, and a third VNet, the “Azure 3” that is only peered with the “Azure 2” VNet. To enable connectivity between the “Azure 3” VNet and the rest of the networks, including the on-premises, we need a router at the “Azure 2” VNet. This can be an NVA or Azure Firewall. In my case, I added an Azure Firewall. The Azure Firewall of “Azure 2” VNet has the private IP: 192.168.200.64.

• Azure 3 VNet, VM Subnet Route Table:
  • 10.0.0.0/16 NH 192.168.200.68
  • 192.168.0.0/20 NH 192.168.200.68
  • 192.168.4.0/24 NH 192.168.200.68
  • 192.168.5.0/24 NH 192.168.200.68
  • 192.168.200.0/28 NH 192.168.200.68

• Azure 2 VNet, AzureFirewallSubnet:
  • 10.0.0.0/0 NH Internet
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.0.0/20 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4

• Azure 2 VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.200.68
  • 192.168.4.0/24 NH 192.168.200.68
  • 192.168.5.0/24 NH 192.168.200.68
  • 192.168.0.0/20 NH 192.168.200.68
  • 10.100.0.0/16 NH 192.168.200.64

• Azure Hub VNet, AzureFirewallSubet:
  • 10.0.0.0/0 NH Internet
  • 192.168.200.0/28 NH 192.168.200.68
  • 10.100.0.0/16 NH 192.168.200.68
• Azure Hub VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4
  • 192.168.4.4/32 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4
  • 10.100.0.0/16 NH 192.168.2.4
• Azure Hub VNet, GatewaySubnet:
  • 192.168.0.0/24 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4
  • 192.168.4.4/32 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4
  • 10.100.0.0/16 NH 192.168.2.4
• Spoke 2 VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.0.0/24 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4

Routing Example

Let’s describe a packet’s journey. The On-premises Server X (10.0.2.10) makes sends a packet to 10.100.0.4. 1st hop the packet goes to the default gateway, reaching the on-premises VPN device, in our case the RRAS. The RRAS has a custom route for 10.100.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway The Azure VPN Gateway has a custom route for 10.100.0.0/16 and forwards the packet to the HUB Azure Firewall, 192.168.2.4. The HUB Azure Firewall has a custom route for 10.100.0.0/16 and forwards the packet to the “Azure 2” Azure Firewall, 192.168.200.68. The “Azure 2” Azure Firewall does not have a custom route, but it has a route for 10.100.0.0/16 that is automatically populated by the VNet peering. The Azure FIrewall knows to forward the packet through the VNet peering and reaches the destination.

You can find more commends and tests in the below diagram with the whole solution.

Diagram: (Click here to download a high-resolution SVG image)

References:
Azure Routing Experiences | Scenario 1 – Apostolidis Cloud Corner
Azure Routing Experiences | Scenario 2 – Apostolidis Cloud Corner
Use Azure Firewall to inspect traffic destined to a private endpoint – Azure Private Link | Microsoft Docs
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs