Nmap can tell you a great deal about a network, which is exactly why your first scan should not be aimed at a random one.

A home lab gives Nmap a useful boundary. You know which systems belong to you, which services you intentionally started, and what should be reachable before the scan begins.

That changes the exercise from:

"What can I find?"

to:

"Does the network look the way I think I built it?"

That second question is much closer to real administration and troubleshooting.

This article stays deliberately small. You will discover hosts on one lab subnet, scan one host, inspect a few ports, ask Nmap to identify services, change something, and compare the results.

No Internet-wide scanning is required.

2. What Nmap Actually Does

Nmap stands for Network Mapper. The project describes it as a free and open-source utility for network exploration and security auditing, and administrators also use it for inventory, service discovery, and availability work.

Nmap actively sends probes and interprets the responses.

Depending on the options you choose, it can help answer questions such as:

  • Which hosts appear to be available?
  • Which TCP or UDP ports appear reachable?
  • Does a port look open, closed, or filtered from this location?
  • What service appears to be listening?
  • Does the behavior change after a firewall or service configuration change?

The phrase from this location matters.

Nmap's own port-scanning documentation emphasizes that a port state describes how Nmap sees the target from the scanner's position. The same service can appear open from one network and filtered from another.

That makes Nmap especially useful in a lab with VLANs, firewalls, or multiple test systems. You can change where the scan originates and see whether your policy behaves as intended.

Nmap is not a vulnerability verdict. An open port is not automatically a vulnerability, and a service label is not proof that the expected application is healthy.

Think of the result as another piece of network evidence.

3. Keep the First Lab Local and Authorized

Nmap's legal guidance recommends obtaining authorization before scanning networks you do not control.

For this article, keep the scope simpler:

Scan systems you own, administer, or have explicit permission to test.

A good first environment is:

  • A host-only or isolated virtual network
  • Two or three virtual machines
  • A spare computer and a virtual machine on a home-lab segment
  • A dedicated lab VLAN you control

Avoid copying an example subnet and assuming it belongs to your lab.

Private IPv4 address space is used by millions of unrelated networks. 192.168.50.0/24 is a useful example here because it is easy to read, not because every reader should scan it.

Also remember that a home Internet connection can contain equipment or services managed by an Internet service provider. "It is in my house" is not always the same as "I administer every system represented by this address."

The cleanest learning target is a lab you created yourself.

4. Install and Verify Nmap

Use the official Nmap download page for installers and platform guidance.

On Windows, the Nmap project provides a self-installer and offers Npcap during installation. Npcap gives Nmap the packet-capture and packet-sending capabilities used by several scan techniques.

After installation, open Command Prompt and run:

nmap --version

You should see the installed Nmap version and build information.

The project also provides the Zenmap graphical interface. A GUI can be useful, but this article uses the command line because a short command is easy to repeat, document, and compare later.

You do not need to learn dozens of flags before the first scan.

5. Find the Lab Subnet First

Before asking Nmap to scan a network, identify exactly which network you intend to scan.

On a Windows system connected to the lab, run:

ipconfig

Find the adapter connected to the lab and note:

  • IPv4 address
  • Subnet mask
  • Default gateway, if the lab uses one

Suppose the lab host has:

IPv4 address: 192.168.50.10
Subnet mask: 255.255.255.0

That mask corresponds to /24, so the network is:

192.168.50.0/24

If you are not comfortable converting a mask to a prefix or identifying the network address yet, use the Cert Happens IPv4 subnet calculator to verify your work.

Do that before the scan.

A subnet calculator is more useful when it keeps you from scanning the wrong network than when it merely confirms an answer after the fact.

6. Discover Hosts Without a Port Scan

Start by asking which systems appear to be available on the lab subnet:

nmap -sn 192.168.50.0/24

The -sn option tells Nmap to perform host discovery and not continue into a port scan.

It is often called a ping scan, but that name can be misleading. Nmap's host-discovery process can use several probe types, and on a local Ethernet network it normally uses Address Resolution Protocol (ARP) or IPv6 Neighbor Discovery where appropriate.

A result may show entries such as:

Nmap scan report for 192.168.50.10
Host is up.

Nmap scan report for 192.168.50.20
Host is up.

Depending on the platform, privileges, and local network, Nmap may also show a Media Access Control (MAC) address or vendor information.

The useful questions are:

  • Which addresses responded?
  • Did you recognize each system?
  • Is a VM missing that you expected to see?
  • Is a system present that you forgot was running?

Do not treat a missing host as proof that it is powered off. Firewalls and discovery behavior can affect what Nmap sees.

The point of this first step is inventory, not certainty.

7. Scan One Lab Host

Choose one target that you know belongs to the lab.

For example:

nmap 192.168.50.20

A plain nmap <target> performs host discovery and then scans Nmap's most commonly used 1,000 TCP ports on a host it determines is up.

That is an important detail.

The default scan does not mean "scan every possible TCP port." TCP port numbers run through 65535, while Nmap's default selection focuses on the most commonly used ports in its services database.

A simplified result might look conceptually like this:

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

Do not memorize the example as a desired result. Your target should reflect the services and firewall rules you actually configured.

Also notice the SERVICE column. For a normal port scan, Nmap can associate a common service name with a port number. That is a useful hint, but a process can listen on an unusual port and a familiar port can host something unexpected.

If you want Nmap to actively investigate what service is responding, use version detection later in the workflow.

8. Read Open, Closed, and Filtered

Nmap recognizes six port states. For a first lab, concentrate on the three you will see most often.

State What it means from this scan point Useful next question
open An application is accepting connections or traffic on that port. Is this service supposed to be reachable from here?
closed The host is reachable, but Nmap did not find an application accepting connections on that port. Should a service be running, or is closed the intended result?
filtered Nmap cannot determine whether the port is open because packet filtering prevents the probes or responses from giving a clear answer. Is a firewall, access list, or another network control affecting this path?

Nmap also reports unfiltered, open|filtered, and closed|filtered in situations where the scan technique cannot make a more specific determination.

The biggest beginner mistake is treating filtered as another word for closed.

It is not.

Closed means Nmap received enough information to conclude that no service is accepting the relevant traffic. Filtered means the network path prevented Nmap from making that determination.

That difference is exactly why running the same scan from two lab segments can be educational.

9. Ask About Specific Ports

Once you know what question you want to answer, make the scan smaller.

If your lab target is supposed to provide Secure Shell (SSH), HTTP, and HTTPS, scan only those common ports:

nmap -p 22,80,443 192.168.50.20

The -p option overrides the default port selection.

You can also test one port:

nmap -p 8000 192.168.50.20

That is useful when you intentionally start a lab service on port 8000 and want to check whether it is reachable.

Use the Ports and Protocols reference when you need context for a common port number, but keep one distinction clear:

A port number suggests the service that commonly uses it. The actual application still needs to be verified.

Scanning the exact ports related to your change also makes before-and-after results easier to compare.

10. Identify Services With -sV

Nmap's service and version detection sends additional probes to open or potentially open ports and tries to determine what is actually responding.

Use:

nmap -sV -p 22,80,443 192.168.50.20

The -sV option can identify details such as:

  • Service protocol
  • Application name
  • Version information when exposed
  • Device or operating-system clues in some responses

This is more informative than assuming that port 80 must contain one particular web server simply because 80/tcp is commonly associated with HTTP.

Version detection is still evidence, not magic.

Applications can hide information, proxies can sit in front of services, banners can be customized, and Nmap may not get a confident match.

A useful workflow is:

  1. Find the port.
  2. Ask what Nmap thinks is running there.
  3. Check the target's actual configuration or service manager.
  4. Investigate disagreements instead of automatically trusting either side.

That is much more useful than collecting version strings for their own sake.

11. Understand -Pn and -A Before Using Them

Two Nmap options appear constantly in tutorials. Neither needs to be your default.

-Pn: skip host discovery

If a known lab host is up but ordinary host discovery does not identify it, you may see advice to add -Pn:

nmap -Pn -p 443 192.168.50.20

-Pn tells Nmap to skip host discovery and treat the target as online for the requested scan.

It does not bypass a firewall.

It does not make a filtered service reachable.

And when you specify a large target range, -Pn causes Nmap to attempt the requested scanning work against every target address because it is no longer using discovery to narrow the list first.

Use it deliberately on a known lab target when you have a reason.

-A: several advanced features at once

Nmap's -A option currently enables:

  • Operating-system detection
  • Service/version detection
  • Default Nmap Scripting Engine scripts
  • Traceroute

That makes -A convenient, but it also hides several different questions behind one letter.

For a beginner, this is usually better:

nmap -sV -p 22,80,443 192.168.50.20

than reaching immediately for:

nmap -A 192.168.50.20

Learn what each feature contributes first. Nmap's own documentation notes that the default script scan enabled by -A can be intrusive and should not be used against target networks without permission.

A home lab is the right place to explore advanced options later because the extra traffic and results have context.

12. Pair Nmap With Wireshark

Nmap and Wireshark answer different questions.

Nmap sends probes and interprets the responses. Wireshark shows you packets visible at the capture point.

That makes them useful together.

Start a Wireshark capture on the scanner or another authorized capture point, then run a small Nmap scan against one lab host:

nmap -p 22,80,443 192.168.50.20

In Wireshark, a display filter such as:

ip.addr == 192.168.50.20

can reduce the capture to traffic involving that host.

Now Nmap output stops being a mysterious table produced by a scanner. You can compare it with the packets that generated the result.

Questions to explore:

  • What traffic did host discovery send?
  • What did an open port return?
  • How did a closed port respond differently?
  • What happened when a firewall caused a port to appear filtered?
  • Did the scan technique change when Nmap ran with different privileges or options?

The Wireshark beginner article walks through the packet-analysis side of that exercise.

This pairing is one of the fastest ways to understand that a scan result is derived from network behavior, not pulled from a hidden database of answers.

13. Change Something and Scan Again

The most useful Nmap lab is not a single scan. It is a controlled comparison.

Experiment 1: start and stop a service

If the target has Python installed, you can intentionally start a basic web server on the target system:

python -m http.server 8000

From the scanner, check that port:

nmap -p 8000 192.168.50.20

Stop the web server and run the same Nmap command again.

You have now created a simple before-and-after experiment where you already know why the result should change.

Experiment 2: change a firewall rule

On a lab target you control:

  1. Confirm the service is listening.
  2. Scan the service port from the allowed network.
  3. Apply a firewall rule that blocks the test path.
  4. Run the same Nmap command again.
  5. Restore the rule when the exercise is complete.

Depending on the firewall behavior, Nmap may report a different state or fail to receive the response you expected.

Experiment 3: scan from another VLAN

If your lab has multiple VLANs, run the same small scan from two authorized segments.

A management service might be open from the trusted or management VLAN and filtered from a guest or IoT VLAN.

That is much more educational than merely reading that firewall policy controls traffic between networks.

You built the policy, tested it from both sides, and collected evidence of the difference.

14. Save the Evidence

Nmap can write its normal output to a file with -oN.

For example:

nmap -oN before.txt -p 8000 192.168.50.20

Make your controlled change, then run:

nmap -oN after.txt -p 8000 192.168.50.20

Now you have two small artifacts you can compare.

For a learning log or portfolio project, record:

  • What you expected before the scan
  • Exact target and scan scope
  • Nmap command used
  • Relevant result
  • Configuration change
  • Result after the change
  • Your explanation for the difference

Sanitize addresses or other environment details before publishing anything that should remain private.

A page full of Nmap output is not documentation by itself. The useful part is explaining what question the scan answered.

15. A Repeatable Nmap Lab Workflow

When you want to practice without turning Nmap into a flag-collecting exercise, use this sequence:

  1. Define the boundary. Identify the exact lab systems or subnet you are authorized to scan.
  2. Predict the result. Which hosts and services should be reachable?
  3. Discover hosts lightly. Use -sn when you want inventory without a port scan.
  4. Choose one target. Do not expand scope until you understand the small result.
  5. Scan the ports that matter. Use -p when a specific service or change is the question.
  6. Interpret the state. Open, closed, and filtered describe different evidence.
  7. Use -sV when identity matters. Ask what service appears to be responding instead of trusting the port number alone.
  8. Change one thing. Start a service, stop it, modify a lab firewall rule, or move the test across a VLAN boundary.
  9. Run the same scan again. Keep the command stable so the network change is the meaningful variable.
  10. Save and explain the result. Write down what the scan proved and what it did not prove.

The Free Tools and Resources article can help you build the rest of the toolkit around this workflow. Use Nmap to ask active network questions, Wireshark to inspect packet behavior, Ports and Protocols for quick context, and the subnet calculator to verify the scope before scanning.

The goal is not to make Nmap produce more output.

The goal is to make each scan answer a question you understand.

16. Official References

Free Tools and Resources Worth Knowing as an IT or Cybersecurity Student Build a useful free toolkit for learning, packet analysis, threat research, and technical reference work. Wireshark for Beginners: What to Look for in Your First Packet Capture Capture traffic you intentionally create and learn to follow requests, responses, connections, and protocol fields. How to Build IT Experience With a Home Lab Without Buying a Rack of Hardware Create a safe environment where you can build, break, observe, and document technical systems. Why Use VLANs at Home? Learn how logical network boundaries change reachability and where firewall policy can apply.
Ports and protocols Check common ports, transport protocols, purposes, and related details while interpreting scan results. IPv4 subnet calculator Verify the network range you intend to scan before sending probes to it. Network+ resources Review network discovery, troubleshooting, ports, protocols, and related certification concepts. CCNA resources Connect host discovery and reachability testing to switching, routing, services, and access-control concepts.