Port 20 and 21: FTP (File Transfer Protocol)

File Transfer Protocol has been moving files across the Internet since the 1970s—before the web existed, before most people had heard of the Internet, before we learned to distrust incoming connections. Its two-port architecture, elegant when designed, now collides with fundamental assumptions of modern networking.

Understanding why FTP uses two ports, and why that causes problems, reveals what happens when a protocol outlives the trust model it was built for.

Two Ports, Two Channels

FTP separates control from data. Port 21 handles the conversation: authentication, commands like LIST and RETR, directory navigation. This connection stays open throughout your session, maintaining state.

Port 20 handles the payload—actual file contents, directory listings, binary data. This separation lets you issue commands while transfers are in progress and lets the protocol establish and tear down data connections without disrupting the command session.

The control channel on port 21 negotiates each data transfer: what's being sent, how to connect, which port to use. Then the data flows separately. A clean design for its era.

Active Mode: When Servers Called You Back

In active FTP mode, you connect to the server's port 21 and authenticate. When you want data, you send a PORT command that says, essentially, "I'm listening on port 5001—send the data there."

The server then initiates a new connection from its port 20 to your specified port. The data flows. Transfer complete.

This worked beautifully in the early Internet. Machines had real IP addresses. Networks were flat. If you told a server to connect to you, it could.

Then we put firewalls everywhere.

The PORT command is FTP saying "call me back at this number." When you're behind a firewall, that callback gets dropped. The firewall sees an unsolicited incoming connection from some server's port 20 and rejects it. The server thinks the connection failed. The client waits for data that never arrives.

Active mode FTP is effectively dead for most users—not because of a bug, but because the Internet stopped trusting incoming connections.

Passive Mode: The Workaround

Passive mode reverses the data connection. Instead of PORT, you send PASV. The server responds with an IP address and port where it's listening—something like "connect to me at 10.0.0.5 port 52341."

Now you initiate both connections: control to port 21, data to the server's specified port. Both are outbound from your perspective. Firewalls allow outbound connections. Problem solved.

Except passive mode creates its own problem: the server must listen on a range of high ports for incoming data connections. A typical configuration opens ports 50000-50100. That's 100 potential entry points instead of two. Server firewalls must allow this entire range, expanding the attack surface.

We traded one hole in the firewall for a hundred.

The Security Problem

FTP's deeper issue isn't the ports—it's the plaintext.

When you authenticate to an FTP server, your username and password cross the network unencrypted. Anyone capturing packets sees them. File contents, directory listings, every command—all visible to anyone watching.

In the 1970s, this wasn't a concern. Networks were trusted. Hostile actors sniffing packets was exotic.

Today, transmitting credentials in plaintext is disqualifying. WiFi networks, shared infrastructure, sophisticated attackers, compliance regulations—the assumption of a trusted network is gone.

FTP also lacks integrity verification. TCP ensures packets arrive, but nothing cryptographic confirms files weren't modified in transit. A man-in-the-middle could alter contents without detection.

Modern Alternatives

SFTP (SSH File Transfer Protocol) tunnels file transfers through SSH on port 22. Despite the similar name, it's a completely different protocol—no two-port complexity, no active/passive modes, no plaintext credentials. Everything happens within an encrypted SSH session. One port. Strong authentication. Simple firewall rules.

FTPS adds TLS encryption to traditional FTP. Explicit FTPS starts on port 21 and upgrades to TLS via the AUTH command. Implicit FTPS establishes TLS immediately on port 990. FTPS preserves FTP's workflow but inherits its complexity—you still need passive port ranges, and encryption can interfere with firewall inspection.

For new systems, SFTP wins on simplicity. FTPS exists for organizations with existing FTP infrastructure and compliance requirements specifying TLS.

Firewall Configuration

For active mode: clients need outbound access to port 21; servers need outbound access from port 20 to client ephemeral ports. This rarely works through NAT.

For passive mode: clients need outbound access to port 21 and the server's passive port range. Servers need inbound access to port 21 and the passive range.

Some firewalls offer FTP inspection (application layer gateway) that watches the control channel and dynamically opens ports for data connections. This can simplify configuration but sometimes breaks encrypted variants. Many administrators disable it and configure ports explicitly.

SFTP simplifies everything: port 22, both directions, done.