Checking Specific TCP Port Access to a Remote Machine

Troubleshooting network connections is tough. Generic error messages make it hard to identify the root of the problem. This PowerShell cmdlet can help.

Checking Specific TCP Port Access to a Remote Machine

Did you know that you can use a simple PowerShell commandlet, Test-NetConnection, to check remote access to a specific TCP port?

Test-NetConnection -ComputerName MyBuddysComputer -Port 3389 

This is especially useful when troubleshooting the following types of network connections:

  • Remote Desktop connections (default port 3389)
  • SQL Server connections (default port 1433)
  • VNC connections (default port 5900)

As network administrators implement increasingly restrictive firewalls, this is a great way to isolate the potential source of a connection error.

Troubleshooting Remote Desktop Connections

It's common to see the following error message when trying to connect to a machine via Remote Desktop.  

Remote Desktop Connection
Remote Desktop can’t connect to the remote computer for one of these reasons:

1. Remote access to the server is not enabled
2. The remote computer is turned off
3. The remote computer is not available on the network

Make sure the remote computer is turned on and connected to the network, and that remote access is enabled.

The error message is not particularly helpful, as it does not tell you what is preventing you from connecting.  Can you even see the remote machine?  If you can see it, can you communicate with the RDP port?  The error message offers no insight.

The Test-NetConnection cmdlet, on the other hand, provides lots of valuable debugging data with no extra noise.

Sample Usage

The screenshot below shows two calls to the Test-NetConnection cmdlet.

The first call, to a computer named "csa411," fails to connect to port 3389.  However, we know that DNS is working because the command was able to properly resolve the RemoteAddress of the machine (10.54.146.19).  We also know that the machine itself is accessible over the network, since a Ping succeeded.  Finally, we know that the command went out over the network interface named, "Ethernet 3."  On a laptop with a network cable, WiFi, and one or more active VPNs, knowing which network adapter is being used for the network connection test could prove quite handy indeed.

In the second call, to a computer named "csa307," the connection to port 3389 succeeded.  It should come as no surprise, then, that when I tried to connect to "csa411" via Remote Desktop I got the unhelpful error message from earlier in the article.  When I tried to connect to "csa307" though, I was immediately prompted to provide my credentials for the Remote Desktop session.

The SourceAddress Property

The SourceAddress is especially useful for troubleshooting connections where there is an IP-based whitelist that restricts which devices are able to connect.

For example, the screenshot below restricts which computers can connect over Remote Desktop to the target device based on the IP address of the connecting device. The three 10.24.xxx.xxx ranges are approved subnets of the local LAN.  The 10.50.50.xxx range is set aside for VPN connections.  If you are connected to one or more VPNs, then your local device can have multiple IP addresses.  

Thus, knowing which IP address is being used while connecting to the remote device can provide valuable debugging information.

Big thanks to Ben Clothier for letting me in on the secret.

External references

Test-NetConnection (NetTCPIP)
Use this topic to help manage Windows and Windows Server technologies with Windows PowerShell.

Referenced articles

Quick Way to Troubleshoot SQL Server ADO Connections
This simple trick provides you with plenty of clues when debugging a failed SQL Server connection on a user’s computer.

Image by Daniel Dino-Slofer from Pixabay

All original code samples by Mike Wolfe are licensed under CC BY 4.0