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