Have you selected the 'default backend' in the frontend? Or use a 'use backend' action.?

@jimp: As you can see from the log entry, the problem appears to be from safesearch, not the category itself. That would be something to bring up to squid directly, though that may be a squidGuard issue as well (and it has been essentially abandoned). Yes, thanks for confirming that about squidguard. I'm considering switching to suricata, anyway. You can disable logging in squid, which could help, but if you are worried about users seeing the passwords, why do those users have access to the squid log at all, or pfSense? If I get hit by a truck, a couple of other sysadmins are authorized to access pfSense. And while we configure logging to minimize noise, we /never/ turn it off. We actually use our logs.

Excelente, sirvio para 2.4.2 Excellent, it works on 2.4.2

proposed workaround (works for me): (create a dir /usr/local/extra/certs/, put cert files there) (I put any addition into /usr/local/extra) certinstall script (which should be run e.g. on startup or manually: This can easily be integrated into the squid package (and the certs could be entered via the web interface) #!/usr/local/bin/php-cgi -f         $CERTBASE = "/usr/local/extra/certs/";         $CERTSTORE = "/usr/local/share/certs/";         $cafiles = glob($CERTBASE."*.{pem,crt}", GLOB_BRACE);         foreach ($cafiles as $cafile)         {                 $cas = file($cafile);                 $cert = 0;                 foreach ($cas as $ca) {                                 if (preg_match("/–BEGIN CERTIFICATE--/", $ca)) {                                                 $cert = 1;                                 }                                 if ($cert == 1) {                                                 $crt .= $ca;                                 }                                 if (preg_match("/-END CERTIFICATE-/", $ca)) {                                                 file_put_contents("/tmp/cert.pem", $crt, LOCK_EX);                                                 $cert_hash = array();                                                 exec("/usr/bin/openssl x509 -hash -noout -in /tmp/cert.pem", $cert_hash);                                                 if (! file_exists ($CERTSTORE . $cert_hash[0] . ".0"))                                                 {                                                         file_put_contents($CERTSTORE . $cert_hash[0] . ".0", $crt, LOCK_EX);                                                 }                                                 $crt = "";                                                 $cert = 0;                                 }                 }         }         unlink("/tmp/cert.pem"); ?>

Answered my own question, posting solution here to close the loop: Apparently older versions of the Squid Reverse Proxy package had issues with this. With the current version, you just need to enable the HTTP Reverse Proxy so that it writes the correct cache_peer entries in squid.conf. Then you can create your web servers and set their Protocol to HTTP, and Squid will properly proxy them, SSL terminating at your pfSense. Externally you are presented with the site as HTTPS and your configured pfSense SSL certificate, even though the internal server is actually plain old HTTP port 80 (or whatever port) Hope this helps someone!

Hello, i have exactly the same problem. how can be this solved? I wold like to split interface by purpose. Now reverze proxy is catched on all virtual ip and wan ip. Jan

hsts does not hinder you bumping tls traffic, it just forces the client to use tls instead of plain text. you have to have your ca in place on your client devices. I would recommend 1. setting up a ca in pfsense (you don't necessarily have to have the private key on the pfsense box and I recommend againt it, it is you last resort if you private keys of you sub cas are leaked at some point) 2. setting up a sub ca for ssl bumping 3. exporting the ca certificate of the top ca (just the cert) 4. selecting the right ca in the squid config 5. configure bumping as i describe over here https://forum.pfsense.org/index.php?topic=135178.0 6. put on the whitelist what you desire 7. install ca on the client. that should generally be done by your endpoint management solution (active directory gpo, kaspersky endpoint security, you name it). if you want to manually install the ca make sure you put it into the /SYSTEM'S/ Trusted Root Certifaction Authorities else it won't work. 8. here you go (push f12 in your browser to verify your certs are being generated by your bumping ca.

Have you had any luck?  I'm trying to get Squid to work with my VPN, whenever I enable squid guard I loose my VPN connection, it bypasses it for some reason?

Have you had any luck?  I'm trying to get Squid to work with my VPN, whenever I enable squid guard I loose my VPN connection, it bypasses it for some reason?

Hi! I did some more testing now I am not at home. So it seems like everything is working fine :). Now testing with different SSL certificates. Thanks!

Thanks KOM, seems to work after pressing save and apply in general. Cheers!

That's got nothing to do with squid.  Add a host override in your DNS config to resolve that host to whatever address you specify.

BUMP, does anyone use Squid with OPEN VPN?

I'm facing the same problem, however in my case when PfSense server restarts the Squid initialization path returns to "redirect_program /usr/pbi/squidguard-amd64/bin/squidGuard" and I get the same error: "No such file or directory", so I did not find yet any solution.

The Cache/Proxy forum is a better place to ask your squid questions.  The Documentation forum is for issues with pfSense's documentation.

@beauw: Okay - remzej's script saved me so much grief. I run PFsense with about 1200 clients and the squid memory continually increases over the day until it locks up with no reboot.  Even on the newest versions. I adjusted the script to reboot only on memory (65% for me) and it works like a charm. Once I got the cron running, it checks every 15 mins.  At the most, the reboot results in 15 seconds downtime for the network which is palatable. Thanks again remzej for your contribution…. Do You have rule this similar it?