Hi Guys, Yutaka Sato wrote: > The problem seems not in SSL but in TCP/IP level. You are absolutely correct. You prompted me to do some in depth debugging and I'm sending this in case it helps anyone else out in a firewalled environment. Our FTP proxy uses IPtables as a local firewall (there are more serious firewalls further out) which essentially opens TCP ports 20 and 21 and related/established. With passive FTP, because the client initiates the Data connection TO the Proxy (or server - same scenario) which as far as the IPtables system knows are not related/established, helper modules are normally loaded (ip_conntrack_ftp.ko ip_nat_ftp.ko) which 'peek' into the Control channels' conversation and sniff the port details out from the data payload. This way, IPtables knows to which port to expect the incoming connection request. With TLS, the Control channel is encrypted and so the helpers cannot sniff the data payload to fins out where to expect the incoming request. Result is the data channel open request is denied. Ah. Now it all makes sense. The fix is to have the FTP server use a restricted range of ports for passive mode, and have the firewall rules allow them. Usually, the recommended range is the IANA registered ephemeral range of 49152-65534. Yutaka, thanks for your patience for my assumption there was an issue in Delegate, which there wasn't. Steve