The ping command has always been an IT person's best friend to do quick network connection checks. How many of you are the family and neighborhood go-to guy to fix anything with buttons? I'm guessing most of you. And as such, if someone told you they were having trouble accessing the Internet from their laptop at home, what is the first thing you would do when you showed up? Try to ping their router, a website, or another computer in their network. You know you would! This has always been a wonderfully quick and easy way to test whether or not you have network traffic flowing between two endpoints. The same troubleshooting procedure exists in all workplaces and corporations. I have even seen many monitoring tools and scripts utilize the results of whether or not a ping replies to report on whether or not a particular service is up and running. If you get a ping reply, it's working, and if it times out, it's down, right?

Not necessarily. The problem we are here to address today is that more and more networks and routers are starting to block ICMP traffic by default. Pings = ICMP. This means that you can no longer take your ping test results to the bank. If your network connection traverses a router or firewall that blocks ICMP, your ping test will time out, even if the service is up and running. Windows Firewall even blocks ICMP by default now. So if you bring a new server online in your network and give it an IP address, you may notice that attempting to ping that new server results in timeouts. There is nothing wrong with the server, and it is capable of sending and receiving network traffic, but the local firewall on that server is blocking the incoming ping request.

I only lay out this information to let you know that ping is no longer the best tool for determining a connection between machines. Today's recipe will introduce a tool that has been around for a long time, but that I don't find many administrators taking advantage of. This is the Telnet Client, which I use on a daily basis. I hope that you will too!

How to do it...

To start working with Telnet Client, have a look at these instructions:

1. First, just to prove our point here, let's open up Command Prompt on our testing client machine and try to ping WEB1 using the ping web1 command. Because ICMP is being blocked by the firewall, all we get is a series of timeouts:

2. Now let's use the Telnet command to accomplish some more intuitive digging into whether or not WEB1 is online and functional. Note that Telnet Client is not available inside Command Prompt by default; it is a Windows feature that must be installed. On the client machine we are using to test, head into Control Panel | Programs | Turn Windows features on or off (or Server Manager if your testing machine is a server) and choose to add roles or features. We want to install the feature called Telnet Client. Alternatively, you can install the Telnet Client feature with a simple PowerShell command:

           Install-WindowsFeature Telnet-Client

3. Now we have the telnet command available to use inside Command Prompt. The general format of the command goes like this: telnet <server> <port>. When you run this command, you are effectively saying "Let's try to create a connection to this server name, on this particular port."

4. Even though we cannot ping WEB1, let's try to use telnet to open a connection to port 80, which is the website that we have running. The command is as follows:

           telnet web1 80

5. When we press Enter, the Command Prompt window changes to a flashing cursor. This is your confirmation that Telnet was able to open a successful connection to port 80 on the WEB1 server:

6. Now try using the telnet 10.0.0.85 3389 command. This also results in a flashing cursor, indicating that we successfully connected to port 3389 (RDP) on IP address 10.0.0.85. This is the IP address of WEB1. I wanted to show this to point out that you can use either names or IP addresses with your telnet commands.

 

7. And finally, how about telnet web1 53? This one results in a timeout, and we do not see our flashing cursor. So it appears that port 53 is not responding on the WEB1 server, which makes sense because port 53 is commonly used by DNS, and this is a web server, not a DNS server. If we were to query one of our domain controllers that is also running DNS, we would be able to make a successful telnet connection to port 53 on those guys.

Note

Telnet queries work with TCP traffic, which covers most services that you will be polling for. Telnet does not have a connector for UDP ports.