Reading Debug Flow When Only Some Flows Fail
A FortiGate 100F has internal1 10.10.0.1/24 (staff 10.10.10.0/24) and internal2 10.20.0.1/24 toward a core switch. A route 10.20.0.0/16 points to 10.20.0.1. A vendor publishes an HTTPS service on server 10.20.5.5 via VIP 203.0.113.20:443 on wan1. The server has two NICs: 10.20.5.5/24 with no gateway, and 10.10.5.5/24 with default gateway 10.10.0.1. Internet users time out. The server's local log shows the SYN arriving and a SYN-ACK being sent. A capture on the FortiGate shows the SYN-ACK arriving on internal1 from 10.20.5.5. debug flow for the return packet shows 'reverse path check fail, drop'. The admin wants to run set asymroute enable.
1. Explain the debug flow message and why the connection fails even though the server sends a SYN-ACK.
Read the worked answer
The FortiGate routes 10.20.5.5 through internal2 (10.20.0.1), because that is the route for 10.20.0.0/16. The SYN-ACK, however, arrives on internal1. The reverse path check compares the packet's source against the route for that source; the incoming interface does not match, so the packet is dropped as a reverse-path failure.
The root cause is on the server: its default gateway is 10.10.0.1, so replies to internet clients leave via the 10.10.5.5 NIC instead of the 10.20.5.5 NIC. The server is dual-homed with an asymmetric return path. The SYN reached the server because the inbound direction was routed correctly; the reply was not.
Confirm the asymmetry with diagnose sniffer packet any 'host 10.20.5.5' 4: the SYN should appear on internal2 and the SYN-ACK on internal1. After the fix, both should appear on internal2.
2. Why is enabling asymroute a poor fix, and what should be changed instead?
Read the worked answer
set asymroute enable relaxes the reverse path check so the FortiGate accepts traffic that arrives on a different interface than the route predicts. That can make the connection work, but it weakens stateful inspection and can interfere with security profiles and session handling for asymmetric flows. It treats the symptom globally for all traffic, rather than fixing one server's routing.
The correct fix is to make the server's return path symmetric: set the default gateway on the 10.20.5.5 NIC to 10.20.0.1 (the core switch/FortiGate path for 10.20.0.0/16), and remove the default gateway from the 10.10.5.5 NIC. If the server needs both NICs, add specific routes so that internet-bound replies use the 10.20.5.5 side.
On the FortiGate side, verify the VIP and inbound policy are correct and that no stale more-specific route points 10.20.5.5 elsewhere. Only consider asymroute as a temporary diagnostic, never as the production design.
3. After the routing fix, what evidence would you collect to prove the problem is resolved rather than merely intermittent?
Read the worked answer
Collect evidence on both sides for a full session:
- On the FortiGate, a sniffer capture should show SYN arriving on internal2, SYN-ACK returning on internal2, and the ACK completing the handshake. No packet should appear on internal1 for this flow.
diagnose debug flowfiltered on 10.20.5.5 should show the packet passing the reverse path check and creating a session, with no drops.diagnose sys session listshould show an established session with the VIP translation and the expected source/destination addresses.- On the server, the connection log should show completed requests from multiple external test addresses, not just retries.
Test from at least two external networks and repeat after a few minutes; a single successful request does not prove the return path is stable. If any return packet still appears on internal1, the server routing is not fully corrected.