Technical Tip: FortiGate is unable to route the traffic correctly due to IP conflict with administratively down interface

[jera]

Description	This article indicates why a network conflict with an administratively down interface prevents FortiGate from properly routing traffic.
Scope	FortiGate.
Solution	Sample Topology: DMZ port 1 <> FortiGate <> IPSEC Tunnel <> (Remote Subnet) 10.10.10.3 (Server) DMZ interface (10.10.10.1/24) and the IPSec remote network (10.10.10.3) are in the same subnet. FortiGate will never forward that traffic into an IPSec tunnel. Scenario: DMZ interface is administratively down/down.  IPSEC tunnel is up. Explanation: FortiGate will still treat 10.10.10.0/24 as a connected subnet, not something that should be routed through IPSEC. The FortiGate routing behavior precedence: Connected Routes. Static Routes. Dynamic Routes. Since 10.10.10.0/24 is/was directly connected, FortiGate tries to ARP 10.10.10.3 and will never consider IPSEC as a valid path. This happens even when the interface is down/admin down, because the subnet still exists in the routing table logic.  To Fix: Use a different subnet on each side.