Nmap Network Scanning: Commands, Port States, and Safe Diagnostics

NETOPS TOOLS · NETWORK DIAGNOSTICS GUIDE

See the network clearly. Scan only what you are authorized to test.

A practical introduction to Nmap host discovery, TCP scanning, port states, version checks and well-scoped diagnostic reports.

Host discovery-snFind responding hosts

TCP connect scan-sTTest selected TCP ports

Service detection-sVIdentify responsive services

Network administrators use Nmap (Network Mapper) to help inventory hosts, assess reachable services and verify whether filtering rules behave as expected. The results describe what Nmap can observe from a particular location at a particular time; they do not, by themselves, prove that a system is secure or vulnerable.

Authorization first. Run Nmap only against systems you own or are expressly permitted to test. Agree on target IPs, approved techniques, maintenance windows, contacts and expected scan impact before starting. Examples below use a fictional private laboratory network; replace it only with your authorized scope.

1. How does an Nmap scan work?

Nmap can discover hosts, test ports, identify selected services and produce a report. Those are related but distinct activities: finding a host does not mean its application ports are open, and finding an open port does not guarantee an application is usable or properly configured.

1. ScopeChoose authorized IPs and objectives

2. DiscoverIdentify hosts with approved probes

3. Check portsInspect specific TCP or UDP services

4. InterpretDistinguish open, closed and filtered

5. ReportKeep commands, timestamps and findings

Host discoveryAnswers: which addresses appear to respond to discovery probes?

Port scanAnswers: what state does a port appear to have from this vantage point?

Version detectionAnswers: can service probes identify the software or protocol?

By default, a basic nmap target invocation scans the 1,000 most commonly selected TCP ports, not every port. To reduce unnecessary probing in a production environment, start with the smallest approved target and port set that answers your question.

2. Host discovery: when to use -sn and -Pn

-sn performs host discovery without the normal subsequent port scan. This can help confirm whether approved devices respond, although firewalls and host policies can prevent responses. It is not the same thing as checking every TCP or UDP service.

Laboratory example — host discovery only

nmap -sn -n 192.168.56.0/28

Private example network only. The /28 prefix covers 16 IPv4 addresses, including network and broadcast addresses; Nmap processes the supplied targets according to its discovery rules.

What if a host does not answer discovery? -Pn skips the normal host-discovery stage and treats specified targets as candidates for the requested scan. That can be helpful for a small known host behind filtering, but it does not make that host reachable. Across a large range, it can increase the scan duration and network activity substantially.

Practical rule: use -sn to ask which approved hosts respond. Reserve -Pn for a known, narrowly defined target when the discovery result is inconclusive.

3. TCP SYN, TCP connect and UDP scans

Method	Option	What it does	Planning note
TCP connect	`-sT`	Uses the operating system’s connection interface to test TCP ports.	Useful in constrained environments; may create connection logs.
TCP SYN	`-sS`	Sends TCP SYN probes without completing the normal application connection on open ports.	Generally requires raw-packet privileges; not guaranteed invisible.
UDP	`-sU`	Tests UDP ports; missing responses can leave uncertainty.	Can be comparatively slow; scope UDP targets and ports carefully.
Host discovery	`-sn`	Identifies hosts without the usual port scanning step.	Some active hosts may not respond.
Version detection	`-sV`	Sends additional probes to learn about detected services.	More interaction with services; verify suitability first.

A TCP connect scan explicitly uses the network stack’s connection function, while SYN scanning depends on packet capabilities and privileges. Neither approach should be described as universally undetectable. UDP is different: no response may mean that a port is open but silent, or that a firewall discarded the probe.

4. What do Nmap port states actually mean?

Nmap reports a state observed during a scan, not an immutable property of a port. For example, port 443 may appear open from an approved internal VLAN and filtered from another network segment. Both observations can be correct.

State	Interpretation	Possible next step
open	A network service appears to be accepting the type of communication probed.	Verify the expected owner and service.
closed	The port is reachable, but no service appears to be listening.	Compare with the documented service inventory.
filtered	Filtering prevents a definitive open/closed determination.	Review firewall policy and approved network vantage point.
open\|filtered	Nmap cannot distinguish an open but silent service from filtering.	Consider protocol behavior; common with UDP.
unfiltered	Accessible, but the selected scan cannot distinguish open from closed.	Use an appropriate authorized method if necessary.
closed\|filtered	The chosen technique cannot distinguish closed from filtered.	Record the ambiguity; do not infer a definite state.

open ≠ vulnerableAn open port does not establish a security flaw. Assessment requires context.

filtered ≠ closedA firewall may hide the actual state from the scanning location.

service ≠ certaintyPort numbers and version fingerprints can be incomplete or misleading.

5. Three practical Nmap commands for an authorized lab

The following commands are illustrative; no live scan was performed for this guide. The lab host 192.168.56.10 is a placeholder within a private-address range and might not exist on your network.

Example A — discover lab hosts

Host discovery

nmap -sn -n 192.168.56.0/28

The -n option disables reverse-DNS lookups. Nmap still sends discovery probes according to environment and privileges; the result is not guaranteed to list every active device.

Example B — inspect three approved TCP ports

Selected TCP ports

nmap -sT -p 22,80,443 192.168.56.10

This tests exactly three TCP port numbers on one lab host. It is often enough to answer a focused operational question such as whether expected SSH, HTTP and HTTPS listeners are reachable from the scanner’s network segment. An unrecognized service can run on any port, so the familiar port number alone is not proof of service identity.

Example C — request service identification and save a report

Version probes + a local record

nmap -sT -sV -p 22,80,443 -oN lab-scan.txt 192.168.56.10

-sV performs additional service-detection interaction on ports selected by the scan. -oN lab-scan.txt saves normal-format output into a local text file. The command records observations; it does not audit application configuration or prove exposure to a vulnerability.

How to read a report

Illustrative sample output — not measured results

PORT    STATE     SERVICE
22/tcp  filtered  ssh
80/tcp  open      http
443/tcp closed    https

Fictional demonstration of states, not an actual scan of 192.168.56.10.

Here, 80/tcp open means Nmap observed a listening service from its vantage point. 22/tcp filtered does not prove SSH is disabled, and 443/tcp closed describes the scan result at that moment.

6. Understanding service detection, OS guessing and saved output

Option	Purpose	What to keep in mind
`-p 22,80,443`	Tests an explicit, limited port list.	Specify only the approved ports for the task.
`-sV`	Attempts to identify service names and versions.	Uses active probes and may be inconclusive.
`-O`	Attempts OS fingerprinting.	A best-effort guess, not guaranteed identification.
`-Pn`	Skips ordinary host discovery.	May scan each specified address even if unreachable.
`-oN file.txt`	Writes a human-readable scan record.	Protect the file as network infrastructure information.
`--reason`	Displays the basis for host and port state choices.	Useful for troubleshooting uncertainty.
`-A`	Enables several advanced features together.	Broader scope and potential impact; not a routine first step.

A service response may help Nmap infer software, but a reverse proxy, banner configuration, network policy or incomplete signature can affect that result. Validate important findings with your asset owners and configuration records. Use advanced probes only when they are needed and authorized.

Production equipment caution: embedded controllers, printers, CCTV devices, access-control readers and legacy services may react differently to active probes. Coordinate approved tests with the owner and prefer carefully limited port checks before considering service detection or broader options.

7. Use the NetOps Nmap Command Generator

The NetOps Nmap Command Generator helps build Nmap command syntax using a target field, scan-type choice and options such as service-version and OS detection. It generates text for review; it does not establish permission, remotely scan a target on your behalf or independently verify results.

1Identify scopeOne approved device or defined subnet

2Choose scanSelect an appropriate discovery or port method

3Review optionsCheck probes, privileges and impact

4Copy commandInspect the entire resulting syntax

5Run and recordExecute Nmap only in the approved environment

Generator vs. scanner: our web tool helps assemble commands. To execute them you need a suitable Nmap installation, network access, permissions and the target owner’s authorization.

8. A low-impact network diagnostics checklist

Define the owner and approvalDocument authorized targets and contacts before testing.

Start with a minimal scopeOne device, a few ports, a clear operational question.

Choose appropriate timingAvoid business-critical windows and sensitive devices without coordination.

Know the network vantage pointInternal and external results can differ due to ACLs and firewalls.

Record exactly what was runKeep command, time, source IP and relevant environment details.

Treat inconclusive states honestlyFiltered does not mean closed; absence of reply does not always mean offline.

Protect scan reportsHostnames and service lists may reveal sensitive infrastructure information.

Verify before remediationConfirm ownership, intended service and change-control requirements.

9. Common Nmap interpretation mistakes

Assuming no ping reply means no host: host discovery can be limited by filtering or host policy.
Treating filtered ports as closed: a firewall may prevent a reliable conclusion.
Calling SYN scanning invisible: network and endpoint controls may still log or detect probes.
Scanning every port when three are enough: larger scans increase time and operational exposure.
Treating an open port as a vulnerability: exposure assessment requires service context and validation.
Assuming a service fingerprint is definitive: banners, proxies and protocol behavior can distort identification.
Running advanced scanning without approval: even standard tools can impact sensitive operational technology.

10. Frequently asked questions

What is the difference between -sn and -sT?

-sn performs host discovery without the regular port scan. -sT uses operating-system TCP connection attempts to test ports on target hosts. They answer different diagnostic questions.

Does -Pn mean the host is reachable?

No. It makes Nmap skip its normal discovery stage and attempt the requested work on listed targets. An unreachable host does not become reachable simply because -Pn was specified.

Are closed and filtered ports the same?

No. A closed port is reachable but appears to have no listening service. A filtered state means probes or replies were blocked enough that Nmap cannot determine whether the port is open or closed.

Does -sV identify every version correctly?

No. Version detection depends on application responses and available signatures. Software behind proxies or custom configurations may be identified incompletely or inaccurately.

Can I scan a website or public IP without permission?

Do not assume that publicly accessible means authorized for testing. Obtain explicit permission, understand provider policies and follow applicable law and change-control requirements.

Does the NetOps generator actually run Nmap?

No. It helps compose command-line syntax. You must independently review and execute commands in an environment where you have authorization.

Build your next authorized Nmap command

Choose the smallest approved scope, generate a command and verify each option before running it. For network sizing, use the separate IPv4 Subnet Calculator.

Open Nmap Command Generator Open IPv4 Subnet Calculator

Technical references

Nmap Project — Port Scanning Overview (default behavior and port states).
Nmap Project — Host Discovery (-sn and -Pn behavior).
Nmap Project — TCP Connect Scan (-sT).
Nmap Project — Service and Version Detection (-sV).
Nmap Project — Normal Output (-oN).
Nmap Project — Script Usage and Safety Considerations (why advanced scripting needs review).

Last reviewed: October 27, 2026 · Developed and maintained by: NetOps Tools. Examples are educational and assume express authorization. No scans were performed to create the sample outputs. Nmap is an independent open-source project; this guide and the NetOps generator are not an official Nmap service.