RootUsers

Most of us would be familiar with the simple ICMP based ‘ping’ command which allows us to test for a basic response from some network connected device. While great for basic troubleshooting it does not allow us to confirm if the particular host at the other end is responding on TCP or UDP ports where the majority of services are likely to be provided.

Ping isn’t the be all and end all of network troubleshooting, if a firewall blocks inbound ICMP traffic then a ping will not succeed which can produce a false perception that the host is down as it is not responding to the ping, however other services could still be responding fine.

Alternatively while ping may come back fine with a response it doesn’t indicate if a web server is responding on port 80 for HTTP requests, the web server may have failed and no longer be responding.

So if ping is ICMP based, can we hit a TCP or UDP port for response instead? The answer is yes, let’s take a look.

Enter tcping

tcping is one such tool that can be used to check that a TCP port is responding, there are a few versions available however I use this one: http://www.elifulkerson.com/projects/tcping.php

The manual is on the same page, basically you can run a command similar to the below.

C:\Users\Admin\Desktop>tcping.exe google.com 443

Probing 150.101.161.230:443/tcp - Port is open - time=2.203ms
Probing 150.101.161.230:443/tcp - Port is open - time=1.426ms
Probing 150.101.161.230:443/tcp - Port is open - time=1.764ms
Probing 150.101.161.230:443/tcp - Port is open - time=1.393ms

Ping statistics for 150.101.161.230:443
     4 probes sent.
     4 successful, 0 failed.
Approximate trip times in milli-seconds:
     Minimum = 1.393ms, Maximum = 2.203ms, Average = 1.697ms

Here we are using tcping to check port 443 at google.com. As can be seen the port is showing as being open and responding, if the port is not open it will show as no response after 2000ms by default.

You could also use telnet to test for TCP connectivity to a port, however the tcping tool provides further features as outlined in the usage section here. Some such features include being able to continually run the test allowing a way to generate traffic for you to watch out for in live packet captures as well as the response time.

What about UDP?

As UDP is a connectionless protocol, determining if it is responding is a bit different. A TCP ‘ping’ works by performing a three way hand shake, the source will send a SYN to the destination, the destination will reply with a SYN-ACK, and the source will then send an ACK completing the handshake and establishing the connection. As UDP does not establish a connection we can’t just look for this to determine if the port is responding, we instead need to send specific data and see if we receive a response.

NMAP is a great tool for this, you can download it and use it to port scan a destination address to determine what ports are open.

In this example we are querying if 8.8.8.8 is responding on UDP port 53, as it serves DNS we would expect it to be open.

C:\Users\Admin\Desktop\nmap-6.47>nmap -sU -p 53 8.8.8.8

Nmap scan report for google-public-dns-a.google.com (8.8.8.8)
Host is up (0.0050s latency).
PORT   STATE         SERVICE
53/udp open|filtered domain

Nmap done: 1 IP address (1 host up) scanned in 5.31 seconds

The open|filtered result is used when nmap is unable to determine if the port is open or filtered, the open port may not have given a response. It shows that the service has been identified as ‘domain’ as it’s for serving DNS. I’ve tested this to some other DNS servers out on the Internet and some do show as open only confirming that they are responding.

NMAP can also be used to check a TCP port is open in a similar way, just change -sU to -sT.

Why a port may not respond

There are a few simple reasons that a port may not respond to your test.

• A firewall is blocking the traffic: There may be a firewall running between the source and destination filtering the traffic depending on the rules in place even if you know the destination should be responding on a particular port.
• The destination may not be listening on the port: Simply put, the destination you are trying to connect to may not have any services listening on the port specified so there will not be any response. This can also happen if a service has been stopped, for example if you stop Apache a web server will no longer respond to port 80 requests.
• There is some other network problem between the source and destination of the traffic: There could be any number of network connectivity problems between the source and destination, if possible check the network however if the traffic is traversing the Internet you will be limited in what you can check.

You can check the connectivity along the path of the traffic by running a packet capture with something like Wireshark or tcpdump, this will show you where the traffic is getting through to and where it’s being stopped along the route. You could run it on the source and destination servers, as well as devices in between that you have access to such as firewalls or routers. Follow the flow of traffic until you determine where the problem is.

Summary

While performing a TCP ‘ping’ to a destination you can confirm if it is responding as intended, though there are a few reasons the port may not respond as noted. UDP can be checked however it’s a bit more difficult to be certain if you’re correctly receiving a response so the tests aren’t always reliable, which makes sense as UDP is not a reliable protocol. These tests can be useful when testing security by confirming if ports are open or closed.