6

Let's say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.

When I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:

# ping server1.mydomain.com
PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms

But with tcpdump, I can see no ICMP traffic on eth0 and instead see the pings coming through lo:

# tcpdump -i lo
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64
08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64
08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64
08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64
08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64
08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64

This behaviour is not limited to ping. I get the same with wget.

Why is this happening? Is this something caused by the configuration on my server?

I am using Debian 9 (Stretch).

EDIT: to clarify some disagreements that arose in the comments:

I would not mind so much if, when pinging my own public IP address, the traffic actually went to 127.0.0.1. But then, ping should be honest and actually show it is pinging localhost. What I find treacherous, is that I am pinging 11.22.33.44, which according to ifconfig is associated with eth0, and ping pretends it sends traffic to eth0, but actually sends to lo.

  • 1
    This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't. – roaima Jan 1 at 10:03
  • 4
    You wanted to ping the machine at 11.22.33.44 (or server1.mydomain.com) and you did... The interface is irrelevant in your case because your packet does not need to be routed. – std_unordered_map Jan 1 at 11:33
  • 1
    @std_unordered_map - it is not irrelevant !!! it is being blocked by my current firewall rules – Martin Vegter Jan 1 at 12:14
  • 2
    You may block all the exits in or out of your "room", but it won't stop you from reaching your "room" if you are already there... – std_unordered_map Jan 1 at 12:28
  • 10
    Physically, if it actually went out on eth0 it wouldn't be received, an Ethernet interface doesn't "hear" what it's sending. So in any case, there needs to be a shortcut somewhere that says "oh this is a local packet, it must be handled locally". Probably easier to redirect the packet to lo0 than adding a "handle outbound traffic as inbound path", though one would have to check the relevant RFCs for correctness. – jcaron Jan 1 at 13:20
9

The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.

Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.

  • actually that new network namespace does have (only) a loopback interface, but it's down by default – A.B Jan 1 at 16:47
2

This has to do with how network routing happens on linux. You can look at your routing table, for example, and it will most likely say that any traffic that falls under the 11.22.33.0/24 subnet is going to be routed "locally". This means it will just go straight to loopback.

[jar@coffee ~]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.107.136.1    0.0.0.0         UG    100    0        0 eth0
10.107.136.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0

Having 10.107.136.0 in the Destination column means any traffic on the local subnet should be sent to the listed Gateway, which is 0.0.0.0 -- which in this case means route locally.

Having 0.0.0.0 in Destination means traffic going anywhere outside this subnet. The default gateway is then listed in Gateway

You'll also notice if you run tcpdump with the -n switch, that the IP address is not 127.0.0.1, it just happens to be showing up on the loopback interface because it is local traffic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.