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.

ping www.example.com

We immediately get some useful information.
Results can be as follows:

1- Pinging www.example.com [] 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

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 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

netstat -na
Active connections
  Proto  Local Address       Foreign Address       State
  TCP                  LISTENING
  TCP                  LISTENING
->  TCP                 LISTENING
  TCP                LISTENING
  TCP                LISTENING
  TCP                LISTENING
  TCP               LISTENING
  TCP               LISTENING
  TCP               LISTENING
  TCP              LISTENING
->  TCP      TIME_WAIT
  TCP              LISTENING
  TCP              LISTENING
  TCP         LAST_ACK
  TCP         CLOSE_WAIT


As we can see from the example, we have in localhost (IP a service listening on port 80, indeed we read, and a web service listening on port 80 on the local address (IP of the server: we read

Let’s go back to Telnet just to be sure.

From the server we open the command prompt:

telnet 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 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 ( and not as public address (

Open the command prompt

ping www.example.com
Pinging www.example.com [] 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        www.example.com

file hosts2

Save, close then ping again.

ping www.example.com
Pinging www.example.com [] 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 towards the private IP, 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.

banner eng

fb icon evo twitter icon evo

Word of the Day

The term Edge Computing refers, when used in the cloud-based infrastructure sphere, the set of devices and technologies that allows...


The acronym SoC (System on Chip) describes particular integrated circuit that contain a whole system inside a single physical chip:...


The acronym PtP (Point-to-Point) indicates point-to-point radio links realized with wireless technologies. Differently, PtMP links connects a single source to...


Hold Down Timer is a technique used by network routers. When a node receives notification that another router is offline...


In the field of Information Technology, the term piggybacking refers to situations where an unauthorized third party gains access to...

Read also the others...

Download of the Day


Netcat is a command line tool that can be used in both Linux and Windows environments, capable of...



Fiddler is a proxy server that can run locally to allow application debugging and control of data in...


Adapter Watch

Adapter Watch is a tool that shows a complete and detailed report about network cards. Download it here.


DNS DataView

DNS DataView is a graphical-interface software to perform DNS lookup queries from your PC using system-defined DNS, or...


SolarWinds Traceroute NG

SolarWinds Traceroute NG is a command line tool to perform advanced traceroute in Windows environment, compared to the...

All Download...

Issues Archive

  •  GURU advisor: issue 21 - May 2019

    GURU advisor: issue 21 - May 2019

  • GURU advisor: issue 20 - December 2018

    GURU advisor: issue 20 - December 2018

  • GURU advisor: issue 19 - July 2018

    GURU advisor: issue 19 - July 2018

  • GURU advisor: issue 18 - April 2018

    GURU advisor: issue 18 - April 2018

  • GURU advisor: issue 17 - January 2018

    GURU advisor: issue 17 - January 2018

  • GURU advisor: issue 16 - october 2017

    GURU advisor: issue 16 - october 2017

  • GURU advisor: issue 15 - July 2017

    GURU advisor: issue 15 - July 2017

  • GURU advisor: issue 14 - May 2017

    GURU advisor: issue 14 - May 2017

  • 1
  • 2
  • 3
  • BYOD: your devices for your firm

    The quick evolution of informatics and technologies, together with the crisis that mined financial mines, has brought to a tendency inversion: users that prefer to work with their own devices as they’re often more advanced and modern than those the companies would provide. Read More
  • A switch for datacenters: Quanta LB4M

    You don’t always have to invest thousands of euros to build an enterprise-level networking: here’s our test of the Quanta LB4M switch Read More
  • Mobile World Congress in Barcelona

    GURU advisor will be at the Mobile World Congress in Barcelona from February 22nd to 25th 2016!

    MWC is one of the biggest conventions about the worldwide mobile market, we'll be present for the whole event and we'll keep you posted with news and previews from the congress.

    Read More
  • 1