VMware ESXi and vSphere Cluster Management

Understanding Nmap Port States

Learn what Nmap open, closed, filtered, unfiltered, open|filtered, and closed|filtered states mean and how scan methods affect interpretation.

What Nmap Port States Tell You

Nmap is a network discovery and security-auditing tool. It sends probes—packets or connection attempts intended to produce a response—and classifies each scanned port from the response, or from the absence of a response.

A port state is Nmap's interpretation of what it observed during one particular scan. It is not an absolute or permanent property of the target. Firewall rules, routing, timing, packet loss, service changes, and the selected scan type can all affect the result.

The usual goal of port scanning is to identify reachable listening services. A listening service is a process waiting to accept network communication on a port. Finding an open port helps with service discovery, administration, and security assessment, but an open result does not prove that the service is safe, correctly configured, or exploitable.

Nmap Port States at a Glance

State — What Nmap can infer — Typical observation — What it does not prove — Useful next step

open — A service appears to accept communication — A TCP handshake or suitable protocol response succeeds — The service is not necessarily safe or exploitable — Use service and version detection.

closed — The port is reachable, but no matching service is listening — A TCP reset or protocol-specific negative response — The port is not permanently unavailable — Check whether a service should be enabled.

filtered — Filtering prevents Nmap from deciding whether the port is open — Probes are dropped or a blocking response is received — No service exists behind the filter — Review firewall and ACL policy.

unfiltered — The port is reachable, but this scan has not determined open versus closed — The target responds in a way that proves reachability without identifying a listener — The port is open — Use a SYN or connect scan.

open|filtered — Nmap cannot distinguish open from filtered — No expected response arrives — The service is definitely present or definitely absent — Retry, use a protocol-aware probe, or inspect packets.

closed|filtered — Nmap cannot distinguish closed from filtered — The scan method cannot reliably separate the outcomes — The port is reachable or that no service exists — Use a scan type that can distinguish them.

Open

An open port has a service or application accepting connections or datagrams for the scan type used. For TCP, Nmap may observe behavior consistent with a listening socket. For UDP, an application response can provide evidence that the service is available.

Open ports are useful starting points for service discovery. For example, TCP port 22 reported as open suggests that an SSH service is accepting connections. An administrator can compare that finding with the intended host configuration, while a security tester can investigate authentication, software version, and exposure.

Open means reachable and responsive in the observed conditions. It does not prove that the service is trusted, patched, correctly configured, or exploitable.

Closed

A closed port is reachable, but no application is currently listening on that port. With TCP, a reset response commonly indicates that the host received the probe and rejected the attempted connection because no listener exists.

A closed result is useful evidence about reachability: the target or network path was accessible for that probe. This differs from filtered, where a control between the scanner and target prevents Nmap from determining the port's condition.

A closed port can later become open if an administrator starts a service or changes its configuration. Treat the state as a current observation, not a permanent fact.

Filtered

A filtered port is one for which packet filtering, a firewall, an access-control device, or another network control prevents Nmap from deciding whether the port is open.

A firewall may silently drop probes, meaning it discards them without sending a response. It may also send a blocking or administrative error response. Either behavior can prevent Nmap from obtaining the evidence needed to classify the port as open or closed.

Filtered does not prove that a service is absent. A service might be listening behind the filter, or there might be no service at all. To investigate, review firewall and security-group policy, validate the authorized network path, and compare results from an approved location.

Unfiltered

Unfiltered means Nmap can reach the port, but the current scan method has not established whether an application is listening. The result therefore says something about reachability, not service availability.

This state is commonly associated with an ACK scan. An ACK scan is designed to examine how filtering handles TCP traffic; it is not intended to identify listening services. Follow an unfiltered result with a SYN scan or TCP connect scan when you need an open-versus-closed answer.

The key distinction is that unfiltered indicates reachability without a final service classification, while filtered indicates that filtering prevents Nmap from determining whether the port can be reached in the relevant way.

Open|filtered

Open|filtered represents ambiguity between an open port and a filtered port. Nmap uses this combined state when the selected scan cannot distinguish a silently dropped probe from an accepted probe that produces no expected reply.

This outcome is common with UDP scanning because many UDP services do not respond to unexpected or incomplete traffic. It can also occur with specialized TCP scans that rely on unusual flag combinations. A missing response could mean that a service accepted the traffic without replying, or that a firewall discarded the probe.

To reduce uncertainty, repeat the scan with suitable retries and timing, use an authorized protocol-aware probe, try a scan type appropriate to the protocol, and inspect packet captures or ICMP errors when available.

Closed|filtered

Closed|filtered represents ambiguity between a closed port and a filtered port. Some scan techniques cannot reliably separate a target that is not listening from a target whose response was blocked or suppressed.

The result depends on the scan method, target operating-system behavior, and filtering policy. It should not be treated as proof that the port is closed or that a service is hidden. A different scan technique may provide stronger evidence.

How Scan Technique Changes Interpretation

Nmap assigns a state from the interaction between the protocol, the probe, the target's response, and filtering devices. The same endpoint can therefore produce different states under different scan types.

Scan family — Protocol behavior used — States commonly encountered — Common source of ambiguity — Validation option

TCP connect scan — Completes a normal TCP connection using the operating system's networking stack — Open, closed, filtered — Firewalls, application-level controls, and connection limits — Compare with a SYN scan and review service logs.

TCP SYN scan — Sends an initial SYN and interprets SYN/ACK or reset behavior without normally completing the connection — Open, closed, filtered — Dropped replies, rate limiting, and middleboxes — Use --reason, retries, or a connect scan.

TCP ACK scan — Sends ACK packets to examine filtering behavior — Unfiltered or filtered — It does not test whether a service is listening — Use a SYN or connect scan for open versus closed.

TCP FIN/NULL/Xmas scans — Send unusual TCP flag combinations and rely on target-specific responses — Open|filtered and closed-like distinctions — Operating-system differences and firewalls that normalize or drop unusual packets — Compare with SYN or connect scanning.

UDP scan — Sends UDP probes and examines application replies or ICMP errors — Open, closed, filtered, or open|filtered — Many UDP services remain silent; filtering and ICMP rate limits add uncertainty — Use retries, protocol-aware validation, and packet capture.

TCP Connect and SYN Scans

A TCP connect scan uses a complete connection attempt. It is useful when raw-packet privileges are unavailable, but the connection can be more visible in target-side logs.

A SYN scan sends the opening TCP handshake packet and interprets the reply. A SYN/ACK commonly supports an open classification, while a reset commonly supports a closed classification. Filtering or missing replies can produce filtered results.

nmap -sS -p 22,80,443 <target>

SYN scanning often requires appropriate privileges. Use a connect scan when a full TCP connection is appropriate:

nmap -sT -p 22,80,443 <target>

UDP Scans

UDP is connectionless, so it has no universal handshake equivalent to TCP. A UDP service may answer only when the payload matches its protocol, and some services remain silent even when available. An ICMP error can provide evidence that traffic is unreachable or rejected, but a missing response often leaves open and filtered indistinguishable.

nmap -sU -p 53,161 <target>

UDP scans can be slow and need careful interpretation. For example, port 161 reported as open|filtered could indicate an available SNMP service that did not answer the probe, or a firewall silently dropping it.

ACK, FIN, NULL, and Xmas Scans

An ACK scan primarily assesses whether filtering permits or blocks particular TCP traffic. An unfiltered result means the probe reached the target, not that an application is listening.

nmap -sA -p 80,443 <target>

FIN, NULL, and Xmas scans use unusual combinations of TCP flags. Their interpretation depends strongly on target behavior and filtering. They can produce ambiguous results and should not replace a SYN or connect scan when the goal is service discovery.

Practical Interpretation Examples

Reachable SSH Service

A SYN scan reports TCP port 22 as open. This indicates that something is likely accepting TCP connections on that port. Follow with service detection to identify the software and version, then compare the result with the host's authorized configuration.

nmap -sV -p 22,80,443 <target>

Reachable Host with No Service

TCP port 8080 reports closed. The target responded for the probe, demonstrating reachability, but no application is currently listening on that port. This does not mean the port can never be used; a later service or configuration change could alter the result.

Firewall Suppression

TCP port 445 reports filtered after probes receive no usable answer or an administrative blocking indication. The result shows that Nmap cannot determine whether SMB is running behind the filter.

Different Results from Different Methods

An ACK scan may report a port as unfiltered while a SYN scan does not report it as open. These scans answer different questions: the ACK result concerns filtering reachability, while the SYN result investigates whether a listener responds to a new connection attempt.

Validating Inconclusive Results

Do not draw strong operational conclusions from a single ambiguous result. Useful validation methods include:

  • Allowing retransmission and adjusting timeout or retry behavior when packet loss is plausible.
  • Repeating a narrowly scoped scan at a different time.
  • Comparing appropriate scan types, such as SYN or connect after an ACK result.
  • Using service or version detection after a port appears open.
  • Using a protocol-aware probe where the assessment is authorized.
  • Capturing packets to determine whether probes, resets, ICMP errors, or replies are actually exchanged.
  • Reviewing host firewalls, perimeter firewalls, security groups, and network ACLs with administrative access.

Rate limiting, host firewalls, intrusion-prevention systems, network middleboxes, temporary service changes, load balancing, and transient congestion can all affect results. Record the scan time, source location, destination address, options, and observed reasons so that later comparisons are meaningful.

nmap -vv --reason -p <ports> <target>

The --reason option helps show the response evidence behind a reported state. It does not make an inherently ambiguous probe conclusive, but it makes the available evidence easier to inspect.

Troubleshooting Common Results

An Expected Service Is Reported Filtered

  • Possible causes include a host or perimeter firewall, a security group, a network ACL, an incorrect VPN or source path, intrusion prevention, or rate limiting.
  • Confirm the authorized network path and applicable policy.
  • Use --reason to inspect Nmap's evidence.
  • Compare from an approved alternate network location.
  • Verify the service and local firewall configuration when administrative access exists.

A UDP Port Is Reported Open|Filtered

  • The service may accept traffic without replying to the probe.
  • A firewall may silently drop the probe.
  • Packet loss or rate limiting may have suppressed a response.
  • Repeat with appropriate timing and retry settings.
  • Use an authorized service-specific validation method.
  • Review ICMP errors and packet captures where available.

A Port Changes State Between Scans

  • A service may have restarted or changed configuration.
  • Dynamic firewall policy or defensive throttling may be involved.
  • Load balancing may send scans to different backend systems.
  • DNS, address translation, or the destination address may have changed.
  • Record scan details and perform a narrowly scoped repeat scan.

ACK Reports Unfiltered but Another Scan Does Not Show Open

The port may be reachable but not listening, or a firewall may allow ACK traffic while restricting new connections. Use a SYN or connect scan to evaluate open versus closed, and compare response reasons with relevant firewall rules.

Exam- and Practice-Relevant Summary

  • Open: a service appears to be accepting communication.
  • Closed: the port is reachable, but no matching service is listening.
  • Filtered: filtering prevents Nmap from deciding whether the port is open.
  • Unfiltered: the port is reachable, but the current scan has not determined open versus closed.
  • Open|filtered: open and filtered cannot be distinguished, commonly because a probe receives no response.
  • Closed|filtered: closed and filtered cannot be distinguished by the selected technique.
  • Scan states describe observations from a particular method and moment, not permanent target properties.
  • UDP commonly produces more uncertainty than TCP because many UDP services do not answer unexpected traffic.
  • An ACK scan evaluates filtering and is not a service-discovery scan.
  • Verify unexpected or ambiguous findings before changing firewall policy, declaring a service unavailable, or reporting a security issue.

For related study, review Nmap port states alongside TCP and UDP behavior, service detection, firewall policy, timing, and packet capture.