Configuring FTPS (either implicit or explicit) to work behind a NAT firewall can be a headache.
You are correct in that the ASA cannot inspect SSL/TLS encrypted traffic. The breakdown occurs when the data channel is being built. Whether in active or passive mode, L3 (IP) and L4 (port) information regarding the data channel are transferred in the FTP/FTPS control channel. With traditional FTP and the ASA's FTP inspection, this data is "inspected" and "fixed" to match the public/outside/whatever interface IP and the ASA dynamically adds a permit ACL to allow the data channel traffic.
With SSL/TLS (as part of FTPS) the ASA cannot see the necessary control channel details to "inspect" or "fix" what is necessary to make the data channel work. As such, you will need to have some added smarts/capability built into the FTPS server application you are using.
Capabilities include the following:
- The ability to set the port range sent in the control channel to be used for the data channel as used by passive mode (PASV) clients.
- The ability to set the IP address sent in the control channel to be used for the data channel as used by passive mode (PASV) clients.
Lastly, in your firewall, permitting (via nat/static and ACL) the range configured in number 1.
In a Windows environment, Cerberus is a great FTP/FTPS/SFTP server that has the necessary features and functions.
Say your FTPS server has an inside IP 192.168.1.10 and outside IP 18.104.22.168.
- Configure your FTPS server software to use TCP/35000 to TCP/35999 as a range for passive clients.
- Configure your FTPS server software to send 22.214.171.124 as the IP for passive clients. Note: Cerberus auto-detects your WAN IP and uses it automatically. Cerberus is also configured by default to not perform this fix for local IP network clients (as it would break them). Cerberus is smart. :)
- Configure your ASA to NAT (using static NAT or static PAT range) for TCP/35000 to TCP/35999 (plus TCP/21, TCP/990, etc.)
- Configure your ASA to ACL permit TCP/35000 to TCP/35999 to the the FTPS server (plus TCP/21, TCP/990, etc.)
Now when clients connect in from the WAN using implicit or explicit FTPS, the FTPS server will send back the correct WAN IP address (not its private address) and a TCP port in a known range to be used in the data channel. Having specifically NAT'd and ACL permitted the TCP ports, ASA inspection/fixup is not required.
Interesting (lengthy reference on FTP/FTPS/SFTP through firewalls): FTP Through Firewalls