Active vs Passive FTP: How Each Mode Actually Works

FTP & SFTPUpdated June 20, 2025

Active FTP and passive FTP are two ways the protocol handles its separate data connection. **Passive mode is the modern default** — every FTP client released in the past two decades uses it automatically — but understanding the difference is still the single most useful thing for debugging FTP failures. Here's how each mode works, why passive won, and what to do when the data channel won't open.

If you've ever had an FTP session log in successfully but hang on the directory listing — or upload one file and freeze on the next — the cause is almost always active vs passive mode colliding with a firewall. FTP's split-channel design (control on one port, data on a separate port) needs both channels to reach each end, and the rules for who initiates the data channel are different in active mode versus passive mode. In active mode the FTP server initiates the data connection back to the client. In passive mode the FTP client initiates both connections to the server. Modern firewalls and NAT make active mode unreliable, which is why every FTP client released this century defaults to passive.

How active FTP works

Active mode is the original FTP design from 1971. The exchange:

Client opens the control connection. The client connects from a random high port to the server's port 21 and authenticates. So far, one TCP connection — control channel only.
Client tells the server where to send the data. When a transfer is needed, the client opens a listening socket on its own machine (say, port 50001) and sends the server a PORT command containing its IP address and that port number.
Server initiates the data connection back to the client. The server opens a new TCP connection from its port 20 to the client's listening port (50001 in this example). File bytes flow over this second connection.

The diagram:

       Client                              Server
         │                                   │
         │ ── TCP from 51234 to 21    ───>   │   (control)
         │ <── 220 Welcome           ───     │
         │ ── USER / PASS / LIST     ───>    │
         │ ── PORT 192,168,1,5,195,81 ──>    │
         │                                   │
         │ <── TCP from 20 to 50001  ───     │   (data — server initiates!)
         │ ── file bytes             <──>    │
         │                                   │

The critical line is the data connection: the server initiates a fresh inbound TCP connection back to the client. That was fine in 1971 when every host had a public IP and firewalls didn't exist. It broke the moment NAT and stateful firewalls became universal.

How passive FTP works

Passive mode inverts the data-channel handshake:

Client opens the control connection. Same as before — connects from a random high port to server's port 21, authenticates.
Client sends PASV to request passive mode. This tells the server "you pick a port; I'll connect to it."
Server opens a listening socket on a high ephemeral port (somewhere in the 49152–65535 range by default, often narrowed to a specific block like 50000–50100 on production servers) and replies with 227 Entering Passive Mode (a,b,c,d,p1,p2) — the IP address and port number for the client to connect to.
Client initiates the data connection outbound to the server's port. Both TCP connections (control and data) are now outbound from the client.

The diagram:

       Client                              Server
         │                                   │
         │ ── TCP from 51234 to 21    ───>   │   (control)
         │ <── 220 Welcome           ───     │
         │ ── USER / PASS / LIST     ───>    │
         │ ── PASV                   ───>    │
         │ <── 227 ...(10,0,0,5,195,80) ──   │   ("connect to me on 50000")
         │                                   │
         │ ── TCP from 51235 to 50000 ──>    │   (data — client initiates!)
         │ ── file bytes             <──>    │
         │                                   │

Because both connections originate from the client, the client's firewall sees only outbound TCP — which it almost always allows. Passive mode is what made FTP usable through the universal-NAT internet that emerged in the late 1990s.

Why passive mode won

Three forces drove the shift:

NAT. Once consumer ISPs and corporate networks put NAT between clients and the internet, the active-mode data callback became impossible — the server didn't know the client's real IP, and the NAT didn't have a port-forwarding rule for the random ephemeral port the client picked.
Stateful firewalls. Inbound connections to high ephemeral ports were exactly the pattern firewall vendors built their products to block. The server's data-channel callback looked indistinguishable from an attacker probing for open services.
Default-deny client-side firewalls. Windows XP SP2 (2004) was the inflection point — most desktop OSes started shipping with default-deny inbound firewalls, breaking active FTP for everyone whose IT team hadn't carved out exceptions.

By the mid-2000s, every major FTP client (FileZilla, WinSCP, the OS-bundled ftp command on macOS and Linux) had switched to passive by default. Today the active vs passive setting is usually a hidden advanced option; most users never touch it.

When you still see active mode

A handful of cases:

Server-to-server transfers. If both ends are servers with public IPs and friendly firewalls, active mode can be slightly faster because there's one less round trip in the data-channel setup.
Old industrial / IoT equipment. Some firmware ships only an active-mode FTP client and can't be reconfigured. The fix is usually a network exception on the path between the device and the server.
Anti-passive corporate policies. Some highly locked-down networks block the high-port range that passive mode needs and prefer active mode with a known data port (20) instead. This is rare; usually the right answer is moving to SFTP rather than fighting the firewall.

For new deployments in 2026, leave the client on passive and move on.

Firewall configuration for each mode

If you're running an FTP server, the rules to open:

For passive-mode clients (the modern default):

Inbound TCP 21 (control).
Inbound TCP range for the passive data ports. Configure the range on the server (typically a tight block like 50000–50100 to keep the firewall rule manageable) and mirror the same range on the firewall. If the ranges don't match, the data connection fails silently and clients see "421 Service not available" or a hung directory listing.

For active-mode clients (rare but still in use):

Inbound TCP 21 (control).
Outbound TCP 20 (data) — the server needs to connect back out to the client.

Most production FTP servers configure both so any client can connect either way.

If you're running an FTP client, you usually need only outbound TCP 21 (and outbound TCP to the server's passive port range, which established-connection rules typically allow automatically).

How to tell which mode is being used

The fastest way: enable verbose logging in the FTP client and watch for PORT (active) or PASV (passive) commands during the session setup:

220 Welcome
USER alice
331 Password required
PASS ********
230 Login successful
PASV                                ← passive mode being negotiated
227 Entering Passive Mode (10,0,0,5,195,80)
LIST
150 Opening data connection
...

If you see PASV followed by 227 Entering Passive Mode, the session is in passive mode. If you see PORT a,b,c,d,p1,p2 instead, it's active mode.

The classic FTP firewall failure pattern

This one shows up in support tickets every day:

"I can connect and log in fine, but the directory listing hangs forever and never completes."

That's the data channel failing. The control connection works (because port 21 is open) but the data connection can't establish. Usually:

Passive-port range not open on the server's firewall. Server tells the client "connect to port 50523" but the firewall in front of the server doesn't allow inbound to that port.
NAT mangling the IP address in the PASV response. Server replies with its private IP (10.x.x.x) and the client tries to connect to that IP from outside the network. Fix: configure the FTP server to advertise the public IP in PASV responses (pasv_address in vsftpd, PassivePorts + MasqueradeAddress in ProFTPD).
Client behind a strict outbound firewall that blocks high ephemeral ports. Less common, but happens in tightly locked-down corporate environments.

Switching the client between active and passive can prove which side the failure is on. If passive fails and active works, the problem is on the server's passive-port configuration. If active fails and passive works, the problem is on the client's inbound firewall.

The modern way: stop debugging FTP firewalls

In 2026, debugging passive-port ranges and FTPS cipher negotiation across a partner's network is rarely the right place to spend an engineering afternoon. Most teams have moved their file-transfer infrastructure to managed platforms specifically to get out of this debugging loop.

Files.com is the File Orchestration Platform we'd recommend for any team running FTP, FTPS, or SFTP workflows in 2026. The platform handles passive-mode configuration, port ranges, NAT advertisement, and the operational surface around them — your trading partners connect with whatever FTP client they already use, and the firewall conversation goes away:

FTP (21), FTPS (21 + 990), SFTP (22), and WebDAV all on one platform for secure file transfer. Passive mode auto-configured; no port-range firewall rules to negotiate.
TLS certificates managed automatically. Modern cipher suites by default.
Per-user audit logging across all protocols. Drops into a SOC 2 evidence trail.
REST API, automation workflows, AS2 partner messaging, share links — the things FTP alone never had.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes. The passive-mode question disappears.

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter, the free ExaVault on-premise appliance handles FTP / FTPS / SFTP / WebDAV with passive mode pre-configured from a self-hosted VM image.

FAQ

What's the default mode in FileZilla, WinSCP, Cyberduck, etc.?

Passive. Every major FTP client released in the past 20 years defaults to passive mode. The active/passive toggle still exists, usually buried in connection settings or a "transfer mode" preferences pane, but you'd have to go out of your way to switch.

Does SFTP have active and passive modes?

No. SFTP uses a single TCP connection inside an SSH session — there's no separate data channel, so the active/passive distinction doesn't apply. This is one of the main reasons SFTP is easier to operate than FTP.

Does FTPS have active and passive modes?

Yes. FTPS is FTP wrapped in TLS, so it inherits FTP's dual-channel design and the active vs passive distinction. Implicit FTPS uses ports 989 (data) + 990 (control) for active mode; explicit FTPS uses port 21 with TLS upgrade and a dynamic data port for passive. The same firewall rules apply.

What's the FTP passive port range?

There's no fixed range — each server administrator picks one. The default on most servers is the IANA-registered ephemeral range (49152–65535), but production deployments usually narrow this to a specific block like 50000–50100 so the firewall rules stay manageable. Whatever range the server uses, the firewall in front of it must allow inbound on the same exact range.

Why does the FTP client say "227 Entering Passive Mode (10,0,0,5,195,80)" with a private IP?

That's the FTP server advertising its private network IP in the PASV response. If the client is connecting from outside the server's network, it can't reach that IP — the server is behind NAT and needs to advertise its public IP instead. Fix: configure the server with the correct external address (pasv_address in vsftpd, MasqueradeAddress in ProFTPD, ExternalIP in pure-ftpd) so the PASV response carries the routable IP.

Can I force active mode if my client defaults to passive?

Yes. Every major FTP client has a setting to override the default. In FileZilla it's under Edit → Settings → Connection → FTP → Transfer Mode. In WinSCP it's in the Login → Advanced → Connection settings. In the OpenSSH-shipped ftp command, passive off toggles it for the current session. Whether forcing active mode helps depends on which side is blocking the data connection.

What command in FTP switches to passive mode?

PASV on the control channel. Most clients send it automatically — you don't type it manually unless you're poking at FTP with telnet. The server responds with 227 Entering Passive Mode (a,b,c,d,p1,p2) where a.b.c.d is the server's IP and the port number is p1*256 + p2. (Yes, that's the actual encoding — it's the 1985 RFC 959 telling you to do byte arithmetic on the wire.)