Azure networking also comes with its own quirks. Routing decisions can seem like black magic to the untrained eye. The hub-and-spoke model helps centralize control, but it also demands a clear understanding of how traffic flows across virtual networks to avoid asynchronous routing for specific scenarios.
This article explores the trade-offs between granular control and operational simplicity –especially when comparing traditional hub-and-spoke topologies with Azure Virtual WAN.
User defined routing crash course
On each subnet in virtual networks in a hub-and-spoke topology, a route table should be associated to ensure that User Defined Routes can be applied and send traffic to the Azure Firewall to have the traffic inspected. In Azure, there are three types of routes, prioritized as follows.
- User Defined Routes – Routes you manually configure in a Route Table.
- BGP learned routes – Dynamically learned from on-premises or other networks.
- System routes – Default routes automatically created by Azure, including those from VNET peering.
Furthermore, the longest subnet length will win over a shorter subnet path. We can describe it with the following examples:
- A system route learned via VNET peering, 10.45.0.0/22 will win over a user defined route 0.0.0.0/0 because the subnet length of the system route is greater than the user defined route.
- A user defined route 10.45.0.0/22 will override a system route with the same prefix, because UDRs have a higher priority than system routes.
The “traditional” hub and spoke topology in Azure
The traditional Azure Networking topology as outlined in the Cloud Adoption Framework is designed to support scalable, customized networks across regions. It enables inter-hub routing and ensures traffic between spokes can be inspected—typically via a centralized firewall. The topology can be seen below. 
Zooming in on the hubs themselves, each regional hub is essentially a virtual network with three to five subnets. The exact number depends on whether you're deploying an AzureFirewallManagementSubnet, and whether your Private DNS Resolver requires both inbound and outbound endpoints. Within these hubs, you'll typically find VPN Gateways, the Private DNS Resolver, and the Azure Firewall.
Spokes can be configured with a user defined route that send internet traffic to their respective hub, where the firewall will take care of forwarding and inspection – either to other spokes or out to the internet.
But here’s the catch: system routes learned by the spoke are often more specific than the generic UDR for 0.0.0.0/0. That means traffic destined for services like the VPN Gateway or Private DNS Resolver can bypass the firewall entirely. I've seen this oversight several times. Some assume that routing everything through the tunnel from on-premises to Azure guarantees inspection by the firewall. In reality, due to system route precedence, that traffic might bypass the firewall—leaving a blind spot in their security posture.
Challenge 1: Not all hub traffic is inspected by firewall
If we use the following topology, the hub learns a route to 10.45.65.0/24 via VNET peering, while the spoke will learn a route to 10.45.0.0/22 the same way.
By only defining a 0.0.0.0/0 route going via the Azure Firewall, the VNET peering system route continues to stay active. Traffic between the VPN Gateway and workload subnet – or between the VPN Gateway and Private Resolver subnet can bypass the Azure Firewall rule processing.
We can see it reflected on the DemoWorkloadSubnet, and on the GatewaySubnet effective routes. For this demonstration, I have deployed a virtual machine in the different subnets in order to get the Effective Routes visualized.
Solution – Define directly peered VNETs to go via the Azure Firewall?
To ensure traffic is inspected, we need to modify the UDRs for directly peered VNETs - specifically in the rt-hub-vpng and rt-spoke-workload route tables. The effective routes are updated as follows.
Now traffic destined to and from the VPN gateway will go across the Azure Firewall. Great success!
Challenge 2: Let me introduce my friend, Asynchronous Routing!
Azure Firewall is highly available by design. While the Azure Portal doesn’t expose the underlying architecture, it’s fair to assume there’s an internal load balancer, an external load balancer, and multiple backend appliances. That’s speculation, of course—but it helps explain what’s happening.
You don’t need to worry about HA when deploying the firewall, but you do need to account for it when configuring UDRs—especially when using DNAT rules.
In our current setup, all hub traffic is routed to 10.45.0.4, the internal IP of the firewall. This works fine for internal flows. But when external traffic comes in via DNAT, things get tricky, and a new challenger appears. Asynchronous routing.
Due to the high availability nature, some TCP sessions will be load balanced to the same instance of the firewall, while other times it will be load balanced to the unknowing other instance of Azure Firewall, causing the session to be dropped. To resolve this, we have to reconfigure our user defined routes towards the Private DNS Resolver subnet and the VPN Gateway subnet to be pointing to the firewall. However, traffic to the firewall itself should follow the system route via VNET peering. 
Finally, if we map out the packet flow, it will start to become clear why UDP sessions could work in the previous routing scenario, but TCP sessions would sometimes work and sometimes fail. 
To summarize, to ensure that full traffic inspection in a traditional hub and spoke topology, we need:
- Separate route tables on the hub subnets with UDRs to neighboring subnets and peered VNETs.
- On the spokes, a default route 0.0.0.0/0 to the Azure Firewall.
- On the spokes, explicit routes to other hub subnets to the Azure Firewall.
The upside of the traditional hub and spoke is full control over routing and control over the individual VPN gateway, firewall resources and express route gateway resources. This also allows us to use some cheaper SKUs, making this topology more effective for the operational costs.
The downside is that it requires extreme discipline to maintain. As the network grows larger, peering relationships multiply, and so does the amount of user defined routes – small mistakes will become increasingly difficult to spot.
Routing with Azure Virtual WAN
Azure Virtual WAN introduces the concept of routing intent, which abstracts routing decisions into two broad categories: private and internet. This eliminates much of the complexity introduced by manually managing user-defined routes and custom route tables.
An added benefit of Virtual WAN is the scalability across regions. You can deploy a single global Point-to-Site (P2S) VPN profile, and Azure will automatically connect users to the nearest virtual hub based on proximity – no manual region selection required.
In addition, you get highly available VPN gateways by default in Virtual WAN – with two public IP addresses to support redundant tunnels to the hub.
Comparing costs of traditional hub-and-spoke with VWAN
As mentioned previously, the traditional topology can be more cost effective than VWAN. Let’s take a look at comparable SKUs between the two. We are using the West Europe region for pricing comparison.
- Traditional hub and spoke – using a Standard firewall SKU and a VpnGw1AZ for high availability - comes in at a monthly price of $1.065,80 at the time of writing.
- Azure Virtual WAN (Standard SKU) – using a Standard firewall SKU, a scale unit, and a connection unit for S2S and P2S (no traffic) – comes in at a monthly price of $1.777,19 at the time of writing.
That is almost 70% more expensive to go with the Virtual WAN equivalent – and if we did not require highly available tunnels, we could save even more using the traditional topology. That is food for thought.
Final thoughts
Both topologies recommended by the Microsoft Cloud Adoption Framework have their strengths.
- The traditional hub-and-spoke model offers granular control and can be more budget-friendly, especially for environments with limited routing complexity.
- Azure Virtual WAN, on the other hand, abstracts routing, enhances the P2S VPN experience, and feels more enterprise-ready out of the box.
To get greater control of routing in Virtual WAN, it’s worth exploring the Route Maps feature which recently went into General Availability (GA), to control which routes are advertised to and from the hub.
In the end, it’s a trade-off between control and simplicity, cost and scalability. Choose the topology that aligns best with your operational needs and growth plans.
About Andreas Bækgaard Larsen
Andreas is a Cloud Consultant in the Cloud Platforms & Security team at twoday Denmark, where he helps organizations navigate cloud transformation with clarity and precision. Since joining twoday in 2023, he has focused on enabling developers and strengthening cloud governance, optimization, and scalability. With expertise in Azure networking, governance, FinOps, and Azure Virtual Desktop, he tackles complex routing and topology challenges, implements Infrastructure as Code for secure, repeatable deployments, and uncovers cost-saving opportunities through FinOps reviews. Known for his pragmatic, developer-friendly approach, Andreas also shares his cloud knowledge to help teams grow – believing that collective growth leads to stronger solutions.
Andreas Bækgaard Larsen, Azure Consultant