Thank you for responding. > 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. I am using Ssl-bump, but on a different inbound port and it will never be for traffic heading out to this peer. There is an entry in my logs much earlier during the process (just before it does peer_select) which states: kid1| 85,5| client_side_request.cc(1444) sslBumpAccessCheck: cannot SslBump this request Does this use of ssl-bump at any stage preclude the use of cache_peer authentication with CONNECT? My http_port, various acls and ssl_bump statements are all after the config extract shown below. > What kind of HTTP authentication does your client/peer use/expect? >From the successful GET connections, I can see that the peer requests both a Negotiate and NTLM, my clients respond with a Negotiate. regards, Paul 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
