Forget telnet for testing ports, use portqry

I keep coming across situations where techs use telnet to see if a remote port is open or not. Please stop using telnet for this especially as the results it gives back can be ambiguous and there is an awesome alternative that's been out for sometime called Portyqry.

Download this little tool and add it to your tools library. When you want to test a port just use this command:

portqry -n [server name] -e [port number]

For example, to test out if RDP is working on a domain controller:

portqry -n dcs04.gdwnet.com -e 3389:

It has additional tricks as well, if you run the same command against the LDAP port of the DC:

portqry -n dcs04.gdwnet.com - 389

With portqry it's very easy to see if a port is accessible from the client side.

If portqry shows that a port is filtered then something is stopping access, either an ACL or firewall along the route to the target server. Another thing to check is that the port is actually open on the server. A good tool for this is netstat, there are a few tricks that can make this more useful as well:

netstat -nao |find "80" will show if port 80 is open or not, what IP is listening on that port and the process that has access to the port. In this example, the process ID is "4" which is always the process ID for "system" which owns IIS.
The "|" character is the pipe command and sends the output of one command to act as the input for another command.

You could use netstat -nabo but I find the output of that to be really messy. I prefer using the process above and then using pslist from the sys internals toolset to see which process links to which process ID. I can also use the |find trick as listed above on that output to filter it to just the process ID I'm interested in.

Author image
IT Person | Veeam Vanguard | VMware vExpert | Windows admin | Docker fan | Spiceworks moderator | keeper of 3 cats | Avid Tea fan