Troubleshooting Tip: Ping fails to the WAN IP of FortiGate

[SassiVeeran]

Description	This article describes how to ensure ping is reachable to a FortiGate WAN IP in the Dashboard with VIP configured.
Scope	FortiGate 6.4.8 and below.
Solution	A test ping failure to the FortiGate WAN IP shows in the dashboard from the internal network. A sniffer packet shows the packet enters FortiGate but no ping reply is received from the WAN IP. Debugging shows the packet was dropped with the error 'iprope_in_check() check failed on policy 0, drop'. In this example, the WAN IP is 161.142.148.52. Sniffer: Debug: No IP pool is configured. It was discovered that FortiGate has a VIP configured mapping the WAN IP to an internal IP address. However, it was not used in any firewall policy. This is due to how VIPs are considered local IP addresses if responding to ARP requests on these external IP addresses is enabled. The solution is to disable ARP replies in the VIP. config firewall vip     edit <name>         set arp-reply disable (default: enable)     next end In addition to the previously mentioned factors, the way a Virtual IP (VIP) is configured on a FortiGate device can directly affect whether ping (ICMP) requests to the FortiGate's WAN IP receive a reply. Understanding the Behavior: When a VIP is configured to map the FortiGate’s WAN IP to an internal IP address without specifying a particular port, all inbound traffic, including ICMP, is forwarded to the internal IP. This causes FortiGate to act as a forwarder rather than a responder, meaning: FortiGate receives the ping packet destined to its WAN IP. The VIP configuration causes it to forward the ping to the internal IP specified in the VIP. The internal device is then responsible for replying to the ping. If no firewall policy explicitly permits ICMP traffic from the WAN interface to the internal IP address defined in a Virtual IP (VIP), FortiGate will drop the traffic.  This behavior is confirmed in the debug flow output, where the following line is observed: id=65308 trace_id=100 func=fw_forward_handler line=849 msg="Denied by forward policy check (policy 0)" In this instance, a VIP is configured to perform DNAT from FortiGate's WAN IP to 10.11.10.10:60418, as shown in: id=65308 trace_id=100 func=__ip_session_run_tuple line=3593 msg="DNAT <x.x.x.x>:8 > 10.11.10.10:60418" However, because no matching firewall policy allows this ICMP traffic, FortiGate does not forward it, and the session is denied. Recommended Configuration Practices for Ping Handling: When the objective is for FortiGate itself to respond to ICMP echo requests sent to the WAN IP, the VIP configuration should not forward all protocols, particularly ICMP. Instead, the VIP should be limited to specific service ports (e.g., TCP/80 or TCP/443) to ensure ICMP is not unintentionally redirected to an internal system. This approach maintains FortiGate's ownership of ICMP traffic while allowing only intended services to be forwarded internally. Related document: Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4