I should start a web site and charge for all the answers... AskPodo.com [8D]
Seriously though, this is quite odd, since if it works at one site, it should work just fine at another site with exactly the same equipment. There are some possibilities though.
Generally, FTP will not work correctly from behind a normal NAT. This is because an FTP connection is actually two connections. First, your client establishes a TCP connection to port 21 of the FTP server. This connection is known as the controle connection. Once up, the controle connection is used to send commands to the server. In cases where the server need only respond to a command, the response is sent back across the controle connection.
In cases where the server needs to respond with data, it gets a little bit more interesting. When data needs to be sent to the client, following commands like ls, which lists all files in the directory, or GET commands which instruct the server to send a file, another connection needs to be opened.
The client sends a PORT command to the server, which tells the server the client's IP address. After the PORT command, the FTP server establishes a new TCP connection back to the client, on port 20. This is the data connection. Once the data connection is open, data is sent through it to the client.
During the data transfer, the client and server use the controle connection for signalling and status messages.
Here we find a two-fold problem:
Firstly, with a client behind a NAT, the client will always send the server the IP address which it believes it is at. In the case of machines behind a NAT, this will be a private address.
Receiving the PORT command, the server will do one of two things, it will either try to connect to the private address, if that address happens to exist on its own network and nothing will happen, since there is no FTP client running on the machine which has that address, from the point of view of the server.
Alternatively, the server could recognise the address as private and just give up right away. Either way, your data won't be getting through. In the first case, there will be a long time-out followed by an error message.
Secondly, if the client did manage to send the FTP server the correct outside address of the NAT, there would still be no data connection, since the FTP server would be connecting back directly to port 20 on the NAT machine and there is no FTP client running on the NAT. Again, no connection.
A way has been devised to get around this problem, in the form of the PASV command, which initiates "passive" mode FTP. In passive mode, no data connection is established. Instead, data is transmitted back to the client through the controle connection. This has some drawbacks as no signalling is possible while data is traveling, but it is the only reliable way to FTP through most NATs, so it is accepted by most servers.
Some NAT servers also perform proper FTP NATing. This implies watching the controle connection of any FTP session from a machine behind the NAT. When the NAT sees a packet carrying a PORT command, the packet is altered so that the NAT's address is sent to the server, not the machine's internal address.
When the FTP server connects back to the NAT, traffic on port 20 of the NAT's external interface is forwarded to port 20 on the internal machine. In this way, the data connection can make it through the NAT. This is a little bit limited though, as there can be only one FTP session at a time. For more FTP sessions, more external interfaces need to be available on the NAT. If the NAT were to have multiple interfaces, the limit would change from one session, to one session per external interface.
Obviously, "passive" mode FTP is the best way to work around this problem, but it comes with its own drawbacks. To take advantage of passive mode, your FTP client must allow it. "Client-in-a-browser" clients generally do not know about the PASV command, especially Internet Explorer. In order to use passive mode, you will have to install a third party FTP client and use it for all FTP uploads and downloads.
Incidentally, uploads also use the data connection.
If installing real FTP clients and teaching your users how to use them is not an option, you might want to look at an FTP proxy.
This is fairly simple. Find a slightly underutilised UNIX or Windows NT machine on your network and install the appropriate version of the Squid proxy software. Set up Squid's internal FTP proxy to always use PASV when connecting to FTP servers. Then, set up each machine to use Squid as an FTP proxy. In this way, all FTP connections will be converted into PASV sessions and your FTP sessions should be able to traverse the NAT without any problems.
As a side note, there are also some NAT solutions, which, for no aparent reason, break passive mode FTP. These are NAT system which insist that FTP should be done in the traditional way, meaning a dual-connection session. These NAT systems are badly designed, since they force the use of the "one session only" kind of FTP NAT. If you are currently using PASV, try turning it off and see if it helps. If so, you have a "stupid" NAT.
Willie Viljoen
Web Developer
Adaptive Web Development
Sign up with Google
