by Introduction
Ah, the joys and simplicity of the humble telnet utility when it comes to debugging networking connectivity issues. Ever-present in any Unix-based operating system worth it’s salt but sorely missed in Windows systems post-XP (although it can be manually installed).
It has long since been superseded by it’s more secure cousin SSH but did you know that it can still be used to great effect to help determine the most likely reason you are unable to connect to another server in your network, or on the wider Internet.
What does success look like?
What many people don’t realise is that by specifying an additional parameter when using it, you can instruct the program to try to establish a connection on a specific port number (rather than the default port of 23). Take the following example which shows a successful connection to a fairly standard web server:
$ telnet myhost.example.com 80 Trying 192.168.1.10... Connected to myhost.example.com. Escape character is '^]'.
The key thing to note here is the presence of the message, “Connected to myhost.example.com” and the fact the the session remains connected (i.e. you don’t get bumped back to the command prompt immediately). This is telling you that you have successfully established a valid connection to the required port on the server you’re interested in, which also (and most importantly) confirms that:
- You are not being blocked by a firewall.
- The service you’re trying to connect to is alive and well, listing on port 80.
- There are no software-based access rules preventing you from accessing the service on that port.
Help, it didn’t work!
In my experience, the above list represents the three most common reasons why things may not be working the way you hoped or expected. The neat thing about the telnet command is that it usually hints at this in the response it gives you, consistently so across the wide range of operating systems it runs on. The following table summarises the meaning of each such response from telnet:
| Response | Meaning |
| Trying… | Firewall issue |
| Unable to connect to remote host | Service not running |
| Connection closed by foreign host | Software-based access rule |
Keep reading for a more detailed explanation of each scenario:
1. You are blocked by a firewall
If the response to your telnet command is simply a “Trying x.x.x.x…” message (which eventually times out) then there is most likely a firewall rule (somewhere along the route to the remote server) blocking you:
$ telnet myhost.example.com 80 Trying 192.168.1.10...
Resolving this normally requires the services of a network engineer to grant the correct access through the firewall that is blocking you.
2. Nothing is running on the specified port
If the response to your telnet command ends swiftly with, “Unable to connect to remote host”, then you can be confident that you are not being blocked by a firewall but the server (you’ve managed to connect to) does not appear to have a process running that’s listening the port you specified:
$ telnet myhost.example.com 80 Trying 192.168.1.10... telnet: connect to address 192.168.1.10: Connection refused telnet: Unable to connect to remote host
Resolving this normally requires the services of the server administrator (normally having them start the offending service for you).
3. You’re not allowed to talk to the service anyway
If your telnet command appears to connect successfully but immediately returns to the command prompt with a “Connection closed by foreign host” message, then you can be confident that you are not being blocked by a firewall, there is a valid service listening on the specified port but there is some form of software-specific access rule preventing you from communicating with that service:
$ telnet myhost.example.com 80 Trying 192.168.1.10... Connected to myhost.example.com. Escape character is '^]'. Connection closed by foreign host. $
Resolving this normally requires the services of the support team that manages the service you are trying to connect to (and having them add a rule allowing traffic from your network).
Summary
There are of course many other connectivity debugging tools (e.g. netcat) and indeed telnet is only suited to TCP-based protocols. However, the presence of this command on almost every operating system out there, along with the fact that it’s syntax and responses have not changed for so long, make it well suited for use in multi-platform environments and multi-layered networks.