nmap missing pingable, arpingable LAN host unless UFW has been disabled on the remote host

[erjoalgo]

Describe the bug
nmap fails to discover a LAN host that is both pingable and apingable. But Disabling UFW on the LAN host makes it discoverable by nmap.

To Reproduce
sudo nmap 192.168.0.0/24

Expected behavior
Host 192.168.0.106 should show as UP

Version info (please complete the following information):

• OS: [e.g. Linux 4.15, Windows 10 1909]
• Output of nmap --version:

Nmap version 7.93 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.6 openssl-3.0.11 libssh2-1.10.0 libz-1.2.13 libpcre-8.39 libpcap-1.10.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

• Output of nmap --iflist

Starting Nmap 7.93 ( https://nmap.org ) at 2024-05-03 18:50 EDT
************************INTERFACES************************
DEV             (SHORT)           IP/MASK                      TYPE        UP MTU   MAC
lo              (lo)              127.0.0.1/8                  loopback    up 65536
lo              (lo)              ::1/128                      loopback    up 65536
eno1            (eno1)            192.168.1.111/24             ethernet    up 1500  A4:BA:DB:15:13:EA
eno3            (eno3)            192.168.0.102/24             ethernet    up 1500  AA:BB:CC:DD:EE
eno3            (eno3)            fe80::a6ba:dbff:fe15:13ee/64 ethernet    up 1500 AA:BB:CC:DD:EE


**************************ROUTES**************************
DST/MASK                      DEV             METRIC GATEWAY
192.168.0.0/24                brkvm           0
192.168.0.0/24                eno3            0
0.0.0.0/0                     eno1            0      192.168.1.254
::1/128                       lo              0

ff00::/8                      eno3            256
ff00::/8                      brkvm           256

Here's a verbose log after attempting to scan only the given host:

█$ nmap 192.168.0.106 -vvvv  -dddddddd
Starting Nmap 7.93 ( https://nmap.org ) at 2024-05-03 18:40 EDT
Fetchfile found /usr/bin/../share/nmap/nmap-services
PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
Fetchfile found /usr/bin/../share/nmap/nmap.xsl
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Initiating Ping Scan at 18:40
Scanning 192.168.0.106 [2 ports]
CONN (0.0652s) TCP localhost > 192.168.0.106:80 => Operation now in progress
CONN (0.0652s) TCP localhost > 192.168.0.106:443 => Operation now in progress
**TIMING STATS** (0.0652s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 2/*/*/*/*/* 10.00/75/* 1000000/-1/-1
   192.168.0.106: 2/0/0/2/0/0 10.00/75/0 1000000/-1/-1
Current sending rates: 8130.08 packets / s.
Overall sending rates: 8130.08 packets / s.
**TIMING STATS** (1.0664s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 0/*/*/*/*/* 10.00/75/* 1000000/-1/-1
   192.168.0.106: 0/0/0/2/2/0 10.00/75/0 1000000/-1/-1
Current sending rates: 2.00 packets / s.
Overall sending rates: 2.00 packets / s.
CONN (2.0667s) TCP localhost > 192.168.0.106:443 => Operation now in progress
CONN (2.0668s) TCP localhost > 192.168.0.106:80 => Operation now in progress
**TIMING STATS** (2.0668s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 2/*/*/*/*/* 10.00/75/* 1000000/-1/-1
   192.168.0.106: 2/0/0/4/0/0 10.00/75/0 1000000/-1/-1
Current sending rates: 2.00 packets / s.
Overall sending rates: 2.00 packets / s.
**TIMING STATS** (3.0676s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 0/*/*/*/*/* 10.00/75/* 1000000/-1/-1
   192.168.0.106: 0/0/0/2/2/0 10.00/75/0 1000000/-1/-1
Current sending rates: 1.33 packets / s.
Overall sending rates: 1.33 packets / s.
ultrascan_host_probe_update called for machine 192.168.0.106 state UNKNOWN -> HOST_DOWN (trynum 1 time: 1001127)
ultrascan_host_probe_update called for machine 192.168.0.106 state HOST_DOWN -> HOST_DOWN (trynum 1 time: 1001001)
Moving 192.168.0.106 to completed hosts list with 0 outstanding probes.
Completed Ping Scan at 18:40, 3.00s elapsed (1 total hosts)
Overall sending rates: 1.33 packets / s.
mass_rdns: Using DNS server 192.168.1.1
mass_rdns: Using DNS server 192.168.2.1
mass_rdns: Using DNS server 77.88.8.8
mass_rdns: Using DNS server 77.88.8.1
mass_rdns: Using DNS server 192.168.0.1
Nmap scan report for 192.168.0.106 [host down, received no-response]
Read from /usr/bin/../share/nmap: nmap-services.
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.07 seconds
█$ 

Additional context

This behavior is flaky and sometimes nmap does discover the host.

As mentioned earlier, completely disabling ufw on the host 192.168.0.106 changes the result and makes the host consistently discoverable by nmap.

I'm not very familiar with the details but my understanding is that running as root allows nmap to send arpings which cannot be blocked by firewalls like ufw according to some sources.

[erjoalgo]

Looking at the logs on the host eluding discovery (192.168.0.106), I see some of the following UFW block logs:

2024-05-03T18:39:11.740403-04:00 bee kernel: [2070015.956759] [UFW BLOCK] IN=wlo1 OUT= MAC=01:00:5e:00:00:01:e4:fa:c4:e6:9a:3d:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 
2024-05-03T18:41:16.764399-04:00 bee kernel: [2070140.968665] [UFW BLOCK] IN=wlo1 OUT= MAC=01:00:5e:00:00:01:e4:fa:c4:e6:9a:3d:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 

After reading https://superuser.com/questions/739481/what-might-these-connection-attemps-mean, my guess would be that these PROTO=2 packets being blocked are related to nmap's attempts to discover the host.

Is there anything I can do from the nmap side to ensure discovering hosts like these?

Again, I can consistently arping and ping the host but somehow nmap fails to find it.