FTP Clients and Servers
Here is why it is such a pain to get any Network Address Translator (NAT) routing device like the LinkSys to run FTP – either as a client or server.
I hope you’re already aware what a client and a server are. For FTP…
Clients can be programs such as MSIE, Netscape, WS_FTP, CuteFTP, BPFTP, FlashFTP, ftp commandline, etc. Servers are programs such as ftpd, wu-ftpd, BPFTPServer(G6ftp), Serv-U, IIS, etc.
FTP uses 2 TCP connections (or channels), 1 for control and one for data. The standard control connection is TCP port 21. The default data connection (and extremely rare to see – you can almost forget it exists) is port 20.
When an FTP connection is made but listing a directory or sending data fails it is almost ALWAYS the data connection at fault! This is by far the most common problem encountered in FTP connections.
FTP has 2 modes, PORT (also called “regular” or “normal” mode) and PASV (“passive” mode for clients behind firewalls).
The client determines the mode that will be used (or attempted as the case may be)… If the client issues a PORT command, it is attempting “PORT” mode. If the client issues a PASV command, it is attempting “PASV” mode. If the client does not issue either command, PORT mode is assumed using port 20 for data (again, very rare these days).
In PORT mode, the client (yes to CLIENT!) is the server end of the data channel. In PASV mode, the server is the server end of the data channel. The difference between PORT and PASV modes is which end plays “server” for the data channel!
Clients *may* use the PORT command when NOT running PASV to tell the other end what address and port they will be listening on. The Linksys router only translates this command on standard port 21 (else, the server gets your LAN address which doesn’t work!).
If you are going to use FTP regularly, get to know how to read logs and what the PORT and PASV commands do! Here’s some help…
Client> PORT 12,34,56,78,65,43 Server> 200 PORT command successful.
In this example of PORT mode the client has said it will be listening on IP address 188.8.131.52 on TCP port 16683 for the data channel. (Note: the port is the 65,43 pair and is: 65×256 + 43 = 16683). The client is the server for the data channel so if behind an NAT, port 16683 better be forwarded!
What is PASV mode?
PASV (passive) mode was designed for clients behind firewalls. When NOT using PASV mode the client actually becomes a server for the data channel (that’s right!). Since firewalls typically prevent this, PASV mode is used and this switches the data channel to be served by the server side.
Browsers (like Netscape and MSIE) may use PASV mode exclusively but it’s really been pot-luck. I found MSIE 5.5 has a setting that seems to lie about what it uses. Most ftp programs (like CuteFTP and WS_FTP) can be set to run PASV or not.
Client> PASV Server> 227 Entering Passive Mode (123,45,67,89,158,26)
In this example of PASV mode the server has said it will be listening on IP address 184.108.40.206 on TCP port 40474 for the data channel. (Note: the port is the 158,26 pair and is: 158×256 + 26 = 40474). The server needs this data channel to be forwarded along with the control channel!
Important Note – How the LinkSys helps a bit and why your log can fool you:
The LinkSys BEFSRx1 (as of f/w 1.39) translates and then forwards the data port correctly for a PORT command from a client on the LAN – but ONLY IF the command channel is port 21 (the standard ftp command port). THIS IS NOT TRUE ON NON-STANDARD COMMAND PORTS! This means the client’s log will say: PORT 192,168,1,100,65,43… BUT… 1) The server end will see the 192.168.1.100 LAN address changed to the WAN address. 2) The Linksys will forward the data port (port 65×256 + 43 = 16683 in this case) to the LAN PC that connected. These 2 things are done automatically by the Linksys:
Unlike standard port 21, the LinkSys does NOT translate the FTP “PORT” command on other ports. The only way a client behind a LinkSys router can connect to an FTP server on a non-standard port is to use PASV mode.
Some servers and clients know how to handle FTP modes behind an NAT!
Notice PORT and PASV commands involve an IP address and a port for the data channel. One problem is the client or server in on a LAN but needs the WAN address to be sent:
The other problem is the client or server needs to have the data channel port forwarded – if it is the server end of the data channel:
Both IP and port ranges is handled by some clients and servers. Here’s some I know about:
Servers that can do PASV mode behind an NAT firewall:
Clients that can do PORT mode behind an NAT firewall:
BAD NEWS FOR DYNAMIC IPs! These servers and clients have a setting for the port range that must be forwarded and the IP address to send. Unfortunately, as of this writing, none of these has the ability to change that IP address dynamically (but look for some soon I hope!).
The MTU and FTP
A MTU mismatch may also show it’s ugly head on FTP connections – for clients not servers. This is because a regular (not PASV) FTP connection on port 21 includes an inbound connection to the client. This inbound (data) connection could have too large of an MTU size, which can cause the TCP/IP stack in the router to flake out.
Most everyone with a router that uses FTP has seen the inability to list directories. An MTU mismatch can be yet another possible cause of this.
More information about mismatched MTU values, see this other article on MTU and PPPooE
FTP SERVERS behind the LinkSys – Any Port
Just the opposite of the client case, when a server is behind the LinkSys it can NOT do PASV mode for the outside world. Notice the irony – if both client AND server are behind LinkSys’ AND non-standard ports are used, no connection can be made easily. Standard Port 21 is the only quick way.
By Bill_MI, information from DSL Reports Message Boards, reproduced with permission.