Redmine#13984

This fixed a lot for me with Squid and Squidguard

@DBMandrake OpenSense products have full updated support for Squid. I am going to ride out 23.05.01 until it dies and find a product that supports Squid and or use a raspberry pi 5 for Squid and update my firewall one or the other.

Do you know if the OpnSense build of Squid is patched to fix the issue I reported in https://redmine.pfsense.org/issues/14390 ?

I saw discussion in the OpnSense forum from a couple of years ago about a patch for this but later posts from people saying the patch didn't actually solve the issue and then no follow up.

By the way, this issue can be tested using my Python script ("Transparent Proxy test.py") attached to the redmine ticket.

FYI...side note
Snort 3.1.75.0 is available to download now.
It's got QUIC support too.

I don't see Squid leaving my device anytime soon.

https://redmine.pfsense.org/issues/14390

Now that the announcement has been made that Squid and SquidGuard in PFSense is depreciated and will be removed entirely in the next major release, it is obvious why no effort has been made to address this issue.

What a shame - we rely on Squid and Squidguard for SNI based domain blacklisting so the removal of Squid will force us to switch to another firewall product.

I was going to try to build the Squid package myself and apply the necessary patch to the source to fix this issue, but with the impending removal of the package I see no point in going to this effort.

Well, it was nice while it lasted.

https://redmine.pfsense.org/issues/14390

I can only assume by the lack of action taken that this will not get looked at unfortunately by any dev.
So in order to alleviate this problem by users such as the OP I submitted a redmine to have the documentation updated to reflect this /409 problem - https://redmine.pfsense.org/issues/14842

This documentation ticket also hasn't been looked at as well and so we are on this cycle of people reporting an issue with Squid, the problem being known and we have a fix but no one from Netgate touches this and so goes the cycle.

What also impacts the resolution to this is that there doesn't seem to be an assigned maintainer for Squid on pfSense, so there is no one to escalate to other than Netgate.

As ive been telling people, its best to assume that the Squid package is no longer maintained but is kept around for legacy reasons. If there is a serious CVE i have no doubt a patch will be pulled from upstream but at this time dont expect any of the known issues with Squid to be resolved.

If you can do it, explicitly assigning a proxy setting is a much better solution - although not as good as this over 10 year old bug in Squid being fixed of course. To be fair to the PFSense guys this bug exists in mainline squid since around 2012 so any fix would require a custom patch on Netgate's part and careful consideration of how to approach the problem.

Here is a 7 year old thread on the squid mailing list discussing the issue: (there are many more as well)

https://squid-users.squid-cache.narkive.com/zdrtxq6b/host-verify-strict-and-wildcard-sni

While it's referring to wildcard SNI's (and whether they're valid or not) the underlying problem is the same - host_verify_strict off does not work as documented.

Set in custom

add teams domain

Also do not cache them.

I have zero issues with this.

The workaround we use is to ensure that all clients which use Teams/Office 365 have PFSense configured explicitly as their HTTP/HTTPS proxy server, then it works perfectly.

On Windows PC's we do this using group policy, for iPads and some other non-Windows devices we have set up WPAD proxy auto-configuration using an internal HTTP server, however on recent versions of iOS you still have to manually change "Proxy configuration" to "Automatic" in WiFi settings the first time you connect to WiFi. (Although this is better than trying to get users to enter proxy settings by hand!)

https://redmine.pfsense.org/issues/14390

Ive submitted a Redmine to have the documentation updated.
https://redmine.pfsense.org/issues/14842

The problem is just that the proxy is resolving a different IP to what your client is resolving to therefore breaking the connection.

The solution to this is to use the Bypass function in the Transparent Proxy section.
Create an Alias using the IPs found here for the application you need:
https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

Apply that Alias in Squid. You will need a firewall rule as well as those IPs will no longer go through the proxy. I have this set up and it works.