When working with network reconnaissance, I recently encountered a puzzling scenario where Nmap's ping scan (-sn) failed to detect clearly responsive hosts. Here's what I observed:

$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes 
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=1.585 ms

Yet Nmap reported:

$ nmap -sn 192.168.0.2
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn

Examining the traffic with tcpdump revealed something interesting:

12:45:30.742933 IP 192.168.0.222 > 192.168.0.2: ICMP echo request, id 2715, seq 0, length 8
12:45:30.743061 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply, id 2715, seq 0, length 8

The host was clearly responding to ICMP requests, yet Nmap wasn't recognizing it as alive.

Nmap's -sn (ping scan) isn't just a simple ICMP echo request. By default, it actually performs multiple checks:

• ICMP echo request (ping)
• TCP SYN to port 443 (HTTPS)
• TCP ACK to port 80 (HTTP)
• ICMP timestamp request

Looking at the full tcpdump output, we can see the target responding to ICMP but rejecting TCP connections:

12:45:30.742974 IP 192.168.0.222.36388 > 192.168.0.2.443: S 3607279099:3607279099(0) win 1024
12:45:30.743134 IP 192.168.0.2.80 > 192.168.0.222.36388: R 3607279099:3607279099(0) win 0

Here are several approaches to handle this situation:

1. Force ICMP-only Scanning

To make Nmap rely solely on ICMP:

nmap -sn -PE 192.168.0.2

The -PE option tells Nmap to only use ICMP echo requests for host discovery.

2. Skip Host Discovery Entirely

When you're certain the host is up:

nmap -Pn 192.168.0.2

This bypasses host discovery and proceeds directly to port scanning.

3. Customize Nmap's Host Discovery

Create a more tailored discovery approach:

nmap -sn -PS80,443 -PE --disable-arp-ping 192.168.0.2

This behavior was observed with:

Nmap version 5.61TEST5 (http://nmap.org)
Platform: i386-portbld-freebsd7.4

Newer versions of Nmap have refined host discovery algorithms, so upgrading might help:

sudo apt-get update && sudo apt-get install nmap  # For Debian/Ubuntu
brew update && brew upgrade nmap                 # For macOS

Despite the firewall rule:

pass quick on fxp0

The target host might still be dropping certain packet types. Modern systems often:

• Respond to ICMP echo requests
• Drop unexpected TCP SYN packets
• Ignore TCP ACK packets without prior connection

When Nmap's results seem inconsistent, try these verification commands:

# Traditional ping
ping -c 3 192.168.0.2

# ARP ping (works on local networks)
arping -c 3 192.168.0.2

# TCP ping (test specific ports)
nping --tcp -p 80,443 192.168.0.2

The key takeaway is that Nmap's host discovery is more complex than a simple ping. Understanding its multi-probe approach helps troubleshoot these situations. When standard scans fail, combining different techniques usually reveals the true network status.

---

You're observing a common Nmap behavior where hosts responding to regular ICMP ping requests don't appear in Nmap's scan results. The key differentiator here is that standard ping uses basic ICMP Echo Requests, while Nmap's -sn (ping scan) employs a more sophisticated detection method.

Nmap 5.61TEST5's -sn scan performs multiple checks by default:

1. ICMP Echo Request
2. TCP SYN to port 443 (HTTPS)
3. TCP ACK to port 80 (HTTP)
4. ICMP Timestamp Request

From your tcpdump output, we can see Nmap is sending all these probes, but only receiving ICMP responses:

12:45:30.743061 IP 192.168.0.2 > 192.168.0.222: ICMP echo reply
12:45:30.743148 IP 192.168.0.2 > 192.168.0.222: ICMP time stamp reply

Nmap considers a host alive only if it receives at least one response from these probes. However, modern Nmap versions (unlike yours) require responses to specific probe types due to reliability concerns. In your case, the firewall might be:

• Blocking TCP 80/443 probes
• Dropping packets with specific flags (ACK/SYN)
• Filtering ICMP timestamp requests

Option 1: Force Pure ICMP Scanning

nmap -sn -PE --send-ip 192.168.0.2

This uses only ICMP Echo Requests (like regular ping). The --send-ip bypasses Nmap's raw packet crafting which might be causing issues.

Option 2: Use ARP Ping for Local Networks

nmap -sn -PR 192.168.0.2

ARP queries often work when ICMP fails on local networks.

Option 3: Skip Host Discovery Entirely

nmap -Pn 192.168.0.2

This assumes all hosts are up and skips the ping phase completely.

Your Nmap 5.61TEST5 has different default behaviors than modern versions. Consider upgrading or using these additional flags:

nmap -sn -PS80,443 -PA80,443 -PE -PP 192.168.0.2

Your pass quick on fxp0 rule should allow all traffic, but check for:

# Check for additional rules
ipfw show
pfctl -sr

To understand exactly what's being blocked:

nmap -sn --packet-trace 192.168.0.2
tcpdump -i fxp0 -vvv 'icmp or tcp port 80 or tcp port 443'