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

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.

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?

Thanks,

- R.

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