Scan your own public IP from the outside with Nmap
A practical perimeter check you can run today: find the correct public address, scan it from a genuinely external network, understand every result, fix exposure, and prove the change.
Scope
For home users and small organisations testing only public IPv4 or IPv6 addresses they own or are explicitly authorised to assess.
Start with the situation, not the slogan
This lab is designed to produce evidence and judgement, not a ceremonial screenshot of a tool running. Scan your own public IP from the outside with Nmap is successful when you can explain the question, predict the expected observation, collect it safely and distinguish a useful result from noise. The commands are the least interesting part, although they are traditionally the part everyone photographs.
Use systems you own or have explicit permission to test. Keep the exercise isolated from household, client and production networks, take a snapshot before deliberate breakage, and write the rollback step before the first change. A lab without a reset path is simply a future troubleshooting appointment.
An internal scan shows the private side of the router. An external Nmap scan shows what the internet-facing path answers from that particular vantage point. It can reveal open services and filtering, but it cannot prove that an application is patched, safe, or unreachable from every network.
Composite scenario
How this usually reaches the desk
Set one modest objective for the session. Begin with the expected clue: The public address is confirmed independently and distinguished from a private router address or carrier-grade NAT. Then create or collect only enough benign activity to make that clue visible. If the observation does not appear, investigate the data path before adding more tools. Instrumentation that cannot see a known test event will not become more perceptive during a real incident.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
The public address is confirmed independently and distinguished from a private router address or carrier-grade NAT.
Write the expected observation before the exercise. Include the source, destination, time and field that should carry it; this turns an interesting screen into a falsifiable test.
The scan originates from a separate internet connection or controlled remote host, not from behind the router being tested.
Confirm that clocks, names and identifiers line up across the lab. Time drift and ambiguous hostnames can turn three tidy events into an accidental detective novel.
Every open port has an expected service, named owner, business reason, source restriction, patch status, and removal date if temporary.
Keep a known-good comparison. The aim is not merely to produce an alert or packet, but to explain how the test differs from ordinary activity and where false positives would arise.
Do it today
The test: what does your address answer from the internet?
We are not “hacking the router”. We are asking a narrower and much more useful question: from one genuinely external connection, which TCP ports on an address we own answer, which appear filtered, and which service seems to be listening? That gives us a perimeter observation we can compare with the intended firewall and port-forwarding configuration.
Use only an address and service you own or have explicit written permission to test. “It is my public IP” is not always sufficient: a CDN, reverse proxy, shared hosting platform or CGNAT address may belong operationally to somebody else. If the scanner runs from a VPS or cloud account, check that provider’s acceptable-use and penetration-testing policy as well as the target provider’s terms; some providers require notice, a support ticket, a named source IP, rate limits or a defined testing window even for authorised work. Cross-border testing can add legal duties. This is practical scoping guidance, not legal advice.
The examples use 203.0.113.25 and 2001:db8::25, addresses reserved for documentation. They are stage props, not targets. Replace them only after recording the owner, target, source IP, date, permitted techniques, emergency contact and stop condition.
Find the public address. From the network being tested, visit the router status page and a reputable “what is my IP” service, or use curl -4 https://api.ipify.org. On PowerShell, (Invoke-RestMethod -Uri "https://api.ipify.org").Trim() does the same job. Write down the result and time.
Compare it with the router’s WAN address. If the router shows a private address such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or the shared carrier range 100.64.0.0/10, you may be behind upstream NAT or CGNAT. CGNAT is common on mobile broadband in Latvia and across the Baltics, and may also appear on some fixed-access plans. Do not assume the ISP name or connection type settles the question: compare both addresses and ask whether a dedicated public IPv4 is available. Scanning a shared address may test provider infrastructure rather than your router.
Move the scanner outside. Put a laptop on a phone hotspot, use a second site, or use a small remote machine you control. Do not test from the LAN and call it external: NAT loopback can give a different answer, and some routers refuse the experiment out of principle.
Confirm the address again. Dynamic addresses can change between making tea and opening a terminal. Confirm immediately before the scan and stop if the target is no longer yours.
Baseline command
One sensible scan before lunch
# Run this on a laptop using a different connection, or on a remote host you control.
# 203.0.113.25 is documentation space: replace it with YOUR confirmed public IP.
nmap -Pn -sT --top-ports 1000 --reason \
-oA perimeter-2026-08-18 203.0.113.25-PnSkip host discovery and scan the address even if ping probes are blocked. “Host is up, received user-set” therefore reflects your instruction, not proof that an ICMP reply arrived.
-sTUse a TCP connect scan. It works without raw-packet privileges and makes this first run consistent across ordinary machines. It completes real TCP connections, so your logs may quite properly notice it.
--top-ports 1000Check the 1,000 TCP ports Nmap ranks most commonly used. It is a strong first pass, not every possible port. We deliberately begin bounded and expand only when needed.
--reasonShow why Nmap assigned a state—perhaps a reset, a successful reply, or no response. This is far more useful than accepting a coloured word as revelation.
-oA nameSave normal, XML and grepable-format output under one basename. XML is useful for comparison and automation; the normal text remains pleasant for humans and printers with excellent self-esteem.
203.0.113.25The single authorised target. Avoid pasting a hostname until you understand every address it resolves to, especially when a CDN or hosting provider may own the result.
Do not begin with -A, every NSE script, maximum speed and an entire subnet. Nmap is a toolbox, not a loyalty programme: collecting every option does not earn points. The baseline should answer which common TCP ports are reachable without producing needless load or muddying the question.
Read the result
Open, closed and filtered are observations, not moral judgements
Nmap scan report for 203.0.113.25
Host is up, received user-set.
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
80/tcp closed http reset
443/tcp open https syn-ack
8291/tcp filtered winbox no-response
Nmap done: 1 IP address (1 host up) scannedIn the example, SSH and HTTPS deserve an owner and a reason. Port 80 is closed: it answered with a reset but has no listener. Winbox appears filtered from this source, which may match a firewall rule that permits management only through VPN. The word SERVICE is initially based largely on conventional port numbers; a line saying ssh is not yet proof that OpenSSH—or any particular version—is present.
Run service detection only against the ports you found and own:
# Investigate only the TCP ports found open in the baseline.
nmap -Pn -sT -sV --version-light \
-p 22,443,8291 --reason \
-oA services-2026-08-18 203.0.113.25
# If HTTPS is yours, inspect the presented certificate and offered TLS ciphers.
nmap -Pn -sT -p 443 \
--script ssl-cert,ssl-enum-ciphers \
-oA tls-2026-08-18 203.0.113.25-sV sends service-specific probes and may identify an application and version. --version-light uses a lighter probe intensity. Treat the result as an identification lead, not a vulnerability verdict: banners can be hidden, misleading or different from the installed patch level. Confirm on the router, server or application itself.
Decision table
What is not all right—and what to improve
Telnet 23, plain FTP 21 or an accidental database
These are rarely sensible on a home or small-office public address. Disable the service or port forward. Replace legacy protocols with an encrypted, authenticated alternative. A public database, SMB, RDP or management panel deserves immediate confirmation and usually immediate restriction.
SSH 22 or MikroTik Winbox 8291
If remote management is genuinely required, prefer a VPN and a trusted management network. Otherwise restrict source addresses, use key-based or strong authentication, remove defaults, patch promptly, rate-limit sensibly and monitor logins. Moving the port reduces noise, not risk.
HTTP 80 and HTTPS 443
Port 80 may exist only to redirect to HTTPS; prove that it does. For 443, inspect the certificate and ciphers, patch the web stack and review the application itself. A good TLS configuration cannot make an exposed admin panel a good idea.
Everything expected
“Expected” still needs a named owner, purpose, update path, logs and a retirement trigger. An intentional port with an abandoned appliance behind it is merely an accident that completed paperwork.
Check the router’s port forwards, UPnP mappings, VPN configuration and input rules, then check the listening process on the destination host. Cloud firewalls, provider controls and container publishing can create additional layers. Remove the exposure at the authoritative layer rather than stacking a temporary rule somewhere everyone will forget.
Vulnerability triage
An open port is exposure. A CVE needs considerably more evidence.
Nmap’s first answer is reachability. Service detection adds a product or protocol lead. A vulnerability decision requires the actual product, installed package or firmware build, affected configuration, reachable feature and a primary advisory. Keep those conclusions separate in the case record:
443/tcp openA TCP listener accepted the external connection.Identify the owner, reverse proxy, application and reason for public exposure.-sV resultA best-effort service fingerprint or banner.Confirm the installed package, container digest, appliance firmware and backported security fixes locally.For a Linux SSH result, confirm the package rather than trusting a banner:
# Debian or Ubuntu
dpkg-query -W -f='${Package} ${Version}\n' openssh-server
apt-cache policy openssh-server
# RHEL, Fedora or Rocky Linux
rpm -q openssh-server
dnf updateinfo list --security openssh-serverDistributions often backport security fixes without changing the upstream-looking banner in the way a scanner expects. Compare the installed package release with the distribution security notice or vendor advisory. For containers, identify the immutable image and scan that exact build:
docker inspect --format='{{.Config.Image}} {{.Image}}' CONTAINER_NAME
trivy image --severity HIGH,CRITICAL --ignore-unfixed YOUR_IMAGE@sha256:YOUR_DIGESTFor TLS configuration on a service you own, the targeted Nmap scripts ssl-cert and ssl-enum-ciphers are more intelligible than throwing the whole script cupboard at it. Before any NSE script, read its description and categories with nmap --script-help SCRIPT_NAME. Nmap’s vuln category is not a harmless “find problems” switch: NSE also includes intrusive, exploit, brute-force and denial-of-service scripts, scripts are not sandboxed, and some default scripts are considered intrusive. Do not run --script vuln, -A or third-party scripts blindly against production.
Unexpected exposure
If nobody owns the port, treat it as an incident lead
Do not immediately launch more aggressive probes at a service nobody recognises. First preserve the external Nmap output and identify the internal listener, port forward, container or router service through local control-plane evidence:
# Linux: listener, process and executable lead
sudo ss -lntup
sudo readlink -f /proc/PID/exe
# Windows PowerShell: listener and owning process
Get-NetTCPConnection -State Listen | Sort-Object LocalPort
Get-Process -Id PID | Select-Object Id,ProcessName,Path,StartTime
# Docker: host bindings
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
# MikroTik RouterOS: forwards, UPnP and router services
/ip firewall nat print detail where action=dst-nat
/ip upnp mappings print
/ip service print detailAn undocumented but legitimate service should still acquire an owner, purpose, patch path and logging. Escalate to incident response when the port is new and accompanied by an unknown process or container, new privileged account, unfamiliar remote administration tool, unexplained outbound connection, suspicious login, disabled security control or unapproved configuration change. Block or restrict the exposure at the perimeter when that can be done safely, preserve volatile state and logs, and follow the web-server compromise playbook or the Linux compromise guide. Rebooting first may remove the listener and the evidence while leaving stolen credentials perfectly employed elsewhere.
Second pass
Catch the things the first command deliberately missed
# Full TCP range: slower, but catches services outside the common 1,000 ports.
nmap -Pn -sT -p- --reason -oA all-tcp-2026-08-18 203.0.113.25
# A deliberately small UDP sample. Administrator/root rights are normally required.
sudo nmap -Pn -sU --top-ports 20 --reason \
-oA udp-2026-08-18 203.0.113.25
# IPv6 is a separate perimeter. Replace the documentation address with YOUR IPv6.
nmap -6 -Pn -sT --top-ports 1000 --reason \
-oA ipv6-2026-08-18 2001:db8::25A full TCP scan checks ports 1–65535. Run it during a suitable window, still against the one authorised address. The small UDP check is intentionally not -p-; UDP is slower and ambiguity is normal. Verify any interesting UDP result against the router and host rather than escalating punctuation.
IPv6 is not decorative IPv4. Devices can have globally reachable IPv6 addresses without the IPv4 port-forwarding model you expected. Identify your assigned prefix and actual device addresses, confirm authorisation, and scan only the intended target. Review the IPv6 firewall independently. “The IPv4 scan was clean” says nothing about a forgotten IPv6 management service.
A result of no open ports is encouraging but limited. It describes the tested address, protocols, ports, source network and time. It does not assess outbound compromise, web-application flaws behind port 443, cloud services on another address, a VPN-only path, or a service that was asleep. Write the boundary next to the conclusion.
GUI route
Zenmap, for the especially industrious sort of lazy
Zenmap is the official graphical front end and results viewer for Nmap. On Windows, the official Nmap self-installer offers Zenmap as an installation option. Open it on the external machine, put your confirmed single address in Target, and paste the baseline command into Command. Zenmap updates the profile controls, runs the same Nmap engine, and displays the ordinary output alongside Ports/Hosts and other views.
Nmap scan report for 203.0.113.25
PORT STATE SERVICE
22/tcp open ssh
443/tcp open https
8291/tcp filtered winbox- Install the current release only from the official Nmap site and leave the Zenmap option selected where offered.
- Enter your one authorised IP in Target. Do not select a convenient neighbouring range; your neighbour did not consent merely by owning an address.
- Paste
nmap -Pn -sT --top-ports 1000 --reason YOUR_IPinto Command, inspect it, then click Scan. - Use Ports / Hosts to review open and filtered ports. Choose Scan → Save Scan and save XML if you want Zenmap to open it again; the plain-text format cannot be reopened as a Zenmap scan.
- Create a profile for the bounded command if you will repeat it. Use Tools → Compare Results to compare the before and after scans; a new
+line is an addition and a-line is a removal.
The built-in “Intense scan” profile is broader than our first pass. It can be useful on a suitable authorised target, but choosing the most dramatic name because it sounds thorough is how a five-minute check becomes an afternoon of unexplained probes. The GUI removes typing; it does not remove scope, judgement or ownership.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Run a bounded authorised TCP baseline
- Prerequisites
- One public IP you own, written scope, and an external network; replace the documentation IP only after verifying ownership.
nmap -Pn -sT --top-ports 1000 --reason -oA perimeter-baseline 203.0.113.25Nmap classifies common TCP ports as open, closed or filtered and saves normal, XML and grepable output.
Open means a listener answered; it does not mean vulnerable. Filtered means the scan could not decide. Compare every open port with the intended inventory.
Run focused version detection only on expected or unexplained open ports, then confirm the process and package locally.
Identify one exposed service carefully
- Prerequisites
- A port found open in the baseline and permission for service probes.
nmap -Pn -sV --version-all -p 443 --reason -oA service-443 203.0.113.25Nmap reports a service fingerprint or best-effort product/version lead for TCP/443.
A banner can be hidden, proxied or backported. Never equate the printed string directly with a CVE match.
Confirm the product and package version on the server, then check the vendor advisory, supported version and CISA KEV/NVD record where applicable.
Check a web endpoint passively
- Prerequisites
- A website you own and approval for spidering; the baseline scan is passive after a short spider.
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://www.example.com -r zap-report.htmlZAP writes a report of passively observed warnings; by default alerts are warnings rather than automatic failures.
A warning is a configuration or application lead, not proof of exploitability. The baseline does not perform a full active security test.
Review each alert against the application, fix confirmed issues, rerun the same command, and retain both dated reports.
Lab procedure
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Keep a lab notebook with four columns: time, action, expected evidence and observed evidence. Add screenshots only when they preserve information that text cannot. The notebook should allow another person to repeat the exercise without inheriting your browser history, shell history and particular relationship with luck.
The transfer-to-production question matters more than the demo. For Nmap, Public IP and Perimeter, consider data volume, retention, credentials, privacy, performance, ownership and failure behaviour. A successful lab proves that a mechanism can work under stated conditions; it does not prove that it can be deployed everywhere before lunch.
Handover
Make the result useful to the next person
Turn the exercise into a reusable lab card. Record the learning objective, isolation boundary, diagram, versions, seed data, expected observations, exact queries, screenshots that add real information, and the reset procedure. Mark which evidence was generated and which was supplied. If the lab uses a deliberately vulnerable image or sample, store its provenance and checksum. Future-you is a different operator and deserves better documentation than “it worked after I restarted something”.
End with a short teach-back. Explain why “Confirm ownership and determine the public IPv4 and any public IPv6 address; compare them with the router WAN address before scanning.” matters, demonstrate the observation that supports the conclusion, and show how the environment returns to baseline after “Remove or restrict unnecessary exposure, patch expected services, repeat the same scan, and keep the before-and-after evidence.” Then name one production assumption the lab did not test. That last sentence keeps a useful experiment from turning into unjustified confidence and gives the next exercise a sensible place to begin.
Validate before you close
The check is complete when the scan was external and authorised, every exposed service is explained and safely configured, unnecessary ports are closed or restricted, IPv6 and UDP were considered, and a repeat scan proves the intended change.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Connecting an intentionally weak lab directly to a home or production network.
- Copying commands without recording the expected evidence and rollback step.
- Calling a test successful without comparing the result to a known-good baseline.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Can I run this against a public target for practice?
No. Keep the work to systems you own or are explicitly authorised to assess. An educational intention is not an access-control mechanism and will not improve the conversation with a provider or solicitor.
What should I save from the exercise?
Keep the topology, versions, raw evidence, exact filters or rules, expected result, observed result and rollback notes. Remove real secrets and personal data before sharing the notebook.
How do I know the lab worked?
The check is complete when the scan was external and authorised, every exposed service is explained and safely configured, unnecessary ports are closed or restricted, IPv6 and UDP were considered, and a repeat scan proves the intended change. Repeat the key observation from a clean snapshot; repeatability is a stronger result than a single attractive screenshot.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- Nmap Reference GuideNmap Project
- Port Specification and Scan OrderNmap Project
- Service and Application Version DetectionNmap Project
- Zenmap GUI User’s GuideNmap Project
- ZAP Baseline ScanOWASP ZAP
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.