PowerShell: Test-NetConnection

A deep dive on a super useful command

It’s been a minute since I last posted here, it was supposed to be a lot more regular however life got in the way. But here I am!

Just a quick and dirty post today, on the super useful PowerShell command Test-NetConnection. It also has a handy short alias, tnc. This command can validate a TCP connection within your local network, or out across the internet.

Test-NetConnection 

##and a short alias:
tnc

So how can I use that? Lets do a quick break down on TCP vs UDP networking protocols. Don’t worry, it will be super quick, you don’t need a CCNA for this one.

TCP vs UDP

UDP is a connectionless protocol. This means that packets are sent in a constant stream. They have no order, no acknowledgement and no care for whether it was received or not. “Did you receive all the packets? Scrap that, I don’t care, here’s some more”

Do you want to hear a joke about UDP?
Do you want to hear a joke about UDP?
Do you want to hear a joke about UDP?
Do you want to hear a joke about UDP?

---

TCP is the opposite. It creates a connection, using a SYN-ACK handshake. SYN being an attempt to create a connection, ACK being the receiving device acknowledging the connection. A nice friendly “Hello, can you hear me?”, “Yes, I can hear you”. The packets are ordered, acknowledged and if one is missed, it is sent again.

Do you want to hear a joke about TCP?
Did you get it?
Did you get it?
Did you get it?
Did you get it?

---

Speaking broadly, UDP is “faster” and useful for things like video calls. TCP is “stable” and useful for things like browsing the web.

The Command

Test-NetConnection leverages this SYN-ACK handshake, meaning we can test and see if a connection can be made using TCP. The easiest example of this is testing if we can connect to www.google.com using HTTPS, port 443.

This gives us some great information output. We can see the IP address that the command connected to, 142.250.67.4, the interface my computer used to connect, my local IP and if the TCP connection succeeded. In this case, it was a successful connection. “TcpTestSucceeded: True” = a good result (probably).

Lets look at a failed TCP connection:

I didn’t expect Google to have a random port open, and I can see I was right. “TcpTestSucceeded” is false. However, the ping succeeded and the address resolved to an IP address.

What can we gather from this? The address is right (www.google.com) because it resolved and the “computer” (in this case Google) responded to ping. So it’s online and I’m pointing in the right place. However, it didn’t receive any ACK back from port 4000. If I was troubleshooting this connection, it would be safe to assume that port 4000 is either closed or being blocked along the way.

Extra information

If you need some more detail, there’s a few extra switches to play with.

-Traceroute: Show the path the connection is taking

-Hops: Limit the number of hops a packet can take to the destination

-CommonTCPPort: A shortcut to test the connection of 4 protocols: SMB, HTTP, RDP and WINRM if you blank on the port numbers

Funny little problem

Recently I experienced a funny little issue with the output of a Test-NetConnection command, confirmed on StackExchange.

If you pass a long list of IP addresses, the results can come through quite slowly - 2 to 4 seconds per result. That doesn’t sound like a lot, but it adds up on 100+ addresses. If you pass a list of URLs, it goes significantly faster.

Why?

The way that Windows references the destination IP address in the output. It references it in an inefficient way, and digs through output to find it. Why doesn’t this happen with a URL? Who knows.

Happy Testing!