How to Document Evidence That a TCP Port Is Open (Without Relying Only on Telnet)
In network support and troubleshooting, saying “Telnet connected” is sometimes not strong enough as evidence. Telnet can leave you with a blank screen, provide no clear success message, or fail to produce an audit-friendly result. In this post, I’ll share a simple, repeatable way to collect clear evidence that a TCP port is open and responding, using standard tools like Nmap and PowerShell.
Scenario
We need to verify connectivity to a client host on a public IP (anonymized) and a specific TCP port. To preserve confidentiality, this example uses:
- IP (example): 203.0.113.10
- Port (example): 10100/TCP
- Source: Windows workstation (PowerShell + Nmap)
What “Port Open” Means (Practically)
A TCP port is considered open when the destination responds to the TCP connection attempt (for example, by returning a SYN-ACK). This demonstrates that a service is listening and that the path is not blocked by a firewall (at least from your current source network).
1) Evidence with Nmap (Fast and Standard)
Nmap is one of the most widely accepted ways to document port state. For a direct scan of a single port:
nmap -Pn -p 10100 203.0.113.10
In the output, look for a line like:
10100/tcp open.
That “open” status is explicit evidence.
Optional: Add “--reason” and Service Detection
If you need stronger evidence (for example, showing a clear TCP-level response), add --reason
and -sV:
nmap -Pn -sV -p 10100 --reason 203.0.113.10
This may show the reason for the state (e.g., something equivalent to “syn-ack”) and, in some cases, even detect that the service responds at the application layer (HTTP/HTTPS or other banners).
Note: if Nmap captures application-layer content (for example an HTTP 200 response), that’s often even stronger evidence: not only is the port open, but a service is actively responding.
2) Evidence on Windows with PowerShell: Test-NetConnection
For many teams (support, audit, operations), a Windows-native result is ideal.
PowerShell includes Test-NetConnection, which reports whether the TCP test succeeded.
Test-NetConnection 203.0.113.10 -Port 10100
The key field you want to capture is:
TcpTestSucceeded : True.
Tip: Include Date/Time in the Evidence
If your evidence needs an explicit timestamp, you can run:
Get-Date
Test-NetConnection 203.0.113.10 -Port 10100
3) What About Telnet? Use It as a Signal, Not the Primary Evidence
Telnet can be useful for a quick validation, but as evidence it’s often weaker because it doesn’t always display a clear “OPEN/TRUE” status. Use it as supporting context, but prioritize Nmap and/or Test-NetConnection for a clear, reportable result.
Checklist for a Strong “Evidence Package”
-
Screenshot 1: Nmap output showing
PORT STATEand the port marked asopen. -
Screenshot 2: Nmap output with
--reason(if applicable), showing the reason for the state. -
Screenshot 3: PowerShell output showing
TcpTestSucceeded : True. -
Date/time: visible in the console output or added via
Get-Date. - Context: note the source network/location the test was performed from (without exposing sensitive details).
Confidentiality Best Practices
- Anonymize public IPs, hostnames, and domains (use documentation ranges like 203.0.113.0/24).
- Avoid posting screenshots that include internal IPs, Wi‑Fi names, usernames, or file paths.
- If you include command outputs, crop or redact fields that don’t add value to the evidence.
Wrap-Up
With Nmap and Test-NetConnection, you can generate clear, repeatable, and audit-friendly evidence that a TCP port is open and responding—without relying solely on Telnet’s often ambiguous behavior.
If you’d like, I can also tailor this post to a more technical or more executive audience and add an email template to share the results with your network/security team.
