FTP Active and Passive Modes

FTP PORT and PASV MODE

Essentially,

PASV : client connects to server for data transfer.

PORT : server connects to client for data transfer.

An FTP Server uses only 2 TCP ports and no UDP ports:

/1/ main port (usually 21) for command (USER, PASS, CWD ...)

/2/ data port (main port - 1) for data transfer (ascii listing, binary upload and download)

The difference between Passive mode (PASV) and normal mode (PORT) is the connection:

when using PASV, client asks server where it (the client) will have to connect to establish data transfer link.

Client > PASV
Server > 227 Entering Passive Mode (65,246,15,6,249,155)

FTP client must connect to 65,246,15,6 on port 249*256 + 155 = 63899

Client > PORT 192,168,1,100,5,114
Server > 200 PORT command successful.

This time, it is the FTP server which connects to the FTP client (ip = 192.168.1.100 on port 5*256+114 = 1394)

ProFTPD reads the MasqueradeAddress entry of the proftpd.conf file upon startup. It will not check the WAN IP (MasqueradeAddress) of the Linksys again until the next time the daemon is restarted. If you have a dynamic IP from your ISP, PASV mode connections will stop working when your WAN IP on the Linksys changes until you update proftpd.conf with the new WAN IP address and restart proftpd. If using a resolvable domain name for MasqueradeAddress, you won't have to edit your proftpd.conf file.

In active mode you talk to the FTP server and ask for a file. Over that connection the server says to you, "Okay, I'm going to send you a file, and I'm going to send it you over a new connection to Port X on your machine." X is from 1024 to 65535. Your client replies, "Aye Aye Captain".

Now the FTP server tries to open that port speaking on a port that the NAT gateway is not expecting a request over. All of a sudden your NAT gateway receives a request on Port X and it does not know which machine on the your net that the packet is intended; it then denies the request and you don't get your file.

On Linux, ip_masq_ftp, a kernel module, can be loaded to fix this. Instead of blindly NATing away, it eavesdrops on the FTP protocol, and it knows in active mode that the server will reply to the client over the control connection with a port number which is contained in the *data* of the packet. When a reply comes in on this port the ip_masq_ftp module tells the NAT code to route it to the correct client behind the gateway. You still need to open any firewall to all incoming ports, but only if the source port is the FTP data port.

In PASV (passive) mode port 21 is always initiated by the client for control and port 20 is always initiated by the client to receive data. This makes it NATable. Most FTP clients are set to Active mode by default and must be told to switch to PASV mode.

It's kind of a misnomer to say the client is passive. Basically, it instructs the server to be passive, telling it, "Hey FTP server, don't get active on me. When I want the file, I'll open a connection to you and get it".

You may be saying, why did they bother with this active baloney at all? Like everything invented in Unix, there's more to it than meets the eye. Two properly implemented FTP servers can be made to work together from a third machine. Using the FTP control port from machine A, you can tell the FTP server on machine B to download the contents of a directory on machine C. This is basically how FTP mirror sites get updated.

FTP in passive mode

In passive mode, the FTP client sends the command 'PASV' to the server, which reacts by opening a listener port for the data channel and sending the IP address and port number of the listener as a reply to the client. The reply is of the form '227 Entering Passive Mode (10,10,10,99,6,12)'.

When the Secure Shell client notices the reply to the PASV command, it will create a local port forwarding to the destination mentioned in the reply. After this the client will rewrite the IP address and port in the reply to point to the listener of the newly created local port forwarding (which exists always in a local host address, 127.0.0.1) and pass the reply to the FTP client.

The FTP client will open a data channel based on the reply, effectively tunneling the data through the SSH connection, to the listener the FTP server has opened. The net effect is that the data channel is secure all the way except from the Secure Shell server to the FTP server, if they are on different machines. This sequence of events happens automatically for every data channel.

Since the port forwarding is opened to a local host address, the FTP client must be run on the same machine as the Secure Shell client if passive mode is used.

FTP in active mode

In active mode, the FTP client creates a listener on a local port, for a data channel from the FTP server to the FTP client, and requests the channel by sending the IP address and the port number to the FTP server in a command of the following form: 'PORT 10,10,10,99,6,12'. The Secure Shell client intercepts this command and creates a remote port forwarding from the Secure Shell server's localhost address to the address and port specified in the PORT command.

After creating the port forwarding, the Secure Shell client rewrites the address and port in the PORT command to point to the newly opened remote forwarding on the Secure Shell server and sends it to the FTP server. Now the FTP server will open a data channel to the address and port in the PORT command, effectively forwarding the data through the SSH connection. The Secure Shell client passes the incoming data to the original listener created by the FTP client. The net effect is that the data channel is secure the whole way except from the Secure Shell client to the FTP client. This sequence of events happens automatically for every data channel.

Since the port forwarding is made to a local host address on the Secure Shell client machine, the FTP client must be run in the same host as the Secure Shell client if passive mode is used.

Where end-to-end encryption of FTP data channels is desired, the FTP server and Secure Shell server need to reside on the same host, and the FTP client and the Secure Shell client will likewise need to reside on the same host. If this is the case, both active or passive mode can be used.

Consider using sftp2 or scp2 instead of FTP forwarding to secure file transfers. It will require less configuration than FTP forwarding, since the SSH Secure Shell server already has sftp-server2 as a subsystem, and sftp2 and scp2 clients are included in the distribution. Managing remote user restrictions on the server machine will be easier, since you do not have to do it also for FTP.

Copyright  © 2003 mail-production.com^® created 2000 -- last modified 2001-04-14