Host Discovery With Nmap: Find Which Probe a Firewalled Host Actually Answers

Key takeaways

• Use --reason to see why Nmap marked a host up.
• --packet-trace shows exactly which probes were sent and answered.
• Change one probe per run, and remember a reset also proves a host is alive.
• -Pn skips discovery but is slow on large ranges; scan only with authorisation.

The problem this guide solves

You scan a subnet with Nmap and a host you know is alive shows as "down". Usually the host is fine and a firewall is dropping the probes Nmap chose. This guide shows how to work out which probe a given host answers, using Nmap's own diagnostics. Do this only on networks you own or are authorised to test, such as a home lab or VMs on a host-only network.

For a table of every probe type and what it does, see the companion guide listed under Next steps. Here the focus is on method.

Step 1: ask Nmap why it decided a host was up or down

The --reason option prints the evidence behind each decision. This is the quickest way to learn which probe worked.

sudo nmap -sn --reason 192.168.56.0/24

In the output, the line for each host includes a reason such as arp-response, echo-reply, syn-ack, reset or conn-refused. An arp-response means the host is on your local segment. A reset reply to a TCP probe means a live host rejected the connection, which still proves it exists.

Step 2: watch the packets

sudo nmap -sn --packet-trace 192.168.56.101

Lines beginning SENT and RCVD show every probe and reply. If you see SENT lines and no RCVD lines for every probe, something on the path is dropping them. For a second view, capture on the same interface with Wireshark and filter on the target address.

Step 3: change the probe, one at a time

Try one probe type per run so you know which one caused the result.

sudo nmap -sn -PE 192.168.56.101 # ICMP echo
sudo nmap -sn -PP 192.168.56.101 # ICMP timestamp
sudo nmap -sn -PS22,80,443 192.168.56.101 # TCP SYN to common ports
sudo nmap -sn -PA80,443 192.168.56.101 # TCP ACK
sudo nmap -sn -PU53,161 192.168.56.101 # UDP to common services

Pick ports the host is likely to expose or to reject. A SYN to a port that is open gets a SYN/ACK. To a closed port on a live host with no firewall in the way, it gets a reset. Both prove the host is up. A firewall that silently drops the packet proves nothing.

An illustrative result on a host with a firewall

This shows the pattern you might see, not output from a specific lab. A host blocks ICMP echo but allows web traffic:

$ sudo nmap -sn -PE --reason 192.168.56.101
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.1 seconds

$ sudo nmap -sn -PS80,443 --reason 192.168.56.101
Nmap scan report for 192.168.56.101
Host is up, received syn-ack ttl 64 (0.00041s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.2 seconds

The conclusion is not "the host is up on port 80" but "this host answers TCP SYN probes to 80 and ignores ICMP echo". Record that, because it tells you about the firewall policy.

Step 4: if nothing works, skip discovery

-Pn tells Nmap to treat every address as up and go straight to port scanning. It finds hosts that ignore all discovery probes, but it is slow across a wide range and may produce many "filtered" results for addresses that are empty.

sudo nmap -Pn -p 22,80,443 192.168.56.101

Scaling up to a larger range

• Save results with -oA hosts so you have normal, XML and greppable files.
• Use -n to skip DNS lookups.
• Use a list scan (-sL) first to confirm the range is what you meant to scan, since it sends no probes to the targets.
• Combine probes for a mixed network, for example -PE -PS22,80,443 -PA80.
• For IPv6, add -6 and remember that scanning a /64 by brute force is impractical, so use known addresses or neighbour discovery on the local link.

What defenders learn from this

Each probe leaves a trace. A sudden run of ICMP, ARP or SYN packets to sequential addresses is a classic reconnaissance pattern that an IDS can alert on. Blocking all ICMP is not necessary and breaks tools such as path MTU discovery, so allow the types you need and rate-limit the rest. Do not depend on being invisible to ping.

Common mistakes

• Concluding a host is offline after one probe type.
• Running without root and not realising Nmap fell back to TCP connect probes.
• Using -Pn on a large range and waiting hours.
• Scanning without written permission.

The official guide to host discovery options is in the Nmap reference guide.

Next steps

Learn structured scanning in the VAPT course. Read the companion guide host discovery in Zenmap, the overview of network scanning and the scanning tool comparison.

Related reading

• Top Host Discovery Techniques in Ethical Hacking | ICMP, ARP, TCP Scans Explained
• What is Hping3 Tool? Features, Installation, Commands & Use Cases Explained