In message <_A3597@delegate-en.ML_> on 12/06/06(22:21:27)
you Steve Brown <firstname.lastname@example.org> 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
Thank you for your precise description of the problem. It'll be
helpful for others who will encounter the same problem, and for me
to reduce a suspicion on DeleGate :)
|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
|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
|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
|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.
Maybe what DeleGate should do on this issue is to put more helpful
information about the error in the response message to the FTP client.
9 9 Yutaka Sato <email@example.com> http://delegate.org/y.sato/
( ~ ) National Institute of Advanced Industrial Science and Technology
_< >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller