ExpressRoute Circuit Shows Connected but Traffic Fails
Fabrikam has an ExpressRoute circuit with a private peering to a virtual network gateway in West Europe. The circuit status shows 'Enabled' and the peering shows 'Provisioned'. The provider reports the BGP session is up. However, VMs in the spoke VNet cannot reach on-premises servers at 10.20.0.0/16. The hub VNet has address space 10.10.0.0/16 and the gateway subnet 10.10.1.0/24. A route table on the spoke subnet contains a default route 0.0.0.0/0 pointing to a firewall appliance, and the firewall's effective routes do not include the on-premises prefix. Peering between hub and spoke is 'Connected' with allow gateway transit enabled on the hub and use remote gateway enabled on the spoke.
1. Identify the most likely cause of the connectivity failure and explain the routing logic.
Read the worked answer
The gateway and circuit are healthy, so the fault is in the data path inside Azure. The spoke subnet has a user-defined default route to a firewall appliance. Because the UDR is more specific than the system-learned routes? No - a 0.0.0.0/0 UDR is the least specific but it overrides the default system route for all traffic not otherwise matched, and crucially it captures traffic destined to 10.20.0.0/16 unless a more specific route exists. The more specific 10.20.0.0/16 route learned via the gateway should win over 0.0.0.0/0 by longest-prefix match, but the firewall's effective routes do not show the prefix, meaning the gateway-propagated routes are not reaching the spoke.
Likely causes, in order:
- Gateway transit misconfiguration: use remote gateway must be enabled on the spoke peering and allow gateway transit on the hub; the status text can show Connected while the flags are wrong.
- Route propagation disabled on the spoke subnet's route table, preventing BGP-learned routes from being added.
- The firewall appliance itself has no route to 10.20.0.0/16, so even if traffic reaches it, return traffic fails.
Check the effective routes on the spoke VM NIC and on the firewall NIC separately.
2. How would you distinguish a control-plane issue from a data-plane issue here?
Read the worked answer
Control plane = provisioning and state: circuit status, peering state, BGP session, peering flags, route table associations. Data plane = actual packet flow: effective routes on NICs, NSG flow logs, firewall logs, and traceroute-like diagnostics.
Method: if control-plane objects all read healthy but effective routes on the NIC lack the on-premises prefix, the problem is route propagation or peering flags - still control-plane configuration affecting the data plane. If effective routes include the prefix and packets still drop, inspect NSGs on the gateway subnet and spoke subnet, the firewall policy, and on-premises return routing. Use Network Watcher connection troubleshoot and next hop to confirm which hop discards traffic.