Technical Tip: PING Behavior when source IP is a Loopback and destination is Public IP

[rbernal]

Description	This article describes the behavior of traffic(PING) when the source of the traffic is a Loopback IP and the destination is a Public IP.
Scope	FortiGate.
Solution	Setup:    For testing purposes, assume that the FortiGate's port1 IP address 10.47.1.175/20 is a Public IP address. Interface Setting: Firewall Policy:   Initiating PING traffic from FortiGate using the Loopback IP 192.168.10.100 (Private IP) as the source IP and Public IP 1.1.1.1 as the destination IP. It will show that the PING will fail. FortiGate-2 # execute ping-options source 192.168.10.100 FortiGate-2 # execute ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes --- 1.1.1.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss Using the 'diagnose sniffer packet' (packet capture), it will show that the Loopback IP was not Source NAT to 10.47.1.175, even on the Firewall Policy ID 1, the NAT is enabled. Source IP remains as 192.168.10.100 as it leaves the FortiGate port1 going to Public IP 1.1.1.1 (Internet), which causes the PING failure: FortiGate-2 # diagnose sniff packet any "host 1.1.1.1 and icmp" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[host 1.1.1.1 and icmp] 2025-03-03 16:16:45.691145 port1 out 192.168.10.100 -> 1.1.1.1: icmp: echo request 2025-03-03 16:16:46.691255 port1 out 192.168.10.100 -> 1.1.1.1: icmp: echo request 2025-03-03 16:16:47.691440 port1 out 192.168.10.100 -> 1.1.1.1: icmp: echo request 2025-03-03 16:16:48.691582 port1 out 192.168.10.100 -> 1.1.1.1: icmp: echo request 2025-03-03 16:16:49.691860 port1 out 192.168.10.100 -> 1.1.1.1: icmp: echo request This is an expected behavior since the traffic generated from the source Loopback IP is considered as Local-Out traffic or Self-Generated traffic. This kind of traffic does not hit any Firewall Policy, which is why the Source NAT for this traffic will not be applied, and the source IP will remain as it is, which in this scenario is 192.168.10.100.  This is the same behavior when the PING source was a Physical Interface of the FortiGate, like on this link: Technical Tip: Unable to ping public servers (for testing) using ping-option source interface The same behavior also occurs when a VLAN Interface IP was used as the source: Technical Tip: Testing Internet Connectivity from FortiGate VLAN Interface The PING will become successful if the Loopback IP that will be used is a Public IP address, and if the traffic is still sourced from the FortiGate Note: The scenarios above are only when the traffic was sourced from the FortiGate Loopback IP. If the scenario is the other way around, wherein the source of the PING is from a Public IP address and the destination is the FortiGate's Loopback interface Public IP, the PING will fail since the source of the PING traffic did not come from the FortiGate. This scenario will need a Firewall Policy to allow the traffic, as explained on this link:  Technical Tip: Best practice when IPSec VPN is bound to loopback interface Related article: Technical Tip : Configuring and using a loopback interface on a FortiGate