Re: [squid-users] FTP through Squid and pf.conf with load balancing dsl

Amos Jeffries wrote:
> Well ...
>
> To 'initiate' passive data mode is to send a PASV or PORT control
> message.

Minor niggle. To initiate passive data mode is to send a PASV control
message. Sending the PORT command means you want the remote server to
connect to you (and hence sets up an active transfer).

> To do that the _sender_ must already have a data listening port open
> and ready to 'passively' receive the response.

Erm... In passive mode FTP the client originates both the control and
data connections. The PASV command is a request for information on what
IP and which port to connect to for the data channel.

> To my mind that makes the side which is capable of receiving
> anonymous FTP connects in passive.

I'm having a bit of trouble parsing this statement.

> If your squid is connecting _out_ badly, _it_ must be in passive and
> accept requests from clients.

Agreed, and I think I now better understand what you are saying, and why
you made the suggestion you did.

>
> This it show squid behaves with "ftp_passive on". It just opens a
> listening socket (on port 20 I believe) and issues a number of
> PORT/EPRT/PASV/EPSV controls to tell the client where to connect to.

It issues the PASV/EPSV to the server, correct (since it wouldn't issue
a PORT or EPRT with ftp_passive enabled)?

>
>
> Back to the initial problem; was with _squid_ outgoing data traffic
> going through the wrong ADSL link. Which to me means the passive was
> OFF, or the client incoming request came _in_ through that second
> ADSL.

In other words perhaps Squid gave a PORT command and specified a
different IP than was used for the command channel? Odd behavior, but
fair enough.

>
> I considered the possibility squid might be sending the wrong IP in
> PASV.

I don't understand this statement either. The PASV command is sent
without arguments. The response to a PASV request contains IP and port
information.

> BUT, found that its looking up the dst-IP of the control connection
> to generates the PASV. That means it sends out the IP the client is
> connecting to.

Are you saying that Squid (with ftp_passive on) originates the data
connection from the same IP/interface as is used for the control
channel? The comment from ftp.c "Open data channel with the same local
address as control channel" indicates that this should be the case.
Then again, the variable (addr.sin_addr) looks to be used when
constructing the PORT command, so the same IP used for the control
channel should be used to accept active FTP connections.

> There is only a small possibility of this going wrong if in
> transparent mode.

But it shouldn't be an issue in transparent mode, as port 21 would not
be intercepted by the proxy, and the likelihood of port 80 being used
for the data channel is minuscule.

If I'm my above understanding of what you are saying is correct, using
ftp_passive on (the default) sounds like a winning plan to me then. It
allows for fail-over (in that FTP transfers are not limited to one
tcp_outgoing_address as in my solution), but should keep all
related-to-the-FTP-connection traffic on the same network path. I still
find it odd that Squid would send out a PORT command specifying a
different IP than was used to originate the command channel... My C-foo
is pretty weak, but it sure doesn't look like this is the case, so I am
now left to believe that the issue is outside of Squid.

 From the original message:

> > Im thinking to use squid ftp proxy under the firewall in other
> > machine and procces the data for later send all ftp to the open bsd
> > firewall.
> >

Heck if I know...

>
> Amos

Chris
Received on Thu Dec 06 2007 - 15:41:43 MST