I currently used SLift Pro ftp product (google with keywords "SLift privylink")
without SSL enabled (but the files are sort of hashed/encrypted at one end &
when transferred over, it's unhashed/decrypted) but our customer (the remote
end whom we have data interchange with) now wants SSL to be enabled as
Internet files transfer needs better security than the current method & this is
the challenge facing me now
SLIFT Pro's data transfer mechanism is implemented based on FTP protocol. When SSL is not enabled/used, firewall configuration between server and clients is quite straightforward (&
is currently working in our environment) as most firewall products can support FTP protocol without any issue. Server and client hosts can use private IP addresses with NAT enabled at both ends' firewalls/routers. NAT will translate IP address information in FTP protocol communication messages from public to private, or private to public, automatically and do necessary port forwarding actions in context.
But when SSL is enabled to protect the data/messages, the message content will become unknown to the firewall servers/network routers. For this reason, NAT will not be possible anymore as firewalls/network routers will not be able to translate the IP address information in the 'encrypted' data packets. When this issue happens, the server will request a connected client to establish a new connection to server's private IP address for data transfer. Subsequently, client will follow the incorrect instruction (as not modified by NAT) to attempt to make a connection to server's private IP address.
Customer does not agree to replace SSL with SSH tunnel (ie ftp over
SSH tunnel/VPN )
I'm setting up a test network at my end to do a more rigorous test. Any suggestions
on how I can approach this troubleshooting? Checking firewall console for denied
access? Anyway to check for NAT not being successfully translated?
Can I run netstat or some sort of tool to sniff (both client & server are Windows 2003)?