Le 07/06/2012 05:09, Amos Jeffries a écrit :
3.1.6 has quite a few issues with IPv4/IPv6 behaviour in FTP. Please try
upgrading to the 3.1.19 package in Debian Wheezy/Testing or Unstable.
I tried with Debian Wheezy, the behavior is the same. I will test with a
3.2.x version compiled...
As a workaround, to force FTP clients to connect to Squid using IPv4,
I created a "proxy-ftp" entry in our DNS pointing to the IPv4 address
of the proxy. If FileZilla is configured to use "proxy-ftp", it's
working fine.
The problem is that sometimes the FTP server has IPv6 enabled and
then it's not working, the workstation is using IPv4 to reach Squid
which is using IPv6 to reach the FTP server. The FTP client is
immediately failing after a PASV command.
Squid is coded to try IPv6+IPv4 compatible commands (EPSV) first. If it
gets as far as trying IPv4-only PASV command it will not go backwards to
trying the IPv6+IPv4 EPSV command.
... "ftp_epsv off" is making Squid go straight to PASV and skip all the
non-IPv4 access methods.
When I force the FTP client to reach Squid in IPv4, the client will try
to perform PASV on the server even if Squid is connected to the FTP in
IPv6, I think this is the root of the problem.
"CONNECT debian.mur.at:21 HTTP/1.1" 200 521 TCP_MISS:DIRECT:2a02:3e0::14:80
On FileZilla : "Enter passive mode (80,223,35)" => failing
The third option is to upgrade your FTP server to one which supports
those extension commands (they are for optimising IPv4 as much as IPv6
support). Then you won't have to hack protocol translation workarounds
through Squid to access it from modern FTP clients.
The problem is happening on remote FTP servers I don't manage.
Is there a possibility to make Squid using its IPv4 address for all
outgoing FTP? I tried with "tcp_outgoing_address" with no luck.
Regards,
Nicolas
