Hey Michael, I am missing couple details about the setup which might affect the way we would be able to understand what is causing the issue and how to resolve it. There are changes from squid 2.7 to 3.5 and to my opinion these are mandatory to resolve and to not go one step back. What version of SquidGuard 1.4 did you installed? The patched for squid 3.4+ compatibility? More details about it here: http://bugs.squid-cache.org/show_bug.cgi?id=3978 Now if it is indeed patched and works as expected it from the 3.4+ computability level of things then lets move on. Are you using Squid in intercept\transparent\trpoxy mode or is it defined in the browsers directly? If you are using intercept mode, what have you defined on the FreeBSD pf\ipfw? And about the quote from the mailing list: SquidGuard was written to operate under the url_rewrite interface\protocol and not external_acl. Due to this it has some disadvantages and the advised details are to modify the helper(SquidGuard or another) to operate in another way. It is possible to use the patched version of SquidGuard under the external_acl interface and use squid options to deny\redirect the request. It removes some things from the complexity of the issue. I have just written an example on how to use use my software SquidBlocker under external_acl and here the adapted example that can be used with a patched SquidGuard: ## START OF SETTINGS external_acl_type filter_url ipv4 concurrency=0 ttl=3 %URI %SRC/- %LOGIN %METHOD /usr/local/bin/squidGuard url_rewrite_children acl filter_url_acl external filter_url deny_info http://ngtech.co.il/block_page/?url=%u&domain=%H filter_url_acl #or # deny_info 302:http://ngtech.co.il/block_page/?url=%u&domain=%H filter_url_acl http_access deny !filter_url_acl http_access allow localnet filter_url_acl ## END OF SETTINGS I have not tested this request format but if it doesn't work this way then a little cosmetics will make it work. When more information will be available we can try to see where the issue is from. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of reqman Sent: Wednesday, June 15, 2016 10:22 AM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: HTTPS issues with squidguard after upgrading from squid 2.7 to 3.5 Hello all, I have been running squid 2.7.X alongside squidguard 1.4 on a FreeBSD 8.x box for years. Started out some 10 years ago, with a much older squid/squidguard/FreeBSD combination. Having to upgrade to FreeBSD 10.3, I examined my option regarding squid. 3.5.19 was available which I assumed would behave the same as 2.7, regarding compatibility. Squidguard 1.4 was also installed. - Squid was configured to behave along the lines of what I had on 2.7. - For squidguard I used the exact same blocklists and configurations. Note that I do not employ an URL rewriting in squidguard, only redirection. - no SSL-bump or other SSL interception takes place - the squidguard-related lines on squid are the following: url_rewrite_program /usr/local/bin/squidGuard url_rewrite_children 8 startup=4 idle=4 concurrency=0 url_rewrite_access allow all - In squidGuard.conf, the typical redirect section is like: default { pass local-ok !block1 !block2 !blockN all redirect 301:http://localsite/block.htm?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u } I am now experiencing problems that I did not have. Specifically, access to certain but *not* all HTTPS sites seems to timeout. Furthermore, I see entries similar to the following in cache.log: 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3446 FD 591 flags=1 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3448 FD 592 flags=1 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3452 FD 594 flags=1 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3456 FD 596 flags=1 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3454 FD 595 flags=1 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3458 FD 597 flags=1 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 remote=192.168.2.239:3462 FD 599 flags=1 Searching around, the closest I have come to an answer is the following: http://www.squid-cache.org/mail-archive/squid-users/201211/0165.html I am not sure though whether I am plagued by the same issue, considering that the thread refers to a squid version dated 4 years ago. And I definitely do not understand what the is meant by the poster's proposal: "If you can't alter the re-writer to perform redirection you can work around that by using: acl foo ... some test to match the re-written URL ... deny_info 302:%s foo adapted_http_access deny foo " Can someone help resolve this? Is the 2.7 series supported at all? As is if everything fails, I'll have to go back to it if there's some support. BR, Michael.- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
