FTPS over a NAT Firewall is a problem, but there are solutions. First, an explanation of the problem: The reason why FTPS (and even FTP without SSL) is a problem with firewalls is that unlike most internet protocols, FTP requires two socket connections, not just one. The first connection, called the control connection, is the one where all of the commands and responses are exchanged between client and server. The second connection, called the data connection, is where all of the data is transferred (files and file listings). There are two ways to setup the data connection – active or passive. Active mode means that the data connection will be opened from the server to the client (the client will listen for an incoming connection from the server). Passive mode is just the opposite, the client will open the data connection on the server (the server will listen for an incoming connection from the client). Passive mode is recommended, especially for SSL connections.
A normal, unencrypted, passive FTP data connection gets configured and opened like so:
CLIENT-->SERVER: PASV
SERVER-->CLIENT: 227 Ok, Entering Passive Mode (193,21,1,121,15,6)The client sends the PASV command, and the server says “OK”, and tells the client the ip address and port that he is listening to. The first four octets in the parenthesized response form the dotted ip address (193.21.1.121) and the last 2 form the port number (15*256 + 6) = 3846. At this point, the server is listening for an incoming data connection – and the client can go ahead and make that connection so that the two sides can begin transferring data.
When you throw a NAT (Network Address Translation) in the middle
CLIENT–>NAT–>SERVER:
you now have the following communication:
CLIENT-->NAT: PASV
NAT-->SERVER: PASV
SERVER-->NAT: 227 Ok, Entering Passive Mode (10,0,1,121,15,6)
NAT-->CLIENT: 227 Ok, Entering Passive Mode (193,21,1,121,15,6)As you can see, the NAT must spy on the servers response to the PASV command. The NAT sees that the server is listening on 10.0.1.121 port 3846. The server is of course on a private IP address that the client cannot reach. The NAT has the public IP address that the client is communicating with. So the NAT replaces the servers response with his own – telling the client to open the connection to HIS ip address and port. In turn of course, when the NAT receives a connection to that location, he will forward it on to the FTP servers IP and port.
Now throw in another complication: SSL. Now the NAT cannot spy on the PASV response, nor can he alter it. So the client would attempt to open the data connection on an IP address that was not accessible, since it is behind the firewall.
What is the solution?
Some NATs will allow you to specify port ranges that will automatically forward to a specific location. If you can configure this port range to match the passive port range used by the FTP server – that may be a solution.
Another solution is to set your FTP server up to use the EPSV command (Extended Passive Mode). The EPSV command only sends the port – and the IP address is inferred to be the same as the IP address of the control connection. The IP*Works! FTPS control supports UseEPSV as a configuration option:
SettingFTPS1.Config(“UseEPSV=true”)will add support for EPSV.
posted on Tuesday, August 23, 2005 9:45 AM
