Using Telnet and Test-NetConnection to test a connection and network flow

The ping (or Test-Connection, in PowerShell) 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 you have network traffic flowing between two endpoints. The same troubleshooting procedure exists in all workplaces and corporations. I have seen many monitoring tools and scripts utilize the results of whether a ping replies to report on whether a 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. ICMP is another protocol like TCP or UDP and is used by a lot of network troubleshooting tools. In the Windows world, a ping is ICMP traffic (on Unix and Linux, this is not always true – but this is a book on Windows Server, after all!). 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. Earlier in this book, we created a Windows Firewall rule to block ICMP as an example. 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 have only laid 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 Telnet Client, which I use on a daily basis. I hope that you will too! We'll also take a look at some of the different parameters of Test-NetConnection that can achieve a similar outcome.

Getting ready

We have a Server 2019 web server that has a website running. It is also enabled for RDP access and file sharing, but ICMP is being blocked by the local Windows Firewall. We are going to run some tests with a client machine against this server to try to determine which services are up and running.

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 a prompt on our testing client machine and try to ping WEB1 using the ping web01 command. Because ICMP is being blocked by the firewall, all we get is a series of timeouts:
   

   Figure 3.11 – A failed ping test between two machines

2. Now, let's use the telnet command to accomplish some more intuitive digging into whether WEB01 is online and functional. Note that Telnet Client is not available inside the 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.

   On Windows Server, run the following command:

   Install-WindowsFeature Telnet-Client

   On Windows 10, the command to install Telnet Client is different:

   dism /online /Enable-Feature /FeatureName:TelnetClient

3. Now, we have the telnet command available to use inside the Command Prompt. The general format of the command is 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 WEB01, let's try to use telnet to open a connection to port 80, which is the website that we have running. The command for this is as follows:

   telnet web01 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 WEB01 server. Press Control + C to exit the Telnet session:
   

   Figure 3.12 – A blank telnet screen, indicating a successful connection

6. Now, try using the telnet web01 3389 command. This also results in a flashing cursor, indicating that we successfully connected to port 3389 (RDP) on our WEB01 server. You could have also used an IP address instead of the name WEB01 here.
7. And finally, how about telnet web01 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 WEB01 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 to one of those.

   Tip

   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.

I don't blame you if you found that all a little bit confusing – it's OK. A blank screen indicates a valid connection? Strange, but true! However, PowerShell has a command that provides us with some more human-readable output. Let's try those tests again, but this time using PowerShell:

1. To replace our first test, which was checking for an active web server, run the following command. Notice that you do not need to remember which port HTTP runs on, as this command has a short list of commonly tested ports to choose from if you can't remember:

   Test-NetConnection web01 -CommonTCPPort HTTP

   You should be presented with a short report that indicates whether the test was successful:

   

   Figure 3.13 – Test-NetConnection showing a successful connection

2. Next, let's reproduce our test of the RDP server. You should see a similar outcome:

   Test-NetConnection web01 -CommonTCPPort RDP

3. And finally, let's test a non-common port, such as 53 for DNS, as in our previous examples. This time, we won't use CommonPort; we will use a specific port:

   Test-NetConnection web01 -Port 53

You will receive the following output:

Figure 3.14 – A failed Test-NetConnection command

How it works…

Telnet and its partner, Test-NetConnection, are simple but powerful commands that can be run to query against ports and services on your servers. When trying to determine whether a service is available, or when trying to troubleshoot some form of network connectivity problem, it is a much more reliable tool than using a simple ping request. If you have been thinking about building a script that programmatically reaches out and checks against servers to report whether they are online or offline, consider using Test-NetConnection rather than ping so that you can query the inpidual service that the system is providing by using its particular port number.