On 18/02/2014 1:16 p.m., Nikolai Gorchilov wrote: > Hi Spyros, > > Seems you're experiencing request loops, that are unrelated to your ACLs > > Looking at the logs, we can clearly see pairs of requests for same > url. Like this: > 1392590890.301 0 192.168.1.20 TCP_MISS/403 4158 GET > http://www.tvxs.gr/ - HIER_NONE/- text/html > 1392590890.302 1 192.168.1.1 TCP_MISS/403 4263 GET > http://www.tvxs.gr/ - HIER_DIRECT/192.168.1.20 text/html > > As the logging happens at the end of transaction, records are ordered > by finish time, not start. They actually started in reverse order: > 1. First came the request from 192.168.1.1 for http://www.tvxs.gr/. > 2. As it was considered a MISS, your Squid decided to go directly to > the destination server (thus hierarchy code HIER_DIRECT) > 3. PROBLEM! PROBLEM! Surprisingly, Squid resolves www.tvxs.gr as > 192.168.1.20 and fires the request towards this IP! Sadly, NOT surprising: A) kernel NAT records on the Squid box indicate that no NAT alterations to the TCP packet took place there. B) TCP packet indicates that destination server is 192.168.1.20. ==> forward DIRECTly to original destination server (192.168.1.20). > 4. Boom! This is how the same request arrives again, this time from > source IP 192.168.1.20 (Squid itself). We have a loop! > 5. Squid detects the loop (something like "WARNING: Forwarding loop > detected" in cache.log) and generates internal error response like > HTTP/403 Forbidden, using ERR_ACCESS_DENIED or alike. Thus hierarchy > code is HIER_NONE. "SECURITY ALERT: Host header forgery detected" should also be showing up on the initial request processing. Since Squid validates whether (192.168.1.20 == www.tvxs.gr) => FAIL. http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery Although something strange is still going on. Squid should be logging the hierarchy details as ORIGINAL_DST instead of DIRECT. > 6. The error returns in the first instance of this request after 1ms, > and Squid returns it to the original caller (TCP_MISS/403). > > I don't have clear idea what is the root cause of the loop, but I'd do: NAT interception occuring on the OpenWRT makes critical IP address details unavailable to Squid. The proper way is to use policy routing on the OpenWRT and only do the interception on the Squid box. OpenWRT config: http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute Squid box config: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat OR http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect HTH Amos
