An Nmap result does not reveal the permanent truth about a port. It describes what Nmap could infer from particular probes, sent from a particular network location, at a particular time.
That single idea explains most confusion around open, closed, and filtered.
The six Nmap port states
Nmap recognizes six states: open, closed, filtered, unfiltered, open|filtered, and closed|filtered.[1]
Open
An application is accepting TCP connections or UDP packets on the port. This confirms exposure, not vulnerability. Port 443 may host a carefully maintained application or a forgotten administration panel; the state alone cannot distinguish them.
Next question: What service is actually responding, and should it be reachable from here?
nmap -sV -p 443 192.0.2.10
curl -kI https://192.0.2.10/
Closed
The target is reachable, but no application is listening on that port. A closed TCP port commonly returns a reset. Closed is useful because it confirms the host responded and helps Nmap with operating-system inference.
Closed does not mean permanently disabled. A service may start later, bind only to another interface, or be exposed from another network segment.
Filtered
Nmap cannot determine whether the port is open because a firewall, router rule, host filter, or other obstacle prevents a decisive response. A dropped probe often produces this state.
Filtered is not synonymous with “secure.” It can mean the control is working from the scanner’s position. It can also reflect packet loss, asymmetric routing, a rate limit, or a different access rule.
Unfiltered
The port responds to probes, but the chosen scan cannot determine whether it is open or closed. This state is commonly associated with ACK scanning, which is primarily useful for mapping filtering behavior.
Open|filtered
Nmap cannot distinguish open from filtered because the scan expects no response in either case. UDP scans commonly produce this ambiguity: an open UDP service may remain silent, while a firewall may silently drop the probe.
Closed|filtered
Nmap cannot distinguish closed from filtered. This state is less common and can appear with scan techniques where the two conditions produce indistinguishable behavior.
Why scan technique changes the answer
Different scan types ask different network questions.
A TCP SYN scan sends a SYN and interprets the response without completing the normal connection. A connect scan asks the operating system to complete a connection. An ACK scan examines filtering rather than whether a service is listening. A UDP scan waits for application responses or ICMP errors.
# SYN scan; usually requires elevated privileges
sudo nmap -sS -p 22,80,443 192.0.2.10
# Full TCP connect scan
nmap -sT -p 22,80,443 192.0.2.10
# Selective UDP scan
sudo nmap -sU -p 53,123,161 192.0.2.10
Use these only against systems you own or are authorized to test.
Why two scanners can disagree
Suppose a host shows port 445 as open from the corporate LAN and filtered from a guest network. Both results may be correct. Firewalls apply policy based on source, destination, protocol, identity, interface, or time.
Results also differ because of:
- VPN or split-tunnel routing;
- cloud security groups;
- host-based firewalls;
- intrusion prevention and temporary blocks;
- scan timing and packet loss;
- IPv4 versus IPv6;
- TCP versus UDP;
- a service starting, stopping, or moving.
Always record the source address and network position with scan evidence.
A safe validation workflow
1. Save the first observation
nmap --top-ports 1000 192.0.2.10 -oA initial-tcp
-oA preserves normal, XML, and grepable output. This makes comparison and reporting easier.
2. Re-scan only relevant ports
nmap -p 22,80,443 --reason -vv 192.0.2.10 -oA focused-check
--reason shows the response behind the state. Verbosity helps distinguish “no response” from a tool or routing problem.
3. Add service detection deliberately
nmap -sV -p 22,80,443 192.0.2.10 -oA service-detection
Service detection sends additional probes. Apply it to known ports instead of reflexively increasing traffic across an entire range.
4. Validate at the application layer
curl -i http://192.0.2.10/
openssl s_client -connect 192.0.2.10:443 -servername lab.example.test
nc -nv 192.0.2.10 22
An HTTP-looking service on port 8080 could be a reverse proxy, admin console, API, or decoy. Read the protocol response.
5. Compare authorized vantage points
If the assessment permits it, compare external, internal, and segmented locations. Document differences as control behavior rather than merging them into one misleading list.
Common mistakes
“All 1000 ports are filtered, so the host exists”
Maybe. A firewall, nonexistent route, or upstream device can generate similar output. Combine scan evidence with approved discovery and routing checks.
“No ping response means the host is down”
Host discovery and port reachability are different. If scope and safety allow, -Pn tells Nmap to skip host discovery and test the specified ports. It does not make the host reachable; it prevents Nmap from stopping early.
nmap -Pn -p 443 192.0.2.10
“Open means exploitable”
Open means listening. Risk depends on the service, configuration, authentication, exposure, data, and available attack paths.
“Filtered means the firewall is correct”
A port filtered from the tester’s address might be open to the whole office network. Compare the observed rule with the intended rule.
Reading output as evidence
For each important result, record:
- target and resolved hostname;
- source and vantage point;
- date and time;
- exact command and Nmap version;
- port, protocol, state, and reason;
- service validation;
- whether the observation was repeated.
The conclusion should sound like this: “TCP 443 accepted connections from the external test address and served the customer portal.” That is stronger than “443 open.”
Sources
Nmap Project, Port Scanning Overview. ↩︎