That's never been the correct path with the PBI crap.

https://github.com/pfsense/pfsense-packages/pull/1062

Dear PiBa,

Thank you very much. The OCSP issue was indeed caused by a problem in StartCom's infrastructure, as StartCom's friendly certmaster did confirm. It is gone at present and I hope that it will remain OK in the future.

Thanks for following up with the OpenSSL issue. It would be good to move from npn to alpn before major providers and their browsers (Chrome) will make the switch, probably by the end of 2015, if they stick to their announcements. Nevertheless all of us should practically take it as it is.

Regards,

Michael

Guess its working, when I add Anonymous Only, that works.

Guess I'll mess with it… maybe I'll get something to click

did you remember to reboot?

Frankly, the Squid* stuff is beyond repair. Perhaps, if someone makes a decision what's gonna be the deal with 2.3 packages, people can start reworking those from scratch, without the tons of legacy, buggy and messy code bloat.

Regarding the changes you mentioned, the only stuff touched there were completely broken cronjobs handling and boot checks. Finally, there's been a change regarding the pinger helper permissions that didn't work due to idiotic chmod() implementation in PHP and - mainly - couldn't have broken anything because it never worked in the first place, due to permissions being screwed by the package code from the very beginning. (https://github.com/pfsense/pfsense-packages/pull/1056).

I cannot see how's that causing any other breakage anywhere, except that the whole package is just bunch of badly broken code that only works when the moon phase is right and the butterflies wave their wings carefully enough, plus the generic issues with upgrades mentioned above plus the generic issues with the PBI idiocy well known by anyone who touched the packages code.

I've requested input regarding the cron changes from marcelloc on GitHub. Received absolutely none. Assume he's just dropped the ball due to all that PBI shit. Not surprised and don't blame him.

I have similar problems, this time with fresh install. Strange this is that c-icap binds only to IPv6 socket:

netstat -na | grep 1344
tcp6      0      0 *.1344                .                    LISTEN

Is it the same on every installation? Can I enforce to bind it to ipv4? Same problem here - squid is unable to communicate with icap.

Welp. No success, so I changed the cache directory to /var/hddcache, and suddenly it works.

So there's what you need to do folks.

Make a config.xml backup and then try again by installing from scratch then restore your config.xml.  For me, squid never works after any upgrade until I reboot the box or stop & restart the squid service.

I found a work around. Since fetch does work I wrote a script to fetch the blacklist to /root. I put it in cron before the invoking the SquidGuard blacklist install.  I have the SquidGuard install the blacklist from /root. It is not elegant but it is functional.

I use Squid in nontransparent mode Does it Block cookies ?

1)  Squid generally isn't used to block anything.  It's a caching proxy.  While it can do some simple URL filtering, squidGuard is better suited.
2)  Since these filter on domains/URLs, not web objects in general, it doesn't block cookies.

I am having the same issue with clam AV. As soon as the primary  syncs with the secondary it clears my config on the secondary and no VirusScan happens. Any ideas?
Temporarily I have disabled siync on the secondary but that is not the fix.

In Squidguard,

Proxy filter SquidGuard: Common Access Control List (ACL)
and in Target Rules deny a list that has torrents.

This means your question belongs here https://forum.pfsense.org/index.php?board=60.0

A simple solution that will solve your problem : Remove Squid.
It is (was ?) known that Squid modifies pfSense own script files, so be careful, be ready to re-install a clean pfSense version.

hi.
have you managed to resolve this? i'm seeing the same behaviour.

FYI, some RFCs like 4515 describe string representation in search filters and especially characters that must be escaped.
ampersand is clearly one of these which means it requires backslash as an escape character.

Adding acl's is not used for selecting the certificate thats gets send back to the client which is only influenced by SNI and haproxy itself, it is however used for selecting which backend will actually serve the request. So if your hosting multiple sites, on different webserver behind 1 public ip, the using acl's is required for that. As you probably know the used host header for the acl can only be read after the ssl-handshake already completed.

Ill check if i can add the option "Add ACL for certificate Subject Alternative Names." you mention, it seems indeed the X.tld is only added by default (by some ca's) for the www. subdomain.

Hello. I myself have the same problem wit the block page not displaying properly and it does when i switch the admin interface to use http instead https. Any fix for this yet?

I found a solution, here is what I did :

viconfig, find the line ldap_user in <squidauth>type the letter with the accent. Now I can see the accented character in web configurator". I still cannot save, I think there is some kind of bug with accented characters with the proxy server LDAP authentication form in the web configurator.

By way, to test the ldap connection from the shell /usr/pbi/squid-amd64/libexec/squid/squid_ldap_auth …. I had to create three missing symbolic link :

ln -s /usr/pbi/squid-amd64/local/lib/libmd5.so.1 /usr/lib/libmd5.so.1
ln -s /usr/pbi/squid-amd64/local/lib/liblber-2.4.so.8 /usr/lib/liblber-2.4.so.8
ln -s /usr/pbi/squid-amd64/local/lib/libldap-2.4.so.8 /usr/lib/libldap-2.4.so.8

Chris</squidauth>