All I can tell you is I had for a while a ftp + ssl server running (and yes ftp + ssl is useful in some scenarii) behind a pf machine and it all worked perfectly well.
The problem is that you get first a SSL handshake and then all the rest is ciphered, preveting ftp-proxy from doing its work. You may need to do the following: - restrict the data ports of the ftp server to a certain range (for example 40000 to 45000) - open these ports on the pf machine (bypassing the ftp proxy behaviour) - have the ftp server listen on a port other than 21 If you wanted ftp-proxy to work transparently with SSL it would have to proxy the SSL handshake as well which might be a problem in terms of security since the data flow would exist in clear (somewhere in memory) on the proxy. On 7/31/07, Peter N. M. Hansteen <[EMAIL PROTECTED]> wrote: > A client of ours (don't ask) has been sold by somebody else on the > idea that FTP over SSL (afaik implemented with some Microsoft system > or other) is the way to go. > > Now FTP over SSL seems to be a variant which isn't obviously well > supported other than a few experimental clients, and with a fairly > straightforward 4.1 pf + ftp-proxy setup (close enough to the one in > the tutorial[1]) near the client end, what I get is that the client > and server happily clear authetication, but do not manage to set up > their SSL connection. > > What I get from ftp-proxy is a sequence of > > Jul 31 10:49:27 delilah ftp-proxy[15797]: #1 client command too long or not > clean > > with incrementing # numbers, until the partners give up. > > The 'techies' at the other end seem to have problems with concepts > such a server tunables, so the question is, is there some obvious > ftp-proxy workaround I've missed (other than the even more obvious > 'use something else')? > > - P > > [1] http://home.nuug.no/~/peter/pf/, specifically > http://home.nuug.no/~peter/pf/en/newftpproxy.html > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
