Skip to main content
Blog|
Learning center

FTP port 21: what it is and how it works

|
Apr 3, 2026|9 min read
LEARNING CENTERFTP port 21: what it is andhow it worksHOSTNEYhostney.comApril 3, 2026

Port 21 is the default port for FTP (File Transfer Protocol). When an FTP client connects to a server, the initial connection goes to TCP port 21. This connection handles commands, authentication, and directory listings. The actual file data travels on a separate connection, which is where FTP gets complicated and where most firewall problems originate.

FTP was designed in 1971 when the internet was a small, trusted research network. The protocol reflects that era. It transmits credentials in plaintext, splits transfers across multiple ports, and has a connection model that was not designed to work with firewalls or NAT. Despite all of this, FTP is still in use on some servers, and understanding how port 21 works is relevant for troubleshooting, firewall configuration, and knowing why modern alternatives are better.

How port 21 works#

FTP uses two separate connections for every session: a control connection and a data connection. This dual-connection model is unique to FTP and is the root cause of most FTP-related firewall and NAT problems.

The control connection (port 21)

When you connect to an FTP server, your client opens a TCP connection to port 21 on the server. This is the control connection. It stays open for the entire session and handles:

  • Authentication (sending your username and password)
  • Directory navigation (cd, ls, pwd)
  • File operation commands (get, put, delete, rename)
  • Transfer mode negotiation (active vs passive)

The control connection does not carry any file data. It is purely for commands and responses. When you type ls to list a directory, the command goes over port 21, but the directory listing itself comes back on a separate data connection.

The data connection (dynamic port)

Every file transfer and directory listing opens a second, temporary TCP connection for the actual data. This data connection uses a different port, and which port it uses depends on whether the transfer is in active or passive mode.

This is the part that confuses people and breaks through firewalls.

Active mode vs passive mode#

Active mode

In active mode, the client tells the server “I am listening on port X, connect to me there.” The server then opens a connection from its port 20 back to the client’s port X.

The problem: the server is initiating a connection to the client. If the client is behind a firewall or NAT router (which nearly every client is in 2026), the incoming connection from the server is blocked. The firewall does not know that the client requested this connection because the negotiation happened on port 21 and the data connection is a separate, new connection from the server.

Active mode worked in 1971 when both machines were on the same network with no firewalls. It does not work reliably in modern network environments.

Passive mode

In passive mode, the server tells the client “I am listening on port Y, connect to me there.” The client then opens a connection to the server’s port Y.

The client initiates both connections (control on port 21, data on port Y). Since the client is always the one initiating, firewalls and NAT routers on the client side do not block anything. This is why passive mode is the default for virtually every modern FTP client.

The trade-off: the server now needs a range of ports open for incoming data connections. The server tells the client a random high-numbered port (typically in the range 1024-65535, though this is usually configured to a narrower range). The server’s firewall must allow incoming connections on this range.

A typical passive mode port range configuration on a server:

# In the FTP server configuration (vsftpd example)
pasv_min_port=40000
pasv_max_port=40100

The server’s firewall must then allow incoming TCP connections on ports 40000-40100 in addition to port 21.

Port 21 vs port 22#

This is the most important distinction for anyone making a decision about file transfer protocols.

Port 21 (FTP)Port 22 (SSH/SFTP)
ProtocolFTPSSH (SFTP runs inside SSH)
EncryptionNone (plaintext)Full encryption
CredentialsSent in plaintextEncrypted
File dataSent in plaintextEncrypted
ConnectionsTwo (control + data)One
Firewall friendlyNo (dual connection, dynamic ports)Yes (single port)
NAT friendlyNo (active mode fails)Yes

SFTP runs over SSH on port 22. It uses a single connection for everything: authentication, commands, and file data. All of it is encrypted. There are no dynamic port ranges to configure, no active/passive mode headaches, and no firewall gymnastics. If your server has SSH access, you already have SFTP without any additional setup.

FTP on port 21 transmits your username and password in plaintext. Anyone on the network between your client and the server can intercept them. This is not a theoretical risk. It is trivially easy with tools like Wireshark. On a coffee shop Wi-Fi network, a shared office network, or any network you do not fully control, FTP credentials are visible to anyone capturing traffic.

For a detailed comparison of all three file transfer protocols, see SFTP vs FTP vs FTPS: which should you use.

FTPS: FTP with encryption (still port 21)#

FTPS (FTP Secure, also called FTP over TLS) adds a TLS encryption layer on top of FTP. It still uses port 21 for the control connection and dynamic ports for data connections, but both connections are encrypted.

FTPS comes in two modes:

Explicit FTPS (the common one) starts as a regular FTP connection on port 21, then upgrades to TLS using the AUTH TLS command. The client connects to port 21 in plaintext, sends AUTH TLS, and the connection switches to encrypted. This is the mode most FTP clients use when they offer “FTP with TLS” or “FTPS.”

Implicit FTPS uses port 990 instead of port 21. The connection is encrypted from the start with no plaintext phase. Implicit FTPS is less common and considered deprecated by most standards.

FTPS solves the encryption problem but not the firewall problem. It still uses dual connections with dynamic port ranges, which means the same firewall configuration headaches as plain FTP. The TLS encryption also makes it harder for firewalls with deep packet inspection to understand the data connection negotiation, which can create new problems that plain FTP did not have.

FTPS exists primarily for organizations that have existing FTP infrastructure and need to add encryption without switching to a completely different protocol. For new deployments, SFTP is simpler and more firewall-friendly.

Why port 21 is often blocked#

Many ISPs, corporate networks, and hosting providers block port 21 by default. The reasons:

Security. FTP transmits credentials in plaintext. Blocking port 21 prevents users from accidentally sending passwords over an unencrypted connection.

Abuse. FTP servers have historically been used for hosting pirated content, malware distribution, and as drop points for stolen data. Blocking port 21 reduces this attack surface.

Firewall complexity. FTP’s dual-connection model requires either stateful packet inspection (the firewall tracks the control connection to identify related data connections) or opening a wide range of ports. Both are operational burdens.

Better alternatives exist. SFTP on port 22 provides the same file transfer functionality with encryption, single-port simplicity, and no special firewall configuration. There is little reason to keep port 21 open when port 22 handles everything better.

If you are trying to connect via FTP and the connection times out or is refused, port 21 being blocked at the network level is the most likely cause. Try SFTP on port 22 instead. For SFTP commands and usage, see the reference guide.

When FTP is still used#

Despite all its problems, FTP has not completely disappeared. You will still encounter it in:

Legacy systems. Industrial equipment, embedded systems, mainframes, and older server software that only supports FTP. These systems were built when FTP was the standard and cannot be easily upgraded.

Automated batch transfers. Some business processes involve automated FTP transfers between systems that have been running for years. Switching to SFTP requires coordinating changes on both ends, which involves multiple teams, testing, and sometimes vendor involvement.

Anonymous FTP. Some public file repositories still use anonymous FTP (no authentication required) to distribute open-source software, RFC documents, or public datasets. The Linux kernel was historically distributed via anonymous FTP, though most projects have moved to HTTPS downloads.

Web hosting control panels. Some older hosting control panels still offer FTP as the default file transfer method. If your hosting provider gives you FTP credentials instead of SFTP credentials, that is a signal about the age and security posture of their infrastructure.

Configuring FTP on a server (if you must)#

If you genuinely need FTP (for legacy compatibility, not by choice), here is a minimal secure configuration using vsftpd on Linux:

# Install vsftpd
sudo dnf install vsftpd   # RHEL/Rocky
sudo apt install vsftpd   # Ubuntu/Debian
# /etc/vsftpd.conf - minimal configuration
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES

# Force TLS (FTPS) - never run plain FTP
ssl_enable=YES
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1_2=YES

# Passive mode port range
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
# Open ports in firewall
sudo firewall-cmd --add-port=21/tcp --permanent
sudo firewall-cmd --add-port=40000-40100/tcp --permanent
sudo firewall-cmd --reload

# Start the service
sudo systemctl enable --now vsftpd

Even with this configuration, you are running a more complex setup than SFTP would require. SFTP needs no additional software (it is built into OpenSSH), no extra ports, and no passive mode configuration. If you have any choice in the matter, use SFTP.

Troubleshooting port 21 connections#

Connection refused

Nothing is listening on port 21. The FTP server is not installed, not running, or configured to listen on a different port.

# Check if anything is listening on port 21
ss -tlnp | grep ':21'

# Check if vsftpd is running
systemctl status vsftpd

Connection timed out

Port 21 is blocked by a firewall between you and the server. This could be your local firewall, your ISP, the server’s firewall, or a network firewall in between.

# Test port 21 connectivity
nc -zv server.example.com 21

# Compare with port 22
nc -zv server.example.com 22

If port 22 connects but port 21 does not, port 21 is blocked somewhere in the network path.

Connected but transfers fail

You can log in (port 21 control connection works) but file listings and transfers fail. This is almost always a passive mode port range problem. The server negotiated a data port that the firewall is blocking.

Check that the server’s passive port range is open in the firewall and that the FTP client is using passive mode (not active).

“530 Login incorrect” with correct credentials

If you are sure the credentials are right but login fails, check whether the FTP server requires TLS. Some servers are configured to reject plaintext logins. Switch your client to FTPS (explicit TLS) mode and try again.

On Hostney, plain FTP is not available. File transfer uses SFTP over SSH (port 22) or FTPS (FTP over TLS on port 21). SFTP is the recommended option since it requires no additional port configuration and is encrypted by default. FTPS is available for tools and workflows that require FTP compatibility. Connection details for both are available in the control panel under Terminal Access.

Quick reference#

PortProtocolEncryptedConnectionsUse case
21FTPNoTwo (control + data)Legacy systems only
21FTPS (explicit)Yes (after AUTH TLS)Two (control + data)Legacy + encryption requirement
22SFTPYesOneModern file transfer (recommended)
990FTPS (implicit)Yes (from start)Two (control + data)Deprecated, rarely used
# Test port 21 connectivity
nc -zv server.example.com 21

# Connect via FTP
ftp server.example.com

# Connect via SFTP instead (recommended)
sftp user@server.example.com