Azure Virtual WAN routing traffic via 3rd party firewall NVA in sidecar VNet

Hi Pete Kick,

Thanks for reaching out in Microsoft Q&A forum,

Is anyone able to point me in direction of what the routing should look like for this?

To resolve the routing issues in your Azure Virtual WAN (vWAN) setup featuring a single vHub, three spoke VNets, and a dedicated VNet for the firewall NVA focus on custom vHub route tables and symmetric paths to ensure all spoke-to-spoke (east-west) and internet-bound traffic traverses the NVA without direct peerings.

The common problems of traffic bypassing the NVA or return paths looping back through it arise from default vHub route propagation and asymmetric routing, which custom configurations can fix effectively.

Key steps include connecting all VNets to the vHub while disabling route propagation on the NVA VNet connection to prevent unwanted overrides.

• Create a "To-NVA" vHub route table with static routes for each spoke CIDR and 0.0.0.0/0, setting the NVA VNet as the next hop, then associate this table exclusively to the spoke connections.
• On the NVA side, configure its route table with UDRs pointing spoke CIDRs to the NVA's internal IP, and ensure the NVA forwards return traffic to the vHub's gateway IP (often 169.254.x.x range) to avoid loops.
• Set up a "From-NVA" vHub route table to propagate NVA-advertised routes (via BGP if supported) back to the hub, associating it only to the NVA connection for clean spoke-to-spoke flows.
• Disable any vHub routing intent features, as they can inject default routes that bypass your NVA.

For spoke-to-spoke traffic, packets from one spoke hit the vHub, follow the "To-NVA" static route to the firewall for inspection, then return symmetrically via the NVA to reach the destination spoke. Internet traffic follows the same 0.0.0.0/0 path through the NVA for NAT handling.

Troubleshoot by checking effective routes on VM NICs with Network Watcher, verifying next hops, and testing connectivity flows adjust route priorities if asymmetry persists, potentially using vWAN route-maps for finer control.

Update:

• On the "To-NVA" route table, do I need to configure the next hop IP of the NVA for each route here? If don’t add the IP, inter spoke traffic bypasses the NVA but if I do configure it, traffic leaving the NVA goes to the vhub then gets routed back to itself?
• Is it correct to have the To-NVA route table associated with all spoke connections (not NVA Vnet) and propagating with all?
• For 'On the NVA side, configure its route table with UDRs pointing spoke CIDRs to the NVA's internal IP, and ensure the NVA forwards return traffic to the vHub's gateway IP (often 169.254.x.x range) to avoid loops' Please could you clarify this? If I create a UDR for spoke CIDRs associated with its own IP would it not just route back to itself?
• The From-NVA route table, associated to NVA Vnet connection and propagate with spokes only?

• For the "To-NVA" route table, yes, you need static routes with the exact private IP of the NVA's network interface (e.g., 10.0.1.4) as the next hop for each spoke CIDR and 0.0.0.0/0 not the VNet connection or gateway IP. Without the IP, traffic defaults to vHub paths and skips the NVA; with it, the loop happens if the NVA's return path isn't set right (more on that next).
• Association and propagation: Associate "To-NVA" only to spoke VNet connections (exclude NVA VNet). Set propagation to none spokes consume these routes but shouldn't advertise back into it.
• On the NVA VNet side, skip UDRs on the NVA subnet for spoke CIDRs (that would loop to itself). Instead:
  • Keep the NVA subnet on default system routes (0.0.0.0/0 points to vHub gateway, like 169.254.x.x).
  • Inside the NVA appliance config (CLI/GUI), set return routes for spoke CIDRs to the vHub gateway IP (visible in NVA NIC effective routes). This sends replies to vHub, which forwards via "From-NVA" without looping back.
• For "From-NVA", associate it only to the NVA VNet connection, propagating from spoke connections (lets NVA-learned spoke routes flow back cleanly).

Verify with Network Watcher effective routes on a spoke VM (should show NVA IP next hop inbound) and NVA NIC (vHub gateway outbound). If needed, enable BGP on NVA for dynamic spoke advertisements.

Reference:

• Route traffic through NVAs by using custom settings - Azure Virtual WAN | Microsoft Learn
• Scenario: Route traffic through a Network Virtual Appliance (NVA) - Azure Virtual WAN | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Hi Venkatesan S, many thanks for your help on this, please could I clarify a couple of points as I'm still hitting the same issue?

• On the "To-NVA" route table, do I need to configure the next hop IP of the NVA for each route here? If don’t add the IP, inter spoke traffic bypasses the NVA but if I do configure it, traffic leaving the NVA goes to the vhub then gets routed back to itself?
• Is it correct to have the To-NVA route table associated with all spoke connections (not NVA Vnet) and propagating with all?
• For 'On the NVA side, configure its route table with UDRs pointing spoke CIDRs to the NVA's internal IP, and ensure the NVA forwards return traffic to the vHub's gateway IP (often 169.254.x.x range) to avoid loops' Please could you clarify this? If I create a UDR for spoke CIDRs associated with its own IP would it not just route back to itself?
• The From-NVA route table, associated to NVA Vnet connection and propagate with spokes only?

Hi Pete Kick,

Updated in answer.
Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Hi Venkatesan S, thanks for clarifying.

With this config, spoke traffic from a VM in one spoke to another spoke goes via vhub, then the NVA ok, but anything leaving the NVA loops back to the NVA. The NVA not currently configured for BGP routing.

I've also just deployed another VM in the same subnet as the NVA and if I do a trace from that to a spoke vnet it hits the vhub address but then gets routed back to the NVA (and subsequent loop).

I've tried setting routes in both the NVA and the test VM in NVA subnet to go to spokes via 169.254.169.254 which I think is the vhub gw address you are referring to? I also tried the private vhub IP shown in traces .

Would you have any idea how to stop vhub from sending traffic back to the NVA? I've double checked the 'From-NVA' route table is associated with NVA VNet etc.

Thanks for your help.

Pete Kick ,

The loop on return traffic (and even from the NVA subnet test VM) is a frequent vWAN quirk without BGP, where the vHub applies your "To-NVA" table routes directly to the NVA subnet's effective routes, overriding manual UDRs and pointing spoke traffic back to the NVA IP locally.

Here's the fix to stop the vHub from re-directing:

• NVA subnet route table: Create/assign a custom route table exclusively to the NVA subnet (leave spokes alone). Add UDRs for all spoke CIDRs with next hop explicitly set to vHub gateway (169.254.169.254)—this has higher precedence than vHub-injected routes and breaks the local loop.
• NVA appliance & test VM: Keep your spoke CIDRs > 169.254.169.254 routes (correct). Same for NVA config (CLI/GUI) route spokes to vHub gateway, not its own IP or subnet default gateway.
• vHub table confirmation:
  • "To-NVA": Associated to spokes only; propagates from none.
  • "From-NVA": Associated to NVA VNet only; propagates from spokes only.
• Quick test: Apply the NVA subnet UDRs first, then trace from test VM to spoke via Network Watcher "Next hop" it should now go NVA subnet > 169.254.169.254 > spoke (no NVA IP). Check effective routes on NVA NIC to confirm.

This ensures inbound hits NVA (via "To-NVA" IP route), but all NVA subnet outbound goes straight to vHub for "From-NVA" handling. If the private vHub IP from traces differs, use that instead, but 169.254.169.254 is standard.

Official Docs:

• Virtual hub route table to NVA
• Custom NVA routing in vWAN

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Kindly let us know if the above helps or you need further assistance on this issue.