Directly-connected network device can be pinged from Windows 10 but not from Debian 10

My setup is as follows:

1. I have a dual boot computer.
2. I have a network device (IP Address 192.168.1.251) directly connected to the PC.
3. I can ping that device, when the PC is booted up with Windows 10.
4. 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:

1. 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?).

2. 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

3. 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.

1. 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

2. 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

3. 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

4. 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:

1. Apparently ufw or nftables or firewalld are not installed. Also I have no host.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

2. 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 and traceroute 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.

Edit 3:

nmap can find the host.

nmap -Pns 192.168.1.200/32
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-21 14:42 CET
Nmap scan report for 192.168.1.200
Host is up (0.062s latency).
All 1000 scanned ports on 192.168.1.200 are filtered

Nmap done: 1 IP address (1 host up) scanned in 5.90 seconds

So after almost a year of not following up on this, I ended up trying a dozen different things today, and scouring the different linux distro forums, I finally struck gold here.

After doing the following, I could successfully ping (keeping my fingers crossed that it stays that way, but for the moment things look good).

From here, I tried this.

sudo lshw -C network

Which showed me what hardware I have for that ethernet port.

*-network                 
       description: Ethernet interface
       product: Ethernet Connection I217-LM
       vendor: Intel Corporation
       physical id: 19
       bus info: pci@0000:00:19.0
       logical name: enp0s25
       version: 04
       serial: 70:5a:df:b9:a7:47
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.13-4 ip=192.168.1.34 latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
       resources: irq:31 memory:d2100000-d211ffff memory:d213a000-d213afff ioport:6040(size=32)

I downloaded the latest driver from intel.

cp e1000e-3.0.4.tar.gz /usr/local/src/
cd /usr/local/src/
tar xzvf e1000e-3.0.4.tar.gz
rmmod e1000e
apt-get install linux-headers-amd64
cd e1000e-3.0.4/src/
make install

Rebooted and bam! pings and all work! Sometimes to get things to work, you just have to do them yourself.

The idea that put me on this track is that, I could ping and do nearly everything over the other ethernet port (which is not a real ethernet port really. It's a USB Dongle, but that's besides the point.) but on the ethernet port itself, nothing worked (except somehow the traceroute and nmap got through I don't know how).

It may have been that 3~4 years ago when I installed debian on this laptop (next to Windows 10), "Fast Boot" was maybe active in BIOS and maybe the ethernet drivers did not get installed or something. Maybe!

FEEDBACK/UPDATE AFTER A COUPLE OF WEEKS:

After observing this for a couple of weeks now, this works only intermittently for some reason. It worked but then it stopped working. And then today it has started working again. It could be that the real problem lies somewhere else. One thing I did do today differently was I turned of "Automatically Connect" from the Network Manager. Maybe that makes a difference?