Validate Network Segmentation with Nmap

Admin

October 7, 2026

8 min read

An asset-discovery scan asks which systems and services exist. A segmentation check asks whether a specific source zone can reach only the destination ports its policy permits. Compare results from approved test points against a written access matrix, then correlate unexpected results with firewall logs.

Define Source, Destination, and Allowed Ports

Scope

Before scanning, list the exact source test host, destination host, protocol, and expected result for each path. Use RFC documentation addresses in notes only; replace the example target in commands with an approved lab or organization address before running them.

Source zone     Destination     Ports       Expected
App-Test        App-Server      TCP 443     Allowed
User-Test       App-Server      TCP 443     Denied
User-Test       App-Server      TCP 22      Denied
Example target  192.0.2.25      Documentation-only; do not scan

Check the Scanner Before Sending Probes

Preflight

Run Nmap from a host actually located in the source zone being tested. Confirm the scanner IP and route with the network owner, check Nmap is installed, and create a protected results directory. A test from the wrong VLAN does not validate the intended firewall path.

nmap --version
ip address
ip route
umask 077
# Reserve a new private directory; do not overwrite an earlier scan's evidence.
mkdir -m 700 results || { echo 'Results directory already exists; choose a fresh path.' >&2; exit 1; }

Run a Limited TCP Connect Scan

Controlled Scan

Replace the documentation-only target with the exact approved host. This command disables DNS lookups and host discovery, uses a TCP connect scan, limits probes to ports 22 and 443, and saves normal, XML, and grepable output. It does not run vulnerability scripts or scan a subnet.

TARGET='192.0.2.25'  # Replace only with the approved test host.
nmap -n -Pn -sT -p 22,443 --reason -oA results/app-from-user-test "$TARGET"

❯ Illustrative Output (Results Vary)

PORT    STATE     SERVICE  REASON
22/tcp  filtered  ssh      no-response
443/tcp filtered  https    no-response
Example only; the target and path determine actual results.

Compare Results with the Written Policy

Compare Paths

Run the same limited scan from each authorized source test point, using a distinct output basename for each one. Here, run the second command from the approved App-Test host after setting TARGET to the approved App-Server address. Compare each observed state with the matrix. open means a TCP connection was accepted, closed means the host responded but no application was listening, and filtered means Nmap could not determine the state because probes were filtered or unanswered.

nmap -n -Pn -sT -p 22,443 --reason -oA results/app-from-app-test "$TARGET"
grep -E '22/tcp|443/tcp' results/app-from-user-test.nmap
grep -E '22/tcp|443/tcp' results/app-from-app-test.nmap

Correlate Scan Results with Firewall Logs

Evidence

A filtered result alone does not prove a firewall rule blocked the traffic; packet loss, routing, host firewalls, and scanner placement can produce similar observations. Compare Nmap timestamps with firewall logs and service health checks. Escalate unexpected open ports or unexpected outages to the owners before changing policy.

Nmap XML: results/app-from-user-test.xml
Nmap normal output: results/app-from-user-test.nmap
Change ticket: [approved test or incident reference]
Firewall log correlation: [timestamp and rule]