I know it’s been a day or two since the first part of this, but here we are. Part two where I go down the rabbit hole of basic network troubleshooting between a client and a server. The intent here is to start at the absolute beginning and walk through a simple scenario between two machines. I’ll be working with a few tools, and pointing at a few spots where things can go wrong.
Let’s start with the network. Here’s the design of our sample network:
There is a single Virtual Network called VNET-TEST with a single subnet called SUBNET-VMS. Attached to that subnet are two virtual machines (VM1 and SERVER01). Each Virtual Machine has a NIC with a private IP address. Each NIC also has a Public IP Address associated with it. Lastly, I have a basic Network Security Group attached to both virtual machine NIC’s that is allowing TCP Port 3389 inbound, as well as allowing Ping and HTTP within the subnet. This creates a simple two VM network that we can RDP into from the outside. If you’d like to build this yourself, I have some bicep code you can use as a template.
From the server, we want to reach TCP port 80. But rather than install a full blown web server, I’m going to use PowerShell to open a specific port. I’ve found this method invaluable in quickly simulating or testing port connectivity between two basic endpoints (when doing firewall troubleshooting). So, the following code is run from the server:
This will open TCP Port 80 on the local IP Address to be listening for connections. Now we turn our attention to the client and begin to introduce our first tool
Ping
Ping is…basic. It’s basic and not always reliable, but it should always be one of your first tools in your arsenal. There are only two conditions with ping – works or it doesn’t. Here’s an example of ping not working:
The most common reason for the above is a firewall of some kind blocking ICMP (Ping) traffic. Many servers and network appliances will block or drop ICMP traffic. In our case, it’s actually firewall related. Windows Server installations, by default, enable the internal Firewall and block inbound ICMP:
The above is shown in the Advanced Firewall settings within Windows Server. By simply enabling the inbound ICMP Allow rules we can see that we can now ping the server properly:
Trace Route
Trace Route (or TraceRt) is a tool used to see how many “hops” are between your source and destination machines. This can be useful in identifying routing problems. It leverages ping and DNS. In our network, there are no routers, firewalls, VPN’s or other devices to hop through, so when we trace route to our server we get a simple result:
This basically says that anytime the client is communicated with the server, it’s direct. There’s nothing in between the two that can block or filter the traffic.
What’s something more complicated look like? Well here’s what it looks like to trace our route through to www.bing.com:
There are 12 devices between my client and the server that responded to www.bing.com. None of those devices are responding directly to ICMP (thus the “Request timed out” messages), but we know there’s something there.
Test-NetConnection
So those were basic tools to help us test whether the server is alive and how far it is – next up is this PowerShell cmdlet. By passing just the server name, we’re essentially performing the PowerShell equivalent of ping:
But this cmdlet can actually help us test whether that server is responding on TCP port 80 by adding the Port parameter:
If this fails, things to look for will be either something blocking that traffic in transit (like a Firewall) or checking that the server is truly listening on port 80 (usually with netstat on the server itself).
Test-NetConnection is a great tool with a few useful options such as performing trace routes, getting detailed information from the remote host, and performing certain diagnostics. Full documentation on the use of this cmdlet can be found here.
PSPing
Lastly we have PSPing, which is part of the Sysinternals Suite of tools. This tool takes things to the next level, by allowing us to set up a constant “ping” to the server on port 80. The syntax is simple – we tack the port number to the end of the IP address we want to target, separated by a colon:
This shows 5 successful connections to port 80 on our server. The tool has a variety of other options for performing latency or bandwidth tests, adjusting the payload size, running until manually stopped, etc. Full documentation can be found here – this is a tool worth knowing and using.
Summary
I’ve taken all of these tools for granted over the years, making wild assumptions that everyone knows about them and how to use them. The reality is that not everyone does. These basic tools and skills are invaluable, and sometimes they’re overlooked when people troubleshoot a server / site / service is unresponsive.