Passive FTP

In passive mode, the server picks a temporary data port and you connect to it. You already opened the control connection to port 21. Now you open the data connection too.

That direction works much better through client-side NAT and firewalls. Most desktop clients default to passive for that reason. When someone tells me “just turn on passive,” this is the behavior they mean.

On the server side, document the passive port range next to the firewall rule. Future you will thank present you when a ticket says “listing hangs after login.”

Ask the server for an endpoint, then transfer:

ftp> passive
Passive mode on.
ftp> pasv
227 Entering Passive Mode (203,0,113,10,195,81)
ftp> get report.csv
150 Opening data connection
226 Transfer complete

The last two numbers in 227 are the port. Here it is 195 * 256 + 81, or 50001. The client connects to 203.0.113.10:50001.

The server firewall must allow its passive port range. The address in the reply must be reachable from the client. A private IP advertised to an Internet client is a classic NAT bug:

227 Entering Passive Mode (10,0,0,8,195,81)

If transfers work on the LAN but fail from outside, compare the address in 227 with the public IP you expect. Fix the server’s advertised address before you blame the client.

Some clients ignore a bad address in 227 and reuse the control peer. Do not rely on that. Configure the server correctly, or use EPSV, which returns only a port.

Write the port math out once on paper. After that, passive replies stop looking magical.

Decode the reply above by hand and decide whether a remote client on the Internet can reach that endpoint.