Forum Discussion
Help ! - Hub Spoke Architecture and Routing via NVA
This behavior is not a defect but a design limitation of Azure’s routing model. System routes from VNet peering are always injected, and the only sustainable method to guarantee firewall inspection for future spokes without manual intervention is to adopt Azure Virtual WAN with a secured hub. Otherwise, ongoing maintenance of UDRs for each new spoke remains necessary.
https://learn.microsoft.com/en-us/azure/virtual-wan/scenario-route-through-nva
https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/azure-vwan-sd-wan-ngfw-deployment-guide/372408/microsoft-azure-vwan-and-nva-overview
This is usually caused by route selection. Azure chooses routes using longest prefix match first, then route type.
So if you add a broad supernet UDR, such as 10.0.0.0/8, but the system has more-specific VNet peering routes, the more-specific routes can still win. That means traffic may bypass the NVA even though a broad UDR exists.
Options:
1. Add specific UDRs for each spoke prefix pointing to the NVA.
2. Automate route management as spokes are added.
3. Use Azure Virtual Network Manager for routing/security administration at scale.
4. Consider secured Virtual WAN/routing intent if the environment is moving in that direction.
For hub/spoke inspection through an NVA, broad summary routes are convenient but can be overridden by more-specific routes. Check effective routes on the spoke NICs/subnets to confirm the selected next hop.