What Is Telnet? And Why You Should Use Test-NetConnection Instead

A vendor's install guide says to telnet to the database server on port 1433 and see if it connects. The command comes back "not recognized", and the technician spends ten minutes hunting through Windows features instead of testing the port. This post covers what Telnet is, where it still turns up, and why Test-NetConnection does the port test without installing anything.

What Telnet Is

Telnet is one of the oldest protocols still in use. RFC 854, published in May 1983, defines it as a TCP connection "used to transmit data with interspersed TELNET control information", built to let a terminal on one machine drive a program on another.

The design rests on three ideas from that RFC. Each end pretends to be a Network Virtual Terminal, a standard imaginary terminal, so neither side needs to know the other's hardware. The two ends then negotiate options with four verbs (DO, DON'T, WILL, WON'T) to agree on extras like echo mode. And the connection is symmetric, so either side can ask for a change.

The server listens on TCP port 23 by default, which is why a port scanner reports "telnet" for anything answering there. Microsoft's own command reference still documents the Windows client with the same default, and lets you point it at any port instead.

What the RFC does not contain is any form of encryption. Every keystroke, including the username and the password, crosses the network as readable text. That one fact explains everything that follows, from why SSH replaced it for logins to why the client is switched off on a fresh Windows install.

The video below walks through the protocol and a live session, which is worth five minutes if you have only ever used telnet as a port tester:

Where Telnet Still Shows Up

Telnet did not disappear. It moved into the corners of the network nobody looks at. Older switches and console servers still offer it next to SSH. Industrial controllers, building systems and lab equipment ship with it on because the firmware predates the alternative. And a surprising amount of IoT hardware listens on port 23 with a default password.

That last group is how the Mirai botnet grew. CISA's October 2016 alert describes the malware scanning the internet for devices on ports 23 and 2323 and trying a list of 62 default usernames and passwords. The devices it caught were cameras and routers, not servers, but they sat on the same networks as the servers.

The protocol still produces fresh incidents too. In January 2026, NVD published CVE-2026-24061: the GNU InetUtils telnet daemon let a remote client log in as root by sending a crafted USER value, with a CVSS score of 9.8. The r/sysadmin thread below filled up with people who had spent years asking to switch the daemon off on legacy systems. Our guide on what an exploit means covers how a flaw like that moves from disclosure to a patch window.

The lesson for a small IT team is an inventory question, not a Telnet question. Anything answering on port 23 inside your network is either a device you have forgotten about or a device that cannot be updated, and both belong on a segment of their own.

Why the Telnet Client Is Off by Default on Windows

Microsoft's reference for the telnet command opens with a warning: you must install the client before the command works. On Windows 10 and 11 it sits under Settings, Optional features, More Windows features, as "Telnet Client". The one-line route is PowerShell as an administrator:

powershell
Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient

The cmdlet comes from Microsoft's DISM module, and the feature name is the same one the Windows Features dialog uses. It takes a few seconds and no reboot.

The question is whether you should. The client on its own opens no port and listens for nothing, so it is not a vulnerability in itself. The risk is the habit it supports: a technician who has it will use it to log in to the switch, and that login crosses the wire in the clear. It also tends to stay: the feature survives upgrades, and a year later a vulnerability scan lists "Telnet Client enabled" across half the fleet, which is a finding you then have to explain to an auditor or an insurer.

Keep it on one jump host if you need the interactive mode. Everywhere else, use the built-in.

Test-NetConnection: The Port Test Built Into Windows

Test-NetConnection has shipped with Windows since PowerShell 4, and Microsoft's reference describes what it covers: ping, a TCP test, route tracing and route selection diagnostics. The alias is tnc. The port test is one line:

powershell
Test-NetConnection -ComputerName sql01.corp.local -Port 1433

The result that matters is the last line, TcpTestSucceeded. True means the three-way handshake completed, so the host is up, the port is open, and nothing in between dropped it. False means one of those three failed, and the rest of the output tells you which.

Three switches cover the usual follow-ups. -CommonTCPPort takes a name instead of a number (HTTP, RDP, SMB, WINRM), which saves looking up 5985. -InformationLevel Detailed adds the name resolution results, the matching firewall rules and the route the packet took, which is the difference between "it failed" and "it failed because DNS returned the old address". And -TraceRoute runs the trace in the same command. Our list of PowerShell commands by ticket type has the companion cmdlets for DNS and routing.

The thread below is a technician discovering the Windows Features panel and asking why nothing native tests a port. The cmdlet above is the answer, and one reply makes a fair point worth keeping: the client alone has no security impact. What matters is where it gets used.

Reading the Result

The two booleans in the output tell different stories, and reading them together is the whole skill.

PingSucceeded False with TcpTestSucceeded True is the common case on a managed network. The firewall drops ICMP and lets the port through, so the service is fine. Treat the ping result as noise unless both fail.

Both False means the host is unreachable, the port is closed, or something between you and the host dropped the SYN. Run it again with -InformationLevel Detailed and look at NameResolutionResults first. A stale DNS record sends the test to the wrong machine, and the output shows the address it used. If the address is right, -TraceRoute shows where the path stops; our post on destination host unreachable covers what each reply from a hop means.

PingSucceeded True with TcpTestSucceeded False is the useful one. The host is up and answering, and the port is not. That is a service that is stopped, a listener bound to the wrong interface, or a host firewall rule, and the fix is on the server, not on the network. On the server itself, Get-NetTCPConnection -State Listen shows what is bound where.

Off Windows, the same test is nc -vz host 1433 with netcat, or curl -v telnet://host:1433, since curl speaks the protocol and reports whether the connection opened. Neither needs the Telnet client either.

When Telnet Is Still the Right Tool

Test-NetConnection answers one question: did the handshake complete. It then closes the connection. Sometimes you need to keep it open and type.

Mail is the classic case. Connecting to port 25 and typing EHLO shows you the banner, the advertised extensions and whether the relay accepts a recipient, which no boolean can tell you. The same goes for sending a raw GET to a web server on port 80, or checking what a legacy device prints when you connect to its management port. For anything behind TLS, openssl s_client -connect host:443 does the same job with the encryption on.

For those sessions, the Telnet client on a single admin host is fine, because nothing you type is a credential. The rule is about where it lives, not whether it exists. The same thinking applies to the ports you open on the edge: our guide on port forwarding covers why a port exposed for one test tends to stay exposed.

Across a fleet, the port test is a script, not a session. A loop over Test-NetConnection with the servers and ports a site depends on, run from one machine, turns "the app is slow for some people" into a list of which hosts cannot reach which port. OpenFrame can run that script across a client's devices and collect each device's output in one place, which is how you find the one VLAN where the firewall rule never got copied.

FAQ

Is Telnet secure?

No. RFC 854 defines no encryption, so the username, the password and the whole session cross the network as readable text. Use SSH for logins and keep any remaining Telnet listener on an isolated segment.

What port does Telnet use?

TCP port 23 by default, which is why port scanners label anything answering there as Telnet. The client can connect to any port, and that is the only reason technicians still use it: to see whether a service answers.

How do I test if a port is open without Telnet on Windows?

Run Test-NetConnection -ComputerName host -Port 443 in PowerShell. It ships with Windows, needs nothing installed, and reports TcpTestSucceeded True or False. Add -InformationLevel Detailed for the DNS result and the route it used.

What is the difference between Telnet and SSH?

Both give you a remote terminal over TCP. SSH encrypts the session and authenticates the server; Telnet does neither. SSH replaced Telnet for logins in the 2000s, and the Telnet client survives mainly as a way to poke at a port by hand.

The Short Version

Telnet is a 1983 protocol for driving a remote terminal over TCP port 23, with no encryption anywhere in its design. It still runs on old network gear, industrial kit and IoT devices, which is where the risk lives, and the January 2026 telnetd flaw shows the daemon side still produces critical CVEs. On Windows the client is an optional feature for a reason: the only job technicians use it for, testing whether a port answers, is already built in as Test-NetConnection. Install the client on one jump host for interactive protocol work, use the cmdlet everywhere else, and treat any port 23 listener on your own network as an inventory finding. If the handshake fails, read our guide to the stateful firewall next, because the thing dropping the SYN is usually one of those.