Core issue
Firewalls do not normally pass FTP connections encrypted with Secure Socket Layer (SSL). This is commonly referred to as FTP over SSL. The reason for this is that a firewall cannot inspect the FTP control connection because it is encrypted.
FTP over Transport Layer Security (TLS) does not affect the operation of the FTP protocol as viewed by a simple port filtering firewall. The connections and the ports are exactly the same. Content-aware firewalls are no longer be able to understand the content of the control connection. This means that any packet on the control connection that cannot be inspected must be configured to be passed through.
Normal port filtering firewall rules must be in place for the data connection, as the firewall is not able to open up the pinholes, based on the examination of the control connection. Network Address Translation (NAT) firewalls do not work for secure FTP if the NAT affects the port address or the PASV response address. An FTP client on a NATed network should be able to use secure FTP over TLS in firewall friendly mode to a server that has a real Internet IP address. An FTP client with a real Internet IP address should be able to use an FTP server that is on a NATed network in normal mode (assuming there is some mechanism for the client to establish a control connection).
In general, client-server secured FTP does not work with an Application Layer Gateway (ALG). However, it may be possible to configure an ALG as one of the endpoints of the secured FTP session as it flows over a hostile network.
Resolution
When a typical FTP connection is made (without SSL), the client embeds port information in the commands that it sends to the server. The firewall sees these port requests and dynamically opens the ports so that data can be sent back from the server to the client using those ports.
Now you can use TLS/SSL connections to encrypt data transferred over FTP control and data connections. The primary reason for encryption on the control connection is to conceal the password when you log on to the FTP server.
If you choose TLS/SSL encryption for the control connection, the FTP client also encrypts the data sent on the FTP data connection by default. FTP protocol does not allow you to have a secure data connection without a secure control connection.
Some FTP servers support what is called an implicit SSL connection. This connection provides the same encryption protection as the SSL option, but can only be done on a pre-determined server port, usually 990, for which the server must be configured to expect an SSL/TLS connection negotiation. Port 990 is used for the control connection.
This method is provided to allow secure connections to those FTP implementations that may not support the standard protocol for providing TLS/SSL protection.
When the connection is encrypted there is no way that the firewall is able to decrypt the packet to rewrite the public address of the FTP server in the payload. Due to this, secure FTP fails with NAT firewalls. A workaround is to configure the FTP server to write the public IP address instead of its private IP address in the payload. Also configure the server to listen on a pre-determined port for the data connection. Once this is done, create a one-to-one NAT between the FTP servers public and private IP address and open the port for the control connection and a range of ports for the data connection.
PIX Firewall allows the configuration to allow/deny secure FTP traffic through it. There are no fixup commands for this. However you can use access lists to open ports 989 and 990 for FTPS traffic to pass through. Port 989 is for FTPS data (FTP protocol and data over TLS/SSL) and port 990 is for FTP (FTP protocol and control over TLS/SSL). Both of these ports are of Internet Assigned Numbers Authority (IANA) type. Also, if you need to stop the regular FTP data, you can issue the no fixup command for FTP on ports 20 and 21 in addition to access lists.
An important part for the secure FTP is that each of the parties negotiates the encryption method to be used whether they use SSL or SSH. Once they match the encryption method, all the information they exchange in between is encrypted from Layer 4 (L4) and later. Therefore, TCP and UDP are also encrypted. With the traffic being encrypted, no one in the middle can understand the information that is exchanged.
Be aware that the PIX is in the middle of the information exchange (FTP client and FTP server). Also, the ports the PIX uses to filter are in the TCP/UDP header. The only information not encrypted is the IP header because it must be readable for all the parties in between to route the packet. This is the only information the PIX can use to filter.
If opening ports 989 and 990 does not work, open ports 20, 21 and all ports over 1000. Since traffic is encrypted, the PIX has no way of knowing what ports to open, and it would only work with a static one-to-one translation.
