Azure RouteServer

Question

Azure RouteServer

Peter Stieber 70

I’m working with the topology described here: https://learn.microsoft.com/en-us/azure/route-server/multiregion Diagram showing multi-region network architecture with Azure Route Server in each hub virtual network.

In addition to that setup, Hub1 has a VPN Gateway that establishes a VNet-to-VNet tunnel to a remote site, and that remote site is also connected to on-premises. BGP propagation is disabled on both NVA subnets, and I’ve configured static routes on each NVA subnet pointing to the opposite hub.

However, on the NVA subnet in Hub1, I’m unable to configure a static route that uses the Virtual Network Gateway as the next hop — when I do, the effective routes show the next hop as None. Because of this limitation, I enabled BGP propagation on the NVA subnet in Hub1 so it could learn a return route. With BGP propagation enabled, it partially works — return traffic flows correctly and I can ping all spokes, including those attached to Hub2 — but I still cannot ping the NVA in Hub2. Everything else is reachable except that one NVA.

Why is the NVA in Hub2 the only endpoint I can’t reach?

0 comments

1 answer

Your answer

Answer 1

Hi Peter Stieber,

Welcome to Microsoft Q&A and thank you for posting your query here!

Thank you for detailing your multi-hub Azure Route Server setup. Based on your described architecture, Hub1 with a VPN Gateway connected to a remote site, spoke VNets peered to each hub, and NVAs deployed in both Hub1 and Hub2, you’re seeing correct routing to all spokes and remote networks except direct reachability from Hub1 to the NVA in Hub2.

Root Cause and Azure Routing Limitations

User-defined routes (UDRs) that use “Virtual Network Gateway” as the next hop type are not supported on subnets within the same VNet as an Azure Route Server or on NVA subnets. When configured, the effective routes show the next hop as None, resulting in blackholed traffic.
When you enabled BGP propagation on the NVA subnet in Hub1, it restored return routing and connectivity to spokes and remote sites because BGP dynamically learned the correct routes. However, Azure’s internal routing design prevents direct forwarding to the NVA subnet in Hub2, since that subnet’s route isn’t being advertised through a supported next hop. Azure Route Server does not propagate routes learned from a Virtual Network Gateway to other peers or other Route Servers, which is why only the NVA in Hub2 remains unreachable.
Everything else is reachable because those routes (for spokes and remote networks) are learned via BGP or system routing. The NVA subnet in Hub2 isn’t covered by either and is effectively excluded from the propagation path.

Recommendations

Ensure each NVA advertises its own subnet and next hop via BGP to the local Route Server. (Use the NVA’s internal IP or load balancer front-end IP as the next hop.)
Avoid configuring “Virtual Network Gateway” as the next hop in any UDR associated with Route Server or NVA subnets.
For cross-hub NVA-to-NVA communication, use dedicated overlay tunnels (e.g., IPsec, VXLAN, or GRE) between NVAs, and exchange routes via BGP. This is the recommended approach for multi-hub scenarios to avoid asymmetric paths and blackholing.
Limit custom UDRs to supported next hop types: VirtualAppliance, VirtualNetwork, or Internet.

References:

i hope the above response is helps, please do let me know if you have any questions on this!

if this response helps clarify your query, kindly consider accepting the answer so others can benefit as well.

Thanks,

Harish.