Hello All,
while pinging 8.8.8.8 from lan source in sdwan its not pinging, but no issue in traffic of internet and intranet
what could be the reason
logs
from Lan source its not pinging
execute ping-options source 110.18.8.254
# execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
without souce its pinginging
execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=26.5 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=27.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=26.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=29.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=38.9 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 26.2/29.5/38.9 ms
It's expected.
Ping-option/source IP just changes the source IP area of ICMP/ping packets before going out of the outgoing interface. It doesn't cause those packets to go through any policies, where regularly NAT(SNAT) is configured. As the result, the internet routers(ISPs and Google DNS) doesn't know where to return the ICMP reply packets if the source IP is a private IP like 10.48.18.254.
Toshi
hello can you share one example for it.
Thanks
Created on 03-13-2025 12:11 AM Edited on 03-13-2025 12:12 AM
What do you mean by example? Your case is an example. You can pick any other source IP, which is a private IP. Then the ping to the internet would fail.
But the easiest way to "see" it yourself is opeinging two CLI sessions. At one of them, run a sniffing with "any" interface like
diag sniffer packet any 'icmp and host 1.1.1.1' 4 0
And, execute ping to like 1.1.1.1 after specifying the source from the other CLI session.
Then you would see like below:
fg40f-utm (root) # diag sniffer packet any 'icmp and host 1.1.1.1' 4 0
interfaces=[any]
filters=[icmp and host 1.1.1.1]
7.572060 ppp3 out 172.16.2.1 -> 1.1.1.1: icmp: echo request
8.587080 ppp3 out 172.16.2.1 -> 1.1.1.1: icmp: echo request
9.597071 ppp3 out 172.16.2.1 -> 1.1.1.1: icmp: echo request
10.607074 ppp3 out 172.16.2.1 -> 1.1.1.1: icmp: echo request
11.617071 ppp3 out 172.16.2.1 -> 1.1.1.1: icmp: echo request
I specified my LAN interface IP as the source option. Those are never NATed. One of SD-WAN interfaces I have is PPPoE. That's why it's showing ppp3 as its interface name.
Toshi
And if you don't specify the source option, the ping packet has the outgoing interface IP, which is generally a public IP. That's why it works without NAT.
User | Count |
---|---|
2087 | |
1181 | |
770 | |
451 | |
344 |
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.