On 13/12/17 04:51, Sticher, Jascha wrote:
Hi, we're currently upgrading our proxy environment to squid 3.5.23 (Debian Stretch) and would like to use the native FTP proxy feature to replace our old FTP proxy solution (frox). Due to some design choices, we have a proxy hierarchy for HTTP as well as FTP traffic. Is there a way (yet) to tell my first squid instance to use another squid as a forward proxy with native FTP? IIRC, the cache_peer directive always uses HTTP requests, so this seems as a dead end.
The FTP traffic arriving at Squids ftp_port is converted from a stream of FTP messages to a stream of HTTP messages for handling.
AFAIK those resulting HTTP messages can be routed through a cache_peer same as any other HTTP traffic. BUT at very least the peer needs to also have the same "native FTP" implementation to successfully convert them from HTTP back to FTP native messages on the outgoing server connections at the other side of the cache hierarchy.
There may be other internal state checks on the HTTP messages to make them get the "native FTP" conversion on outgoing. So YMMV.
If the peer delivery does not work you may be required to do the same workaround SSL-Bump sometimes requires. Do allow the front-end Squid to re-FTP the traffic to the appropriate server then intercept it independently into the backend with its own ftp_port accepting the "native FTP" coming out of the frontend.
FYI: I do know there are conversion issues with FTP <-> HTTP authentication recently uncovered and not yet resolved. So if you need proxy auth at all staying with Frox would be better for now.
Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
