Re: [squid-users] OpenBSD + PF + Squid: forwarding loop

On 2013-06-01 2:51, Amos Jeffries wrote:
> On 1/06/2013 6:13 p.m., Rob Sheldon wrote:
>>
>> Can you explain a little more about "non-intercept traffic" vs.
>> "intercept traffic"? I thought the only difference was whether the
>> browser sent an absolute URL in the GET request ("non-intercept") or a
>> pathname + "Host:" header in the GET request ("intercept"). Am I
>> missing something?
>
> That is pretty much the HTTP level difference. However the TCP/IP
> level also has its own differences. When acccept() happens PF hands
> Squid its own listening IP:port details on direct traffic, and the
> clients original IP:port details on intercepted traffic.
>
> That difference affects the Squid security systems which for
> intercept ports check those IP:port against the HTTP level Host:
> header detail of the clients destination. If they match Squid can use
> DNS to try and locate better origin servers. If they dont match Squid
> does the safe things and transparently relays it to that same IP:port
> the client was apparently contacting. So if you configure a browser to
> use a intercept port directly the IP:port received will be Squid's
> ones, the security checks guaranteed to fail, and a loop begins as
> Squid contacts itself.

OK, that makes sense, thanks.

Hmmm ... but, I'm pretty sure that rdr-to rewrites the destination
address in the packet. From http://www.openbsd.org/faq/pf/rdr.html: "The
redirection rule does apply and the destination address gets replaced
with that of the internal server."

So an rdr-to rule should cause Squid to be seeing itself as the
destination address...

> If you set debug_options 11,2 you can get IP:port details on each
> connection Squid is using to correlate with those traces and see if
> anything unexpected is showing up.

Thanks! This is something I've been looking for. (I did find
http://wiki.squid-cache.org/KnowledgeBase/DebugSections but couldn't
quickly make heads or tails out of it.)

Here's where the loop is happening (192.168.10.164 is the test
machine):

2013/06/01 03:02:20.447| src/client_side.cc(2298) parseHttpRequest:
HTTP Client local=192.168.0.1:3129 remote=192.168.10.164:36365 FD 9
flags=33
2013/06/01 03:02:20.447| src/client_side.cc(2299) parseHttpRequest:
HTTP Client REQUEST:
---------
GET / HTTP/1.0^M
Host: www.associatedtechs.com^M
^M

----------
2013/06/01 03:02:22.586| src/http.cc(2177) sendRequest: HTTP Server
local=192.168.0.1:25276 remote=192.168.0.1:3129 FD 12 flags=1

...That sort of does look to me like Squid's confused about the
destination address.

Here's the rest of that log up until the forwarding loop warning:

2013/06/01 03:02:22.587| src/http.cc(2178) sendRequest: HTTP Server
REQUEST:
---------
GET / HTTP/1.1^M
Host: www.associatedtechs.com^M
Via: 1.0 firewall.local (squid/3.2.7)^M
X-Forwarded-For: 192.168.10.164^M
Cache-Control: max-age=259200^M
Connection: keep-alive^M
^M

----------
2013/06/01 03:02:22.587| src/client_side.cc(2298) parseHttpRequest:
HTTP Client local=192.168.0.1:3129 remote=192.168.0.1:25276 FD 13
flags=33
2013/06/01 03:02:22.587| src/client_side.cc(2299) parseHttpRequest:
HTTP Client REQUEST:
---------
GET / HTTP/1.1^M
Host: www.associatedtechs.com^M
Via: 1.0 firewall.local (squid/3.2.7)^M
X-Forwarded-For: 192.168.10.164^M
Cache-Control: max-age=259200^M
Connection: keep-alive^M
^M

----------
2013/06/01 03:02:22.587| WARNING: Forwarding loop detected for:...

- R.

-- 
[__ Robert Sheldon
[__ No Problem
[__ Information technology support and services
[__ (530) 575-0278