Core issue
Although IP connectivity exists between the end devices, sometimes IP-based applications like Telnet may not function properly. This problem can occur for a variety of reasons.
If the IP connectivity itself fails, refer to these documents, as applicable:
If the IP connectivity is verified, refer to the resolution section.
Resolution
This network and these components are assumed in the network. You can apply similar troubleshooting checks that fit your network topology:
- Network assumed. Two Sites connected over leased line.
- Components assumed. Server on Site-1, Router(R1) on Site-1, Router(R2) on Site-2 and Host on Site-2.
To resolve this issue, perform these steps:
Check the physical connectivity by pinging the devices end to end. Sometimes the network administrator might have disabled Internet Control Message Protocol (ICMP) packets anywhere in the transit network (for example, R1 or R2). To verify the end to end connectivity, you may want to temporarily disable these filters and pass the ICMP traffic for the ping application to work.If you try to access the server using the hostname rather than its IP address, verify the Domain Name System (DNS) is functioning properly. A simple way to isolate this issue is to connect to the application using the IP address instead of the server name. If the application works with IP address but not with the name, then it must be a DNS resolution issue.If the physical connectivity and DNS issues are verified, perform these steps:- Verify that the application you are trying to access (for example, Telnet) is up and running on the server.
- If the application is running properly, confirm that the server is listening on the well known port for that application. The Telnet well known or standard TCP port # is 23. Telnet clients, by default connect to this Port number on the server. For security reasons, sometimes the administrators configure the server to listen on a non-standard port. In such cases, you must find the correct port number from the administrator and configure the client application accordingly. For the latest list of well known port numbers for various applications refer to PORT NUMBERS
- If the application still does not work, then it is possible that the specific application traffic is blocked by one of the transit devices in the network. In this case, perhaps R1 and R2 are configured with NAT or Access Control List (ACL). If NAT is configured, refer to Internal hosts cannot access the outside network because NAT does not translate. If the ACLs were configured to block the application traffic, punch a hole in those ACLs to allow the specific application traffic. Remember to open up the application on both directions. For more information on ACLs refer to How to filter IP packets.
