[squid-users] Transparent Proxy on OSX Yosemite

[Shively, Gregory]

> -----Original Message-----
> From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf
> Of Amos Jeffries
> Sent: Thursday, September 1, 2016 11:05 AM
> To: squid-users at lists.squid-cache.org
> Subject: [EXTERNAL] Re: [squid-users] 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users