-sn disables normal port scanning and retains host discovery. -Pn skips ordinary host discovery and attempts the requested work against every supplied target. Neither option forces a response or establishes that a host is absent.
Choose according to the question: discover responsive candidates on a verified lab segment, or inspect selected ports on one independently identified VM. This guide provides a controlled comparison rather than a command for scanning an unknown network.
What changes, and what stays unknown?
| Command pattern | Requested work | Interpretation limit |
|---|---|---|
nmap -sn TARGET_IP | Host discovery; no normal port scan. | A non-response may reflect the path or probes, not an absent VM. |
nmap -sT -p PORTS TARGET_IP | Discovery, then selected TCP checks on hosts considered up. | A skipped target has not received the requested port scan. |
nmap -Pn -sT -p PORTS TARGET_IP | Selected TCP checks without the ordinary discovery gate. | “Host up” can represent the assumption, not an independent response. |
nmap -sL -n TARGET_IP | Target-list preview without host probes or reverse DNS. | It lists the supplied target; it does not test it. |
The options are case-sensitive. -Pn contains a capital P; -sn uses a lowercase s. The official discovery controls describe these different phases.
Compare the methods on the same identified lab VM
Confirm the target MAC or another independent VM identity, the source adapter and the intended route first. Keep the target, source, privileges and port selection constant while comparing discovery behavior. Replace TARGET_IP and PORTS below with actual lab values; choose ports relevant to your observed service or exercise.
mkdir -p evidence nmap --version nmap -sn -n --reason -oA evidence/D001-discovery TARGET_IP nmap -sT -n -p PORTS --reason -oA evidence/D002-default-gate TARGET_IP nmap -Pn -sT -n -p PORTS --reason -oA evidence/D003-no-gate TARGET_IP
Use unused output basenames. These examples request no version detection, default scripts, OS detection or UDP scan. The comparison is not complete if you change several other options at the same time or compare different target addresses after DHCP changes.
First inspect whether discovery reported the target. Then check whether each port scan actually ran and what response supported each state. Preserve completion messages and errors, not just the open-port lines.
Interpret the difference without inventing a cause
| What you observe | Supported statement | Next useful check |
|---|---|---|
| Discovery reports the target; both port scans agree. | The default discovery gate did not prevent the tested TCP work in this comparison. | Continue to service identification if needed. |
| Default scan skips the target; -Pn gets an open or closed TCP response. | A selected TCP probe received a response despite the earlier discovery result. | Compare discovery methods, privileges and path; do not assume a particular firewall rule. |
| -Pn reports the target up, but all selected ports are filtered. | The requested port tests did not obtain conclusive open/closed evidence. | Recheck identity, route and filtering. Host existence is still not proved by the assumed up label. |
| Both tests receive no useful response. | Neither method established the expected communication under these conditions. | Return to boot state, adapters, addressing and route selection. |
| A browser works while discovery fails. | That browser request succeeded through its own path. | Compare destination, protocol, proxy, DNS and source path with Nmap before treating them as equivalent. |
These are interpretation examples, not observed results from a particular Kioptrix image. A filtered state does not prove that a listening service exists behind a firewall. An open TCP port does not identify an application vulnerability.
Why a local Ethernet lab can behave differently
Nmap’s discovery is not always an ICMP echo request. Probe selection depends on privileges, platform and target location. Directly connected Ethernet targets commonly involve ARP for IPv4 or Neighbor Discovery for IPv6, including when other discovery options are selected.
-Pn therefore does not promise an absence of all discovery or link-layer traffic. A local ARP response can also be affected by proxy ARP. Do not disable mechanisms just to force a tutorial’s output; record the actual path and compare the host discovery reference with your environment.
Custom probes such as -PS answer another question about a chosen discovery method. They can replace the default probe selection. Read the technique documentation before adding them. More probe types do not automatically explain a disagreement.
Common command mistakes
- Adding -Pn to an unknown range: every supplied address becomes a candidate for the requested work. Start with the known target rather than multiplying retries across unused addresses.
- Treating -sn as port enumeration: discovery traffic can involve TCP, but it does not provide the requested normal port-state survey.
- Combining -Pn and -sn for inventory: this skips the ordinary discovery and port-scanning stages. It can be useful with separately requested NSE work, but it is not a reliable “find live hosts” shortcut.
- Reading a label without its reason: distinguish an assumed host state from a received response.
- Fixing silence by changing the subnet: confirm the lab configuration rather than expanding onto a physical network.
Save a small comparison record
Target VM identity and current address: Source interface, route, privileges and Nmap version: Port list and why these ports were selected: Discovery command and response reason: Default-gated scan: ran / skipped / incomplete: -Pn scan: literal port states and reasons: Evidence filenames: What this comparison supports: What it does not explain: Next check:
Use the network observation exercises to learn interfaces and routes. For all other flag choices, see the Nmap flags reference. If the VM boundary itself is uncertain, return to network setup before collecting more scan output.