ftp problems with Cable

NAT-unfriendly applications and protocols

Network Address Translation works by simply re-writing the IP address in the IP header, and/or the port number in the TCP or UDP header, of a data packet. If a network application puts IP addresses or port numbers anywhere else, such as in the user-data section of the packet, then they will not usually be translated, and the application might fail to work correctly if its data passes through a NAT router. Common example of such NAT-unfriendly applications are:

* The File Transfer Protocol (FTP);
* The H.*2* protocol as used by NetMeeting etc.

The FTP protocol transmits both IP addresses and port numbers over the FTP control connection when clients and servers tell each other about the setup details for a data transfer connection.

NAT routers cannot know about the non-NAT-compliant peculiarities of all possible network application protocols. Nevertheless, where certain application protocols are recognised, their special requirements are dealt with by Application Level Gateway (ALG) support incorporated into the NAT router.

For instance, Linksys routers with firmware *.** or higher incorporate ALG support which permits FTP clients on the LAN to function in Active PORT-mode when connecting to a remote FTP server on port 2* (only: it is the destination port 2* which triggers the FTP ALG function).

If the NAT router does not have ALG support for Active PORT-mode FTP clients, then FTP client applications will only work if they can be configured to use Passive mode (the standard command-line ftp command in Windows cannot use Passive mode). The classic symptom of an Active PORT-mode FTP client failing to work through a NAT router is to be able to log on to the server, but not to be able to get a directory listing.

It is even more difficult to get an FTP server working behind a NAT router: see [url]http://www.linksysftp.org/[/url] for instructions on how to set up an FTP server behind a Linksys router.