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).

... doh. Yes you are right. I've checked you are right. I can't believe I
forgot that. I was working from a 8-month memory of the code.

>
>> 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.

ooh sorry. Yes its fudging my head now too ;-)
"in passive" == "need to respond in passive not active"
 but we seem to sync up later where its more important.

>
>> 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)?

Yes, squid defaults to passive both in the setting and in the code. From
the code it only attempts active (PORT/EPRT) if that setting is "off" or
when the PASV fails. then it retries with a PORT immediately before going
to error.

>
>>
>>
>> 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.

Yup, so I said check 'ftp_passive on'. Should be trying a PASV first. if
thats also failing there are NAT problems with the remote (server?) end.

>>
>> 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.

Sorry, me getting the PASV and its response bass-ackwards again.

Either end of control can send PASV. When squid receives one it sends out
its control-sockets IP in response.

>
>> 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.

I was, wrongly it seems.

You can view the whole sequence with debug_options 9,2.

>
>> 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.

Thus 'small'. But nasty. Lets hope it's not occuring.

>
> 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.

Possibly a NAT or router at remote end playing evil with the data channel.

>
> 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
>

Amos
Received on Thu Dec 06 2007 - 16:18:29 MST