Nmap does not have one way to scan a TCP port, it has a whole family of them, and each one sets different flags to provoke a different reaction from the target. Knowing which scan type to reach for is the difference between mapping a firewall's rules cleanly and getting a page of misleading results. This article is part of the complete Nmap guide, and it walks the full family of TCP scan types, shows what each one detects, and (more usefully) shows where each one lies to you when the target stack does not play by the rules.
The TCP scan family at a glance
Every TCP scan type comes down to which flags Nmap sets in the probe packet and what it infers from the response. Here is the family, one line each on the flags it sends and what it is good for:
The SYN and connect scans are covered in depth under port scanning. This article focuses on the rest of the family, because that is where the interesting (and dangerous) behavior lives.
ACK scan maps firewall rules, not open ports
The ACK scan, -sA, is the odd one out: it is not trying to find open ports at all. It sends a bare ACK, and since a stateful firewall only permits ACKs that belong to an established connection, an unsolicited ACK gets a very telling reaction. If the ACK reaches a live host, the host sends a RST (there is no connection, so it rejects it), and Nmap marks the port unfiltered. If a stateful firewall drops the ACK instead, Nmap sees nothing back and marks it filtered. So the ACK scan does not tell you what is listening, it tells you where the firewall is.
Run it through a real Cisco ASA and every port comes back filtered, because a stateful firewall drops any ACK that is not part of an established session:
$ nmap -sA -p 22,23,80,443 10.10.20.32
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-28 07:01 UTC
Nmap scan report for 10.10.20.32
Host is up (0.0086s latency).
PORT STATE SERVICE
22/tcp filtered ssh
23/tcp filtered telnet
80/tcp filtered http
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 1.35 secondsAll filtered is the signature of a stateful firewall in the path. Now contrast that with an ACK scan against a plain Linux host with no stateful firewall between you and it:
$ nmap -sA -p22,80,443 127.0.0.1
Starting Nmap 7.95 ( https://nmap.org ) at 2026-07-05 15:05 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000042s latency).
PORT STATE SERVICE
22/tcp unfiltered ssh
80/tcp unfiltered http
443/tcp unfiltered https
Nmap done: 1 IP address (1 host up) scanned in 0.10 secondsEvery port is unfiltered: the host RST'd each ACK, proving nothing stateful is dropping traffic in the path. Put the two side by side and the ACK scan becomes a firewall detector. All filtered means a stateful device is between you and the target; all unfiltered means the path is clear. That is genuinely useful when you are verifying whether an ASA rule is actually taking effect, and it is the foundation of the techniques in firewall and IDS evasion.
FIN, NULL, and Xmas: the RFC 793 stealth scans
The FIN (-sF), NULL (-sN), and Xmas (-sX) scans all lean on the same trick from RFC 793, the original TCP specification. That RFC says a compliant stack must send a RST when it receives a packet with no SYN, RST, or ACK flag set to a closed port, and must send nothing when the same packet hits an open port. So Nmap sends a weird flag combination (bare FIN, no flags at all, or FIN/PSH/URG lit up like a Christmas tree) and reads the silence:
- Closed port sends a RST, so Nmap reports closed.
- Open port sends nothing, so Nmap cannot tell open from a firewall drop and reports open|filtered.
These scans are called stealthy because they never open a connection and often slip past simple filters looking for SYNs. On a compliant stack the logic works perfectly. Here are all three run against a Linux localhost, and they behave exactly as RFC 793 predicts:
$ nmap -sF -p22,80,443 127.0.0.1
PORT STATE SERVICE
22/tcp open|filtered ssh
80/tcp open|filtered http
443/tcp closed https
$ nmap -sN -p22,80,443 127.0.0.1
PORT STATE SERVICE
22/tcp open|filtered ssh
80/tcp open|filtered http
443/tcp closed https
$ nmap -sX -p22,80,443 127.0.0.1
PORT STATE SERVICE
22/tcp open|filtered ssh
80/tcp open|filtered http
443/tcp closed httpsAll three agree: 22 and 80 (which are open) report open|filtered because they stayed silent, and 443 (which is closed) reports closed because it sent a RST. This is the RFC 793 behavior working as designed on a Linux stack.
Where stealth scans fail: non-compliant stacks
Now the trap. RFC 793 compliance is not universal, and Cisco IOS is a well-known example of a stack that sends a RST for every unexpected packet, open port or not. Watch what a FIN scan does to a Cisco router whose ports 22 and 23 are genuinely open:
$ nmap -sF 10.10.10.1
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-28 07:01 UTC
Nmap scan report for 10.10.10.1
Host is up (0.0038s latency).
All 1000 scanned ports on 10.10.10.1 are in ignored states.
Not shown: 1000 closed tcp ports (reset)
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 1.76 secondsEvery single port reads closed (reset), including 22 and 23, which you know from a SYN scan are open. The Xmas scan gives the identical result, and the NULL scan behaves the same way. Because the IOS stack RSTs everything, the actually-open ports look closed, and the stealth scan reports a router with nothing listening. If you trusted this output you would walk away thinking the device was locked down when SSH and Telnet are wide open. The lesson: FIN, NULL, and Xmas scans only tell the truth against RFC-793-compliant stacks (mostly Unix-like hosts), and they will actively mislead you on Cisco gear, many Windows systems, and other stacks that RST unconditionally.
Window scan: reading the RST size
The Window scan, -sW, is a refinement of the ACK scan. It sends the same bare ACK, but instead of only checking whether a RST comes back, it inspects the TCP window field of that RST. On certain stacks an open port returns a RST with a non-zero window while a closed port returns a zero window, letting Nmap distinguish open from closed where a plain ACK scan could only say unfiltered. The catch is that this depends entirely on quirks of the target's TCP implementation, so it is unreliable across the board and produces plenty of false results on stacks that do not exhibit the behavior. Treat it as a situational tool, not a primary scan.
Maimon scan: the FIN/ACK BSD quirk
The Maimon scan, -sM, sets both the FIN and ACK flags. By RFC 793 any host should answer such a probe with a RST regardless of port state, which would make it useless. Its author, Uriel Maimon, discovered that many BSD-derived stacks break the rule and drop the packet silently on an open port while still sending a RST on a closed one, exactly the open|filtered versus closed split the FIN scan relies on. On modern hardware that quirk is rare, so Maimon is mostly a historical and niche technique, but it is worth recognizing in the family because it shows how scan types exploit specific stack behaviors rather than a single universal rule.
Which scan when
The family is large, but the decision is usually simple. Use this as your quick reference:
Key takeaways
The TCP scan family is a set of flag tricks, and the right choice depends on the target's stack as much as your goal. Use -sS as your everyday scan, -sT when you lack root, and -sA to map firewalls: all filtered points to a stateful device in the path, all unfiltered means the path is clear. The stealth scans (-sF, -sN, -sX) exploit RFC 793 and work cleanly on Unix-like hosts, where an open port stays silent (open|filtered) and a closed port sends a RST, but they fail hard on non-compliant stacks like Cisco IOS that RST every port and make genuinely open services look closed. Window and Maimon scans are situational tools built on specific stack quirks. When in doubt, cross-check a surprising result with a straight SYN scan. For the fundamentals behind these techniques see port scanning and, to turn firewall mapping into evasion, firewall and IDS evasion. For the full workflow and the rest of the cluster, start at the complete Nmap guide.
