[squid-users] Transparent Proxy on OSX Yosemite

[Shively, Gregory]

> 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, 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.



> >

> > As mentioned, the -with-nat-devpf fails to compile on OSX due to a

> > missing header file. And from looking it sounds like the header is for

> > the ioctl() on /dev/pf, which doesn't seem to be public API on OSX. So

> > I'm trying to determine if my issue is due to a misconfiguration - or

> > is this portion of the code not working with OSX.



> It has been a long time since anyone using MacOS has provided any particular feedback about Squid behaviour on MacOS. So it could be just bugs when running on MacOS.





> > I looked at the code for mitmproxy, and it seems like they require a

> > sudoers entry to run "pfctl -s state" and parse the state.

> > Would something like that need to be added to squid to support

> > transparent proxy on OSX. I had started to put some code together like

> > mitmproxy, but thought better check if I didn't get something

> > configured correctly.



> Squid (when built with the /dev/pf support) master process which is run as root [you are running Squid from the root account right?] should be preserving its permission to access the device before it drops down to low privilege levels for handling the network traffic.



Yeah - I'm running the squid process as root; that is partially what headed me down the road with the /dev/pf - the permissions had changed after a reboot of the Mac and I started getting curious on why squid didn't give me a permission warning in the same way that mitmproxy was. And from the code, at least in the portion of the code I was looking, since I didn't have the -use-devpf it doesn't seem to open the dev file.



> Some other troubleshooting things to try:



> * using the machines public IP addres instead of 127.0.0.1. There are hardware or driver level restrictions on locahost addresses that often prohibit that type of NAT.



> * using a divert-to rule instead of rdr. If your PF firewall accepts that and the 'tproxy' option in squid.conf works then the /dev/pf is not relevant. rdr sometimes does not work when divert-to is fine.



> * 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.



> Amos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160831/e8a6c07a/attachment.html>