> 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
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
