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?
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.
I'll re-run the tests using another machine on the network for the
request origin, with the rdr rule on, using a request that should be
obvious in tcpdump and shouldn't be in the Squid cache.
- R.
--
[__ Robert Sheldon
[__ No Problem
[__ Information technology support and services
[__ (530) 575-0278
