On 1/8/21 12:18 PM, Paul@xxxxxxxxxx wrote: > I am using Ssl-bump, but on a different inbound port and it will never be for traffic heading > out to this peer. My assumption is correct then -- bugs notwithstanding, we can ignore SslBump limitations here because they do not apply to your use case. > From the successful GET connections, I can see that the peer requests both a Negotiate > and NTLM, my clients respond with a Negotiate. AFAICT, Squid documentation implies that Negotiate PASSTHRU authentication should work in combination with connection-auth=on (which you do have). This is not my area of expertise, but my previous recommendation regarding sharing four CONNECT-related headers stands. Alex. > On 7 Jan 2021 at 15:18, Alex Rousskov wrote: > >> On 1/7/21 2:43 PM, Paul@xxxxxxxxxx wrote: >> >>> I am currently using Squid 5.0.3 but have an issue when using a cache_peer (non-squid & >>> outside my control) that requires authentication. My Squid server doesn't require >>> authentication and reading the documentation indicated that I need to set >>> 'login=PASSTHRU' on my cache_peer line, which I have done. This has enabled GET >>> methods to work as expected, but CONNECT methods are failing. The response from the >>> peer is a '407' with both methods. >> >>> I am controlling access to the peer via an acl: >> >>> --------------- >>> acl localClients src 10.10.1.0/24 >>> http_access allow localClients >>> >>> acl aclREDIRECT dstdomain "/etc/squid/redirect.txt" >>> cache_peer 10.10.10.167 parent 8080 0 no-query name=peerREDIRECT login=PASSTHRU >>> connection-auth=on >>> cache_peer_access peerREDIRECT allow aclREDIRECT >>> cache_peer_access peerREDIRECT deny !aclREDIRECT >>> never_direct allow aclREDIRECT >>> always_direct deny aclREDIRECT >>> always_direct allow all >>> >>> http_port 80 connection-auth=on >>> --------------- >> >> >>> An extract from my logs showing the failure: >>> kid1| 11,2| HttpTunneler.cc(326) handleResponse: Tunnel Server RESPONSE: >>> <!-- default "Proxy Authorization Required" response (407) -->---------- >>> kid1| 83,3| HttpTunneler.cc(345) bailOnResponseError: unsupported CONNECT response >>> status code [state:w FD 17 job22] >> >>> Is this a mis-configuration? or have I mis-understood how cache_peer works? >> >> N.B. I assume you do not use SslBump -- the configuration snippet above >> does not show SslBump being used. SslBump does not support what you want >> per commit f5e1794 message. >> >> What kind of HTTP authentication does your client/peer use/expect? >> >> The 407 response from the peer may be normal/expected (a part of HTTP >> authentication) or indicate a problem. If you do not get better >> suggestions, please show us the CONNECT request and response headers, >> exchanged between the client and your Squid and between your Squid and >> cache_peer (i.e. 4 headers total). You can use tools like >> tcpdump/wireshark to collect/render those plain text headers. >> >> Alex. > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
