Adventure Works: Spoke-to-Spoke Traffic Through a Hub Firewall

Two facts combine: peering is non-transitive, and forwarded traffic is a per-link switch.

1. Non-transitive peering. Azure programs routes only for directly peered VNets. Spoke1 has a route for 10.0.0.0/16 (hub) but no route for 10.2.0.0/16. That is expected and handled: the 0.0.0.0/0 UDR sends the packet to the firewall.
2. The packet is now forwarded traffic. It arrives at the firewall from 10.1.1.4 and must be forwarded out of the hub towards 10.2.0.0/16. For that, the peering used in each direction must permit it - the 'Allow forwarded traffic' setting must be enabled on the hub↔Spoke2 link (outbound from the hub) and on the hub↔Spoke1 link (for the return path). If those settings are off, the firewall's egress packet is dropped at the peering boundary, even though the firewall rule allowed it.

Also verify:

• 'Allow virtual network access' is enabled on all four links.
• NSGs on AzureFirewallSubnet are not blocking (Azure Firewall subnet NSGs are restricted).
• The firewall rule collection is applied in the correct policy/classic rule collection and has not been shadowed by a higher-priority deny.

Connected status only means the peering was established with matching address spaces - it says nothing about which traffic classes are permitted.

Prove where the packet dies before touching a setting.

1. Effective routes on the source NIC (10.1.1.4). Confirm 0.0.0.0/0 → Virtual appliance 10.0.1.4 is present and that no system route or BGP-injected route wins over it.
2. Next hop from 10.1.1.4 to 10.2.1.4. It should return Virtual appliance 10.0.1.4. If it returns VirtualNetworkGateway, Internet or None, the route table is wrong or not associated to that subnet.
3. IP flow verify from 10.1.1.4 to 10.2.1.4:443. An NSG block names the rule; 'Allowed' with continued failure points past the NSG.
4. Connection troubleshoot from the source VM to the destination IP and port - this walks the path and reports the hop that drops.
5. Effective routes on the destination subnet and the return path. The return leg from 10.2.1.4 to 10.1.1.4 also hits a 0.0.0.0/0 UDR, so it is forwarded too - asymmetry is fine here only because both directions use the same firewall.
6. Peering properties on all four links - read allowForwardedTraffic and allowVirtualNetworkAccess directly rather than trusting the Connected badge.
7. Firewall logs (Kusto in the workspace, AZFWNetworkRule). If there is no log entry at all, the packet never reached the firewall and the problem is routing or peering, not the rule.

Full mesh is the wrong answer at 25 spokes - 300 peering links, each with its own forwarded-traffic and route configuration, plus a UDR on every subnet. It is operationally unmaintainable.

Options, in order of preference for this requirement:

1. Azure Virtual WAN with a secured virtual hub. Spokes attach to the hub, the hub carries the routing, and Azure Firewall (or a supported NVA) provides inspection. Routing intent can force all private and internet traffic through the firewall centrally, which removes the hand-built UDR and peering matrix. Trade-off: less granular control of route tables than hand-rolled UDRs, and cost scales with hub and connection units.
2. Keep the hub-and-spoke but standardise it. Enable 'Allow forwarded traffic' on every spoke-to-hub link at creation (template/policy), keep the 0.0.0.0/0 UDR as a single enforced pattern, and manage the firewall rule collection centrally in a firewall policy. Works well to maybe 10–15 spokes; the peering count is linear, the route tables are not, which is the actual limit.
3. Direct spoke-to-spoke peering for a small number of chatty pairs, kept alongside the hub for everything else. Only viable if the pairs are few and stable.

Non-negotiable in all three: one consistent pattern for the UDR, and the forwarded-traffic flag set by policy at peering creation - the failure in this case came from a per-link setting that no one was checking.