ibpalle

There is no transparent in google auth method for Android - in order to log in using your google account, you would need a Google directory connection and a login redirect to the SSL Login page on the Smoothwall so users can manually login using their Google credentials. If you have active directory on site and are syncing usernames and password between that and the Google directory, you can use 802.1x for an SSID and have users login to the Wifia and the Smoothwall by using the Smoothwall as the radius service for authentication and accounting.

For the transparent proxy, what method is set in the behaviour dropdown for the auth policy? You could try 'Block HTTPS with no SNI header' - it may interfere with some other apps on mobiles as well but general browsing works fine.

There should not be any inherent block for HTTP sites in the cloud filter extension - it use the same settings as the on-prem filter. The insecure block is likely a Chrome setting set in your Google admin console - seems to remember it was made default a bit ago but not certain.

Obviously I'd recommend taking a look at Smoothwall. UK based with options for both on-premise and cloud, which can be mixed, and there is a range of monitoring options with the MMS system as well as built in safeguarding reporting. New cloud reporting options with massively improved speeds for reporting is in it's final trial stages now, so should be in general release this year. Comes both as filter solution and as UTM with filtering so may offer some consolidation options.

So obviously the auth exception for the domain or the auth proxy exception policy for the systems static IP has not been implemented yet. Go to web proxy - authentication - exceptions and check what categories have been added to the exceptions field. Add the domain 'squidcard.com' to any of those categories and wait for 15s - then try again. If you would like to exclude the entire system from requiring authentication, then make sure that there is a no authentication policy for the proxy, using a location with the systems static IP in the where field and make sure it is listed before the authentication policy asking for NTLM or Kerberos.

Then obviously none of the suggestions I made earlier has been implemented correctly. What is the IP of the system and can it be set to be static? Where is the app going - what domains is it accessing? Did you add a no authentication policy for a location including the IP of the system - if so, send me a pm with a screen of the location and the auth policy you added. Did you add the system IP to exclusion in Guardian - web filter - exclusions?

Not in the address objects unfortunately

One thing to try while you wait is to go to the reports - realtime - web filter and add the systems IP address to the filtering field. Then fire up the SquidSync app and see if there are any entries in the web filter logs. If there is to much chatter traffic, close other apps running on that system and also try adding the word 'denied' to the category field as that will show only blocked requests. You should be able to see where the app is going if it's still using the proxy. If there is nothing, go to the firewall section in the realtime area and add the system IP address as a filter and try to refresh/open the app again. This should show you if any firewall rules are blocking the traffic. Additionally, a lost of ports and protocols used by the app as well as where it's trying to go, would be a good list to get from the provider.

We have a KB that lists the IP ranges located here: https://kb.smoothwall.com/hc/en-us/articles/360010312859 - Microsoft has one as well, which is likely to be more up to date: https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#skype-for-business-online-and-microsoft-teams

Absolutely possible but not needed - I think we should troubleshoot why any of the 4 options given so far does not seem to be working first. Are there proxy settings on the SquidSync application?

Is the error from SquidSync the same as before? If so, are there proxy settings in the SquidSync application and if there are, can you remove them?

Ok, any new symptoms from the system that I can use to help you further and are there any log entries you can see in the reports - realtime - web filter once you filter for the source IP? Also, could you show me the auth policy you added for the location - just want to check that the sequencing is correct as that policy obviously needs to be in place before the generic ntlm auth policy.

You have done something wrong You have added the source IP to exclusions but are still using proxy settings. Here are a couple of solutions: 1: Find the domain the SquidSync application connects to and add that to an authentication exception in web proxy - authentication - exceptions. 2: Create a location in guardian - policy objects - locations with the source IP and add an auth policy in web proxy - authentication - manage policies for that location to not require authentication and treat unauthenticated requests with the appropriate group membership for the access from that system.

The secret knock is only required when you are using the cloud filtering extension on Chrome or Win-books - it's there to prevent double filtering of system already being filtered by the cloud filter extension. You can easily have non cloud filtered devices and cloud filtered devices on the same network behind a transparent proxy. Adding a 2nd VLAN is not really needed.

The secret knock is for the transparent proxy - when you tell the client specifically to use the proxy, it has no effect. What's the use case? However, the secret knock will still work for anything excluded from being proxied.

Not being quite aware of how the filtering is setup in your situation but the name of the category group that Adult content is part of is called Global Forced blocked categories so yes, I would assume so.

Most likely blocked due to the adult sites, which is a global policy and thus cannot be overridden by the policies local to your location. Either adult sites have to be unblocked globally and then implemented locally for each location(tenant) or the domain has to be allowed in a global custom allow.

Yes, the domain is the only thing that needs adding. No need for wildcards - 'repl.co' is what you should add to the domain/url filter field. If you want to be more specific, you can add a regular expression in the URL field in the advanced section - 'five-nine.repl.co' would work there if that part is constant as well.

The default allow means that there are no policies that apply to it - were there any HTTPS inspection policies listed when you try the policy test tool?

Use the policy tester in Guardian - quick links to test and see what policy blocks it. Or have a look at the realtime logs and filter for the URL - the policy that blocks it should also show.

It applies to both settings - the idea is to not have Youtube pre-filter the results, allowing Guardian full visibility of all content returned, so the content filtering takes over instead the strict/moderate mode. We have used this before when the Youtube filtering cleans up the returned content just enough so Guardian doesn 't trigger but the customer want's stricter filtering on searches in particular.

Good and bad news. Short version of the bad: Searches on YouTube are POST requests and not GET requests, so we can't block based on the search-term (as we can't see it) A potential fix, while we figure this out, is to remove any content modification policy enforcing restricted mode on Youtube. This will turn off the filtering Youtube does and lets guardian have the full content, where it can then filter based on content.

If you can see the log entries for the searches then QUIC isn't the issue. That being said, it's a good idea to block outgoing UDP 80 and 443 traffic on the firewall to augment the QUIC header removal policy - if a browser is in QUIC mode, the filter can't remove the QUIC header. I'll ask the blocklist team about this and get back to you.

The graphs for the interfaces show all traffic, not just web traffic. The reports - realtime - traffic graphs can also be a good resource when examining bandwidth as well as 'iftop' on the command line. A speedtest can be run directly on the console as well by issuing the command 'speedtest'

Diagnostics look alright as you show. ProvisioningError message is just for version number. Logs are delayed - an hour is what I think is the reporting interval for uploading to the cloud, then it has to be retrieved by the on-prem and indexed so should be present after 90m max.