Routing Loop Between Static Routes and a Firewall
A branch has an ArubaOS-CX 6300 as its core router with SVIs for VLANs 10, 20, and 30. A firewall sits on a transit VLAN 99 (/30) and provides internet access and a site-to-site VPN to headquarters. The core has a default route pointing at the firewall (10.99.0.2). The firewall has static routes for 10.10.0.0/24, 10.20.0.0/24, and 10.30.0.0/24 pointing at the core (10.99.0.1). Users report that internet works, but traffic to headquarters (10.50.0.0/16) times out. traceroute from a user shows the packet bouncing between the core and the firewall repeatedly. The firewall's VPN tunnel to HQ is up, and HQ can reach the branch's VLAN 10 hosts.
1. Explain the loop. Why does internet work while HQ traffic loops?
Read the worked answer
The loop is a routing black hole caused by asymmetric/default-route interaction.
- The core's only route for 10.50.0.0/16 is the default route → firewall.
- The firewall receives the packet, and its route for 10.50.0.0/16 is via the VPN tunnel - but if the tunnel route is missing, less specific, or the firewall's route table prefers a route back toward the core, the firewall sends the packet back to the core (its default or a summary route pointing at 10.99.0.1).
- The core again matches its default → firewall. Loop.
Why internet works: Internet destinations (0.0.0.0/0) are handled by the firewall's own default route out its WAN interface, so there is no return path to the core. HQ traffic is the only class that requires the firewall to send traffic back toward the branch core, exposing the missing/incorrect HQ route.
Confirm with show ip route 10.50.0.0 on both devices and check the firewall's tunnel route and any summary routes that could capture 10.50.0.0/16 and point it at the core.
2. What is the correct fix, and how do you prevent this class of loop in the future?
Read the worked answer
Fix:
- On the firewall, ensure a specific route for 10.50.0.0/16 exists via the VPN tunnel interface, and that no less-specific route (e.g., a default or 10.0.0.0/8 summary pointing at the core) overrides it. Route selection is longest-prefix, so the /16 tunnel route must be present and correct.
- On the core, the default route to the firewall is fine, but consider adding an explicit route for 10.50.0.0/16 via the firewall so intent is documented (it resolves to the same next hop but makes the design explicit).
- Verify return path: HQ must route branch subnets back through the tunnel; confirm HQ's routes for 10.10/20/30.0/24 point at the tunnel.
Prevent recurrence:
- Avoid overlapping summary routes that capture remote-site space and point it at the wrong next hop. Audit for 10.0.0.0/8-style summaries on both sides.
- Use a dynamic routing protocol (OSPF/BGP) between core and firewall if the topology grows, so routes are exchanged rather than hand-maintained statics that can conflict.
- Add monitoring/alerting on route-table changes and a periodic traceroute check to key remote prefixes.
- Document the transit subnet's role and require change review for any default or summary route touching it.