On 1/06/2013 7:12 p.m., Rob Sheldon wrote:
On 2013-05-31 23:13, Rob Sheldon wrote:
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.
OK. I just set up a fairly careful test environment. The short result
is that, with everything configured close to textbook (and as close as
possible to Loic's suggestions), non-intercept requests work fine from
a test machine but all intercept requests go to Squid and then
disappear completely with Squid complaining about a forwarding loop.
To be clear: the requests aren't getting redirected back to Squid at
all; they're never making it out of Squid.
A quick network layout: there's a firewall with three external
interfaces using ECMP routing and three internal interfaces (a LAN, a
Wifi, and a "server" interface (or DMZ if you prefer)).
1. I re-enabled the rdr rule on the firewall. I set up Squid with
"http_port 3128" for its forwarding port followed by "http_port
192.168.0.1:3129 intercept" for its intercept port. 192.16.0.1 is
LAN-facing, so I won't run into an in-out-in routing problem on the
interface when testing from the server interface, which is on
192.168.10.0/24. Before starting Squid, I ran "nc -l 3129" on the
firewall, and sent a www request from the test machine. The request
appeared in nc correctly, so rdr is working fine. (Just for giggles, I
also modified the rdr to reroute inbound 80 traffic from the test
machine to 3128 -- the non-intercept port -- and then made a
non-intercept request (absolute URL) from the test machine, and this
also worked fine. So this is not a broken rdr or pf rule at work here.)
2. I started Squid in "debug mode": "squid -d 1 -N". I sent a
non-intercept request from the test machine ("telnet 192.168.0.1
3128", followed by "GET http://www.associatedtechs.com/1.html";). This
worked as expected. So Squid is at least partially working, it can
talk to the outside world.
-d1 is not debug mode, it is equivalent to "debug_options ALL,1". Which
is a slightly more verbose normal operational output to cache.log. -d
with values 2 to 9 or -X are the debug output options, but provide far
more information than you are needing for these tests.
For these tests I expect the relevant info will be logged by
"debug_options 11,2 ALL,1".
3. I began systematically testing intercept requests against each
interface on the firewall. The firewall has rl0, rl1, rl2, re0, fxp0,
dc0, and lo0. For each interface, I started "tcpdump -s 2048 -X -i
[if] port 80". (And just to verify this should work, I also re-ran the
test in step 1 while running tcpdump on external interfaces; the
traffic appeared in tcpdump as expected.) For each request, I changed
the request URL, just to make sure Squid wasn't trying to return
something from its cache.
Each and every interface tested in #3 showed zero outbound traffic on
port 80 from Squid, and each and every test gave me a forwarding loop
error. The only exception was rl0 -- the server interface that the
test machine is wired to, which showed the traffic originating from
the test machine and the reply from Squid.
I really don't think this is a pf problem. If it was, it should have
shown up in the non-intercept test (or in any of my other tests over
the last couple of days).
There is only one thing about this firewall setup that's a little
quirky, and I wonder if Squid's intercept flag hates it for some
reason: the firewall has pooled its three external interfaces using
ECMP in the kernel. Is it possible that this is confusing Squid's
intercept mode somehow? Because otherwise, this really ought to be
working, near as I can tell.
I'm getting close to building a slap-bang machine just to run Squid.
I'd really rather not do that. Does anybody have any other ideas on
what might be broken?
debug_options 11,2 will show you where Squid is sending the traffic to
servers (if any).
Amos
