[squid-users] Native FTP relay: connection closes (?) after 'cannot assign requested address' error

[Alex Rousskov]

On 01/23/2017 11:11 AM, Alexander wrote:
> Actually, a PASV-handling logic looks a bit strange to me. In
> Ftp::Server::handlePasvReply() there is a comment:
> 
> "In interception setups, we combine remote server address with a local port
> number and hope that traffic will be redirected to us."
> 
> How is it supposed to work? I do
> not have any idea on how a traffic could be redirected to squid (redirecting
> everything from A to B is not an option).

You should only redirect FTP traffic, of course. Sorry, I do not know
how you can identify FTP data traffic in your environment, but I am sure
there are tools that can do that in some environments (e.g., by
monitoring FTP 227 responses on the already redirected connections).
There are also some ideas for future work below in case nobody can
suggest anything better.


> Also, why squid needs to intercept a data connection?

For the same set of reasons Squid needs to intercept everything else --
traffic logging, blocking, and adaptation. If you want Squid to proxy a
"message", Squid expects to proxy the entire "message". In FTP, a single
"message" (from high-level point of view) is often split among two or
more connections (from TCP point of view).

Needless to say, your specific needs may differ from that general
principle. It is possible that Squid needs a knob to handle your use
case differently. However, I am pretty sure that somebody does want
Squid to do what it does know so we should not change Squid behavior to
satisfy your use case.


> If I hardcode one of squid's IP in handlePasvReply(), everything works fine.
> However I am not sure if it is a correct way because a client opens a data
> connection not to an FTP server...

I agree that mixing intercepted [control] and direct [data] connections
is a bad design in general, even if it works in your use case. In many
cases, Squid IP address is not even reachable from the client!
Hopefully, you can find a better way to handle this.

What if you can restrict the set of ports that Squid uses to accept
passive FTP data connections? That way, you can redirect only those data
connections that match those ports. This is not an ideal solution, and
Squid does not support that directly right now, but it might work in
principle.

Another option is to modify Squid to report the expected data connection
IP:ports to some helper so that you can write a script that dynamically
modifies your network redirection rules.

Others may know a better way to handle this (short of deploying an
FTP-aware L7 networking gear).


Cheers,

Alex.