We’d like, with this article, to talk about some basic commands in Windows that are useful to perform diagnosis and network troubleshooting. These few commands, if properly used, allow to quickly come to useful conclusions and resolve the majority of the network troubles that are commonly encountered.
Quite often we get upset because a service or an application isn’t responding, we don’t remain focused enough to follow the required steps about network troubleshooting.
Let’s see how to behave rationally.
The Internet site we host on our Windows web server isn’t working.
We assume that our Internet connection is working, we can safely see other sites, our internal firewall is not blocking us and the local antivirus does not interfere with our activity. These are usually elements that must never be taken for granted!
Who doesn’t know what a ping is? Probably it's the most used Windows CMD (and perhaps Linux CLI too.. ), even by newbies.
Ping is magical because it gives us an immediate response about the availability of a host, be it in the local network or on the other corner of the world. This command has almost twenty options, yet we’ll use the basis.
In the aforementioned scenario, we immediately do a ping test from whichever computer.
We immediately get some useful information.
Results can be as follows:
1- Pinging www.example.com [184.108.40.206] with 32 bytes of data:
Look at the first line. It’s very important because it tells us that the name of our web site is resolved, on a DNS basis, with the IP address 220.127.116.11.
At this point we can check this IP against the one of the web server hosting our web site, or for some reasons we need to check the DNS zone of the domain www.example.com
In this scenario we can assume that everything is right on a DNS basis, and that the IP address of the site is the right one.
Let’s move on.
The lines below the first one can be either:
1- Request timed out.
2- Reply from 18.104.22.168: byte=32 time=50ms TTL=50
In the first case, Request Timed Out, tells us everything and its opposite. Indeed it can be the result of different reasons. It may be the local antivirus that blocks traffic, it might be the local firewall blocking the ICMP traffic, it could be the web server’s firewall, or even the Internet line that isn’t working or the web server is really KO.
We excluded some causes in our scenario, still it’s important to remember about these elements in all the circumstances.
Yet in this case this information shouldn’t delude us: the IP address might be assigned to a firewall and not directly to the web server. In the former case it’s the firewall protecting the web server that replies, so what ping can tell us is that we can reach at least the firewall.
Let’s put in the scenario that there’s a ping reply and let’s go on with the troubleshooting.
This command gets really down in the list of the most used commands, even if it should be taken into account more vigorously, in particular when doing network troubleshooting.
The use of the Telnet command is quite simple.
telnet www.example.com 80
What does it mean?
Telnet is a command that starts a communication software. When doing network troubleshooting it’s “only” used to check that there’s a server replying on the other side. With server we mean a service that replies on a certain port.
Indeed, as the example shows, the host name (www.example.com) is followed by the number 80.
This number represents the port 80 used by the HTTP protocol. It could be port 25 (SMTP) if we were using an mail server.
When there’s someone else listening on the other side, the command prompt will become all black and the cursor will start to blink in the upper left corner, once you execute the command telnet www.example.com 80.
Unfortunately we don’t get any other information in the case of a web server (if using a mail servers we get a different response).
Otherwise it shows:
telnet ww.example.com 80
Connessione a www.example.com...
And after some time if the connection is not starting
telnet www.example.com 80
Connecting with www.example.com...Could not open connection to the host, on port 80: Connect failed
In this case we have a clear clue. Either the firewall that protects our web server is blocking port 80 in order not to pass the HTTP protocol, or the web server itself has the service not active.
Let’s assume we have a reply and the telnet cursor blinks. With just this clue we can figure out if something is listening on the web server, and if we can reach it.
Don’t take for granted this statement too, as in some cases it could be the firewall that does the NAT from the public IP which is assigned (and that corresponds to the web site) to the real private IP of the web server that hosts our site that replies instead of the web server.
In this occasion, let’s say that is quite probable that is telnet starts to behave as described, then it’s the web server that replies, and not the firewall.
We have checked that the connectivity between the client used for tests and the web server works and the firewall routes the connection towards an internal host with port 80 listening.
However, our web site still isn’t working. I am on purpose quite unclear and use the term “isn’t working” to give our scenario a sense, because if we get a little more precise -and a sysadmin must be precise- the statement “the web site isn’t working” should be followed by the reply “how isn’t it working, what is the error message showed by the browser?”. In order to give sense to this scenario let’s keep on with this initial uncertainty.
We need to check the web server itself, and to do that we need to remotely access to it.
What can we do once we establish a remote connection?
First thing, let’s be sure that port 80 of the web server is effectively listening.
Here comes a handy command less used, Netstat!
Netstat is a very powerful command that gives us information about the network connection of the computer on which we execute the command.
If the Web server service is enabled on our machines, we can expect port 80 to be listening.
Let’s run netstat with the option -na to have:
a -> it shows all the connections and listening ports
n -> show addresses and port numbers in numeric format
Proto Local Address Foreign Address State
TCP 0.0.0.0:7 0.0.0.0:0 LISTENING
TCP 0.0.0.0:9 0.0.0.0:0 LISTENING
-> TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING
TCP 10.29.252.7:21 0.0.0.0:0 LISTENING
TCP 10.29.252.7:21 22.214.171.124:50585 ESTABLISHED
-> TCP 10.29.252.7:80 126.96.36.199:47132 TIME_WAIT
TCP 10.29.252.7:80 188.8.131.52:47135 TIME_WAIT
TCP 10.29.252.7:80 184.108.40.206:57638 ESTABLISHED
TCP 10.29.252.7:80 220.127.116.11:12007 TIME_WAIT
TCP 10.29.252.7:80 18.104.22.168:16816 ESTABLISHED
TCP 10.29.252.7:139 0.0.0.0:0 LISTENING
TCP 10.29.252.7:50383 0.0.0.0:0 LISTENING
TCP 10.29.252.7:50769 22.214.171.124:80 LAST_ACK
TCP 10.29.252.7:50794 126.96.36.199:80 CLOSE_WAIT
TCP 10.29.252.7:50799 188.8.131.52:5938 ESTABLISHED
TCP 10.29.252.7:50803 184.108.40.206:443 TIME_WAIT
TCP 10.29.252.7:50806 220.127.116.11:80 ESTABLISHED
As we can see from the example, we have in localhost (IP 0.0.0.0) a service listening on port 80, indeed we read 0.0.0.0:80, and a web service listening on port 80 on the local address (IP 10.29.252.7) of the server: we read 10.29.252.7:80.
Let’s go back to Telnet just to be sure.
From the server we open the command prompt:
telnet 10.29.252.7 80
In our scenario we discover that the service is responding: the prompt blinks in the upper let corner after we executed the command.
Someone might think that it would suffice to access to the web site with a browser to check if it’s working, but this test has a positive outcome only with certain configuration of the web server service.
It’s not true that if we open the browser and place the IP address 10.29.252.7 instead of www.example.com, then we get the requested site, or, to be more precise, the web server replies because it may host more than a site. Because this topic would require another article about the operation mode of a web server, take that for granted and keep reading.
To be safe, we need to be sure that the web servers resolves www.example.com as local address (10.29.252.7) and not as public address (18.104.22.168).
Open the command prompt
Pinging www.example.com [22.214.171.124] with 32 bytes of data:
The web server resolves the site with a public IP, so we need to change things a little bit. We need to edit the host file which is found in “C:\Windows\System32\drivers\etc" (use Notepad of your text editor of choice and run it as administrator, otherwise you won’t have the needed permissions to save it).
Let’s add a line
Save, close then ping again.
Pinging www.example.com [10.29.252.7] with 32 bytes of data:
All right, perfect.
We can now open the browser and use the URL http://www.example.com.
Surprise! The site works as expected.
(the network card of the web server is properly configured, indeed we succeeded to establish a remote connection with our remote control software).
The public IP is reachable from the outside, DNS resolution is correct and Telnet towards the web server replies. Once remotely connected to the web server we find that services are listening on the right ports and we check that the site is working locally.
Where is the problem?
We ought to say that there are no doubts. The problem is on the firewall level! The web server has a private IP as we’ve seen and it works locally (that is, from the web server itself); the public IP is assigned to the firewall that protects the web server.
All the steps we have covered with these “essential” commands, yet not used properly by most sysadmins, take less than 5 minutes.
When you determine that the problem resides on the firewall it’s easier to fix the issue because you can concentrate on it. Possible causes can be several.
The NAT rule is wrong. Perhaps the rule, instead of NATting the public IP 126.96.36.199 towards the private IP 10.29.252.7, wrongly routes towards another IP that is on another web server.
(No, don’t you think that if you go to www.example.com and the firewall routes to the wrong web server, then you’ll visualize the web site of the other web server.. it doesn’t work this way!)
Or, the protocol inspector doesn’t like the output of your web server and stops the flow of data.
At this point you would have to have access to the firewall and to a feature that allows to see in real time the active connections, and to web server, preferably with the command prompt open and the netstat command running to check if the connections from the outside are accepted.
But that is an advanced troubleshooting. Until next time, consolidate the systematic use of this sysadmin-like approach, using the cited commands as reference.
Said commands do exist also in Linux and the approach is the same.