Hey Walter, Now to me the picture is much clear technically. As Amos suggested fix the first proxy(and I am adding choose how to approach) and then move on to the next ones. There are couple subjects in your one single question which are conflicting your desire(or at least how they are written). If you want to Intercept ssl traffic of clients at the network 172.16.0.0/24(or what ever you have there..) specific clients such as that cannot use a proxy, you will need to either bump them(and splice if no bump required) on the router level of the network or route their traffic towards the right next-hop. Since you are already blocking clients with iptables you should get familiar if not yet, with connection marking or Policy Based Routing. What router are you using a CentOS also? If so it would be pretty simple to configure a routing policy which will be based on the source IP address of the connections. Choose if you want to bump on the first proxy ie the 3.1.23 by upgrading to 3.5.X or route the traffic over a tunnel instead of just blocking the traffic. Depend on your router OS you will have different instructions on how to route the "blocked" clients into a proxy that will intercept the connections which needs to be inspected. Where are you stuck in the implementation? Can't you upgrade the 3.1.23(First proxy)? What is blocking you from routing the traffic toward to the second parent proxy from the first one or from the router? Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: Walter H. [mailto:walter.h@xxxxxxxxxxxxxxxxx] Sent: Monday, November 28, 2016 15:02 To: Eliezer Croitoru <eliezer@xxxxxxxxxxxx> Cc: 'Walter H.' <walter.h@xxxxxxxxxxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: Hint for howto wanted ... Hello, I think we aren't understanding each other ... let me show what my system is now: a few clients - not all¹ - have configured a proxy, let's say with IP 172.16.0.10 this proxy is a CentOS 6.8 with squid 3.1.23 this proxy only decides which parent to use ... ¹ some clients must be able to use internet without a proxy, my computer e.g. is blocked at the router to use internet and therefore must use the proxy; one parent is a CentOS 6.8 with squid 3.5.20, which does ACL filtering, SSL-bump, malware checking with ClamAV, let's say with IP 172.16.0.20 the other parent at a webhoster in another country is also a CentOS 6.8 with squid 3.4.14, which should only be used for geoblocked content, nothing more ..., let's say with IP 60.60.60.60 the television has let's say 172.16.10.10 my public IP address at home is let's say 80.80.80.80 the iptables of remote-proxy has besides other web, mail, ... specific things just this: -A INPUT -s 80.80.80.80 -m tcp -p tcp --dport 3128 -m state --state NEW -j ACCEPT -A INPUT -m tcp -p tcp --dport 3128 -j DROP just to prevent others using my proxy; the first proxy has this in it's squid.conf acl kaspersky-labs-net dst 62.128.100.0/23 81.19.104.0/24 195.122.177.128/25 always_direct allow kaspersky-labs-net # specific for the television acl apa-net dst 185.85.28.0/24 185.85.29.0/24 194.232.0.0/16 always_direct allow apa-net acl tv-device src 172.16.10.10 cache_peer 172.16.0.20 parent 3128 0 name=local-proxy proxy-only no-digest default cache_peer 60.60.60.60 parent 3128 0 name=remote-proxy proxy-only no-digest acl remote-domains dstdomain "/etc/squid/remote-domains-acl.squid" cache_peer_access local-proxy deny remote-domains cache_peer_access local-proxy deny tv-device cache_peer_access remote-proxy allow remote-domains cache_peer_access remote-proxy allow tv-device cache_peer_access remote-proxy deny all cache_peer_access local-proxy allow all as you see this is a little bit complex: - the remote proxy is only used by the television, because there is the prevention of geoblocking critical, and for a few domains;² - some networks are accessed directly without filtering, this is because some clients are blocked to connect to internet directly, but can use a proxy, or there is a problem with self-signed certificates; and filling up the logs a 2nd time with 'CONNECT' doesn't really make a sense ... - some clients must connect to the internet without a proxy, either because they cannot configured to use a proxy or they don't want to use a proxy; this reduces the origin question: how can I use a parent proxy, when doing SSL-bump without changing any iptables? (in order not to have to configure SSL-bump a 2nd time on the remote proxy) Thanks, Walter On Mon, November 28, 2016 11:18, Eliezer Croitoru wrote: > Hey Walter, > > I am not sure you understand the direction of things or what I am > aiming for. > First if the client has CentOS 6.8 There are RPM's for newer versions > which I am building manually for the public use. > Second: You can simplify the picture from Intercepting traffic using > the local squid into "route" the traffic in the IP level towards the > remote proxy. > You can open a gre tunnel or to use some kind of simple VPN service to > tunnel between the client box to the 3.5.20 box. > If you will route the clients traffic towards the proxy in the IP > level you would be free from handling the 3.1.X proxy. > > You should prioritize your goals between: > - Caching > - ACL > - Others > > Once you will open your mind from resolving and issue and convert it > into a second form which is functionality I think I would be able to > assist you. > > What is missing from the 3.1.X proxy? > Is the SSL BUMP missing? > What iptables rules are you using on the client machine(3.1.X)? > > All the above matters to understand how to offer the right solution. > > Eliezer > > ---- > Eliezer Croitoru > Linux System Administrator > Mobile: +972-5-28704261 > Email: eliezer@xxxxxxxxxxxx > > > -----Original Message----- > From: Walter H. [mailto:walter.h@xxxxxxxxxxxxxxxxx] > Sent: Monday, November 28, 2016 10:59 > To: Eliezer Croitoru <eliezer@xxxxxxxxxxxx> > Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: Hint for howto wanted ... > > On Mon, November 28, 2016 06:56, Eliezer Croitoru wrote: >> OK so the next step is: > >> Routing over tunnel to the other proxy and on it(which has ssl-bump) >> intercept. > by now only the 3.5.20 squid on the local VM does SSL-bump > >> If you have a public on the remote proxies which can use ssl-bump >> then route the traffic to there using Policy Based routing. > how do I configure this? > >> You can selectively route by source or destination IP addresses. > by now the remote has in its iptables to only accept port 3128 from my > home IP (IPv6 and IPv4), but the IPv4 at home changes several times a > year; means it is not fix; > >> >> Now my main question is: Can't you just install 3.5 on the 3.1.23 >> machine and bump there? > SSL bump and parent proxy together doesn't work, if this worked I > wouldn't need the 3.1.23 machine at all ... > the 3.1.23 machine has the other 2 proxies (3.4.14-remote and > 3.5.20-local) as parent ... > > I should mention that the 3.5.20 box also has ClamAV (SquidClam) which > does malware checking ... > (the remote proxy can't run ClamAV) > >> How are you intercepting the connections? What are the iptables rules >> you are using? > > the client have configured the 3.1.23 squid box as proxy > >> What OS are you running on top of the Squid boxes? > > all squid boxes run CentOS 6.8 > > Thanks, > Walter > > > > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
