Asymmetric Return Path After BGP Dual-Homing
An enterprise uses a FortiGate 400F with two ISP links and eBGP to each ISP. Both sessions advertise a default route; the FortiGate installs the ISP2 default because of a higher local preference set by the carrier. A public web server sits in a DMZ VDOM and is published with a VIP on the ISP1 address. Before ISP2 was added, HTTPS worked reliably. Now external users sometimes complete the TCP handshake but the page stalls; other times it loads. The security team captures traffic and sees the SYN arriving on wan1, but the SYN-ACK leaving wan2 with the ISP1 VIP address as source. ISP2 says it applies unicast RPF. Outbound user traffic is NATed to the outgoing interface and works. The business wants automatic ISP failover for outbound and reliable inbound access to the web server without moving the VIP.
1. Explain the failure mechanism and the evidence you would collect to prove it.
Read the worked answer
The FortiGate is choosing ISP2 for the return path to the external client because BGP prefers the ISP2 default route. The server reply therefore leaves wan2 with the ISP1 VIP as source. ISP2 applies unicast RPF and drops the packet, so the handshake or TLS session stalls. Prove it with a sniffer on both WAN interfaces: diagnose sniffer packet any 'host <server> and port 443' 4 should show SYN on wan1 and SYN-ACK or server reply on wan2 with the VIP source. Check get router info routing-table all and get router info bgp network to confirm the ISP2 default is selected. diagnose sys session list shows the session and its NAT state. ISP1-side captures may show the SYN arriving but no completed handshake. The intermittent behavior depends on which BGP path is active at the time.
2. What routing and policy changes would make inbound and outbound paths deterministic?
Read the worked answer
Make the DMZ return path deterministic. Add a policy route in the DMZ VDOM that matches traffic from the web server subnet and sends it to the ISP1 next-hop; keep the VIP on the ISP1 address so inbound and outbound paths both use wan1. This overrides BGP only for that server flow and preserves ISP2 for outbound user failover. Alternatively, if the design requires BGP symmetry for the whole VDOM, set a higher local preference for ISP1 there, but that removes outbound failover unless a second policy route is added. Do not enable asymroute globally as a fix; it weakens stateful inspection and does not solve upstream RPF. Confirm outbound user NAT still uses the outgoing interface and that the VIP is not advertised on ISP2.
3. How would you test failover without breaking existing sessions?
Read the worked answer
Test with a temporary external client or a test VIP before changing production. Capture on both WAN interfaces while opening a new HTTPS session; do not rely on an existing browser session. Use diagnose sys session clear only for the test flow, not the whole table. Then simulate ISP1 failure by disabling the policy route or shutting the test path in a window, and confirm outbound users move to ISP2 while the DMZ server remains reachable only through the intended design. Verify BGP withdraws or the policy route is removed, and check that return traffic does not reappear on ISP2. After the test, restore the policy route and confirm session counts and logs show no asymmetric drops.