2
0
My setup is as follows:
- I have a dual boot computer.
- I have a network device (IP Address 192.168.1.251) directly connected to the PC.
- I can ping that device, when the PC is booted up with Windows 10.
- I cannot ping the device, when the PC is booted up with Debian 10.
$ ping 192.168.1.251 PING 192.168.1.251 (192.168.1.251) 56(84) bytes of data. From 192.168.1.22 icmp_seq=1 Destination Host Unreachable From 192.168.1.22 icmp_seq=2 Destination Host Unreachable From 192.168.1.22 icmp_seq=3 Destination Host Unreachable ^C --- 192.168.1.251 ping statistics --- 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 80ms pipe 4
Both under Windows 10 and Debian 10, are the interfaces configured in the same way, i.e. they both have the same static IP Address (192.168.1.22) and the same Subnet Mask (255.255.255.0).
ARP can see that the device ( with the IP Address 192.168.1.251) is there as well.
$ sudo arp-scan 192.168.1.251 Interface: enp0s25, datalink type: EN10MB (Ethernet) Starting arp-scan 1.9.5 with 1 hosts (https://github.com/royhills/arp-scan) 0 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.9.5: 1 hosts scanned in 2.538 seconds (0.39 hosts/sec). 0 responded
And if I connect and disconnect the cable, I can see that indeed on this interface on which I am trying to ping the device from, the "link connected" turns to "yes" and "no".
$ sudo ethtool enp0s25 Settings for enp0s25: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes
Question: So why could it be that I cannot ping the device from Debian 10, but from Windows 10 I can hassle free? I have been fighting with this for over 3~4 hours now testing all possible permutations and combinations that I could think of.
p.s. I can even ping the device successfully from a Linux VM running on the Windows 10 host (just saying, in case if that adds any info) but not from the Linux installed directly on the bare-metal.
UPDATE/EDIT:
As per the feedback from the comments, I did the following tests:
- First up, I ran traceroute from Debian 10, while connected ONLY to the target network device. (Both PC and device are totally isolated from any other network/PC.)
$ traceroute -UL 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
1 192.168.1.252 (192.168.1.252) 3070.385 ms !H 3070.330 ms !H 3070.314 ms !H
It succeeded ... ultimately. It took ~3 sec (meh! why?).
- Then I ran the route command from the Debian 10,
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s25
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s25
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
- Sorry for repeating myself, but upon pinging the device, it gave the same error:
$ ping -r 192.168.1.251
PING 192.168.1.251 (192.168.1.251) 56(84) bytes of data.
From 192.168.1.252 icmp_seq=1 Destination Host Unreachable
From 192.168.1.252 icmp_seq=2 Destination Host Unreachable
From 192.168.1.252 icmp_seq=3 Destination Host Unreachable
From 192.168.1.252 icmp_seq=4 Destination Host Unreachable
From 192.168.1.252 icmp_seq=5 Destination Host Unreachable
From 192.168.1.252 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.251 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 147ms
pipe 4
Then I proceeded to rebooting the laptop into Windows 10 and starting the Ubuntu 18.04 LTS Virtual Machine.
- First up, pinging the device worked straight away from Windows 10.
# ping 192.168.1.251
Pinging 192.168.1.251 with 32 bytes of data:
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Ping statistics for 192.168.1.251:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
- Next up pinging from the Ubuntu Virtual Machine running on the Windows 10 host:
$ ping 192.168.1.251
PING 192.168.1.251 (192.168.1.251) 56(84) bytes of data.
64 bytes from 192.168.1.251: icmp_seq=1 ttl=255 time=0.459 ms
64 bytes from 192.168.1.251: icmp_seq=2 ttl=255 time=0.561 ms
64 bytes from 192.168.1.251: icmp_seq=3 ttl=255 time=0.385 ms
64 bytes from 192.168.1.251: icmp_seq=4 ttl=255 time=0.428 ms
^C
--- 192.168.1.251 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3066ms
rtt min/avg/max/mdev = 0.385/0.458/0.561/0.066 ms
- Traceroute was also successful (and responded fast):
$ traceroute -UL 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
1 192.168.1.251 (192.168.1.251) 0.594 ms !P 0.527 ms !P 0.497 ms !P
- Finally the gateways (though I think it makes no difference here what gateway is set, as I am directly connected to the device with no other intermediaries).
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 virbr0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Last word: I have not setup any special firewalls or iptable rules on the Debian 10 installed on the laptop. This is a standard/default installation with of course other user packages installed as required (but no special network configuration done.)
EDIT 2: So, after the recent comments, I followed this and this to disable any "firewall" or iptable rules, that might be blocking the pings (Actually ping is just one of the symptoms. There is a server on the PC side which also cannot communicate with the network device, which was my original problem.)
Here is what I tried, and here is what are the results:
- Apparently
ufw
ornftables
orfirewalld
are not installed. Also I have nohost.deny
file.
$ sudo ufw status
sudo: ufw: command not found
$ sudo nftables
sudo: nftables: command not found
$ cat /etc/host.deny
cat: /etc/host.deny: No such file or directory
$ sudo systemctl disable firewalld
Failed to disable unit: Unit file firewalld.service does not exist.
$ sudo firewall-cmd --state
sudo: firewall-cmd: command not found
- So far so good. Then onto
iptables
we look. Interesting to find all these entries for iptable:
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:67
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
Chain DOCKER (1 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
We see some rules, some for Docker and some in general. I have no idea what those rules and settings are doing, but let's just nuke them away and disable all controls (just for test purposes - to see if something works). In order to achieve that, I took the following steps (literally copied from one of the links mentioned above):
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
This resulted in some nice looking iptable
configuration as shown below.
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
- Unfortunately, the rabbit hole goes deeper. Even though all rules are gone. And I have no other rules/firewalls, etc configured (at least none that I know of), unfortunately, nothing changed.
ping
still fails andtraceroute
still takes ~3000+ milliseconds.
I am starting to suspect the network-manager
service on debian 10 is somehow responsible as that is the only thing different between the bare-metal installation of the debian 10 on the laptop and the ubuntu 18.04 virtual machine running on windows 10 from which I had no problem pinging the device.)
Bonus info: I have another Virtual Machine with Debian 6 running on top of Windows 10 and even that can ping the network device.
Debian firewall blocking ping? – DavidPostill – 2020-01-23T15:02:32.880
Ok. I didn't think of that. I can test pinging on a different interface on Debian. Only thing is, to do so I have to physically go to a different computer (different to the one from which I am writing now - I might then wait for all suggestions to pop up before heading back to the den to try again). :) – Duck Dodgers – 2020-01-23T15:07:40.677
I agree, it's likely the Linux firewall. Try this: from the Linux machine: traceroute -UL 192.168.1.25. Assuming you have traceroute installed. The -UL will send both ICMP and UDP. – user10216038 – 2020-01-23T17:11:45.857
Also try ping -r 192.168.1.25 to ignore the routing table and ping to a directly connected device. – user10216038 – 2020-01-23T17:22:02.920
Run a route command on the Linux box (VM too) to see how your Gateways are defined. – user10216038 – 2020-01-23T17:27:56.983
@user10216038, I will try your suggestions tomorrow morning when I am in front of the machine. Thank your for your suggestions. :) – Duck Dodgers – 2020-01-23T22:20:07.590
I updated the question with the new test results. – Duck Dodgers – 2020-01-24T09:16:09.697
Everything is consistent with the Linux firewall blocking ICMP pings. Google Debian disable firewall. – user10216038 – 2020-01-24T23:25:24.010
Ok. Thank you for the hint. I will check on Monday, how far I can go and get back here with the updates. – Duck Dodgers – 2020-01-26T08:45:40.170