Using Telnet for Basic Network Troubleshooting and Port Scanning
2010-02-04 Initial Post
For many years now, I've known about using telnet to connect to port 25 to test SMTP connectivity (see http://support.microsoft.com for how to telnet to port 25 SMTP). I didn't realize until last week that telnet can be used to connect to any open port.
When most inexperienced sys admins troubleshoot, you'll usually hear "I can ping the server, so app XYZ must be working if the server is up." Pinging a server only tells you that the server is up and its main networking components are working. To get a little deeper, you need to connect to the specific application. For example, if you want to see if IIS is functioning, you need to connect to a Web site hosted on the server. OK, simple enough.
But what if the server is a hosting an application/service and you don't have the client program installed on your computer that can test the application? In that case, you can telnet to the application's port as a troubleshooting step. This is still not 100% assurance that the application is working properly, but it's much better than just simply getting a ping reply from a server.
I was troubleshooting an issue with the Lotus Sametime IM program and ended up using telnet to confirm that my computer couldn't connect to port 1533, which is one of the ports that the Sametime client connects to.
There are free port scanners that can be downloaded, but if you just need to scan one port on one host, then using telnet is the quickest method. Also, you might not always have access to a port scanner, so it's good to know that telnet can be used if necessary.
I don’t recall ever learning about this from any of the networking books or articles that I’ve read. Yes, I know that standard telnet uses TCP to connect to port 23, but I never read that you could actually telnet to any open port. It’s interesting that I haven’t picked up this simple concept even after being involved in IT for over 12 years now. Regarding telnetting to port 25 on SMTP servers, I thought that was possible because the SMTP servers had some special telnet service which allowed that.
Note that there's a difference between telneting to a specific port and telneting to the default telnet port, 23. Telnetting to port 23 is for command line access to a remote system. The remote system must have a Telnet daemon/service running to accept connections to port 23 and provide the remote command line services.
From what I found, you can telnet to any open TCP port. The Windows telnet client only uses TCP--you'd need something else if you want to test UDP ports. Microsoft's PortQry tool can be used to test UDP ports. With the telnet client you'll get a blinking cursor in the upper left of the command prompt window, which tells you that the connection was established. If you run a netstat command, you'll see an established connection to the host. If you telnet to an invalid port, you’ll get a connection error message in the command prompt window.
Below are some examples
Telnet to a specific port on the host:
telnet www.novell.com 80
Netstat showing the established connection:
TCP my-computer:49296 www.novell.com:http ESTABLISHED
Telnet to an invalid port:
telnet www.novell.com 7777
Connecting To www.novell.com...Could not open connection to the host, on port 7777: Connect failed
These type of telnet sessions are "raw" TCP/IP network connections to the hosts and don't really do anything other than establish the connection. They're just a means to make a basic connection to a specific port. If I actually want to do anything useful, I’d have to type in some commands. But the host service itself might not accept any user commands from this type of connection. For example, I don't know of anything that can actually be done after telnetting to port 3389 (RDP).
If I'm connected to port 80 (default for HTTP/WWW) I could issue some basic HTTP commands. When using IE to browse a Web site, IE makes a connection to port 80 and issues all the HTTP commands to request the content—this is all done in the background, so all you see is the content in the browser.
If I’m connected to port 25 (default for SMTP), I’d have to issue some SMTP commands. When using an e-mail client, such as Outlook Express, to send e-mail to an ISP's SMTP server, the e-mail client takes all the info in the message—recipient address, message subject, message body, etc. and issues the SMTP commands in the background. All you need to do is hit the send button.
In my case with the Sametime issue, by using telnet to attempt to connect to the Sametime server on port 1533, and not making a successful connection, I was able to determine that it was a network issue and not an application issue with the client.
This blog post has a good example of telnetting to port 80 and issuing a basic HTTP command. From what I can tell, XP/Server 2003 and older Windows OSes have the telnet client installed and enabled by default; Windows 7 does not have the client installed by default, but you can install it manually per http://www.tech-recipes.com.
If you make a successful connection, the command prompt window will usually just sit idle until the telnet session times out and then you'll get a disconnection notification. In the past I've had to close out the entire command prompt window to cancel the session, but I finally decided to do some research on this and found a posting on Velocity Reviews that gave me the fix.
You just need to press CTRL + ] to get out of the telnet session and then type quit to exit telnet and get back to the regular command prompt window. Your last telnet command will still be in the command history so you can run the command again, against another server. For example, I want to test telnetting to port 6001 on all my Exchange Server 2010 mailbox servers. After connecting to the first server I can just cancel out of the telnet session and, using the command history, modify the server name, and connect to the next server.
After pressing CTRL+], you'll get to the main telnet prompt as shown below.
Welcome to Microsoft Telnet Client
Escape Character is 'CTRL+]'
At this point, type quit to get back to the main command prompt window.