Telnet – TCP Port Testing, Remote Access, and Security

1. What Is Telnet?

Telnet (TELetype NETwork) is an application-layer protocol defined in RFC 854 that provides bidirectional, interactive text communication over a TCP connection. It operates on TCP port 23 by default and was originally designed in 1969 as a way to remotely log into and manage computers and network devices over a network — the first widespread remote management protocol.

In modern networks, Telnet has two distinct contexts. As a remote management protocol it is largely retired — all data including passwords is transmitted in plain text, making it trivially interceptable by anyone with packet capture access to the network path. SSH replaced it for secure device management. As a TCP port connectivity testing tool, however, Telnet remains extremely useful — its ability to open a raw TCP connection to any port number makes it the quickest way to verify whether a specific TCP port is open, closed, or filtered.

  Telnet dual role:

  Role 1 — Remote management (LEGACY, avoid in production):
  Admin workstation ──telnet──→ Router/Switch port 23
                              ← all traffic plain text including passwords!
                              Replaced by SSH (port 22)

  Role 2 — TCP port connectivity testing (CURRENT primary use):
  Admin workstation ──telnet [IP] [port]──→ any TCP port on any host
                                           Tests firewall rules, ACLs,
                                           service availability

2. How Telnet Tests TCP Port Connectivity

When you run telnet [host] [port], the Telnet client attempts a standard TCP three-way handshake (SYN → SYN-ACK → ACK) to the target host and port. The result of that TCP connection attempt tells you exactly what is happening at the network and transport layers — far more precisely than ping, which only tests ICMP reachability at Layer 3 and says nothing about whether a specific TCP service is accessible.

  What Telnet tests vs what ping tests:

  ping 192.168.1.10
  → Tests: Is the host reachable at Layer 3 (ICMP)?
  → Does NOT test: Is TCP port 80 open? Is port 443 blocked by the firewall?
  → A host can respond to ping but have ALL TCP ports blocked by ACL.

  telnet 192.168.1.10 80
  → Tests: Can I complete a TCP three-way handshake to port 80?
  → If yes: the host is reachable AND the service is listening on port 80
            AND no firewall between me and the host is blocking TCP/80
  → If refused: host reachable but nothing listening on port 80
  → If timeout: something between me and the host is blocking TCP/80
                (or the host itself is dropping packets rather than refusing)

  Critical insight: "connection refused" means the host is REACHABLE
  (the TCP packet got there) but nothing is listening on that port.
  "Timeout" means the packet never got a response — firewall or routing.

Telnet Syntax

  telnet [hostname or IP address] [port]

  If port is omitted → defaults to port 23 (Telnet service)

  Examples:
  telnet 192.168.1.10            → connects to port 23 (Telnet management)
  telnet 192.168.1.10 80         → tests TCP port 80 (HTTP)
  telnet 192.168.1.10 22         → tests TCP port 22 (SSH)
  telnet mail.example.com 25     → tests TCP port 25 (SMTP)
  telnet 10.0.0.1 443            → tests TCP port 443 (HTTPS)

3. Telnet Output — All Results Annotated

There are four possible Telnet outcomes. Knowing what each one means — and specifically the difference between "refused" and "timeout" — is essential for the CCNA exam and for real-world troubleshooting.

Result 1 — Port Open, No Banner (Blank Screen)

  $ telnet 192.168.1.10 80

  Trying 192.168.1.10...
  Connected to 192.168.1.10.
  Escape character is '^]'.
  _                          ← cursor blinking, waiting for your input

  Meaning: TCP three-way handshake SUCCEEDED.
  The port is open and the service is listening.
  HTTP does not send a banner until the client sends an HTTP request —
  so you see a blank screen. Type "GET / HTTP/1.0" and press Enter twice
  to send a manual HTTP request and see the server's response.

  How to close: Press Ctrl+] then type "quit" at the telnet> prompt.

Result 2 — Port Open with Protocol Banner

  $ telnet 10.0.0.5 22

  Trying 10.0.0.5...
  Connected to 10.0.0.5.
  Escape character is '^]'.
  SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5    ← SSH server banner

  Meaning: TCP connection SUCCEEDED and the server sent its banner.
  The banner confirms: (1) port is open, (2) the correct service is running,
  (3) the version (useful for patch management).
  Common services that send banners: SSH (SSH-2.0-...), SMTP (220 ...),
  FTP (220 ...), POP3 (+ OK ...), IMAP (* OK ...).

Result 3 — Connection Refused (Port Closed)

  $ telnet 192.168.1.10 8080

  Trying 192.168.1.10...
  telnet: Unable to connect to remote host: Connection refused

  (Windows equivalent):
  Connecting To 192.168.1.10...Could not open connection to the host,
  on port 8080: Connect failed

  Meaning: TCP SYN packet REACHED the host, but the host sent back a
  TCP RST (reset) — meaning no service is listening on this port.
  The HOST IS REACHABLE. The port is closed (no listener).
  This is NOT a firewall block — it is the host actively refusing.

  Key distinction from timeout:
  Refused  = host responded quickly with RST  → no service on this port
  Timeout  = no response at all               → firewall or routing block

Result 4 — Connection Timed Out (Filtered/Blocked)

  $ telnet 203.0.113.25 25

  Trying 203.0.113.25...
  telnet: Unable to connect to remote host: Connection timed out
  (hangs for 30–120 seconds before displaying this)

  Meaning: TCP SYN packet was sent but NO response was ever received.
  The SYN packet was dropped silently — never reached the destination,
  or was dropped by the destination without a response.

  Possible causes:
  → A firewall with a DROP rule (vs REJECT — REJECT sends RST immediately)
  → An ACL on a router along the path dropping the TCP flow
  → The destination host is down (but network gear forwards packets to it)
  → Routing issue — packets routed to wrong next-hop and dropped
  → ISP blocking the port (common for SMTP port 25 from residential IPs)

  The timeout wait: Telnet waits the TCP connection timeout period
  (often 30–120 seconds on most OS) before giving up — this long wait
  IS the diagnostic signal that something is silently blocking.

Telnet Result	TCP Behaviour	What It Means	Next Troubleshooting Step
Connected (blank screen or banner)	SYN → SYN-ACK → ACK — handshake complete	Port open, service listening, no firewall blocking this path	Service is reachable — investigate application-layer issues
Connection refused	SYN → RST — host reached, port rejected	Host is reachable; no service listening on this port; no firewall blocking	Check if the service is running; check the port number; check service config
Connection timed out (long wait)	SYN → (silence) — packet dropped	Firewall, ACL, or routing is silently dropping TCP SYN packets to this port	Check firewall rules; check ACLs on intermediate routers; trace the path with traceroute
Unknown host / Name resolution failure	No TCP attempted — DNS failed first	DNS cannot resolve the hostname to an IP address	Verify DNS with `nslookup` or `dig`; try the IP address directly

4. Common TCP Ports to Test with Telnet

Service	TCP Port	Test Command	Expected Banner on Success
HTTP (web)	80	`telnet [host] 80`	Blank screen (HTTP waits for client request first)
HTTPS (web TLS)	443	`telnet [host] 443`	Garbled binary (TLS handshake data — confirms port open)
SSH	22	`telnet [host] 22`	`SSH-2.0-OpenSSH_8.x`
Telnet management	23	`telnet [host]`	Login prompt or device banner
SMTP (email send)	25	`telnet [host] 25`	`220 mail.example.com ESMTP Postfix`
DNS (TCP queries)	53	`telnet [host] 53`	Blank (DNS-over-TCP waits for query) — but note DNS primarily uses UDP/53
POP3 (email retrieve)	110	`telnet [host] 110`	`+OK POP3 server ready`
IMAP (email)	143	`telnet [host] 143`	`* OK IMAP4rev1 service ready`
HTTPS alternate	8443	`telnet [host] 8443`	Garbled binary (TLS)
HTTP alternate	8080	`telnet [host] 8080`	Blank (like port 80)
RDP (Windows Remote Desktop)	3389	`telnet [host] 3389`	Garbled binary (RDP protocol data)

Important: Telnet tests TCP ports only. It cannot test UDP ports. DNS primarily uses UDP port 53 — telnet [host] 53 tests the TCP/53 path only, which is used for large DNS responses and zone transfers, not regular DNS queries. See Common Port Numbers for a full reference.

5. Telnet Client Availability — How to Install and Use

Windows

  Telnet is NOT enabled by default on Windows Vista and later.

  Option 1 — GUI: Control Panel → Programs → Turn Windows features on or off
  → Tick "Telnet Client" → OK → Wait for installation

  Option 2 — Command Prompt (run as Administrator):
  dism /online /Enable-Feature /FeatureName:TelnetClient

  Option 3 — PowerShell (run as Administrator):
  Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient

  Verify installation:
  C:\> telnet
  Microsoft Telnet> quit

  Modern alternative (no install needed):
  PowerShell> Test-NetConnection 192.168.1.10 -Port 80
  → Directly tests TCP connectivity with clear True/False output

Linux

  # Check if already installed:
  which telnet

  # Ubuntu/Debian — install telnet client:
  sudo apt install telnet -y

  # RHEL/CentOS/Rocky — install telnet client:
  sudo dnf install telnet -y

  # macOS — install via Homebrew:
  brew install telnet

  # Basic test:
  telnet 192.168.1.10 22

Cisco IOS — Telnet as a Client

  ! Cisco IOS can initiate Telnet connections as a client:
  Router# telnet 192.168.1.10
  Router# telnet 192.168.1.10 80    ! test TCP port 80

  ! To exit a Cisco Telnet session back to local device:
  Press Ctrl+Shift+6, then X    ! suspends the Telnet session
  Router# disconnect             ! disconnects all Telnet sessions

  ! List active Telnet sessions from the router:
  Router# show sessions

6. Telnet for Remote Device Management — Cisco VTY Configuration

On Cisco devices, Telnet (and SSH) access is managed through the VTY (Virtual Teletype) lines. These are virtual terminal sessions — the lines that handle remote management connections to the device. Configuration here controls whether Telnet is permitted, restricted, or replaced by SSH.

Basic Telnet Access on Cisco IOS

  ! Enable password authentication on VTY lines:
  Router(config)# line vty 0 4          ! configure VTY lines 0 through 4
  Router(config-line)# password cisco   ! set the Telnet login password
  Router(config-line)# login            ! require password for Telnet access
  Router(config-line)# transport input telnet   ! explicitly allow Telnet only

  ! Enable Telnet AND SSH (both permitted):
  Router(config-line)# transport input telnet ssh

  ! Restrict source IPs with an ACL:
  Router(config)# access-list 10 permit 192.168.1.0 0.0.0.255
  Router(config-line)# access-class 10 in   ! only IPs in ACL 10 can connect

  ! Verify VTY configuration:
  Router# show running-config | section line vty

Disable Telnet — Allow SSH Only (Security Best Practice)

  ! Block Telnet; allow only SSH on VTY lines:
  Router(config)# line vty 0 4
  Router(config-line)# transport input ssh    ! telnet connections rejected

  ! Verify: attempt Telnet from a workstation → should be refused
  $ telnet 192.168.1.1
  Trying 192.168.1.1...
  telnet: Unable to connect to remote host: Connection refused
  ! "Connection refused" confirms Telnet is blocked on VTY — SSH still works.

See: Named ACLs | Applying ACLs to VTY lines | SSH Configuration | SSH & Telnet Security | Step-by-Step: SSH Configuration

7. Telnet vs SSH — Security Comparison

SSH (Secure Shell) was designed specifically as a secure replacement for Telnet. For the CCNA exam, understanding the differences — and being able to configure SSH on a Cisco device — is a required skill.

Feature	Telnet	SSH
Default port	TCP 23	TCP 22
Encryption	None — all traffic in plain text	Strong encryption (AES, ChaCha20)
Authentication	Simple password (plain text)	Password or public-key cryptography
Password visibility	Username and password visible in any packet capture on the path	Username and password encrypted; not visible in captures
Integrity protection	None — commands can be modified in transit (man-in-the-middle)	HMAC integrity checking — modified packets are detected and rejected
Use for device management	Not recommended; use only in isolated labs or when SSH is unavailable	Recommended for all production Cisco device management
Use for port testing	Yes — primary modern use case	Not applicable (SSH is a management protocol, not a port test tool)
Cisco IOS availability	Available on all IOS versions by default	Requires crypto key generation and IP domain name configuration

Why Plain Text Is Dangerous — Packet Capture Demonstration

  Telnet session captured on Wireshark (any attacker on the same LAN can do this):

  Frame 1:  Client → Router  "u"   ← user types login credentials
  Frame 2:  Client → Router  "s"
  Frame 3:  Client → Router  "e"
  Frame 4:  Client → Router  "r"
  ...
  Frame 12: Client → Router  "c"   ← password begins
  Frame 13: Client → Router  "i"
  Frame 14: Client → Router  "s"
  Frame 15: Client → Router  "c"
  Frame 16: Client → Router  "o"
  → Username: user, Password: cisco — fully reconstructed from capture

  SSH session captured on Wireshark:
  TLSv1.3 Application Data [encrypted]  ← nothing readable
  TLSv1.3 Application Data [encrypted]
  → No credentials visible regardless of how long the capture runs

8. Alternative Tools for TCP Port Testing

Telnet is not always available — it is disabled by default on modern Windows and may be absent on locked-down systems. Several alternatives cover the same use case and add capabilities Telnet lacks.

Tool	Platform	Command Example	Advantage Over Telnet
PowerShell Test-NetConnection	Windows (built-in, no install)	`Test-NetConnection 192.168.1.10 -Port 80`	Always available on Windows 8+; clear TcpTestSucceeded: True/False output; also shows ping result and traceroute in one command
Netcat (nc)	Linux, macOS, Windows	`nc -vz 192.168.1.10 22`	Tests both TCP and UDP ports; supports scripting; can act as a listening server for bidirectional tests; `-z` = scan only (don't send data)
Nmap	Linux, Windows, macOS	`nmap -p 22,80,443 192.168.1.10`	Scans multiple ports simultaneously; detects service versions; OS fingerprinting; comprehensive network audit tool
curl	Linux, macOS, Windows	`curl -v telnet://192.168.1.10:80`	Can test HTTP/HTTPS and many other protocols with protocol-aware responses; shows HTTP headers and response codes
OpenSSL	Linux, macOS, Windows	`openssl s_client -connect 192.168.1.10:443`	Tests TLS-encrypted ports (HTTPS, SMTPS, IMAPS) that Telnet cannot properly test; shows certificate details and TLS negotiation

PowerShell Test-NetConnection — Annotated Output

  PS C:\> Test-NetConnection 192.168.1.10 -Port 80

  ComputerName           : 192.168.1.10
  RemoteAddress          : 192.168.1.10
  RemotePort             : 80
  InterfaceAlias         : Ethernet
  SourceAddress          : 192.168.1.50
  TcpTestSucceeded       : True     ← TCP port open (same as Telnet "Connected")

  PS C:\> Test-NetConnection 192.168.1.10 -Port 8080

  TcpTestSucceeded       : False    ← TCP port closed or filtered
  PingSucceeded          : True     ← but host IS reachable via ICMP
  → Port 8080 blocked/closed; host is up (same as Telnet "refused" or "timeout")

  ! Test-NetConnection does not distinguish between "refused" and "timeout"
  ! (both show False). Telnet is more informative for that distinction.

9. Step-by-Step Troubleshooting Scenarios

Scenario A — Web Server Port 80 Not Accessible

  Problem: Users cannot reach the company website at 192.168.10.10.

  Step 1: Test with ping to check Layer 3 reachability:
  $ ping 192.168.10.10
  Reply from 192.168.10.10: bytes=32 time=1ms TTL=64   ← host is UP and reachable

  Step 2: Test TCP port 80 with Telnet:
  $ telnet 192.168.10.10 80
  Trying 192.168.10.10...
  telnet: Unable to connect to remote host: Connection refused
  ← Refused (not timeout) → host reachable, port 80 has NO listener

  Diagnosis: The web service (Apache/Nginx/IIS) is not running.
  Fix: Start the web service on 192.168.10.10.

  Alternative result (timeout):
  $ telnet 192.168.10.10 80
  Trying 192.168.10.10...
  [hangs 30-120 seconds]
  telnet: Unable to connect to remote host: Connection timed out
  ← Timeout → a firewall or ACL is dropping TCP/80 packets

  Diagnosis: Firewall between the client and web server blocking port 80.
  Fix: Check ACL on the router or firewall rules; add permit rule for TCP/80.

Scenario B — Testing SSH Server Availability

  Problem: Engineer cannot SSH to server at 10.0.0.5.

  Step 1: Test TCP port 22 with Telnet:
  $ telnet 10.0.0.5 22
  Trying 10.0.0.5...
  Connected to 10.0.0.5.
  Escape character is '^]'.
  SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
  ← Port open, SSH server running, banner confirms version

  Interpretation: Port 22 is open and reachable. The SSH service IS running.
  The connectivity problem is NOT at the TCP layer.
  Next step: investigate SSH authentication — wrong username, wrong key,
  or host key changed.

  Alternative result (refused):
  telnet: Unable to connect to remote host: Connection refused
  → SSH service is not running. Start the SSH daemon: sudo systemctl start sshd

  Alternative result (timeout):
  [hangs then times out]
  → Firewall dropping TCP/22. Check ACL: show access-lists on router.

Scenario C — Diagnosing SMTP Server Issue

  Problem: Email clients cannot send email through mail.example.com.

  Step 1: Test TCP port 25 with Telnet:
  $ telnet mail.example.com 25
  Trying 203.0.113.25...
  Connected to mail.example.com.
  Escape character is '^]'.
  220 mail.example.com ESMTP Postfix
  ← Port 25 open, SMTP server running and responding

  Step 2: Continue the SMTP test manually to verify email delivery:
  EHLO myhost.example.com
  250-mail.example.com
  250 OK
  MAIL FROM: <[email protected]>
  250 OK
  RCPT TO: <[email protected]>
  250 OK
  DATA
  354 End data with <CR><LF>.<CR><LF>
  Subject: Test
  This is a test.
  .
  250 Message accepted for delivery
  QUIT

  ! Using Telnet to manually walk through the SMTP conversation is the
  ! definitive way to diagnose mail server problems at the protocol level.
  ! A successful SMTP walkthrough proves the server is accepting mail.

  Timeout result:
  $ telnet mail.example.com 25
  [hangs 30s then:]
  Connection timed out
  → ISP may be blocking outbound TCP/25 (very common to prevent spam).
  → Try submission port 587 instead: telnet mail.example.com 587

Scenario D — Identifying External vs Internal Firewall Block

  Problem: Web application works from inside the office but not from home.

  Internal test (from inside office LAN):
  $ telnet 192.168.1.100 443
  Connected — port 443 open internally ✓

  External test (from home internet connection):
  $ telnet www.company.com 443
  [hangs then:] Connection timed out  ← externally blocked!

  Diagnostic conclusion:
  The service IS running (internal test passed). Something between the
  internet and the server is blocking TCP/443 externally.

  Possible causes:
  1. Edge firewall/router ACL not permitting inbound TCP/443
  2. NAT rule missing (static NAT not configured for the server)
  3. ISP filtering — unlikely for port 443 but possible
  4. Load balancer VIP not configured for external access

  Systematic check:
  → show access-lists on edge router: look for permit tcp any host [server] eq 443
  → show ip nat translations: confirm static NAT entry for the server exists
  → ping from outside: if ping works but Telnet times out, ACL is the cause

10. Security Considerations — When and Where to Disable Telnet

Context	Telnet Risk	Recommended Action
Cisco routers and switches in production	Any Telnet session exposes the device's enable password and configuration commands in clear text — any host on the path (including other devices on the same LAN segment) can capture credentials	Disable Telnet on VTY lines: `transport input ssh`; configure SSH with RSA keys and login local authentication. See SSH Configuration guide
Network device accessible from internet	Telnet port 23 is actively scanned by automated bots — open Telnet is a known attack vector; default credentials are tried automatically	Block TCP/23 at the edge firewall; apply ACL restricting VTY access to management subnet only; use SSH exclusively
Packet Tracer and lab environments	Low risk in isolated labs with no real sensitive data	Acceptable to use Telnet for lab exercises; practice configuring both Telnet and SSH to understand the difference
Port testing on production networks	Very low — Telnet as a test client (not server) does not expose credentials; only the test connection is made and immediately closed	Acceptable use; prefer PowerShell Test-NetConnection or Netcat if Telnet is not installed

11. Exam Tips & Key Points

Telnet uses TCP port 23 by default. It is an application-layer protocol that transmits all data in plain text — including usernames, passwords, and commands.
Telnet tests TCP ports only. It cannot test UDP ports. DNS primarily uses UDP/53 — telnet [host] 53 tests the TCP/53 path, not normal DNS operation.
Know all three Telnet results and what each means: Connected/banner (port open, service running), Connection refused (host reachable, port closed — no listener, no firewall block), Timeout (firewall or ACL dropping packets silently).
The critical exam distinction: refused ≠ timeout. Refused means the host responded with RST. Timeout means no response — a firewall is the likely cause.
Telnet syntax: telnet [host] [port]. Port is optional; omitting it defaults to port 23.
On Cisco VTY lines: transport input telnet allows Telnet; transport input ssh blocks Telnet and allows only SSH; transport input telnet ssh allows both.
SSH (port 22) is the secure replacement for Telnet — it encrypts all data including credentials. Never use Telnet for production device management. See SSH & Telnet Security.
Telnet client is not installed by default on Windows — enable it via Turn Windows Features On or Off, or use Test-NetConnection instead.
Protocol banners revealed by Telnet (SSH-2.0-OpenSSH, 220 SMTP, +OK POP3) confirm both connectivity and the correct service is running on that port.
For Telnet to test HTTPS (port 443), you will see garbled binary output — this still confirms the TCP port is open, but you cannot read the content because TLS encryption is active.

12. Summary Reference Table

Topic	Key Detail
Telnet default port	TCP 23
Protocol type	Application-layer, plain text, TCP only
Syntax	`telnet [host] [port]` (port defaults to 23)
Connected = blank screen or banner	TCP port open; service listening; no firewall block
Connection refused	Host reachable; port closed (no listener); TCP RST received
Connection timed out	Firewall/ACL dropping packets silently; no RST received
Can test UDP?	No — TCP only
Secure replacement	SSH (TCP 22) — encrypted, authenticates, integrity-checked
Cisco VTY — allow Telnet only	`transport input telnet`
Cisco VTY — disable Telnet	`transport input ssh`
Windows Telnet install	Turn Windows Features On or Off → Telnet Client
Windows alternative	`Test-NetConnection [host] -Port [n]`
Linux alternative	`nc -vz [host] [port]` (Netcat)

Telnet Quiz

1. What is Telnet's default TCP port, and what distinguishes its modern primary use from its original purpose?

A. TCP port 22 — originally for file transfer; now primarily used for encrypted remote access to Cisco devices B. TCP port 23 — originally designed for remote device management (login and command execution); its primary modern use is testing whether specific TCP ports are open, closed, or filtered, because it transmits everything in plain text making it insecure for management C. TCP port 80 — originally for web access; now used for HTTP header inspection and web server configuration testing D. TCP port 25 — originally for email relay; now used to test SMTP server connectivity and diagnose mail delivery failures

Correct answer is B. Telnet uses TCP port 23 by default and is one of the oldest application-layer protocols (RFC 854, 1983). It was designed as the first widespread remote management protocol — allowing engineers to log in to remote computers and network devices over TCP/IP. It was widely used to manage routers, switches, and UNIX servers. Its fatal flaw: all data, including usernames, passwords, and commands, is transmitted in complete plain text. Any host on the network path can capture and read Telnet sessions trivially with a packet analyser. SSH replaced it for management. Today, Telnet's main value is as a TCP port test tool —

telnet [host]
                  [port]

attempts a TCP three-way handshake to any port number, telling you in seconds whether the port is open, closed, or blocked by a firewall.

2. Which command syntax correctly tests TCP port 80 connectivity to www.example.com using Telnet?

A. telnet www.example.com — omitting the port connects to port 80 by default when HTTP is detected B. telnet 80 www.example.com — the port number comes before the hostname C. telnet -p 80 www.example.com — the -p flag specifies the port number before the hostname D. telnet www.example.com 80 — the correct syntax is hostname/IP first, then port number; omitting the port defaults to 23

Correct answer is D. Telnet syntax is: telnet [hostname or IP address] [port]. The hostname or IP address always comes first; the port number follows. If the port is omitted, Telnet defaults to port 23 (the Telnet management service). To test HTTP on port 80: telnet www.example.com 80. To test SSH on port 22: telnet 192.168.1.10 22. To test SMTP on port 25: telnet mail.example.com 25. None of the other option syntaxes are valid — Telnet does not use a -p flag, and the port number does not come before the hostname. This command syntax is a frequent CCNA exam question because it tests whether students understand that Telnet can be used to test any TCP port, not just port 23.

3. Telnet to 192.168.1.10 port 80 returns "Connected to 192.168.1.10" and then a blank screen. What does this indicate?

A. The TCP three-way handshake succeeded — port 80 is open, the web service is listening, and no firewall between client and server is blocking TCP/80; the blank screen is normal for HTTP because the server waits for the client to send an HTTP request before responding B. The TCP port is closed or filtered — a blank screen indicates the server rejected the connection silently C. There is a DNS resolution error — the blank screen means the hostname could not be resolved to an IP address D. A firewall is blocking ICMP traffic, which is preventing the banner from being displayed

Correct answer is A. When Telnet outputs "Connected to [host]" and then shows a blank screen (with a blinking cursor), it means the TCP three-way handshake completed successfully. The port is open and accepting connections. The blank screen is entirely normal for HTTP (port 80) — HTTP is a request-response protocol where the server waits for the client to send an HTTP request before sending anything. The Telnet session is sitting in an open TCP connection but neither side has exchanged any HTTP data yet. Services that proactively send a banner (SSH, SMTP, FTP, POP3) show their banner text immediately. Services that wait for client input (HTTP, HTTPS) show a blank screen. Both indicate the port is open. The "Escape character is '^]'" line that often follows the connection line is also a normal part of Telnet's own connection output — it shows you the key sequence to interrupt the session.

4. Telnet to a host returns "Connection refused" almost immediately. What does this tell you, and how does it differ from a timeout?

A. The Escape character '^]' prompt means the connection was temporarily interrupted and will retry automatically B. "Connected to host" — the connection succeeded but the service is configured to refuse non-authenticated sessions C. The host IS reachable (the TCP SYN packet arrived and the host responded with a TCP RST), but no service is listening on that port — no firewall is involved; a timeout (slow, no response) would indicate a firewall is silently dropping packets instead D. A 220 SMTP banner means the mail server rejected the sender address and refused the connection

Correct answer is C. "Connection refused" is one of the most information-dense Telnet results. It tells you two things simultaneously: (1) The host is reachable — the TCP SYN packet got there (Layer 3 routing and any intermediate firewalls are not blocking this packet); (2) The port is closed — the host responded with a TCP RST (reset) packet immediately, which is the TCP stack's way of saying "nothing is listening on this port." A firewall with a DROP rule would not send RST — it would silently discard the packet, causing a timeout (the client waits 30–120 seconds with no response). "Connection refused" = fast rejection = port closed. "Timeout" = slow or no response = firewall drop rule or routing failure. This distinction is a classic CCNA exam question. Fix for "refused": start the service. Fix for "timeout": investigate firewall/ACL rules.

5. Why is Telnet strongly discouraged for remote management of Cisco devices in production, and what specific attack does plain-text transmission enable?

A. Telnet cannot test TCP connectivity — it only supports remote management sessions and lacks any diagnostic capability B. Telnet sends all data including usernames, passwords, and commands in plain text — any device on the network path with packet capture (Wireshark, tcpdump) can reconstruct every keystroke; this enables credential theft without the engineer's knowledge C. Telnet only works on UDP ports — this makes it incompatible with Cisco devices that use TCP for management connections D. Telnet requires complex RSA key configuration — this complexity makes it error-prone and therefore it should not be used in production

Correct answer is B. Telnet has zero encryption — every byte sent between the Telnet client and the device is transmitted as plain ASCII text in TCP payload. This means any host on the same LAN segment, or any device on the routed path between client and device, that captures network traffic can trivially read the entire session. Using Wireshark, an attacker can follow the TCP stream and see each character typed, including the username and password. In a switched network, this requires the attacker to be on the same VLAN as either the admin workstation or the device being managed, but this is a realistic threat model. SSH (Secure Shell, TCP port 22) solves this completely — it encrypts the entire session from the moment the connection is established. Even if an attacker captures every SSH packet, they see only encrypted ciphertext. For the CCNA: always recommend SSH over Telnet for device management; know how to configure transport input ssh on VTY lines.

6. Which of the following is NOT a valid modern use case for Telnet, and why?

A. Secure remote management of a production Cisco router — Telnet transmits all session data including enable passwords in plain text, making it unsuitable for any security-sensitive management session in a real network B. Testing TCP port 25 to check whether an SMTP server is reachable and responding C. Troubleshooting a firewall ACL by testing whether TCP/443 is permitted from a specific network segment D. Verifying that an SSH server is running and accessible by connecting to TCP port 22 and reading the SSH banner

Correct answer is A. Secure remote management is the one use case Telnet absolutely should not be used for in any production environment. The other three options — testing TCP port connectivity, troubleshooting firewall rules, and verifying service availability — are all legitimate and common modern uses of Telnet. These uses involve Telnet acting as a TCP test client that opens a connection and immediately closes it; no sensitive credentials are exchanged. The problem arises specifically when Telnet is used to log into and manage devices, because the management credentials (Telnet password, enable password) and every configuration command typed are sent in clear text. For device management in production: configure transport input ssh on all VTY lines, generate RSA keys, and use login local with username-based authentication.

7. Telnet shows "Unable to connect to remote host: Connection timed out" after waiting over a minute. What is the most likely cause, and how does the wait time itself serve as a diagnostic clue?

A. The port is open and responding — a very long response time indicates the service is processing a heavy workload B. The host is completely unreachable — a timeout always means the host is powered off or has no network connectivity C. The service is responding slowly due to a heavily loaded server D. A firewall or ACL with a DROP rule is silently discarding the TCP SYN packets — the long wait is itself the diagnostic signal; a DROP (no response) causes the full TCP timeout, whereas a REJECT (RST) would appear as "Connection refused" almost instantly

Correct answer is D. A connection timeout is the fingerprint of a firewall DROP rule or a silent ACL deny. When a TCP SYN packet is dropped (not rejected), the sending client has no way to know what happened — it simply never receives a SYN-ACK or a RST. So the TCP stack waits for the full connection timeout period (typically 30–120 seconds depending on the OS) before giving up. This long wait IS the diagnostic: it means the packet is being silently discarded. A firewall configured with REJECT (or a router that actively refuses the connection) would send back a TCP RST almost instantly, causing "Connection refused" with no wait. "Connection refused" = RST = fast = port closed. "Timeout" = silence = slow = DROP rule. The host may still be reachable (ping might work) — the timeout only tells you about that specific TCP port. Next steps: check ACLs on routers in the path, firewall rules, and whether the host itself is dropping packets.

8. Telnet client is not available on a Windows workstation. What is the recommended built-in alternative that requires no installation?

A. Telnet is enabled by default on all versions of Windows — no action is needed; it can be found in the Accessories program group B. Run the Telnet installation command from CMD: "install telnet" — this downloads and installs the client silently C. Use PowerShell's Test-NetConnection cmdlet: "Test-NetConnection [host] -Port [n]" — built into Windows 8 and later with no installation required; returns TcpTestSucceeded: True/False D. Download the Telnet app from the Microsoft Store — Microsoft provides a free Telnet client through its app marketplace

Correct answer is C. The Telnet client is disabled by default on Windows Vista and all later versions of Windows (including Windows 10 and 11). To install it: Control Panel → Programs → Turn Windows features on or off → Telnet Client, or via PowerShell:

Enable-WindowsOptionalFeature -Online -FeatureName
                  TelnetClient

. However, the better built-in alternative that requires no installation is PowerShell's Test-NetConnection. Available since Windows 8: Test-NetConnection 192.168.1.10 -Port 80 performs the TCP connection test and returns a clear TcpTestSucceeded: True or False result. It also simultaneously shows whether ICMP ping succeeded (PingSucceeded) — making it more informative than Telnet alone. The limitation vs Telnet: it does not distinguish between "refused" (port closed) and "timeout" (filtered) — both return False. Telnet's fast-refusal vs slow-timeout distinction is more diagnostic for firewall investigation.

9. When configuring Cisco VTY lines to disable Telnet and allow only SSH, which command achieves this, and what does a user experience if they attempt a Telnet connection afterward?

A. Netcat — "nc -vz" provides SSH-encrypted management sessions that are more secure than both standard Telnet and SSH B. transport input ssh in the VTY line configuration — a subsequent Telnet attempt to the device immediately returns "Connection refused" because the IOS TCP stack rejects the Telnet connection with a TCP RST C. Nmap — "nmap -p 22" provides both port scanning and encrypted management capabilities D. PowerShell — "Test-NetConnection" provides encrypted remote management sessions as an alternative to both Telnet and SSH

Correct answer is B. On Cisco IOS VTY lines, the transport input command controls which protocols are accepted for incoming management sessions: transport input telnet — accepts Telnet only; transport input ssh — accepts SSH only (Telnet rejected); transport input telnet ssh — accepts both; transport input none — rejects all remote access. When transport input ssh is configured and someone attempts telnet [device-ip], the device's TCP stack sends back a TCP RST immediately — the Telnet client sees "Connection refused" almost instantly. This is actually a useful verification step: if you get "Connection refused" when trying to Telnet to a device you just configured with transport input ssh, that confirms the configuration is working correctly. SSH connections to the same device continue to work normally. The full configuration for SSH-only access: line vty 0 4 / transport input ssh / login local.

10. A network engineer uses "telnet 192.168.1.10 53" to test DNS. The connection times out. Why is this result misleading, and what is the correct tool for testing DNS?

A. Port 80 (HTTP) cannot be tested with Telnet — only UDP ports below 1024 are supported by the Telnet client B. Port 22 (SSH) is the correct port to test DNS — the DNS service runs on SSH as a secondary service on modern BIND servers C. Port 25 (SMTP) is the correct port for DNS testing because email relies on DNS MX record lookups D. Telnet only tests TCP ports — DNS primarily uses UDP port 53 for regular queries; a TCP/53 timeout does NOT mean DNS is broken; use nslookup or dig to test DNS functionality directly

Correct answer is D. This question tests the critical limitation of Telnet: it only tests TCP ports. DNS uses UDP port 53 for standard queries (A records, AAAA, MX, NS, etc.) and TCP port 53 only for large responses (over 512 bytes, such as DNSSEC-signed responses and zone transfers via AXFR). So when you run telnet [dns-server] 53 and see a timeout or "Connection refused", this tells you nothing about whether DNS is working — it only tells you about the TCP/53 path, which is normally not needed for DNS. The DNS server might be responding perfectly to UDP/53 queries while having TCP/53 blocked by a firewall. To test actual DNS functionality: on Windows:

nslookup www.example.com
                  192.168.1.1

(queries the specified DNS server); on Linux/macOS: dig @192.168.1.1 www.example.com. Both tools send UDP DNS queries and display the actual DNS response.