Azure Routing Experiences | Scenario 1

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 through Azure VPN gateway

At the start, I created the on-premises network, using a RRAS (Windows Server 2019 with Routing & Remote Access) to act as the router/VPN device and a Server with DNS service. The Azure estate has three VNets, in a hub & spoke topology. One HUB and two Spokes, connected with the HUB with VNet peering. There is no peering between the spokes. My Azure HUB network has three subnets, one has a VPN Gateway, the second has a VM, and the third has an Azure Firewall. In this first scenario, the Azure Firewall acts only as a DNS Proxy. It is not included in routing.

  • On-premises network:
  • HUB VNet Address Space:
  • HUB GatewaySubnet:
  • HUB VMSubnet:
  • HUB Firewall Subnet:
  • Spoke1 (storage account):
  • Spoke2 (VM):

The first spoke has a Private Link to my storage account. The second spoke has a VM.. Azure VPN Gateway knows all routes of its VNet, the peered VNets & the routes propagated from the VPN connection. From on-premises, we can reach all resources using the VPN connection interface ( in RRAS I added a custom route “ interface:AzureGW”)

From the VM of the HUB VNet (, in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “ Next Hop: Virtual Network Gateway” attached to the VM Subnet.

To access the Private Endpoint of the Storage account we need some more resources & configuration. The storage account, as all PaaS services (like Web App & Azure SQL) responds only to URI and not to IP. Since we have connected a Private Endpoint to the Storage Account, the Public Access is blocked. So, in order to connect to the storage account, we need the to translate to the private IP of the storage account, the The proper way to achieve this is by using DNS.

First, we need to create a Private DNS zone and link it to the HUB VNET. For accessing blob storage we need a Private DNS zone with the name, for the file we need More services here. Then add the Storage Account Private Endpoint record to the Private DNS Zone. Now there is an A record azappsa with IP Now, all Azure resources at the linked VNet, the HUB, are able to resolve the DNS records of the Private DNS Zone. We cannot resolve the records of the Azure Private DNS Zone from on-premises. To do so, we need a DNS server on Azure, to use as a conditional forwarder. This can be a Windows or Linux VM with DNS services or in my case, the Azure FIrewall with the DNS proxy enabled (I will use the whole functionality of the firewall to my next scenarios). I enabled the DNS Proxy on Azure, using default Azure DNS, and I added a conditional forwarding at the on-premises DNS “ ->” and “ ->”. Now, I can successfully resolve the private IP of the storage account using its name, and be able to connect to it to both blob and to files with SMB access.

From the VM of the Spoke2 VNet (, in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “ Next Hop: Virtual Network Gateway” attached to the VM Subnet. I added a second route “ Next Hop: Virtual Network Gateway” & changed the VNet DNS to (the Azure Firewall) to be able to access the Spoke1 VNet for storage access.

DNS & Routing example

DNS: The on-premises Server X,, makes a request to At first, it asks the DNS to resolve the URL to an IP. The DNS has a conditional forwarder about, and asks the Azure Firewall, Azure Firewall has a linked Private DNS zone that has a host record for and it resolves to This information routes back to Server X. Now Server X knows that the IP address of is

Routing: To go to first it asks its Default Gateway, in our case the RRAS. The RRAS has a custom route for and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway. The Azure VPN Gateway has a custom route for BUT it also has a route for that is automatically populated by the VNet peering. The /32 route is more specific than the /24 route, so the VPN Gateway forwards the packet directly to the Private Endpoint, bypassing the Azure Firewall. (At the Azure Routing Experiences | Scenario 2 we will see how we will force the traffic through the Azure Firewall.

Please find below the whole solution diagram, I tried to make it as analytic as possible, without messing with too many lines. Also, I have some notes and tests below.

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



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.