Smoothwall not filtering gamepluto.com

[5tu]

Just had a remote session with Smoothwall support and demonstrated the issue - web filter logs show sites are blocked when they aren't. Smoothwall not sure why at this point and further investigation required. Will update this post when I hear back.

[5tu]

Just had a remote session with Smoothwall support and demonstrated the issue - web filter logs show sites are blocked when they aren't. Smoothwall not sure why at this point and further investigation required. Will update this post when I hear back.

 

So... just had an hour long session with 2nd line support and we've found that Google Search isn't being https inspected, despite there being no policies in place exempting Google from inspection. Other search engines are being inspected correctly.

 

Escalated to 3rd line....

 

Edit: I don't understand why users are able to access sites which should be blocked via Google Search results. Maybe that's another issue. Glad to have (finally) made it through to 3rd line.

Edited February 21, 2024 by gybe78

[sigma]

I presume you and Smoothwall have checked that you have QUIC protocol disabled?

 

https://kb.smoothwall.com/hc/en-us/articles/360002136884-Setting-up-QUIC-to-Ensure-That-Web-Traffic-Is-Filtered

[5tu]

I presume you and Smoothwall have checked that you have QUIC protocol disabled?

 

https://kb.smoothwall.com/hc/en-us/articles/360002136884-Setting-up-QUIC-to-Ensure-That-Web-Traffic-Is-Filtered

 

Yep - first thing we checked

[ibpalle]

So... just had an hour long session with 2nd line support and we've found that Google Search isn't being https inspected, despite there being no policies in place exempting Google from inspection. Other search engines are being inspected correctly.

 

Escalated to 3rd line....

 

Edit: I don't understand why users are able to access sites which should be blocked via Google Search results. Maybe that's another issue. Glad to have (finally) made it through to 3rd line.

 

Interesting. Is there a difference between:

 

If a search is being done after opening Chrome, going to Google.co.uk and searching

 

and

 

If a search is being performed right after opening chrome, no opening of google.co.uk and then use the address field for the search?

 

In the 2nd case, the browser may default to google.com instead of google.co.uk, which may be excluded.

 

Just a thought as I've seen something similar.

[Shadow_Walker]

Are you using something like Senso or Impero as well, have had similar in the past where they were causing some conflicts with sites so worth checking if you have them and if you can test with a machine with them on and one without.

[5tu]

Interesting. Is there a difference between:

 

If a search is being done after opening Chrome, going to Google.co.uk and searching

 

and

 

If a search is being performed right after opening chrome, no opening of google.co.uk and then use the address field for the search?

 

In the 2nd case, the browser may default to google.com instead of google.co.uk, which may be excluded.

 

Just a thought as I've seen something similar.

 

Thanks for the post - Doesn't seem to make a difference.

 

Visiting google.co.uk and/or google.com and checking the site's cert shows that the mitm certificate isn't being applied.

[5tu]

Are you using something like Senso or Impero as well, have had similar in the past where they were causing some conflicts with sites so worth checking if you have them and if you can test with a machine with them on and one without.

 

We do have Impero but have removed it from a test machine and the issue remains unfortunately.

[BOOT]

Have you tried disabling QUIC Protocol via the web browser policy?

[5tu]

Have you tried disabling QUIC Protocol via the web browser policy?

 

Thanks for the suggestion. I've just manually disabled QUIC in Chrome on my own PC and now I do see the Smoothwall mitm certificate being applied on google searches.

 

My understanding was that dropping UTP 80 & 443 at the firewall and/or applying the "Remove QUIC Header" content modification rule was all that was needed to avoid this problem? That is also the understanding of Smoothwall support (so far...)

 

@tom_newton - thoughts?

Edited February 22, 2024 by gybe78

[5tu]

Plot thickens.....

 

I recreated my firewall rule which drops QUIC exactly as it was before (same settings and same rule position, 1) and now I can see it taking the appropriate action in the realtime firewall logs. I even took before and after screenshots of my firewall rule to double check everything.

 

More testing needed but we're maybe making progress (and I'm thinking I need a better firewall).

[ibpalle]

Thanks for the suggestion. I've just manually disabled QUIC in Chrome on my own PC and now I do see the Smoothwall mitm certificate being applied on google searches.

 

My understanding was that dropping UTP 80 & 443 at the firewall and/or applying the "Remove QUIC Header" content modification rule was all that was needed to avoid this problem? That is also the understanding of Smoothwall support (so far...)

 

@tom_newton - thoughts?

 

UDP 80 and 443 Yeah, that should be enough. Try to enable forwarded traffic auditing option in network - settings - advanced. Then go to the reports - realtime - firewall and enter a filter of destination ports 80 and 443 and your source IP. Enable QUIC again, restart browser and try to browser while checking the traffic in the firewall logs. It should show the QUIC traffic - you may be able to see if there are issues with the firewall policies.

[CSmith]

Out of interest @gybe78 - has that change made any difference to your ability to access the various gaming websites you've mentioned?

 

There are two ways to prevent HTTP/3 (QUIC), but ideally both should be employed as they both serve slightly different purposes.

 

The first - our 'Remove QUIC Header' content modification - is designed to prevent a server from ever being able to tell the browser that it supports HTTP/3. We do this by altering the contents of the 'Alt-Svc' header returned by the server. The client never realises that the server supports HTTP/3, and thus never tries to establish a connection using that protocol. The downside of this method is that any domain which is not inspected, or added to a 'do not filter' policy won't have this content modification applied to it. In this scenario it's possible that the browser might receive the un-altered 'Alt-Svc' header and start making use of HTTP/3 for future requests. Even if that domain is removed from the 'do not filter' or 'do not inspect' policy in the future, the browser may continue to use HTTP/3 until the cache is cleared within the browser.

 

 

The second method is simply to block UDP port 80 and 443. This should in theory prevent all HTTP/3 requests, however - much like with standard HTTP/s - there is no requirement for an HTTP/3 connection to be established over port 443. The 'Alt-Svc' header described above could contain an alternative port number in which case the firewall policy alone wouldn't prevent the HTTP/3 connection from being established.

[5tu]

Out of interest @gybe78 - has that change made any difference to your ability to access the various gaming websites you've mentioned?

 

There are two ways to prevent HTTP/3 (QUIC), but ideally both should be employed as they both serve slightly different purposes.

 

The first - our 'Remove QUIC Header' content modification - is designed to prevent a server from ever being able to tell the browser that it supports HTTP/3. We do this by altering the contents of the 'Alt-Svc' header returned by the server. The client never realises that the server supports HTTP/3, and thus never tries to establish a connection using that protocol. The downside of this method is that any domain which is not inspected, or added to a 'do not filter' policy won't have this content modification applied to it. In this scenario it's possible that the browser might receive the un-altered 'Alt-Svc' header and start making use of HTTP/3 for future requests. Even if that domain is removed from the 'do not filter' or 'do not inspect' policy in the future, the browser may continue to use HTTP/3 until the cache is cleared within the browser.

 

 

The second method is simply to block UDP port 80 and 443. This should in theory prevent all HTTP/3 requests, however - much like with standard HTTP/s - there is no requirement for an HTTP/3 connection to be established over port 443. The 'Alt-Svc' header described above could contain an alternative port number in which case the firewall policy alone wouldn't prevent the HTTP/3 connection from being established.

 

@CSmith - I was advised by 2nd line support not to deploy both the "Remove QUIC Header" modification rule and the firewall rule dropping UDP 80/443 traffic. In a remote session the support engineer disabled the content modification rule. Should this be re-enabled?

 

Following recreation of the firewall rule, I am evaluating student access to the gaming websites identified. Due to pressure from school leadership I had to employ other solutions to block access to known sites, so now need to remove these in order to observe the behaviour with just Smoothwall filtering in place.

[drewp]

Might also be good to disable QUIC using GPO/MDM to cover all possibilities?

 

Computer Configuration\Administrative Templates\Google Chrome\Allow QUIC protocol = Disabled

Computer Configuration\Administrative Templates\Edge\Allow QUIC protocol = Disabled

[CSmith]

@CSmith - I was advised by 2nd line support not to deploy both the "Remove QUIC Header" modification rule and the firewall rule dropping UDP 80/443 traffic. In a remote session the support engineer disabled the content modification rule. Should this be re-enabled?

 

Following recreation of the firewall rule, I am evaluating student access to the gaming websites identified. Due to pressure from school leadership I had to employ other solutions to block access to known sites, so now need to remove these in order to observe the behaviour with just Smoothwall filtering in place.

 

I would advise having both in place, I'll speak to our support team and try to understand the reasoning behind disabling the content modification policy.

[SilverVanMan63]

We have a similar problem.

Poki.com, Crazy-Games and others are not being blocked.

Even a student who is limited to O365, Seneca and a couple of others can open these sites.

I have an online discussion booked with Smoothwall next week.

[tom_newton]

Be sure you have UDP/443 blocked - often this is other protocols like QUIC bypassing the filter