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

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. 

Possible Fix:

• Use a different subnet on each side.
• In this example, if the DMZ is no longer in use, the DMZ IP address could be removed or changed to another subnet. 
• If the DMZ is in use and there is no desire to change the IP address, it can be corrected by implementing a Site-to-site VPN with overlapping subnets solution.