[squid-users] 2.7.STABLE9 & Error with option deny_info from local requests

Wed Dec 3 14:49:34 UTC 2014

> On 29/11/2014 2:40 a.m., Mark Riede wrote:
> > Hello,
> > 
> > I have a strange behavior with Squid 2.7.STABLE9 and local requests 
> > which should be intercept by the option deny_info.
> > 

> 1) *Please* upgrade your Squid. 2.7 has been unsupported for more than 5 years now and is seriously out of date with modern web traffic needs.
That is not an option. We are already migrating to an other software.

> 2) "intercept" and how deny_info works are completely unrelated concepts.
"intercept" was the wrong word. The word "match" ist more appropiate.

> > I am using Squid as a reverse proxy. I have configured a list of 
> > subdomains (i.e. subdomain.domain.tld) in a file via the option 
> > dstdomain, which will be forwarded to the defined cache peer.
> > There is an additional list of domains (i.e. *.domain.tld) which match 
> > via wildcard to all other domains, which are not absolutely defined 
> > yet and will be forwarded to a custom error page via the option 
> > deny_info.
> > 
> > The problem is that requests forwarded to the ip of the server, i.e. 
> > 192.168.0.1, will be catched up by the option deny_info. But, when the 
> > request is forwarded to the ip of the localhost (127.0.0.1), the 
> > option deny_info will not match.

> ?? *all* traffic to the cache_peer is "forwarded to the ip 127.0.0.1"
> since that IP *is* the cache_peer's IP.
Ok, I think it needs a little bit more explanation.
External requests will be forwarded via nat to internal IP 192.168.0.1 and the option deny_info works well.
But when the nginx sends a request to the squid with the destination IP 127.0.0.1 the option deny_info does not work.

> 127.0.0.1 (and ::1) are special purpose IP addresses. Traffic is not permitted to go to/from it from a global-scope IP address. When you send to/from a localhost IP then it is mandatory for the TCP system to use the localhost IP as source.


> > Now the strange behaviour is that requests to the ip of the localhost 
> > but with the destination domain subdomain.domain.tld will be answered 
> > successfully. I need a fix because clients get the custom error page 
> > for requests via http (NAT to 192.168.0.1) but not the same response 
> > via https (nginx to 127.0.0.1). I don´t know where or how I can fix 
> > this problem or do more debugging.


> Why is nginx not forwarding proper HTTP messages with the relevant
> Host: header contents to Squid? the HTTP message syntax is no different when sent over TLS port 443 as when sent over TCP port 80.
Nginx is forwarding the request with a proper HTTP-Header because the option cache_peer is working well. We are able to cache HTTPS-Requests so far.
It seems that the option deny_info does not work well. 

> - From your description it sounds like nginx is sending to Squid messages with URL https://127.0.0.1/* which cannot be expected to exist in your list of acceptible domains.

> Also, why are you not using Squid to receive and direct both HTTP and HTTPS traffic to the relevant servers?
>  Squid accepts port 443 traffic with an https_port directive just fine.
Because we are using the Squid for multiple clients and Squid in our version ist not able to handle multiple certificates.

> > 
> > # Config http_access allow localhost

> The above rule permits all traffic from 127.0.0.1 to go through this proxy *no matter what*. From your description that would be all traffic arriving from nginx **AND** any traffic you direct at
> 127.0.0.1 IP from any other software.
Thank you for your consideration. I will consider it.

> It is a very bad thing to do, particularly for a reverse-proxy. Remove it and traffic from nginx (and yoru 127.0.0.1 tests) will start to obey the other rules. Not a complete fix, but required for Squid to work as you expect.

> > acl foo dstdomain "/file" acl foo_deny dstdom_regex "/ file _deny" 
> > http_access allow foo

> When testing this ACL with a raw-IP Squid will lookup reverse-DNS of the IPand compare the result with contents of /file.
> Meaning 127.0.0.1 == "localhost" --> is "localhost" one of the peer hosted domain names? should not be.
Which version was in use?
Is it possible to override this behaviour?
I don´t think it is the right location of the problem. Everything works well except the option deny_info.

> > cache_peer 127.0.0.1 parent 8080 0 no-query originserver name=srv1
> login=PASS
> > cache_peer_access srv1 allow foo cache_peer_access srv1 deny all 
> > deny_info ERR_FOO foo_deny http_access deny foo_deny http_access deny 
> > all
> <snip>

> The rest of these rules match your intended behaviour of Squid.

> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)

> iQEcBAEBAgAGBQJUfDWaAAoJELJo5wb/XPRjfEYH/1KMTu400wRO0wmz6RURlUwB
> 6jVEqWGc+rYV1hvtjZe5PtvJW8nMxF6idP0SU2aj/GWoGmcusrq413sAsoQhwEYT
> lGAlDhU08c6aQ5r7ZyNY9TMNip8OJS6NPYEWV07Nw34QuJcQXbHUEC9VTAjboQqa
> VYfnrBZIbMXFY3wkdhGkyNm4m/Uz5scOZ2lKAVabhZ4wHEu/NVMYISD3mEIHNiT7
> rLT9/dqZaj/KHn1Vb5Z31k3szija9ZMh2Gu6A5tg3TfpelBVrbCXFOzoHIJMN7es
> eRScL64c2KZ1PMpTMrTUzq1ILcOIuXcVDSdcj610Tcp524u0ssQ1vteJqj8kFak=
> =8Dhf
> -----END PGP SIGNATURE-----
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users