FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Article Id 217761
Description This article describes about the issue where users are unable to ping public servers (for testing) using ping-option source from LAN interface.
Scope FortiGate, all Firmware.

Consider the following network, where the LAN facing interface with IP address is trying to reach public servers.


LAN<-->( FGT (<-->WAN ---> (


# execute ping-options source

# execute ping


PING ( 56 data bytes


--- ping statistics ---

5 packets transmitted, 0 packets received, 100% packet loss


# Timeout

Connection lost.


- This is an expected behavior as the ping's that are local traffic generated from FortiGate and are also from a private IP


- To confirm if a hosts in the LAN network is able to reach the public servers (reach internet), it is recommended to test it from one of the host itself and not from the firewall.


- For the traffic going through the firewall it will hit the firewall policy and get NATed but not for the local traffic generated from the FortiGate.


- Local traffic does not match a IPv4 firewall policy.


- Here basically its being told to firewall to generate a ping with a private IP as source out through a wan port hence it'll be dropped as no private IP address will be routed.


- Testing from the firewall itself is not ideal, at least not from a private IP as source.


- Generating traffic form a host should work and the packets can be traced to see the route.


- When tested from public IP, that is sourcing the WAN IP and pinging a public IP should work.



If one wonders, why it works when source option is not chosen?


That is because when one pings, automatically public WAN IP is used as source and hence the pings will be successful.

So this is an expected behavior and not an issue with the FortiGate.