I administrate a server running Sambar with a self-generated temporary cert. HTTPS works fine as does regular FTP. The server is behind a LinkSys NAT router. I have port 990 forwarded to the server. I also have a client machine at home that is behind a LinkSys NAT router. My home configuration is: Port triggering for outgoing to 990 to open for incoming port 3001-4000. CoreFTP LE client set with direct ssl, open ssl, ssl list and ssl xfer, active mode, WAN IP specified in connection, data port range 3001-4000. Everything seems to work fine until the LIST command is sent, at which point an error is returned. I know the data connection is getting through because I also run Zone Alarm with the firewall off, but program permissions on. On first connect, it asks if CoreFTP should be allowed to access the internet, and shortly after asks if it should be allowed to act as a server (this shows me the machine has received a connect request for one of the client's listening ports).
Here is the Sambar documentation; perhaps someone can see something I'm doing wrong:
"One option for providing secure FTP is to enable the FTPS server, an "implict" SSL-based FTP server that requires SSL/TLS for all operations running on port 990. The second option is to use the "AUTH AUTH SSL or AUTH TLS" feature which performs the equivalent of "START TLS" on the FTP connection and requires SSL/TLS for all future operations on the user connection. Note: When FTPS is enabled, the connection process is always encrypted. The data channel is always assumed to be encrypted in the Sambar Server unless the config/config.ini FTPS Clear Data Channel is set to true.
Both FileZilla and CuteFTP Pro 3.0 have been reported to work with the FTPS server. CuteFTP 6.0 appears to have an SSL data channel issue, requiring the Clear Data Channel option."
I have tried other FTP clients, and have not gotten anything to work (Core FTP has gotten the farthest - to the LIST command). I would prefer to have the entire session encrypted. Any suggestions?
SSL No LIST
Okay, I've found that I have to update the server software to a version that supports the FTP PASV IP parameter when behind a NAT router so that the WAN IP is encrypted. Data channel IS port 989, so I'll forward it. When that's all done - this should work. Sorry to use up the space here for nothing.... 
Well, still not working! I have no idea what port the server will choose for data during a passive connection (evidently it's only 989 for an active connection), so I have no way to forward the connection to it through the router. I'm going to try active mode since though it says it's not supported, PORT commands work with the normal FTP on port 21. I'll probably have to set the server to send on the data channel in the clear, since even active mode fails when the data is encrypted (server only transmits it's WAN address for passive connections, the router can fix this if it can read it). At least username/password and commands are still encrypted. Setup is going to be like this: Server set for clear data channel, server's router set to forward requests on port 990. Client set for encrypt WAN address, data channel on 50001-50100. Client's router set to trigger ports 50001-50100 for incoming on outgoing requests to port 990. If this doesn't work - I give up! 
Whew! This has been quite an education in the inner workings of FTP!Did find out that Core FTP seems to be a little picky about that port range. I got a LIST through at home, but all my tranfers failed with a 499 error connecting to the client. So at the server, I tried another computer on the network without a port range, and it worked fine. Then I specified the port range and started getting connection failures again. So I looked at the starting port for the successful non-specified-port transfers and it was 83,119 (21367). Then I specified 256 ports from 21367 to 21622, and that worked pretty well until I requested enough files to run through the range twice. Then I started getting errors again. However the neat auto-session-save feature allowed me to complete the transfers a while later. Not sure what's going on there, but I'll try this at home again and post the results.
I was finally able to download files at home, through two NAT routers with an encrypted control channel with the same port range as I used on the server's network. I only had to forward one port on the server's router, and since I have an adaptive software firewall at home, I can turn it up full to block any of the unused triggered ports that the client-side router opens for active mode connections. This is a secure enough solution that I can live with it. The client still seems to miss on some of the data connections on first connect, but if I wait a few minutes and try again it works fine - once the data connections start working it usually runs right through the session with no problem. 
Hope these rantings help someone else! 
Hope these rantings help someone else! It's Core FTP LE v1.3c, build 1446. If the problem arises, it stays through the entire range until all retries are exhausted and the session self-terminates. Perhaps I should also mention that both client machines (home and server's network) are running Win98SE, server is on Win 2000 Pro. If it happens again, I'll post a session log.