@stephenw10 I'm sorry for answering just now, had some family issues, but I solved the problem by cleaning the cache and restarting the desktop. I have no problem with any browser. Thanks for the thelp and attention!

Connnect to console via ssh and Shell (F8) Then just type: tcpdump -i <interface> -s 65535 -w <some-file> (where interface must by eth1 or vmx1 depending on your ethernet driver).

Ouch... Really sorry! I think I've made a mistake... I don't have Pfsense server anymore but i think that It was not External FQDN but reverse https default site witch cares... And I'm wondering if you don't have to use an host name and not a domains one, something like host.mydomain.com and not only a domain.com... But My certificate wasn't a wildcard. So it could be wrong. To be complete there's some points I have to add here: to get through this issue, I used the console to look at the squids configurations files. it's not so difficult and there can be found the ssl adresses usable to connect I ve never been able to have everything working as it should with PFsense with squid on it. One colleague of mine tried again with a fresh install of Pfsense to be sure theyre's no artefact of what I did. But for me, as I read it so many times, pfsense does not work fine with squid (we forgot Squid and changed to a commercial solution)

Thanks for posting your solution, whatever it is.

Commonly that's caused by Squid and clients resolving URLs to different IPs because they are using different DNS servers. https://docs.netgate.com/pfsense/en/latest/cache-proxy/squid-troubleshooting.html?highlight=squid#sites-not-loading-with-splice-error-409-in-access-log Steve

...turns out ACLs are processed in order, just like firewall rules. My bad! Just have to keep a wildcard ACL matching a redir action just like before but at the very end of the ACL list, no default backend needed. I'm so stupid!--no wonder why I kept noticing the little blue anchors next to each entry. ...is it anchor or anvil? 🤨 IDK anymore.

@periko I will answer my own post. Looks like I found the issuem, once we enable and setup bind, for some reason the file /etc/resolv.conf lost the line: nameserver 127.0.0.1 Them squid read this file and for some reason the queries fall. Now, I have 2 paths: Add manually the localhost in the resolv.conf file in the first line. Or add as alternative dns in squid localhost 127.0.0.1 Using any of this 2 options everything start working. Them bind have some daemon, because I select LAN+Localhost for listen. Hope some could check this which affect proxy transparent MITM. Thanks.

Hmm, not sure I've seen that specific use case but I would set it up and try the different algorithms to see what works best for you. Steve

@Bismarck ,thanks for the help. I saw the ssl_bumps just underneath "custom options before auth" but there's a 2 line space between this section and the config so not sure if it's part of it. Custom options before auth acl sglog url_regex -i sgr=ACCESSDENIED http_access deny sglog ssl_bump peek step1 ssl_bump splice all

@PiBa Ok, I increased the time and it works well

hi @KOM unfortunately i did not find any solution.

I think you answered your own question. It doesn't block until you clear their local cache... so maybe it's been working all along and blocking as it should, but the blocked content is being pulled from local cache and/or squid? I don't know how squid behaves if you ask for content that is technically blocked for that user, but is sitting in squid's cache. Squidguard is a helper program that gets called for each URL that squid needs to fetch. If the required content is still is cache and not stale, it will server from there first.

NFM! thanks.

Bump anyone???