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

On 1/06/2013 6:13 p.m., Rob Sheldon wrote:
> On 2013-05-31 22:18, Amos Jeffries wrote:
>> On 1/06/2013 11:58 a.m., Rob Sheldon wrote:
>>> I'd rather not futz around with pf anymore for now, since I don't
>>> think that's where the problem is. (Unless Squid for some reason
>>> requires "http_port...intercept" to be passed through an rdr rule...?
>>
>> Why yes. Squid does.
>> If you don't you will end up with invalid-URL errors.
>>
>> FWIW: sending non-intercept traffic to the proxy intercept port will
>> show up as forwarding loops. But don't read too much into that ...
>> AFAICT your tests were using the non-intercept port for the directly
>> configured traffic so that should be a different loop reason than what
>> you were hitting.
>
> Amos, thanks for responding. I was poking at it again just now.
>
> 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.

>
> I have also been intermittently testing with rdr rules on, including
> the closest I could get to Loic's suggestion (without stuffing up the
> network for a bunch of users), and I'm still getting the same errors.
>
>> The loop you were hitting did seem to be traffoc through Squid and
>> outbound to somewhoere port 80 being redirected a second time into
>> Squid.
>
> I thought about that, so just now I bit the bullet and tcpdump'd port
> 80 on each of the firewall's interfaces (it has several), and then
> tried to send my tests back through again. AFAICT, Squid never sent
> out a request attempt on any interface on port 80 before returning
> with a forwarding loop error. All of my instincts at the moment are
> telling me that the request is making it to Squid but it's never
> making it back out again if I'm using the intercept port.

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.

Amos
Received on Sat Jun 01 2013 - 09:52:05 MDT