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”

  1. Screenshot 1: Nmap output showing PORT STATE and the port marked as open.
  2. Screenshot 2: Nmap output with --reason (if applicable), showing the reason for the state.
  3. Screenshot 3: PowerShell output showing TcpTestSucceeded : True.
  4. Date/time: visible in the console output or added via Get-Date.
  5. 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.