File Transfer Protocol is one of the oldest application layer protocols still in active use today. Its original specification, RFC 114, dates back to 1971 — decades before the modern web existed. It’s still worth understanding in depth, both because it shows up regularly in CCNA and CCNP material and because plenty of real infrastructure still relies on it, for better or worse.
This guide covers how FTP actually works, the real difference between active and passive mode, what genuinely works (and doesn’t) for securing it on Windows and Linux, and practical troubleshooting steps.
How File Transfer Protocol (FTP) Works
FTP is a client-server application layer protocol built for transferring files over TCP/IP. A client application connects to a server daemon — commonly vsftpd or ProFTPD on Linux — using two separate channels:
- Command channel (port 21): carries control messages between client and server — client commands like
USERandPASS, and server status-code replies. - Data channel (port 20): dedicated to the actual file transfer itself, separate from the control conversation.
The client opens the command connection first. Once that’s negotiated successfully, a separate data connection is established for each individual file transfer. This two-channel design is unusual among common application layer protocols — most, like HTTP, handle everything over a single connection — and it’s exactly what makes FTP more complicated to work with through firewalls and NAT.
You can monitor both channels’ activity directly:
Windows:
netstat -aLinux:
ss -lDepending on the permissions granted, an FTP client can download, upload, delete, rename, move, and copy files on the server. Most servers require authentication, though some allow anonymous access with deliberately restricted privileges — a useful real-world example of access control principles in practice.
Active Mode vs. Passive Mode
FTP’s two-channel design creates a genuine complication: who initiates the data connection, and in which direction?
Active mode: the client opens the command channel to the server’s port 21 as usual. For the data transfer, the server then initiates a new connection back to the client, from the server’s port 20 to a port the client specified. This means the client-side firewall has to allow an unsolicited inbound connection — something firewalls are specifically designed to block by default, which makes active mode unreliable on any network with a properly configured firewall or behind NAT.
Passive mode: the server instead opens a dynamic port, somewhere in the ephemeral range (commonly 1024–65535, though many administrators restrict this to a narrower range specifically to simplify firewall configuration), and tells the client which port to use over the command channel. The client then initiates the data connection itself, in the same direction as the original command connection. This makes passive mode dramatically more compatible with modern firewalls and NAT, which is why it’s the default choice in nearly every FTP client today.
A note on Windows’ built-in FTP client: this is worth being precise about, because it trips people up. Windows’ native ftp.exe command-line client does not reliably support passive mode, on any current version of Windows — there’s no -p switch, and even the “quote pasv” workaround only tells the server to switch to passive mode while the client itself remains stuck in active mode, which typically causes the transfer to hang. If you need passive mode on Windows, use a dedicated client like FileZilla or WinSCP instead of the built-in command-line tool.
On Linux, you can test a passive-style connection manually with:
nc -l 2121
Practical Example: Connecting to an FTP Server
On Linux, open a terminal and connect directly:
ftp ftp.example.comLog in with a username and password, or anonymous for public servers that allow it. Once connected, use dir or ls to list files, get filename to download, and put filename to upload.
On Windows, the built-in client can run from a script file for repeatable, non-interactive transfers. Create a text file (for example, script.txt) containing:
open ftp.example.com
user username password
dirThen run it from the Command Prompt:
ftp -s:script.txtConfirm the connection actually worked with netstat -a on either platform, checking that port 21 shows an active connection.
Securing FTP: What Actually Works
Plain FTP transmits everything — including your username and password — in unencrypted plaintext. Anyone able to observe the traffic, on a shared network or anywhere along the route, can read it directly. This isn’t a minor caveat; it’s the single biggest reason FTP has fallen out of favor for anything sensitive.
There are two genuinely different ways to secure file transfer, and they’re often confused with each other:
- FTPS (FTP over TLS/SSL): the original FTP protocol, with an added TLS encryption layer on top. It still uses the same command/data channel structure as plain FTP.
- SFTP (SSH File Transfer Protocol): a completely different protocol that transfers files over an SSH connection. Despite the similar name, SFTP shares no code or protocol lineage with FTP — it’s built on SSH from the ground up.
Both are secure, well-supported alternatives to plain FTP. Which one to use often comes down to what your existing infrastructure already supports — SFTP is generally simpler to firewall, since it only needs a single port (22, the same as SSH).
Setting up FTPS on Linux with vsftpd:
sudo apt install vsftpdEdit /etc/vsftpd.conf to enable TLS:
ssl_enable=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.keyRestart the service to apply the changes:
sudo systemctl restart vsftpdSetting up FTPS or SFTP on Windows: since the built-in ftp.exe client supports neither encryption method, use FileZilla Server for FTPS (enable TLS in its settings and configure a certificate) or an SSH server for SFTP. On the client side, FileZilla Client or WinSCP both handle FTPS and SFTP correctly.
Testing a secure connection:
sftp user@hostFor FTPS, connect using a client that actually supports it — FileZilla Client is the simplest cross-platform option — rather than the plain Windows or Linux command-line ftp tool, neither of which handles TLS negotiation.
Troubleshooting Tips
Connection fails entirely: start with basic reachability.
ping ftp.example.comIf that succeeds but the FTP connection still fails, trace the path to rule out routing problems:
tracert ftp.example.comOn Linux, use traceroute ftp.example.com instead.
Data transfer stalls after connecting: this is the classic active-mode-behind-a-firewall symptom. Confirm both port 21 (command) and, if using active mode, port 20 (data) are actually open and responding:
netstat -aOn Linux:
ss -lSwitching to passive mode, or moving to a client that properly supports it, resolves the majority of stalled-transfer cases.
Firewall blocking legitimate FTP traffic: on Linux, allow the command port explicitly if needed:
sudo ufw allow 21/tcpRemember that passive mode also requires the server’s configured passive port range to be open, not just port 21 — a common oversight when troubleshooting FTP through a firewall.
Understanding FTP Reply Codes
Every FTP server response begins with a three-digit status code, and recognizing the pattern makes troubleshooting significantly faster:
| Code Range | Meaning | Example |
|---|---|---|
| 1xx | Positive preliminary reply — action started, another reply will follow | 150 File status okay, opening data connection |
| 2xx | Positive completion reply — action finished successfully | 226 Transfer complete |
| 3xx | Positive intermediate reply — more information needed to complete the request | 331 Username okay, password required |
| 4xx | Transient negative reply — the request failed, but may succeed if retried | 425 Can’t open data connection |
| 5xx | Permanent negative reply — the request failed and won’t succeed without a change | 530 Not logged in |
A 227 reply specifically indicates the server has entered passive mode and is telling the client which port to connect to for the data transfer — this is the exact reply that Windows’ native ftp.exe can receive and acknowledge, but still fails to act on correctly, which is the root of its passive-mode limitation described above.
If a session hangs immediately after a 150 reply, the data channel itself is the problem — usually a firewall blocking either the server’s port 20 (active mode) or the dynamic passive port range, even though the command channel on port 21 is working fine.
FTP vs. Its Modern Alternatives
| Factor | FTP | FTPS | SFTP |
|---|---|---|---|
| Encryption | None | TLS/SSL | SSH |
| Ports required | 21 (control) + 20 or dynamic (data) | Same as FTP, plus TLS negotiation | 22 only |
| Firewall complexity | High, especially in active mode | High — same channel structure as FTP | Low — single port |
| Native Windows client support | Yes (unencrypted only) | No | No (requires third-party client or PowerShell/OpenSSH) |
| Recommended for sensitive data | No | Yes | Yes |
Why FTP Is Still Around
Given its security limitations, it’s fair to ask why FTP hasn’t simply disappeared. A few reasons keep it in active use: a huge amount of legacy infrastructure, embedded devices, and internal tooling was built around it decades ago and hasn’t been replaced; some internal, network-isolated environments accept the plaintext risk because the traffic never leaves a trusted network; and FTP’s command set is simple enough that it remains a useful teaching tool for understanding client-server file transfer and the active/passive connection problem more broadly. None of that makes plain FTP a good choice for anything crossing an untrusted network today — but it explains why CCNA and CCNP material still cover it in depth.
FAQs
What is the purpose of File Transfer Protocol?
FTP is a client-server application layer protocol, dating back to a 1971 specification, built specifically for transferring files between systems over TCP/IP. It uses a command channel on port 21 and a data channel on port 20 to handle authentication, file listing, and the actual upload or download of files.
How do active and passive modes differ in File Transfer Protocol (FTP)?
In active mode, the server initiates the data connection back to the client after the command channel is established, which often fails behind a firewall since it requires an unsolicited inbound connection. In passive mode, the client initiates the data connection instead, using a dynamic port the server provides — this is far more firewall- and NAT-friendly and is the default in nearly every modern FTP client.
What are the security limitations of FTP?
Plain FTP transmits usernames, passwords, and file contents entirely in cleartext, meaning anyone who can observe the network traffic can read everything, including your login credentials. This is a serious enough limitation that FTP should not be used for anything sensitive without upgrading to FTPS or SFTP.
What’s the actual difference between FTPS and SFTP?
FTPS is the original FTP protocol with TLS encryption added on top, keeping the same two-channel command/data structure. SFTP is a completely different protocol that transfers files over an SSH connection, sharing no code or protocol lineage with FTP despite the similar name — and it’s generally easier to firewall since it only needs a single port.
Does Windows’ built-in FTP client support passive mode or encryption?
No, on both counts. Windows’ native ftp.exe does not reliably support passive mode on any current Windows version, and it has no support for FTPS or SFTP encryption at all. For either passive mode or secure transfers on Windows, use a dedicated client like FileZilla or WinSCP instead.
How can users access an FTP server without logging in?
Some FTP servers allow anonymous access, letting users download or browse public content using “anonymous” as the username and typically an email address as the password. This access is usually restricted to read-only, specific directories, and should always be configured deliberately by the server administrator rather than left as an unintentional default.
