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
