Ping is not working for internal interfaces

Question

I am having a Gateway CentOS 7 which gets no reply for pings on its internal interface when the interface is specified making me think there is the problem, but also not able to ping ANYTHING on the internal network while pings to it work.

ping 10.20.1.7 -I enp0s25
PING 10.20.1.7 (10.20.1.7) from 10.20.1.7 enp0s25: 56(84) bytes of data.
^C
--- 10.20.1.7 ping statistics ---
52 packets transmitted, 0 received, 100% packet loss, time 50999ms

it works without specifying the interface

ping 10.20.1.7
PING 10.20.1.7 (10.20.1.7) 56(84) bytes of data.
64 bytes from 10.20.1.7: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from 10.20.1.7: icmp_seq=2 ttl=64 time=0.029 ms
^C
--- 10.20.1.7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.029/0.040/0.052/0.013 ms

or the interface by ip (thanks to @Gerard H. Pille )

ping 10.20.1.7 -I 10.20.1.7
PING 10.20.1.7 (10.20.1.7) from 10.20.1.7 : 56(84) bytes of data.
64 bytes from 10.20.1.7: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 10.20.1.7: icmp_seq=2 ttl=64 time=0.028 ms
64 bytes from 10.20.1.7: icmp_seq=3 ttl=64 time=0.040 ms
^C
--- 10.20.1.7 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.028/0.039/0.050/0.010 ms

pinging the external interface is also working

ping 192.168.111.247
PING 192.168.111.247 (192.168.111.247) 56(84) bytes of data.
64 bytes from 192.168.111.247: icmp_seq=1 ttl=64 time=5.13 ms
64 bytes from 192.168.111.247: icmp_seq=2 ttl=64 time=0.642 ms
64 bytes from 192.168.111.247: icmp_seq=3 ttl=64 time=0.395 ms
^C
--- 192.168.111.247 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.395/2.057/5.136/2.179 ms

I also verified I can ping the internal and the external IP of the gateway from a maschine inside the internal network

with

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever
2: enp3s11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:02:2a:df:3a:79 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.247/24 brd 192.168.111.255 scope global dynamic enp3s11
    valid_lft 41978sec preferred_lft 41978sec
    inet6 fe80::af94:9dd0:f4a9:8dcb/64 scope link
    valid_lft forever preferred_lft forever
3: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:19:99:5d:91:46 brd ff:ff:ff:ff:ff:ff
    inet 10.20.1.7/16 brd 10.20.255.255 scope global enp0s25
    valid_lft forever preferred_lft forever
    inet6 fe80::219:99ff:fe5d:9146/64 scope link
    valid_lft forever preferred_lft forever

enp0s25 beeing the internal network and enp3s11 beeing the external interface

arp lists the devices in the expected devices

arp
    Address                  HWtype  HWaddress           Flags Mask                                             Iface
    192.168.111.160          ether   00:15:5d:0a:0b:25   C                     enp3s11
    10.20.100.2              ether   2c:d4:44:a2:5a:4c   C                     enp0s25
    192.168.111.155          ether   90:1b:0e:6e:d1:3f   C                     enp3s11
    gateway                  ether   00:19:99:c5:f0:ad   C                     enp3s11
    10.20.1.102                      (unvollständig)                          enp0s25
    192.168.111.245          ether   00:19:99:7e:5d:81   C                     enp3s11
    192.168.111.212          ether   52:54:00:d5:d3:6d   C                     enp3s11

Firewall seems to be correctly configured to not block ICMP

firewall-cmd --list-all --zone=external
external (active)
target: default
icmp-block-inversion: no
interfaces: enp3s11
sources:
services: ssh
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:

sudo firewall-cmd --list-all --zone=internal
internal (active)
target: default
icmp-block-inversion: no
interfaces: enp0s25
sources:
services: ssh mdns samba-client dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

as to get a more complete view netstat -rn output

netstat -rn
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         192.168.111.14  0.0.0.0         UG        0 0          0 enp3s11
10.20.0.0       0.0.0.0         255.255.0.0     U         0 0          0 enp0s25
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s25
192.168.111.0   0.0.0.0         255.255.255.0   U         0 0          0 enp3s11

EDIT:

**this was a wild goose chase because of a recurring transcription error of the IPs in the internal network (real: 10.20.100.x typed 10.20..104) ... **

feeling rather dumb now

this should be closed?

I don't know what's wrong with it, but I couldn't get it working either. So, what interface would ping be using when you specify its IP ??? — Gerard H. Pille, May 11 '18 at 12:26
I would expect the one associated with it but I will try a random out of scope one now — 927589452, May 11 '18 at 12:31
What do you get from "netstat -rn"? (add the result to your question). — Gerard H. Pille, May 11 '18 at 12:38
If you are connected to your gateway and this machine has a internal interface called 10.20.0.1(example) and you cannot ping 10.20.0.1, than check if your machine even allow ping, since this can be deactivated. I for example dont allow ping in my entire local network and if this fails the FW will drop any ping package that it receives. Check for example here https://www.tecmint.com/block-ping-icmp-requests-to-linux/ — Cristian Matthias Ambæk, May 11 '18 at 13:14

score 0 · Accepted Answer · answered May 11 '18 at 11:46

If a machine can ping the gateway and get a response, I'd say the network isnt entirely broken. I'd consider stopping the firewall to see if it's related.

If you get a reply back, which I imply from 'while pings to it work.' then it doesn't appear to be a routing related issue.

My suggestion is to troubleshoot the firewall, by disabling it entirely, first. Consider disconnecting the external interface if disabling firewall poses a policy/security problem.

Br, Martin

Tried that, but still no replies – 927589452 May 11 '18 at 12:12 — 927589452, May 11 '18 at 12:12

Ping is not working for internal interfaces

1 Answers1