A utility's NOC uses dual WAN links to two different upstream providers, with policy routes sending traffic to certain destinations out one link while replies to other, unrelated sessions legitimately return over the other link based on the routing table each provider maintains. What is the general concern this design raises for the FortiGate's default anti-spoofing behavior?
Select an answer to reveal the explanation.
Short Explanation
The FortiGate's spoofing check assumes traffic comes back the same way it expects, based on the routing table. In a deliberately asymmetric dual-WAN design, real traffic can violate that assumption and get mistaken for something suspicious.
Full Explanation
By default, FortiOS performs a reverse-path-forwarding check that expects a packet's source address to be reachable back out the same interface the packet arrived on, according to the routing table; in a genuinely asymmetric dual-WAN or policy-routed design, where outbound and return traffic for related or unrelated sessions can legitimately use different interfaces, this check can misclassify valid traffic as spoofed and drop it. Recognizing this tension is exactly why administrators need to evaluate RPF settings deliberately in asymmetric designs rather than leaving strict defaults blindly in place. The other options describe things that simply do not happen: multiple WAN links do not automatically merge into ECMP without matching distance and priority on identical destination routes, dual WAN has no mechanism that globally disables firewall policies, and IPsec VPNs are commonly and successfully built over one of several WAN interfaces in a dual-WAN deployment, so interface count does not prevent tunnel configuration. A practical check when designing this kind of topology is to test sessions that are known to return asymmetrically and confirm they are not silently dropped, adjusting RPF strictness only where the asymmetry is intentional.