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
