> -----Original Message----- > From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf > Of Amos Jeffries > Sent: Thursday, September 1, 2016 11:05 AM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: [EXTERNAL] Re: Transparent Proxy on OSX Yosemite > > On 1/09/2016 5:59 a.m., Shively, Gregory wrote: > >> On 31/08/2016 11:19 a.m., Shively, Gregory wrote: > > > >>> I'm attempting to get a squid working as a transparent proxy on OSX > > > >>> Yosemite. Every attempt ended with a "Forward loop detected". I > > > >>> initially started with the version from homebrew and moved to just > > > >>> compiling myself to see if I could figure out what was going on. > > > >>> Being new to both pf network and squid, it might be something that I > > > >>> have configured wrong. I configured pf similar to: > > > >>> > > > >>> nat on $ext_if proto {udp, tcp} from $int_if:network to any port > >>> domain -> ($ext_if) > > > >>> rdr pass on $int_if proto tcp from $int_if:network to any port > > > >>> {http, https} -> 127.0.0.1 port 3129 > > > >>> > > > >>> And my squid.conf for my testing is basically: > > > >>> > > > >>> http_port 3128 > > > >>> http_port 3129 intercept > > > >>> http_access allow all > > > >>> > > > > > > > >>> I'm not sure if this is more appropriate on this mailing list or the > > > >>> developer mailing list (hoping it is just something I'm doing > >>> wrong). > > > >>> The squid that I'm using doesn't have -with-nat-devpf enabled; it > > > >>> fails to compile with that option. I'm wondering if the > >>> getsockname() > > > >>> as per comment for PFIntercept (of the !_USE_NAT_DEVPF) in > > > >>> src/ip/Intercept.cc, on OSX is not returning the pre-rdr address and > > > >>> causing the forward loop. > > > > > > > >> Your access.log can show that. It shows up as the server the > >> transaction is being sent to being port 3128/3129 on 127.0.0.1 or > >> another IP assigned to the Squid machine. > > > > > > > > It looks like I get 2 associated TCP_MISS entries in the access.log, > > saying what? *exact details* are important for debugging these types of issue. > I apologize - my Mac where I'm testing was on a different network where I wasn't able to send email and couldn't get access to copy and paste. I now have access to the log entries: 1472664782.393 0 127.0.0.1 TCP_MISS/403 4417 GET http://google.com/ - HIER_NONE/- text/html 1472664782.394 6 192.168.100.2 TCP_MISS/403 4487 GET http://google.com/ - ORIGINAL_DST/127.0.0.1 text/html 1472664782.468 0 192.168.100.2 TCP_MEM_HIT/200 13035 GET http://osx-mdslfd56-u:3128/squid-internal-static/icons/SN.png - HIER_NONE/- image/png 1472664784.921 0 192.168.100.2 TAG_NONE/400 4401 NONE error:invalid-request - HIER_NONE/- text/html > > followed by entries that looks like they are associated with the > > access denied error screen. All generate the forwarding loop warning > > when running squid in debug. I also had the pf logging and see the > > rdr getting redirected, plus had started netcat listening on 3129 > > prior to starting squid and saw the HTTP request come in. > > > > The netcat test tells nothing you dont already know. A forwarding loop by > definition is the request arriving into Squid, then going out and coming right back > a second time (thus 2+ access.log entries). > > netcat test only shows the first arrival, which is of course normal. It also does > not perform the NAT lookup and de-mangling Squid does - so wont show if that > is part of the problem or not. > > Thanks for the explanation - from observation, that is what I was guessing on how it was working. But hearing it helps. > >> * check the PF version in your MacOS. If it derives from OpenBSD > >> 4.8 or later then the .dev.pf is not relevant - rdr/divert-to failure > >> is then a bug somewhere AFAIK. > > > > > > > > I tried using both the internal and external interface IP addresses on > > the rdr rule. Both ended in the same forward loop. And it doesn't look > > like, at least Yosemite, has the option to use the divert-to in the > > firewall rules. I can't seem to find the reference, but I think that > > the pf in OSX is based around OpenBSD 4.4 or 4.5, but don't hold me to > > it. I'm guessing that is the reason that the divert-to is not > > available. I can look at an El Capt machine, but don't currently have > > access. > > > > > > > > Thanks for the help on getting this setup. I had put some code in the > > PfInterception method to replace the "local" address that I pulled > > from running the pfctl -s state command and it did change the results. > > But I'm thinking that I might have gotten the host or port in the > > "address" object incorrectly - it didn't seem to work and further > > connections just errored out. When I get a change will take a more > > detailed look and verify I'm getting the addresses in the correct > > form. > > Okay. I'm thinking its not misconfiguration then and since it seems to be a Mac- > specific PF based on the old /vdev/pf logic you are going down the right path. > > If you can get it working I will take the patch. Wrap the Mac-specific new bits in > " #if _SQUID_APPLE_ " and the missing header include line with " #if > !_SQUID_APPLE_ ". > Will do. Thanks again Amos. > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
