Troubleshooting Tip: Unused IP Pools object can disrupt traffic

[tonylin1]

Description	This article describes the possible reason for service disruption after adding an IP Pools object, even though the object is not applied to any security policy.
Scope	FortiGate.
Solution	Topology: Internet <---> [WAN] FortiGate [LAN] 14.14.14.17 <---> Client 14.14.14.100. FortiGate IP Pools configuration: config firewall ippool     edit "test"         set startip 14.14.14.100         set endip 14.14.14.100     next end Scenario: A new IP Pool 'test' was created on 'FortiGate', but it was not applied to any firewall policy. Client IP address is 14.14.14.100, and the gateway is 14.14.14.17. LAN interface of 'FortiGate' is 14.14.14.17. Client is not able to access the Internet nor PING to LAN 14.14.14.17. After removing the 'test' object from FortiGate, the Client can access the Internet again. Analysis: By default, arp-reply is enabled for the IP Pool object. From FortiOS v6.4.16, v7.0.13, v7.2.6, and v7.4.1 versions and onwards, IP pools and VIPs will be considered as local IP addresses.  After the IP Pool object has been set, 'FortiGate' will take all the IP addresses (from startip to endip) as its own IP address. When trying to ping from the Client to FortiGate LAN interface, FortiGate will accept the ICMP echo request from the Client but send the ICMP echo reply to the root interface. diagnose sniffer packet any 'icmp and host 14.14.14.100' 4 0 l interfaces=[any] filters=[icmp and host 14.14.14.100] 2025-11-19 14:39:58.714801 LAN in 14.14.14.100 -> 14.14.14.17: icmp: echo request 2025-11-19 14:39:58.714853 root out 14.14.14.17 -> 14.14.14.100: icmp: echo reply 2025-11-19 14:39:58.714861 root in 14.14.14.17 -> 14.14.14.100: icmp: echo reply To fix the issue, remove the unused IPPool object or disable the arp-reply of the IP Pool object. config firewall ippool     edit "test"         set startip 14.14.14.100         set endip 14.14.14.100         set arp-reply disable     next end