The TCP connection and port 23

Telnet does not move bytes across the network itself. It sits on top of TCP and lets TCP do the transport work: delivery, ordering, retransmission. What Telnet adds is meaning, terminal semantics layered over a reliable byte pipe.

A Telnet session uses one full-duplex TCP connection. Both sides can send data and Telnet control information through the same byte stream, in both directions at once. There is no second connection for control traffic, which has consequences we will explore in a later lesson.

A Telnet server traditionally listens on TCP port 23. The client uses a temporary local port, chosen by the operating system, so the complete connection is identified by both addresses and both ports:

client 192.0.2.10:53144 -> server 192.0.2.20:23

That four-part identifier is why the server can hold sessions with many clients at the same time, and even several sessions from the same client machine. Each one differs in at least the client port.

You can see a live connection’s two endpoints from the client side:

ss -tn | grep :23
# ESTAB  0  0  192.0.2.10:53144  192.0.2.20:23

Port 23 is a convention, not part of the protocol grammar. A Telnet service can listen elsewhere, and a Telnet client can connect to another TCP port. That second half is the interesting one: it is what turns the client into a general tool for poking at text protocols, as you will do later in this course.

Connected is not working

A completed TCP handshake proves that something accepted the connection. It does not prove that the service speaks Telnet correctly, that authentication will work, or that the session is safe.

This distinction sounds obvious and gets forgotten constantly. Connected to 192.0.2.20 means exactly one thing: a process on that machine accepted a TCP connection on that port. It could be a Telnet server, an HTTP server someone started on the wrong port, or a firewall’s decoy.

Keep the layers separate when reasoning about failures. “Can I reach the port?” is a TCP question. “Does the service behave?” is an application question. The whole troubleshooting module of this course builds on telling those apart.