Spoke Inspection Breaks On-Premises Routing
Contoso's hub VNet is 10.10.0.0/22. GatewaySubnet (10.10.0.0/27) hosts a site-to-site VPN to on-premises 172.16.0.0/16 with BGP enabled; AzureFirewallSubnet (10.10.1.0/26) hosts Azure Firewall at 10.10.1.4. Spoke1 is 10.11.0.0/24, peered to the hub with Use remote gateways enabled. Internet egress was already inspected via a 0.0.0.0/0 UDR pointing at 10.10.1.4. Last week security asked for on-premises traffic to be inspected too, so a second UDR for 172.16.0.0/16 next hop 10.10.1.4 was added to every spoke1 subnet. Now internet access from spoke1 works and hub VMs still reach 172.16.5.0/24, but no spoke1 VM can reach any on-premises address, and on-premises hosts cannot reach spoke1 either. Packet captures on-premises show the SYN arriving and the reply leaving.
1. Diagnose why spoke1-to-on-premises traffic now fails in both directions while hub-to-on-premises traffic is unaffected.
Read the worked answer
Root cause: asymmetric routing through the firewall.
- Forward path: spoke1 VM (10.11.0.5) sends to 172.16.5.10. The 172.16.0.0/16 UDR is a longer prefix than any other match and points to 10.10.1.4, so the packet goes to Azure Firewall.
- The firewall has a route to 172.16.0.0/16 via the VPN gateway (gateway-propagated, since no more specific UDR exists on AzureFirewallSubnet) and forwards the packet to the gateway, then on-premises.
- Return path: on-premises replies to 10.11.0.5. The gateway resolves that destination by peering and sends it straight into spoke1, bypassing the firewall.
- The firewall is stateful and never saw the reply for a flow it forwarded, so the return packet is dropped (and the mirror case explains why on-premises-initiated flows also fail).
Hub VMs are unaffected because their traffic never crosses the spoke1 route table, so no asymmetry exists.
Confirm with the effective route table on a spoke1 NIC (172.16.0.0/16 -> VirtualAppliance), the effective routes on an AzureFirewallSubnet NIC (172.16.0.0/16 via Virtual network gateway), and firewall logs showing the forward flow only.
2. Give a remediation that keeps on-premises traffic inspected, and state the risk you must guard against.
Read the worked answer
Make the return path symmetric by steering gateway-originated traffic for 10.11.0.0/24 back through 10.10.1.4.
- Create/associate a route table on GatewaySubnet with 10.11.0.0/24 next hop VirtualAppliance (10.10.1.4), and keep Propagate gateway routes = Yes.
- Keep the 172.16.0.0/16 -> firewall UDR on the spoke so inspection is preserved.
Risks to guard against:
- GatewaySubnet UDRs are honored; a wrong prefix there can blackhole the VPN. Roll out one spoke prefix at a time and verify tunnel status and BGP peer state afterwards.
- The firewall must keep learning 172.16.0.0/16 from the gateway. Do not disable gateway route propagation on AzureFirewallSubnet, and do not add a competing 0.0.0.0/0 UDR on it that would send on-premises traffic to the internet path.
- The firewall needs a management/HA path unaffected by the UDR; confirm Azure Firewall's health probes and that the firewall private IP is still reachable from GatewaySubnet.
A lower-risk alternative is to stop inspecting spoke-to-on-premises traffic (remove the 172.16.0.0/16 UDR) and rely on the gateway; the trade-off is losing east-west inspection.
3. The team instead proposes removing the 172.16.0.0/16 UDR from the spokes and relying on the 0.0.0.0/0 UDR to send on-premises traffic to the firewall. Explain whether that works.
Read the worked answer
No - it fails for a routing reason, not a firewall reason.
Azure selects routes by longest prefix match first, and only then by origin (user-defined > BGP > system). The BGP-learned 172.16.0.0/16 from the VPN gateway is a /16; the 0.0.0.0/0 UDR is a /0. The /16 wins, so on-premises traffic from spoke1 will not go to 10.10.1.4 at all - it will go directly to the gateway.
Consequences to state explicitly:
- On-premises traffic becomes uninspected (the original security requirement is not met), even though connectivity returns.
- The result is confusing to operators: the route table appears to force everything through the firewall, but effective routes on the NIC will still show 172.16.0.0/16 -> Virtual network gateway.
If inspection is mandatory, you must either add a more specific prefix pointing at the firewall (which reintroduces the asymmetry problem from the previous task until GatewaySubnet is fixed) or insert the inspection point where both directions naturally cross it.