Skip to main content
bnrumesh
bnrumesh
Explorer
March 13, 2025
Question

while pinging 8.8.8.8 from lan source in sdwan its not pinging, but no issue in traffic of internet

  • March 13, 2025
  • 3 replies
  • 1307 views

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

3 replies

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
March 13, 2025

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

    bnrumesh
    bnrumeshAuthor
    Explorer
    March 13, 2025

    hello can you share one example for it.

     

    Thanks 

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    March 13, 2025

    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

      Toshi_Esumi
      SuperUser
      Toshi_Esumi
      SuperUser
      March 13, 2025

      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.

      Terms & ConditionsAccessibility statement