Description |
This article describes a scenario where a user wants to test internet connectivity from the configured VLAN on FortiGate by pinging 8.8.8.8 and does not have access to any machine on VLAN so it is sourcing the ping from the VLAN interface IP address.
FG101F-1 # execute ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=121 time=6.0 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=5.8 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=121 time=6.8 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=121 time=5.8 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=121 time=5.8 ms |
Scope | FortiGate. |
Solution |
This is the expected behavior, the ping is sourced from the internal IP (10.10.1.1). In this example, it will go directly via the wan1 interface without natting as this self-generated traffic is not passing through any IPv4 policy:
469750 wan1 out 10.10.1.1 -> 8.8.8.8: icmp: echo request 489739 wan1 out 10.10.1.1 -> 8.8.8.8: icmp: echo request
This article also has similar behavior if the source IP address is an Internal Physical Interface of the FortiGate: Technical Tip: Unable to ping public servers (for testing) using ping-option source interface
However, in the case of pinging without specifying the source, IP traffic is using the WAN1 interface public IP (10.9.0.141). In this example, ping is successful.
676116 wan1 in 8.8.8.8 -> 10.9.0.141: icmp: echo reply 689739 wan1 out 10.9.0.141 -> 8.8.8.8: icmp: echo request 695574 wan1 in 8.8.8.8 -> 10.9.0.141: icmp: echo reply In this case, to confirm internet connectivity from the internal network, it is necessary to initiate ping traffic from a machine behind the FortiGate on the same network. |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.