Overview

This article demonstrates how Nmap classifies TCP and UDP ports and how firewall configuration directly shapes those results. In a controlled lab, we scan a single target host, trigger the four core port states—open, closed, filtered, and unfiltered—along with the ambiguous open|filtered verdict, and confirm every result at the packet level with Wireshark. We then apply iptables rules to create specific states on demand, showing that a port’s reported state reflects the interaction between scanner and firewall rather than the service alone. The article closes with practical defences that let administrators control exactly what an attacker can learn.

Table of Contents

• Introduction
• Lab Environment
• Detecting an Open Port
• Detecting a Closed Port
• Manufacturing a Filtered Port
• Identifying an Unfiltered Port
• Interpreting open|filtered
• Applying a Global Filtering Policy
• Mitigation Strategies
• Conclusion 

Introduction

Nmap remains the de facto tool for network reconnaissance because it infers a port’s status from how a target responds to carefully crafted probes. Every verdict traces back to the TCP three‑way handshake: the scanner sends a SYN, an open port replies with SYN/ACK, and a closed port replies with RST/ACK. When a firewall intervenes—silently discarding packets or actively rejecting them—the response pattern changes, and Nmap reports the port differently.

This study focuses on five states:

• Open — a service actively accepts connections on the port.
• Closed — the host is reachable, but no service listens on the port.
• Filtered — a firewall blocks the probe, so Nmap receives no usable reply.
• Unfiltered — the port is reachable, yet Nmap cannot tell whether it is open; only the ACK scan reports this state.
• open|filtered — Nmap cannot separate an open port from a filtered one, a common outcome of UDP scanning.

Lab Environment

We built an isolated VMware network with two hosts. A Kali Linux machine acts as the attacker and runs Nmap 7.99 and Wireshark, while a Linux host named “ignite” serves as the target and enforces packet-filtering rules through iptables. Capturing traffic on the eth0 interface lets us correlate each Nmap verdict with the exact packets exchanged. The target consistently identifies itself by the MAC address 00:0C:29:85:D1:03, confirming the VMware-based environment throughout the tests.

Detecting an Open Port

We begin with a single-port TCP scan of port 80. Because Nmap runs with root privileges, it launches a stealth SYN (half-open) scan by default. The target answers the probe, so Nmap reports port 80 as open and identifies the service as HTTP. The result confirms that a web server actively listens on the address.

nmap -p80 192.168.1.9

The packet capture reveals the half-open exchange behind the verdict. Nmap sends a SYN to port 80, the target replies with SYN/ACK to signal that the port is open, and Nmap immediately issues an RST to tear the connection down before it completes. By never finishing the handshake, the scan stays fast and leaves a lighter footprint than a full TCP connect.

Detecting a Closed Port

Next, we probe port 443. The host responds, but no service is bound to the port, so Nmap reports it as closed and labels the expected service as HTTPS. A closed result still confirms that the host is alive and that no firewall interferes—it simply means nothing is listening.

nmap -p443 192.168.1.9

The capture displays the closed-port signature. Nmap sends a SYN, and the target answers immediately with RST/ACK. That reset tells Nmap the port is reachable but offers no service, which is precisely how a closed port differs from a filtered one.

Manufacturing a Filtered Port

To create a filtered state, we instruct the target’s firewall to discard all inbound traffic to port 80 silently. The DROP target neither processes the packet nor returns an error, leaving the sender with no feedback whatsoever.

iptables -A INPUT -p tcp --dport 80 -j DROP

Re-running the earlier scan against port 80 now yields a very different verdict. With its probes vanishing into the firewall, Nmap cannot determine whether a service is listening and therefore reports the port as filtered.

nmap -p80 192.168.1.9

The capture explains the change. Nmap transmits a SYN and waits; receiving nothing, it retransmits the probe from a new source port. These repeated, unanswered SYNs are the hallmark of a DROP rule—silence on the wire translates directly into a filtered verdict.

Identifying an Unfiltered Port

The unfiltered state appears only during an ACK scan, which maps firewall rules rather than service availability. We first configure the firewall to reject traffic on port 83 with an explicit TCP reset, so the host responds to probes rather than swallowing them.

iptables -A INPUT -p tcp --dport 83 -j REJECT --reject-with tcp-reset

We then launch an ACK scan against port 83. The scan sends bare ACK packets and watches for resets: a returning RST proves the probe reached the host and was not silently filtered. Nmap consequently classifies port 83 as unfiltered—reachable, although an ACK scan can never reveal whether the port is open.

nmap -sA -p83 192.168.1.9

The capture confirms the logic. Nmap sends an ACK to port 83, and the host replies with a RST. Because a reset returned rather than nothing, Nmap rules out filtering and records the port as unfiltered.

Interpreting open|filtered

UDP scanning is inherently ambiguous because open UDP services frequently stay silent. To demonstrate, we drop all inbound UDP traffic to port 84 at the firewall.

iptables -A INPUT -p udp --dport 84 -j DROP

A UDP scan of port 84 now returns no response, and Nmap cannot tell whether an open service simply chose not to reply or a firewall blocked the probe. It therefore reports the only honest conclusion: open|filtered.

nmap -sU -p84 192.168.1.9

Applying a Global Filtering Policy

Finally, we clear the per-port experiments and impose a blanket rule. Flushing the rule set removes every previous entry, and inserting a single high-priority rule drops all inbound TCP. From this point, every TCP port on the host meets a scanner with identical silence, presenting a uniformly filtered surface that frustrates enumeration.

iptables -F
iptables -I INPUT -p tcp -j DROP

Mitigation Strategies

The same mechanisms that produce these states give defenders precise control over what a scanner can learn. The following measures harden a host against reconnaissance:

• Enforce a default-deny posture. Block all inbound traffic and explicitly allow only the ports your services require, so unused ports never reveal themselves.
• Prefer DROP over REJECT for untrusted sources. Dropping packets forces scanners into slow retransmission timeouts and denies them the certainty that a reset provides.
• Minimise the attack surface. Disable and remove services you do not need; a port that hosts nothing cannot be exploited.
• Filter statefully and by source. Use connection tracking and source-address allowlists to expose sensitive ports only to trusted networks.
• Throttle connection attempts. Rate-limit new connections to blunt rapid scans and SYN floods without harming legitimate users.
• Deploy detection. Run an IDS/IPS such as Suricata or Snort to flag scan patterns and use fail2ban or port knocking to hide and protect management services.
• Log and review dropped traffic. Continuously monitoring denied packets surfaces reconnaissance early and turns the firewall into a source of intelligence.

Conclusion

Every Nmap verdict tells the story of a conversation. An open port completes a handshake, a closed port resets it, a filtered port says nothing at all, and an ACK scan distinguishes a reachable port from a blocked one—while UDP’s silence collapses into open|filtered. By pairing each scan with a packet capture, this study showed that port state depends as much on firewall policy as on the services themselves. Administrators who understand that relationship can deliberately shape their network’s visible footprint, denying attackers easy intelligence while preserving access for legitimate traffic. Reconnaissance and defence, in the end, read the very same packets—only the intent differs.