<div> </div><div> </div><div>14.02.2017, 21:50, "Alex Rousskov" <rousskov@measurement-factory.com>:</div><blockquote type="cite"><p>When I am talking about the forwarding case, I am talking about a simple<br />configuration without any redirection or other TCP/IP level tricks or<br />even reverse proxing of any sort: The FTP client sends FTP requests<br />directly to Squid's ftp_port (specifying the ultimate destination using<br />an extra @ sign). IIRC, that used to work with popular proxy-aware FTP<br />clients when we added the ftp_port code.<br /><br />In that simple case, some FTP client refuse to accept the FTP data<br />connection from Squid unless that data connection comes from the same<br />source IP address as the destination address of the corresponding FTP<br />control connection. The old "Use local IP..." code/comment were added to<br />make such clients happy (the changes in [trunk] revision 12742.1.41 are<br />pretty telling, especially in the light of your changes).</p></blockquote><div> </div><div>Just tried the following setup with squid running on localhost:21:</div><div> </div><div><div>[alg@centos64x64 ~]$ ftp 127.0.0.1</div><div>Connected to 127.0.0.1 (127.0.0.1).</div><div>220 Service ready</div><div>Name (127.0.0.1:alg): anonymous@172.17.10.30</div><div>331 Anonymous access allowed, send identity (e-mail name) as password.</div><div>Password:</div><div>230 User logged in.</div><div>Remote system type is Windows_NT.</div><div>ftp> passive</div><div>Passive mode off.</div><div>ftp> ls</div><div>200 PORT successfully converted to PASV.</div><div>125 Data connection already open; Transfer starting.</div><div>...</div><div> </div><div>I have also tried to connect from my Windows machine to itself via squid on a different machine with FileZilla client (proxy server was specified in settings) - works like a charm.</div><div> </div><div>It seems that the patch doesn't make things worse (if I understood you correctly).</div></div>