This is because when using FTPS the command/control session (tcp port 21 traffic) is encrypted and the firewall can't see it. Since the firewall can't see it, it can see the PORT/PASV commands and does not know what ports the data connection is trying to use. Since the firewall has no clue what data ports are being used it can't dynamically (and temporally) allow the connection to happen.
If both the client and server support it, you can have the client issue the CCC command before the put/get/ls commands. CCC is the "clear channel command" command. This causes the next command to be issued in the clear (that is not encrypted.
If your ftp client or server does not support the CCC command, then you need to make sure that:
If using active ftp then your firewall needs to allow outbound traffic with a source port of 20 and a destination port > 1023. The other side must allow inbound traffic with source port of 20 and destination port > 1023. If needed the firewalls can be setup just to allow the ports and direction for the specific IP addresses involved.
If using passive ftp, setup the ftp server to use a specific port range for the data connection (say like 10000-10049) and then your firewall needs to allow inbound traffic with a source port >1023 and a destination port range equal to to what you set your server to use for the data port. The other side must allow outbound traffic with source port >1023 and destination port range equal to what you set your server to use for the data ports.
Also it would be best if your server and client supported extended passive or extended active
ftp. If they don't then you could still have problems. This is because the firewall can't change the IP address on the PORT or PASV commands and so the other side sees the servers real IP address, not the NAT'ed address (assuming you are doing NAT).
