RE: [squid-users] Transparent Squid on FreeBSD with PF

---------------------------------------- > Date: Thu, 16 Jan 2014 23:39:43 +1300 > From: squid3@treenet.co.nz > To: squid-users@squid-cache.org > Subject: Re: [squid-users] Transparent Squid on FreeBSD with PF > > > Either auto-configuration (WPAD/PAC) or traffic interception / MITM: > >> No client side configuration. > > It sounds like you chose MITM over auto-configuration. > > >> This is how the network >> looks: >> >> Code: Select all >> client --- --- router/firewall --- internet >>           | >>      squid proxy >> > > Your diagram illustrates the client intercepting themselves. When > actually it is the firewall doing the interception then the router > handling the packet to/from the proxy. > > See the nice picture at > http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat. > I believe I didn't explained this clearly. The "image" might have been messed up in the mail client which made it less clear. The proxy is actually in a star topology with the client and the router/firewall. The | and "squid proxy" should be more to the right. The proxy, router/firewall and client are on the same physical network(Layer 2). The client has it's gateway to the squid proxy(gateway configured through DHCP; autoconfig with DHCP didn't work as most browsers don't support it). The squid proxy is the machine with the rdr rules. The squid proxy has the router/firewall as gateway. So the router/firewall doesn't intercept the connections first. > >> The >> router routes packets for the client to the Squid proxy. The client has >> the Squid proxy as the gateway. I have FreeBSD 9.2 on the proxy. Squid >> 3.4 compiled from source with the --with-nat-devpf and >> --enable-pf-transparent options. Firewall is PF. >> > Okay. > >> Somewhere in the >> process I got confused with the different ways to configure Squid and >> PF. > > No worries you have got lots of company there. ;) > >> I need intercept or TPROXY as http_port(s) option. > > Yes, the "or" is important there. > >> From what I >> understand intercept will see packets that are for a webserver on the >> internet through port 80. > > That describes port-80 pretty well. Both "intercept" and "tproxy" > options handle that type of traffic. > >> The Squid proxy server will then set up its >> own connection to the webserver with its own IP. > > That describes only the "intercept" option behaviour. Ok. What about the TPROXY behavior. It spoofs the IP of the client. Does that mean that the client just has a connection with the proxy(while it thinks it's connected to the webserver) and the proxy a connection to the website (while the website think it's the client)? And that this creates some sort of "tunnel" between client and website? > >> Therefor > > No "therefore". You have now changed topic from packet interception to > TLS/SSL interception. Different beasties. > >> this won't work with HTTPS as it can't see the packet contents unless >> you use SslBump. SslBump creates a secure connection with the proxy >> server, which in his turn creates an SSL connection to the webserver. > > >> So >> this is a man-in-the-middle. > > NAT Interception is a MITM, so is TPROXY Interception and so is Ssl-bump > interception. All three different interception/MITM mechanisms. > Ok. What I was actually wondering is if I need SSLbump in all cases for HTTPS(if I want to filter on domainname in an acl and what if I leave this domain name filter out). >> Because of this reason and you need to >> install a root certificate in the client browser I would like to have another method. > > That is only relevant to port 443 and ssl-bump mechanism. Well I don't want only access to half of the internet ;) So it's still relevant in my case. > >> >> From >> what I understand TPROXY can accomplish this(however not sure how squid >> will check then which domain name is accessed). > > Domain details are in the HTTP message. Which is processed the same to > locate it regardless of mechanism. > > >> If I understand it >> correctly TPROXY acts as the client (sending IP packets to the webserver >> with the client's IP). > > Nope. Squid acts as a client. Always. > > TPROXY *spoofs* the client IP for outgoing TCP connections. Ok. Clear. So if I get this right TPROXY won't give me(in my setup) any advantage over intercept(the router/firewall to the internet does masquerading; otherwise TPROXY would give the advantage that IP based authentication would work). > >> It's not clear if the client will still have an >> SSL connection to the proxy server or not (I would think it still has, >> as otherwise the client should be aware that it has to sent requests >> with https:// just in cleartext to the proxy, which is not secure, and >> this doesn't seem very "transparent" anymore). > > >> Does TPROXY still need >> SslBump configured? > > TPROXY and ssl-bump are not related other than both being ways to > intercept traffic. But sslbump is necessary for making HTTPS work anyway(as you say Squid always acts as the client so squid actually sends the request to the webserver), right? > >> As there is no man-in-the-middle here I would think >> domain names in requests can't be seen and squid can't react accordlingy >> to it. > > MITM is the category of operation being performed. It covers all > operations where the client and/or server is being deceived as to the > proxies existence. > >> If the latter is the case, what are the pros for using TPROXY? In the > end the packets still have to go through your Squid server where they > can be intercepted. >> > > TPROXY avoids the need for NAT packet mangling and all the security > problems which come with it. At the beginning TPROXY was also the only > way to cleanly do interception for IPv6 traffic, that has now changed. > Not sure what you mean by "NAT packet mangling". And with security problems you mean eavesdropping in the packet? Is there any article or reference you have where these problems are explained and how TPROXY fixes this? > >> Anyway >> I configured PF. I read that I need ipdivert.ko which is available in >> my kernel and need divert-to rules for using TPROXY. >> >> I got squid running with Intercept using the rdr rules: >> >> rdr pass on $lan_if inet proto tcp from 192.168.1.32 to any port 443 -> 127.0.0.1 port 3129 >> rdr pass on $lan_if inet proto tcp from 192.168.1.32 to any port 80 -> 127.0.0.1 port 3128 >> >> However for TPROXY I should use divert-to right? >> >> pass in quick log on em0 proto tcp from 192.168.1.32 to any port 80 divert-to localhost port 3128 >> pass in quick log on em0 proto tcp from 192.168.1.32 to any port 443 divert-to localhost port 3129 >> The Squid site actually has an article about squid with PF and TPROXY(however specific for OpenBSD). When using the rules provided there I get an error that divert-reply isn't valid on freebsd. I'm not sure if letting this divert-reply rule out (which removes the warning of course) doesn't need another rule to replace that functionality. >> From what I understand divert-to doesn't actually change anything to the packets. It just delivers the packet on another port.The >> rdr rules rewrite the destination IP, > > Yes to both of those. > I tried using TPROXY with divert-to however couldn't get it to work on my freebsd. Not sure what I was doing wrong. >> so > > No "so". these two parts of the sentence are unrelated facts. > >> the HTTP/HTTPS request has to >> be read anyway to open a connection to the destination webserver. > > True, but is applicable to any TCP connection received by Squid. > >> >> Might >> it be crucial to have 2 interfaces to make TPROXY(or intercept) work >> alltogether > > The two mechanisms do not play nicely together. I'm not sure what the PF > implementation of divert-to does exactly, but on Linux at least the > TPROXY mechanism takes SYN packets out of the network stack prior to NAT > being applied to them so the SYN and following packets have different > IPs and things break. > > If you are able to configure divert-to so that it works I recommend that > with TPROXY. Ok. I'll look further into getting this to work. > >> Please >> correct me if I'm wrong at any point. It would greatly increase my >> understanding of the matter and probably help in solving issues. What >> way should I go here to get the explained goal? >> > > Get it going with just port-80 for starters. Once that is done add > identical PF and routing rules for port-443 before you start with > ssl-bump pieces in squid.conf for the SSL/TLS protocol layer. Ok. I got it working with intercept for both HTTP and HTTPS and the rdr rules in Freebsd PF. I'll try to do the same for HTTP with TPROXY first. From all what I've read here, it seems that anyway I configure squid, something has to be done on the client. Either - auto-configuring (which should still be picked up by the client) - configuring the browser to use a proxy - configuring the browser to add a root certificate Thanks a lot for your elaborate and quick answer!
Received on Thu Jan 16 2014 - 13:38:50 MST