FortiGate IP Pool ARP Reply: The Hidden Mechanism Behind NAT Reliability

January 26, 2026.

Investigating FortiGate IP pool ARP reply behavior, version-specific changes in FortiOS, and critical configuration practices for network stability.

The Silent Protocol Governing Address Resolution

Beneath the surface of FortiGate's Network Address Translation lies a mechanism that determines whether traffic flows or falters: the ARP reply setting for IP pools. When administrators configure source NAT using dynamic address pools, a single toggle—arp-reply—dictates whether the firewall acknowledges incoming Address Resolution Protocol queries for those external addresses. This seemingly minor parameter carries disproportionate weight in production environments, where its misconfiguration can silently blackhole legitimate traffic without generating diagnostic logs.

Understanding the ARP Reply Mechanism

The ARP reply function, when enabled on an IP pool object, instructs the FortiGate to respond to ARP requests for any address within the pool's defined range. This behavior ensures that upstream routers and switches can resolve the MAC address associated with pool addresses, enabling proper Layer 2 delivery of return traffic. Without this response, packets destined for translated addresses may never reach the firewall, manifesting as unexplained connection timeouts rather than explicit denial events.

When interface IP subnets overlap with IP pool ranges, the FortiGate automatically answers ARP requests for the intersecting addresses. For example, if port1 holds 192.0.2.1/24 and an IP pool spans 192.0.2.100-192.0.2.110, the interface will respond to ARP queries for that ten-address subset. This automatic behavior simplifies deployment but introduces complexity when pools span multiple subnets or when unused pool objects remain in configuration.

Version-Specific Behavior Shifts in FortiOS

The Local Address Classification Change

A significant architectural shift occurred across FortiOS versions 6.4.9 through 7.4.0, where IP pools and Virtual IPs ceased being treated as local addresses even when arp-reply remained enabled. During this interim period, the FortiGate would answer ARP requests for pool addresses but would not accept application-layer traffic destined for those addresses unless specific workarounds were implemented. This divergence between Layer 2 responsiveness and Layer 3 acceptance created subtle failure modes that proved difficult to diagnose.

The classification was restored in FortiOS 7.4.1 and later releases, where IP pools and VIPs with arp-reply enable are again considered local addresses. This restoration means the firewall both answers ARP queries and accepts traffic for those addresses, aligning Layer 2 and Layer 3 behavior. Administrators upgrading from affected intermediate versions must audit configurations for unused pool objects, as these now function as legitimate local endpoints that can intercept traffic intended for other destinations.

Features Impacted by ARP Classification

The local address determination affects several FortiOS features operating at the application layer. SSL VPN web mode sessions, explicit web proxy transactions, and interface-mode IPsec VPN tunnels using IP pools as local gateways all depend on the FortiGate accepting reply traffic for pool addresses. When pool addresses are not classified as local, these features fail to establish sessions despite successful ARP resolution, creating a disconnect between network-layer connectivity and application-layer functionality.

Configuration Practices and Troubleshooting Strategies

Preventing Unintended Traffic Interception

Unused IP pool or VIP objects with arp-reply enable can inadvertently capture traffic destined for addresses that happen to fall within their ranges. The FortiGate, treating these addresses as local, will not forward matching packets according to the routing table. Instead, it attempts local delivery, which fails when no corresponding service listens on the expected port. This behavior manifests as silent packet drops rather than explicit rejections, complicating root cause analysis.

Administrators should implement a systematic review process before firmware upgrades: identify all IP pool and VIP objects, verify their usage in active firewall policies, and remove or disable arp-reply on unused entries. The CLI command diagnose firewall ippool list provides visibility into configured pools, while policy references can be audited through configuration exports or the GUI policy matrix.

Workarounds for Intermediate FortiOS Versions

For deployments constrained to FortiOS versions where pool addresses are not considered local, several mitigation strategies restore functionality. Configuring the pool address as a secondary IP on the egress interface forces local classification for that specific address. For SSL VPN web mode, enabling web-mode-snat (available in select intermediate versions) combined with secondary interface addressing allows reply traffic to reach the SSL portal.

Routing adjustments offer an alternative approach: removing blackhole routes that match pool address ranges and ensuring standard routes direct reply traffic to the appropriate interface. This method requires careful planning to avoid creating routing loops or exposing internal addressing schemes to external networks.

Diagnostic Approaches for ARP-Related Failures

Interpreting Debug Flow Output

When investigating suspected ARP reply issues, the diagnose debug flow command reveals how the FortiGate processes packets destined for pool addresses. A route lookup displaying flag=80000000 indicates the destination is treated as a local address, triggering local delivery logic rather than forwarding. Absence of this flag on affected FortiOS versions signals the classification change that underlies many intermittent connectivity reports.

ARP table inspection via get system arp confirms whether the FortiGate is responding to queries for pool addresses. Entries showing the firewall's MAC address associated with pool IPs verify that arp-reply is functioning. Missing entries suggest either the setting is disabled or upstream devices are not broadcasting ARP requests for those addresses.

Log Analysis Limitations

A notable challenge in troubleshooting ARP-related failures involves log visibility. When traffic fails due to local address misclassification, the FortiGate may not generate policy denial logs because packets never reach the policy evaluation stage. Instead, sessions time out at the TCP layer or fail during handshake initialization. Administrators must correlate connection failures with configuration changes, firmware upgrades, or network topology modifications to identify ARP reply as the probable cause.

Frequently Asked Questions

What happens if I disable arp-reply on an active IP pool?
Disabling arp-reply prevents the FortiGate from responding to ARP queries for pool addresses. Upstream devices will be unable to resolve the MAC address for those IPs, causing return traffic to fail at Layer 2. This setting should only be disabled for pool addresses that are routed to the FortiGate via explicit static routes rather than relying on ARP resolution.

Why do unused IP pools cause traffic disruptions?
Unused IP pool objects with arp-reply enable are still treated as local addresses on affected FortiOS versions. Traffic destined for addresses within the pool range gets intercepted by the FortiGate, which attempts local delivery. When no service listens on the expected port, packets are silently dropped, creating blackhole conditions for legitimate traffic targeting those addresses.

How do I verify whether an IP pool is actively used in policies?
Review firewall policy configurations through the CLI command show firewall policy | grep poolname or examine the NAT section of each policy in the GUI. Pool objects referenced in active policies with set ippool enable are in use; those absent from policy configurations may be candidates for removal or arp-reply disablement.

Can VIP and IP pool ARP behavior be managed independently?
Yes. Virtual IP objects and IP pool objects maintain separate arp-reply settings. Administrators can enable ARP responses for VIPs used in destination NAT while disabling them for source NAT pools, provided routing infrastructure supports the resulting address resolution requirements.

What is the recommended approach before upgrading FortiOS firmware?
Audit all IP pool and VIP objects, document their policy references, and test upgrades in a non-production environment. For versions transitioning between local address classification behaviors, prepare rollback procedures and schedule maintenance windows to implement configuration adjustments if connectivity issues emerge post-upgrade.