Greetings:

We do a lot of secure FTP. In regards to you point #2, it isn't a routing issue as such, it's a NAT issue. The FTP protocol includes the IP address of the client machine in the data portion of the packets. NATting firewalls have to change not only the headers of the initial FTP packets, but have to reach into the data packets and change the IP addresses as well. FTPS encrypts packets from the get-go, so what happens is the NAT firewalls change the packet headers, but don't change the client IP in the data. So the server tries to respond to the IP address in the data packet, which are usually IANA private, and definitely wrong no matter what, and it doesn't work.

There are several solutions. Some FTP clients that support FTPS have a spot where you can tell them what their outside IP address will be. It inserts that address into the data packet so the firewall doesn't have to change it. That works OK for people who have a static external address. It doesn't work well for road warriors. A more robust solution is FTPES. That protocol modification does the initial negotiations (which the NAT firewalls have to change) unencrypted, and then switches over to encrypted for passwords and data transmits.

SFTP can also a good choice, but on Linux FTP servers the user setup is different. FTP servers can be given a list of users & passwords separate from the host's user setup. SFTP is really SSH, and so the users are typically given accounts on the box. This isn't necessarily a problem, it's just different.

Good luck.

No, but I am successfully connecting against a dovecot imap server over SSL. Works like a champ.

Our SAN is keeping 4 copies of the data (2 local and 2 remote) and it costs us about $3.50 per GB/month over 3 years for SAN and bandwidth, but without power or data-center space factored in. I think you're paying a little too much.