Traffic from on prem not routing into azure via fortigate NVA firewall

What you've checked vs. what's likely missing

You mentioned checking effective routes at the source VM and the NVA's NIC — but the critical missing piece is the Virtual Hub's own defaultRouteTable effective routes, which is exactly where Microsoft's troubleshooting guide says to start:

"Once you have verified that the effective routes of the defaultRouteTable have the correct prefixes, view the Effective Routes of the Network Virtual Appliance or Azure Firewall." — Virtual WAN routing intent troubleshooting

Since traffic Azure→on-prem works fine but on-prem→Azure never reaches the firewall at all, this points strongly at routing intent / Private Traffic Routing Policy not being applied correctly to the ExpressRoute branch connection specifically — even if it works fine for VNet-to-VNet traffic.

Step-by-step diagnosis

1. Check the Hub's defaultRouteTable effective routes

Go to your Virtual WAN Hub → Route Tables → defaultRouteTable → Effective Routes. You should see:

Prefix: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 → Next Hop: [Your Fortigate NVA]

If these RFC1918 aggregate routes are missing or pointing elsewhere (e.g., directly to the VNet connection instead of the NVA), that's your root cause — Private Traffic Routing Policy isn't being applied to that prefix range.

2. Confirm Private Traffic Routing Policy is actually configured (not just Internet)

It's a common mistake to enable an Internet Traffic Routing Policy but leave Private Traffic unconfigured. Per the docs:

"When a Private Traffic Routing Policy is configured on a Virtual WAN hub, all branch and Virtual Network traffic in and out of the Virtual WAN Hub including inter-hub traffic is forwarded to the Next Hop Azure Firewall, Network Virtual Appliance, or SaaS solution resource."

Without it explicitly configured for Private Traffic (not just Internet), on-prem→VNet traffic can bypass the NVA entirely while Azure→on-prem (often using a separate egress path) still appears to work.

Check: Virtual WAN Hub → Routing → Routing Policies → confirm Private Traffic has your Fortigate NVA selected as next hop (not "Bypass").

3. Verify your destination VM's subnet isn't a non-RFC1918 range

If your VM's subnet (or the on-prem range) uses a non-RFC1918 address space, it won't automatically be covered by the default _policy_PrivateTraffic aggregate routes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16):

"If you're using non-IANA RFC1918 prefixes in your connected on-premises or Virtual Networks, make sure you have specified those prefixes in the 'Private Prefixes' text box."

This is an easy one to miss and produces exactly your symptom — traffic just silently bypasses the NVA with no logs.

4. Check "Propagate gateway routes" on your destination VM's subnet UDR

If the destination VM's subnet has a custom route table:

"Propagate gateway routes" must be enabled for Virtual WAN to advertise routes to workloads deployed in spoke Virtual Networks connected to Virtual WAN.

If this is set to "No," the spoke VNet itself won't even learn the correct routes back, independent of what the Hub does.

5. Check for BGP route advertisement from your Fortigate to the Hub

Since you're using an ILB in front of the Fortigate (sounds like active/active or active/passive HA), confirm your Fortigate is correctly peering via BGP with the Virtual Hub Route Server and advertising the destination VM's subnet:

"For active-passive NVA configurations where only one instance of the NVAs is advertising a route for a specific prefix to Virtual WAN... Virtual WAN ensures that outbound traffic from an Azure Virtual Network is always routed to the active (or preferred) NVA instance."

If BGP peering is broken or only partially established (remember: both hub BGP peer IPs must be peered, not just one), the Hub may not know to route ExpressRoute traffic toward your NVA's ILB at all — even though VM-to-VM traffic still resolves correctly via system routes.

⚠️ Important: confirm you're not running active-active with asymmetric forwarding unsupported — check with Fortinet whether your FortiGate cluster supports asymmetric forwarding/session sync, since:

"Azure's software-defined networking platform doesn't guarantee flow-level symmetry... This results in asymmetric routing which is dropped by stateful firewall inspection."

6. Confirm you don't have leftover static routes conflicting with routing intent

Routing intent requires no custom route tables and no static routes in defaultRouteTable pointing to a Virtual Network connection. If routing intent was enabled after manual UDRs were already in place, leftover conflicting static routes can silently break propagation for ExpressRoute-sourced traffic specifically.

My recommended order of operations

1. Hub defaultRouteTable effective routes ← start here, you haven't checked this yet
2. Routing Policies blade → confirm Private Traffic policy is set to your Fortigate, not "Bypass"
3. NVA effective routes (you've done this, but re-check specifically for the 10.0.0.0/8 etc. aggregate prefixes with next hop = NVA, not just check for presence of any route)
4. BGP peering status between Fortigate and Hub Route Server (both peer IPs)
5. Fortigate logs — confirm whether ICMP from on-prem is being silently dropped at the OS/NIC level vs. never arriving (use a packet capture on the Fortigate's internal interface, not just the firewall policy log, since if BGP/routing is broken the traffic won't even hit the firewall engine)

If after all this you still can't find the gap, this is exactly the kind of case where Microsoft Support + your Fortinet rep working together is warranted — routing intent + dual-role NVA HA interactions are genuinely one of the more complex areas of Virtual WAN, and Microsoft's own docs explicitly recommend reaching out to your NVA provider for these scenarios:

"Check NVA Firewall logs to see if traffic is being dropped or denied by your Firewall rules. Reach out to your NVA provider for more support and guidance on troubleshooting."

References:

• How to configure Virtual WAN Hub routing intent and routing policies — Troubleshooting
• Scenario: BGP peering with a virtual hub
• Virtual WAN routing deep diveGood news — this is a very well-documented troubleshooting pattern in the Virtual WAN routing intent docs, and there's a specific gap in what you've checked so far. Here's a thorough breakdown.