FTP is a notoriously firewall unfriendly protocol, this issue has been dealt with by intelligent firewalls that monitor the FTP control traffic and do what is required to make it work, while limiting some of the potential security problems inherent in the protocol. Unfortunately, the IETF have chosen to make FTPS work identically to FTP but with the addition of TLS encryption, fixing none of the FTP issues and creating more. With FTPS, the control traffic is encrypted so it is not possible for a firewall to see what is going on so we are essentially back to the day of the dumb packet filter when dealing with FTPS. In fact, standard Firewall FTP protocol inspection will block FTPS traffic as being invalid and potentially dangerous.\
FTP and FTPS have two modes PORT (or standard) and PASV (passive).
With PORT mode, the FTP client initiates a connection to the FTP server on the control channel, and sends a PORT command that provides the server with an IP address and TCP port (generally a random port >1024) that it should connect back to for data transfer. With FTP the firewall monitors this conversation and automatically opens the reverse connection, ensuring that the IP supplied is actually the client IP and, in some cases, that the port is not a well known service port. With FTPS the firewall can't monitor the connection so doesn't know any of this. Since inbound firewall connections are typically blocked by firewalls, FTPS PORT mode can not work unless the firewall is manually opened for all traffic on all high ports from the FTPS server address, not a very good solution.
With PASV mode, the FTP client initiates a connection to the FTP server on the control channel and sends a PASV command to the server, which replies with an IP address and port (generally a random port > 1024) that the client should connect to for data transfer. With FTP the firewall monitors this conversation and automatically opens the connection, ensuring that the IP supplied is actually the server IP and, in some cases, that the port is not a well known service port. With FTPS the firewall can't monitor the connection so doesn't know any of this. Outbound firewall connections that aren't to well known services may be blocked by firewalls, when this is the case, FTPS PASV mode can not work unless the firewall is manually opened for all traffic on all high ports to the FTPS server address, also not a very good solution but much better than PORT mode.
A mitigating circumstance with many FTPS servers is that the range of ports that will be used for the PASV data connection can be specified, improving the situation substantially from that specified by the FTP standard. Since a unique port range can be specified (eg 52600-52699), firewall rules only need to allow access to the control port and this range. Unfortunately the standard is all high ports so there is no standard limited range. So even when the port range is limited, it will likely be different for each FTPS site.
There are also serious issues with NAT and FTP/FTPS since the protocol specifies the client or server IP address in the control traffic. If a client (PORT mode) or server (PASV mode) is NATed, FTP/FTPS breaks. With FTP, firewalls are generally smart enough to modify the control traffic when NATing. With FTPS, this is not possible because the control traffic is encrypted.
FTPS is not compatible with NAT. However, some clients and/or some servers have means of getting around the NAT issue but this is not universal and can make things more complicated and non-standard on both ends. Some FTPS servers can be configured to supply a user provided (ie NAT) address to the client rather than real address in the commands they return to the client. Another possibility is that some FTPS servers can be configured to use EPSV (Extended Passive Mode) and not supply an IP address in the commands they return to the client, however, I don't know if all FTPS clients are compatible with this option.
If possible, FTPS should be avoided and some other more firewall friendly protcol such as HTTPS or SFTP should be used. If FTPS must be used, I recommend that only PASV mode (with a limited range of data ports) be used. PORT mode is even more firewall unfriendly than PASV mode and is also incompatible with client side NAT.
Some references:
- ftps - FTP-SSL and FTP-TLS (
RFC4217) - the state of play
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html - FTP SSL through a NAT Firewall
http://geekswithblogs.net/lance/arch.../23/50912.aspx - Secure FTP Over SSL and NAT WhitePaper
www.stdnet.com/uploads/media/MOVEit-DMZ-FTPS-NAT-Whitepaper.PDF Some free FTP/FTPS clients:
- FileZilla (
http://sourceforge.net/projects/filezilla/), a very nice FTP client with FTPS capability.
- MOVEit Freely (
http://www.stdnet.com/moveitfreely/), a scriptable, drop in replacement for the Microsoft command line FTP that addes FTPS and PASV capablilty.
- cURL (
http://curl.haxx.se/)
A commercial FTPS server proxy:
- FTP Guardian (
http://www.tcpdata.com/ftpg_overview.shtml). This product allows you to add FTPS support to Microsofts IIS FTP or other FTP servers that don't natively support it.