Jtdylktuy

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.

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.

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.