On 11/7/18 1:54 PM, Schroeffu wrote: > I have had today experienced today exactly the same issue with Squid 4.4 for > this URL: https://bugs.squid-cache.org/index.cgi > Error Message from Squid: > > /The following error was encountered while trying to retrieve the URL: > https://bugs.squid-cache.org/* > Connection to 2001:4801:7827:102:ad34:6f78:b6dc:fbed failed. > The system returned: (101) Network is unreachable/ > > It is not only IPv6 related issue. It happens to me when denying any request > via proxy without authentification like this: > > acl Authenticated_Users proxy_auth REQUIRED > http_access deny !Authenticated_Users all For most modern Squids, this http_access policy is, IMO, incorrect because it blocks internally-generated requests, such as requests for missing intermediate certificates. Please adjust your configuration to allow those requests (if you want them to be allowed). [rant]It could be argued that Squid should automatically allow internally-generated requests, but I do not think that would be a good approach, despite the inconveniences/problems caused by the current "apply standard http_access rules" approach.[/rant] N.B. There is no need to say "all" after another ACL in a rule. It is like adding "and true" to some boolean statement -- it adds no value and creates noise/overheads. > You will see in the access log Squid is trying to hit > http://cert.int-x3.letsencrypt.org/ directly with 407 (not authenticated), i > am so confused, why is it doing that and why is it not authenticating? I suspect Squid is requesting a missing intermediate certificate for some letsencrypt-issued origin certificate. This is "normal" -- some https sites do not send all of the intermediate x509 certificates, and modern Squids request them automatically instead of failing certificate validation. Squid does not "trying to hit letsencrypt.org with 407". HTTP 407 is a response status code, not a part of the request. That error response is probably generated by Squid (not letsencrypt.org); its existence and its status code are determined/caused by your own http_access settings -- it is your Squid that is denying the internal request, not letsencrypt.org. HTH, Alex. > 1541623232.530 0 - *TCP_DENIED/407 3619 GET > http://cert.int-x3.letsencrypt.org/* - HIER_NONE/- text/html;charset=utf-8 > 1541623232.530 245 172.16.5.15 NONE/200 0 CONNECT > bugs.squid-cache.org:443 xxxx > HIER_DIRECT/2001:4801:7827:102:ad34:6f78:b6dc:fbed - > 1541623232.546 0 172.16.5.15 NONE/503 4940 GET > https://bugs.squid-cache.org/favicon.ico xxxx HIER_NONE/- text/html > Why it happens on > https://bugs.squid-cache.org/index.cgi and how is that letsencrypt related? > I have no problems with any other letsencrypt secured domains and also not > on any site providing ipv4/ipv6 at the same time (Google/Facebook). But yes, > also my Proxy can *not*speech ipv6, if that is something related with > letsencrypt? > more specs: > - ssl bump active > - icapcan active > - ntlm and basic auth active > - dns_v4_first on/off doen't matter/doesnt change anything. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
