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.