After a utility redesigns its WAN routing so that return traffic from the corporate billing network to a field crew's VPN session now takes a different path back through a second FortiGate interface than the path the session originally went out on, the crew's application connections begin silently failing partway through. What FortiOS mechanism explains why asymmetric routing like this breaks stateful sessions?
Select an answer to reveal the explanation.
Short Explanation
FortiGate isn't just checking each packet against the rulebook — it remembers, per session, which interface that session belongs to. Change the return path mid-flight, and the firewall no longer recognizes the traffic as part of that session at all.
Full Explanation
FortiOS is a stateful firewall: once a session is established, it is tracked in the session table with details including the interfaces involved, and subsequent packets for that session are matched against the existing session entry rather than being re-evaluated from scratch against the policy list every time. When routing changes cause return traffic to arrive on a different interface than the session table expects, the traffic no longer matches the existing session, and depending on configuration it can be dropped rather than transparently reassociated, which produces exactly the mid-session failure described. This is a foundational reason why asymmetric routing is a known troubleshooting culprit in FortiGate deployments and why routing symmetry matters even though the firewall isn't a router in the traditional sense. The implicit deny is a policy-list construct that governs new session establishment; it does not contain a special hard-coded anti-spoofing rule targeting interface changes on existing sessions, so framing the failure that way misattributes the mechanism. Policies are evaluated once, at session setup, precisely because FortiOS is stateful, re-evaluating every single packet against the full policy list would defeat the performance purpose of maintaining a session table at all. IP pools track address translation assignments for outbound NAT, not general session-to-interface bindings, so they are not what's enforcing this behavior. To troubleshoot, an engineer inspects the session table for the affected flow and checks whether the expected inbound/outbound interfaces still match the current routing table's path.