After the NOC team adds a policy route sending technician-VPN return traffic out a different interface than the one packets arrived on, some sessions start failing even though the policy route and firewall policy both look correct. What FortiGate mechanism is most likely dropping this traffic?
Select an answer to reveal the explanation.
Short Explanation
The FortiGate has a built-in suspicion detector: it checks whether a packet's return path matches the path it expects based on where the packet actually showed up. When a policy route sends replies out a different door than they came in, that check can flag it as spoofed and drop it.
Full Explanation
Strict reverse-path-forwarding is an anti-spoofing check that verifies an incoming packet's source address is reachable back out the same interface it arrived on, according to the routing table; when policy routing or asymmetric multi-path designs send return traffic out a different interface than the routing table would independently choose, the RPF check can classify that traffic as spoofed and drop it, even though the policy route and firewall policy are both correctly configured. This is a distinct check from content-security features: antivirus inspects payload for malware and has no concept of routing symmetry, so it plays no role here. FortiGuard web filtering evaluates URL categories for web traffic, not IP-layer path selection, and would not intervene in a VPN return-path scenario. The Security Fabric coordinates visibility and configuration sync between Fortinet devices; it does not enforce symmetric routing as a requirement. The practical fix is to adjust the RPF behavior for the affected interfaces or traffic (loosening strict checking where asymmetric-by-design paths are expected) and then confirm with a live session trace that the technician-VPN sessions establish and stay up.