Network Troubleshooting Tools - How to Ping a Specific Port from Windows

How often do we, as system admins, find ourselves with a strange error that might be due to network connectivity?  Pretty often, in my experience.  While Ping is a great tool for validating basic routing, we live in a world of firewalls – be they physically on the network, virtually on the network, or software installed on the server.  When diagnosing network connectivity issues, Ping is not good enough, as that only tests the ICMP network flow.  You can’t ping a specific port in Windows, so if you’re looking to test something like HTTPS (TCP 443), with Ping you’re out of luck.  Fortunately, there are many other tools available.

My favorite tool is PortQry (that link will work as long as Microsoft graces us with a consistent URL… so until tomorrow, probably).  PortQry was originally a SysInternals tool (developed for Windows 2000!) and is still one of the best.  You’ll have to download it, but it’s a simple executable that you can invoke from the command line to do some really precise testing.  Do you want to test a connection to a server on TCP 443?  No problem!  How about UDP 4172?  Yeah, we can do that.  I like this tool because it’s one of the few that can test both TCP and UDP, although the UDP results aren’t always the most useful as UDP doesn’t send replies to received packets.   But, it’ll at least tell you if your destination is not listening on that port, which can be important.

So, how do you use it?  It’s pretty easy, as long as you know what options it uses.  When I use it, I typically use just a few of its options: -n, -p, -e, and –nr.  A common query would look something like this:

portqry –n vcenter.domain.local –p tcp –e 443 –nr

That query would attempt to communicate with the server “vcenter.domain.local” on the TCP port 443, skipping the name resolution test that PortQry does by default (if you’re not troubleshooting DNS issues, that steps just slows down the test… especially if the server name or IP that you’re testing doesn’t have a DNS record).  So, the –n option specifies the name or IP address of the destination server, the –p option specifies the Protocol (either TCP or UDP), the –e option specifies the Port number (you can alternately use the –r option to specify a range of ports) and the –nr option skips the Name Resolution step.  When possible, this is my preferred tool… although it’s not always available, as it’s not built into Windows.  So, what do you do if you’re only using the native Windows tools?

Way back in the olden days (you know, 7 years ago…) all Windows systems included a tool called Telnet.  Telnet is a remote session client, but it allows you to specify not just a remote host name, but a remote host port.  By seeing if that Telnet session establishes or immediately fails, you could determine if a host was listening on that TCP port.  Nowadays, you’d have to install Telnet onto a system, so what tool can we use that’s already there?  PowerShell.

If you’re on a newer system (with PowerShell version 4 or newer), you can use the Test-NetConnection cmdlet.  It’s also pretty simple to use:

Test-NetConnection vcenter.domain.local –port 443

Just specify the remote server’s name or IP and then use the –Port option to specify which port to test.  Notice that it doesn’t allow you to test UDP connectivity, but as I mentioned that’s not always a useful test anyway.  This will come back with a whole bunch of info, but you’re most interested in the TcpTestSucceeded property, which will be either True or False.  But, what if your system has an older version of PowerShell and you can’t upgrade it?  Well, there’s another (more cumbersome) option.

PowerShell can access .net framework components.  So, if you have an older version of PowerShell, you can directly call the TCPClient (or UDPClient) class to do some testing.  It’s a bit awkward, but it works and can save your bacon during a difficult troubleshooting situation:

New-Object net.sockets.tcpclient("vCenter",443)



New-Object net.sockets.udpclient("View01",4172)

That first example will attempt to open a connection to “vCenter” on TCP 443; the second example will attempt a connection to “View01” on UDP 4172.  When you use these commands (or at least the TCPClient one, which is the only one of these two that I’ve had to use), you’ll either get a successful command (with a Connected property that equals True) or if it fails you’ll receive a PowerShell error that reads “Exception calling “.ctor” with “2” argument(s): “No connection could be made…”

And there you have it!  Having tools to validate network flows with arbitrary destination ports (and protocols!) has often been a very important factor in resolving an issue.