Forum Discussion
Help ! - Hub Spoke Architecture and Routing via NVA
I have a classic example of routing. I want to force all traffic via Fortigate firewalls. EastWest and NorthSouth. However when large Supernet of Azure Vnet is used to route and force the traffic via UDR at gateway subnet, its not working. Because Routes learned at Hub Vnet via Vnet peering is taking precedence.
To isolate, i have created multiple small subnet routes for Gateway subnet. Each pointing to spoke vnet and next hop as Fortigate firewall.
However this is working, i want to make solution solid. Means if someone creates new vnet in future and peer with Hub, it should not get direct traffic. Is that possible?
Or this is typical shortcoming of Azure where routing works with preference to vnet peeering.?
Below is architecture -
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
3 Replies
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.
Thanks a lot Kidd_Ip . This really helps to think on different prespective.
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
