Azure NVA Inspection: Why the Reply Takes Another Firewall

A branch-to-Azure flow can be routed correctly in both directions and still fail, because the two directions take different appliances. The request leaves the branch over the VPN, lands on NVA A, and reaches the workload. The reply leaves the workload, matches a route pointing at NVA B, and dies there. Every route in that picture is valid, and the TCP session is still broken.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

That gap is the whole subject here: routing convergence and session-state ownership are different problems that look identical in a diagram.

What Route Server actually programs

Azure Route Server peers with supported BGP speakers, learns their routes, and programs them into the virtual network's effective routes. That is a control-plane job. It does not read a vendor firewall's session table, and it has no idea which appliance admitted a given connection. Two equal-cost next hops are, to the fabric, simply two ways to reach the same prefix, and it will use either.

Learning a route therefore proves reachability. It proves nothing about whether the device on the other end has seen this flow before.

Read both directions before you design

Start by writing down the steering you actually have in each direction, not the one you intended. More-specific BGP routes, user-defined routes and gateway behaviour all compete, and the winner is decided per destination, not per session. An NVA default route does not mean every private prefix traverses it.

A useful check is to ask, for one specific workload IP, which next hop each direction resolves to. If the answer is two different appliances, you have an asymmetry problem whether or not it has surfaced yet.

Where the state lives

A stateful firewall admits a connection and keeps a table entry keyed on the five-tuple. The reply has to reach the device holding that entry, or that device has to obtain the state some other way. Nothing in the Azure data plane forwards the entry between appliances. Either the traffic is steered back to the owner, or the appliances share state through a vendor mechanism, or the design does not work.

This is why two healthy NVAs is not a health check for inspection. Health is about reachability; inspection is about which instance holds the session.

Supported HA models and what each one promises

Microsoft's guidance on Virtual WAN routing intent describes scoped behaviour for dual-role connectivity and firewall NVAs, where direct routing can bypass the hub's normal symmetric enforcement. Read those notes as constraints on the topology you picked, not as a ban on active-active designs. A vendor pair that synchronizes state, or steers per flow, can be supported. An equal-cost pair that does neither is not.

Then define what happens to existing sessions when a node fails. Route convergence restores reachability for new flows within seconds, while the old firewall state is simply gone. A client reconnect may be the documented outcome, and that is a decision to make before the incident rather than during it.

What to test before you trust it

Test with inspection enabled and the workload's access policy in place, because either one can hide the asymmetry. Send a new authorized flow in both directions and confirm the same appliance saw both halves. Then run sustained traffic and trigger the approved failover, watching whether established sessions survive or reconnect.

Correlate each flow with the appliance that handled it. A packet capture on one NVA tells you almost nothing if the reply never came back to it.

Finally, write the plan as three separate lines: route ownership, traffic steering, and session-state ownership. Designs break when the first two are solved and the third is assumed.