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

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
Received on Sat Jun 01 2013 - 11:49:30 MDT