VMware ESXi and vSphere Cluster Management

Disable Host Discovery (Ping Sweep) in Nmap

Learn how Nmap host discovery works, why hosts may appear down, and how to use -Pn to scan authorized targets that do not answer discovery probes.

Overview

Nmap normally performs host discovery before carrying out a more extensive port, service, or operating-system scan. Host discovery is Nmap's preliminary process for determining which supplied targets appear online or reachable.

A target can be a hostname, IP address, CIDR range, or target list. When normal discovery probes receive no usable response, Nmap generally classifies that target as down and skips subsequent scan operations for it.

This behavior is efficient, but it can miss systems that are online but do not answer discovery traffic. The Nmap option -Pn disables host discovery and tells Nmap to treat every specified target as online for scanning purposes.

What Host Discovery Does

Host discovery is sometimes informally called a ping sweep. A ping sweep probes multiple targets to identify live hosts, although Nmap host discovery can use more than traditional ICMP echo requests.

Depending on the scan context, Nmap can use different discovery probes. These may include ICMP-based probes and TCP-based probes. The exact probe behavior can depend on the target, permissions, scan options, and network conditions.

  1. Nmap receives the supplied targets.
  2. It performs host-discovery probes against those targets.
  3. Targets that respond in a way that indicates reachability are marked as up.
  4. Targets that do not respond are normally treated as down and omitted from later scan operations.

This preliminary step avoids spending time port-scanning addresses that appear unused. However, a lack of response does not always mean that a host is offline.

Why an Online Host May Not Respond

Several conditions can prevent a live host from answering discovery probes:

  • Firewalls: Host or network firewalls may block ICMP echo requests, TCP discovery probes, or other packets used for host discovery.
  • Packet-filtering rules: Security policies may silently discard probes instead of returning an explicit rejection.
  • Host configuration: A system can be online while deliberately refusing ping-like requests.
  • Routing problems: Incorrect routes, asymmetric paths, or network segmentation can prevent discovery traffic from reaching the target or its replies from returning.
  • Filtering devices: Routers, intrusion-prevention systems, and other middleboxes can modify or drop probes.
  • Packet loss and latency: Congestion, wireless interference, or high response delay can make a valid reply arrive too late or not at all.

As a result, host discovery is an indication of reachability, not an absolute test of whether a machine is powered on.

Using -Pn to Skip Host Discovery

The current Nmap option for disabling host discovery is -Pn. It tells Nmap to skip the preliminary discovery phase and assume that each specified target is online for the purpose of the requested scan.

nmap -Pn <target>

For example, this command scans an authorized IP address even if it does not respond to normal discovery traffic:

nmap -Pn 192.168.5.102

Disabling discovery does not guarantee that the target is reachable, that packets will receive replies, or that any ports will be found open. It only prevents Nmap from discarding the target before attempting the requested scan.

Older Nmap material may show -PN. That is the legacy capitalization. Current Nmap usage and documentation use -Pn.

Default Discovery Compared with -Pn

BehaviorDefault Nmap scanScan using -Pn
Whether host discovery runs firstYes, normally.No. Nmap skips host discovery.
Target with no discovery responseUsually treated as down and skipped.Treated as up for scanning purposes.
Chance of scanning firewalled or ping-blocking hostsLower if discovery probes are blocked.Higher because Nmap proceeds to the requested scan.
Typical time cost on large or sparse target setsOften lower because apparently down targets are skipped.Often higher because every target is scanned.
Recommended use caseRoutine scanning when discovery works reliably.Known or strongly suspected live targets that do not answer discovery probes.

Effect on Scan Behavior and Duration

With -Pn, Nmap attempts the requested scan against every supplied target. This is useful for a single host behind a firewall, but it can be expensive across a large address range.

For example, if a range contains many unused addresses, Nmap will still try to scan them. Unreachable or heavily filtered targets may cause probes to wait for timeouts and retries. High latency, the observed response delay between the scanner and target, can also increase the total runtime.

Use -Pn selectively:

  • Limit the target list to known, approved, or strongly suspected live systems.
  • Begin with one host rather than an entire subnet.
  • Choose a narrow port set when validating a specific service.
  • Avoid using -Pn across large ranges unless the longer runtime is expected and authorized.

Combining -Pn with Port Selection

A port scan probes network ports to determine their reachable state and identify exposed services. The -p option selects which ports Nmap scans.

Port ranges use a hyphen, such as 50-90, while individual ports in a list are separated by commas, such as 22,80,443.

nmap -Pn -p 50-90 192.168.5.102

This command skips host discovery and checks TCP ports 50 through 90. Depending on the target configuration, that range can include services such as DNS on TCP 53, HTTP on TCP 80, or Kerberos on TCP 88.

A small list is often faster when validating a known service host:

nmap -Pn -p 22,80,443 192.168.5.102

This checks common TCP ports for SSH, HTTP, and HTTPS. A narrow selection reduces the number of probes and is generally more efficient than scanning broad ranges against an unverified target.

Contrasting Normal and No-Discovery Scans

These commands use the same authorized target but different discovery behavior:

nmap 192.168.5.102
nmap -Pn 192.168.5.102

The first command uses normal host discovery. If discovery receives no response, Nmap may report that the host appears down and stop before the requested port scan. The second command does not wait for discovery to classify the target as up; it proceeds with the selected or default scan behavior.

Reading Results from a -Pn Scan

Because -Pn assumes targets are up, Nmap may report a target as up even when the scan cannot independently verify availability. Treat that status as an instruction to scan, not proof that the host is reachable.

Port stateMeaningInterpretation when host discovery is disabled
openAn application is accepting connections or responding on the port.There is evidence that the target and the service responded to the scan. Nmap may also display a service label when it can associate the port with a known service.
closedThe port is reachable, but no application is listening; an explicit rejection is usually returned.The target path responded, but that particular port does not currently expose a listening service.
filteredPacket filtering prevents Nmap from determining whether the port is open.The result does not prove that the target is offline. A firewall may be dropping or blocking the probes.

A scan that finds no open ports is not conclusive proof that the target is offline. The ports may be closed, filtered, outside the selected range, or unreachable despite the assumed-up treatment.

Troubleshooting

The normal scan says the host appears down

Possible causes include blocked ICMP or other discovery probes, a host firewall, a filtering network device, or a route that handles discovery traffic differently from port-scan traffic.

For an authorized target, retry with -Pn and a limited port set:

nmap -Pn -p 22,80,443 192.168.5.102

The -Pn scan is much slower than expected

The target may actually be offline or unreachable, the range may contain many unused addresses, filtering may be causing timeouts, or the selected port range may be broad.

  • Reduce the target scope.
  • Start with one known host.
  • Scan fewer ports.
  • Avoid using -Pn where normal discovery is reliable.

No open ports are reported

Review whether the reported states are closed or filtered. Also confirm that the intended service uses one of the selected ports. A firewall can filter probes, and the host may be unreachable even though -Pn caused Nmap to assume it was up.

Validate connectivity through approved administrative methods and, if appropriate, test a carefully chosen port list rather than immediately scanning a broad range.

An older guide uses -PN

The guide is using legacy option capitalization. Use the current spelling, -Pn, and check the syntax supported by the installed release:

nmap --help

Safe Scanning Workflow

  1. Confirm ownership or written authorization and define the allowed target scope.
  2. Choose one known or strongly suspected live host.
  3. Try a normal scan first if discovery is expected to work.
  4. If the host is believed to be online but appears down, retry with -Pn.
  5. Use a small port list, such as -p 22,80,443, during initial validation.
  6. Interpret open, closed, and filtered states separately.
  7. Expand the target or port scope only when the results and authorization justify it.

Key Takeaways

  • Nmap normally performs host discovery before port, service, or operating-system scanning.
  • Firewalls, filtering rules, routing, latency, and packet loss can make an online host appear down.
  • -Pn skips host discovery and attempts the requested scan against every specified target.
  • -Pn does not guarantee reachability or open ports.
  • Narrow port selections can reduce the time and traffic of a no-discovery scan.
  • Use this option only within an authorized scope, preferably beginning with a single known host.

See the Nmap host-discovery bypass reference when reviewing this option and its scan-time trade-offs.