Diagnose a failed session by layer

Start with the exact symptom. “Telnet does not work” hides several different failures, and each one lives at a different layer. The fix for one does nothing for the others.

The client output usually tells you which layer failed, if you read it carefully:

telnet: could not resolve badname.lab.test: Name or service not known
telnet: Unable to connect to remote host: Connection refused
telnet: Unable to connect to remote host: Operation timed out

Three messages, three layers. Let’s take them in order.

Before the connection

If the name does not resolve, inspect DNS. The connection never started, so firewalls and servers are not suspects yet. Test with dig or try the raw IP address instead. If the IP works and the name does not, you have found your layer.

If the connection is refused, the host answered but nothing listens on that port. Inspect the address, the port number, and the listening process on the server side:

ss -tlnp | grep 2323

If that prints nothing, the server is not running or is bound to a different port. If it prints a line, compare the address in it against the one you connected to.

If the connection times out, packets are disappearing. Inspect the route, the firewall, and the address. A refusal is an answer. A timeout is silence. They point at different problems, and mixing them up wastes hours.

After the connection succeeds

If bytes arrive but look strange, inspect Telnet negotiation and terminal settings. A connected session with duplicated or invisible input almost always points to echo negotiation. Broken screen layout points to terminal type or window size.

A login rejection belongs to authentication or account policy. The network did its job. Your connection worked, your credentials or account did not. Do not restart the network stack for a wrong password.

An application that accepts the connection and then misbehaves is yet another layer. The service may speak a different protocol than you expected, or be unhealthy behind a perfectly working port.

Work methodically

Change one layer at a time. If you change the port, the firewall rule, and the server config in one step, a fixed session teaches you nothing about which change mattered. Next time it breaks, you start from zero again.

Preserve the client message, the server log, and a byte trace when negotiation is involved. Evidence is worth more than repeatedly changing ports or disabling checks.

My advice is to write down each test and its result as you go. Five minutes of notes beats an hour of re-testing things you already ruled out.