fsf001
Has anyone encountered any issues using the ssl feature when the client computer is behind a NAT? If so, how have you resolved the issue?
Thanks for the help.
Thanks for the help.
fsf001 wrote:trying to connect a client ftp to a server using ssl when the client is behind a NAT.
You also need to know if you are doing PASV or PORT mode transfers.
PASV should be fine if there is no server NAT. For PORT mode, you
will need to force your client IP to be whatever your de-NATed address
will be on the outside of the firewall.
fsf001 wrote:I understand from your response that the firewall will be unable to inspect the CLEARTEXT payload and thus fail but given that NATs are so prevelent, is there any solution to doing a secure connection?
No. If any NAT could decrypt your message to read the PASV and PORT
commands and their responses, well that would defeat the whole point of the encryption, right?
fsf001 wrote:You mentioned that the server will have to respond with the real external address but this may be difficult if the server is also behind a NAT(?).
Yes it will be. Unless the server has the ability to force the PASV
response IP to be whatever the server's external IP is. Some servers
have this feature. Notably Valicert's and Covalent's servers do.
If they do not do this, they CANNOT be behind a NAT unless you are
using SmartFTP and the "Force PASV IP" feature (which tells SmartFTP
to ignore the bogus IP in the PASV response and use the already known IP from the control connection.
Connection-tracking firewalls/NATs (iptables, netfilter, etc.) all have
special FTP modules that sniff the *payload* of the FTP control channel
for the PASV and PORT commands (and responses) in order to
create a dynamic opening and NAT rule for the soon-to-be data connection. When the control channel closes, these rules also go away.
Since SSL on the control channel encrypts those messages, there
is nothing the firewalls can detect, and therefore will not open
a hole for the new data connection that will be trying to be established.
Thus, whichever side is receiving the data connections will have to
have a blanket firewall opening for a range of ports that should match
what the server/client will open for data connections.
fsf001 wrote:Do I need a software VPN? Also would you happen to know why HTTPS doesn't have this problem?
A software VPN encrypts *everything* including TCP/IP itself, and thus
you don't need any SSL on anything since it's ALL encrypted. This
is what IPsec and L2TP and friends are all about. SSH can do this, but it's really a port forwarder, not a IP protocol wrapper.
HTTPS does not have this problem since it is a single-connection protocol.
It does not have to establish a completely separate data connection in
the way that FTP does. It also doesn't have to worry about restarts,
file mode (ASCII/BINARY), and such either. HTTP also has no means
to specify filesystem manipulation commands (well, not exactly, that's what web-DAV is all about) either.
You should read RFC2228 and Ford-Hutchinson's information on this
stuff. The Murray IETF draft is also informative as well.