ibpalle

iDex and the Lightspeed agent works in different ways so there should be no conflict. But obviously the software should be able to be removed if the products is not in use.

With Azure AD we can currently only lookup users and groups. We cannot validate password yet. I'd suggest a support call as the auth methods may need to be adjusted for the dual environment.

You need to set the community string in the SNMP section of system - services - snmp and then open up the snmp port on the internal interface you want your snmp server to talk to on the smoothwall in networking - firewall - smoothwall access.

With regards to Dynamic DNS - the router does not have to support it. Traffic out is NATted to the IP so often a client, if available, can be run on an internal machine and achieve the same result.

If the chromebooks are going through a SSL Login proxy and are not authenticating before then, then yes, you will get the login page. It sounds like there may be a bit of confusion about the extension and possibly the secret knock feature. Could you raise a ticket with support please and PM me the number. I'll see if I can pick it up.

Chromebooks, MACs or Windows or a mix? I would obviously point to Smoothwall and our solutions for this. We cover all OS and have various methods that can be used to fit the profile of what you want to achieve.

Living on a farm might be a context but as I said, this is just me assuming. I'll pass it on to the Blocklist team to see if they can improve this.

There we are into context - I can't see the full search text of the first one though. I'm not part of the team that makes the phrase scoring so was just offering a potential explanation why this exact sequence didn't trigger safeguarding. The words kill and knife are used in a lot of contexts - so I think this combination is just too generic.

Chinesewhispers This setup is meant for the chromebooks to not have any proxy settings. The filtering is done by the extension. Remove the proxy settings from a test chromebook and see how that goes.

That does look like an obvious omission but when looking closer, I am not certain which safeguarding category personal weapons would come under - it may only trigger in the safeguarding categories in combination with other items. The search itself was also fairly generic and the request was blocked due to the search so the filter never got the search results. Without checking I'd say the entry was too generic to be picked up by the safeguarding categories but the knife reference was enough to categorise it as personal weapons to get blocked..

You need the new secret knock feature! Sounds weird but basically it allows the extension to tell an on premise Smoothwall to not transparently intercept traffic from cloud filter clients. You need to do 2 things on the SMoothwal: 1: In networking - firewall - smoothwall access find the access rule that applies to the smoothwall internal interface the chromebooks will be using when going to the internet and add the Cloud Filter Client service to the list. 2: Navigate to this URL on the SMoothwall UI https://ip.or.hostname.of.your.smoothwall:441/ui/admin/cloud_filter There enter the same internal Smoothwall IP address you added the cloud filter client service for and a refresh of 600. Save the settings. Once this new configuration has been pulled by the clients, they should no longer be double filtered and only use the extension.

The cloud filter extension would be the best option but when you mention the cloud filter; is that 'Connect for Chrome' or the new extension? Connect for Chrome is for authentication mainly, proxying still goes via the Smoothwall appliance, whether the client is at school or at home. With the Cloud client, the extension gets installed and the browser itself manages the filtering based on policies retrieved from the Smoothwall appliance.

As I said, the global proxy is a valid option. A bit clunky to setup but will work fine for iPads.

loom.com should be enough. If there are any other domains, go to the real time web filter, add the word denied to the category field and the IP you are testing from on the IP field and see if any other traffic from the test IP is being blocked when accessing Loom. If there are no proxy settings, make sure the transparent proxy on Smoothwall is using the "Allow transparent HTTPS incompatible sites and filter other by certificate" for the HTTPS method. You can find this option by editing the auth policy for the transparent proxy.

Ipads - the itch we haven't been able to scratch fully.... Can't you give them chromebooks too? Seriously - iPads is troublesome for various reasons and at the moment, the 'best' option for off site filtering is by way of the global proxy options on Smoothwall and enforced proxy settings on the iPad. With a good MDM setup I'm sure other solutions could be found that would be less cumbersome but without relying on any other tools, the global proxy is a valid option. It does pose challenges mainly on authentication and validation so contact support or your account manager if you would like a chat on the in- and outs.

For the desktop version I'm betting the app just use certificate pinning - exclude loom.com from https inspection and see if that does the trick. Browsers behave normally with https inspection but apps are generally written to only connect to a single domain and then just use stored public keys to verify they are talking to the correct server. This will make them fail when they are subjected to https inspection.

Unrestricted access is often due to the QUIC protocol not being blocked. When using a browser that supports QUIC, youtube and other services can switch to using that as the carrier, bypassing the proxy. UDP ports 80 and 443 needs to be blocked outgoing in your firewall and/or the content modification rules called "Remove quick header" needs to be implemented. HTTPS inpection is required for that to work.

Same functionality exists and for apps on iOS that does not work, one of the first steps to take is to exclude the target domain(s) from HTTPS inspection. Unfortunately apps often use certificate pinning or just embedded public keys for HTTPS verification. This makes their HTTPS traffic fail if it gets HTTPS inspected.

Is anything showing as blocked in the reports - realtime - webfilter when you try to open the app? Add the word "denied" to the category field and add the IP of the device you are testing from as well as a source IP filter. Then try to open or refresh the app. Anything showing up in the log with a red background?

Using Safari for Youtube access instead of the app does give the web filter a better chance of modifying behaviour of Youtube but https inspection has to be enabled for Youtube in order for most of those mods to work. QUIC has to be blocked as well.

Most of these VPNs do not use HTTPS which means the web filter won't have an effect. For most you will need to look at firewall rules. If your Smoothwall is also the firewall, implement the layer 7 blocks for VPN signatures in the firewall section. If this is mainly on BYOD networks and those can be isolated, block all out going traffic - web traffic will still be allowed via the transparent proxy and then open up only essential ports.

Just a note. The clients actually don't do HTTPS inspection as they read what comes out of the browser before it gets displayed. HTTPS inspection is needed when traffic is being intercepted between the browser and the internet. Result is the same, that the filter can see the HTTPS content as it's not HTTPS when the filter looks at it.

Plus one for implementing HTTPS inspection. Certificate Authority distribution can be made easy by having multiple vectors - link on login pages, link on school homepage, email to new users - don't just use one option. Without HTTPS inspection the filter is basically just a token measure in my opinion. Also remember that while installing the CA is needed for validating certificates, it's technically not required - it will be massively inconvenient with tons of certificate warnings and some browsers will complain more, but access can still work.

Categorisation is done for all categories content belong in - I would suggest that blocking the Blogs category is not the right solution, making sure HTTPS inspection is on for Blogs is. Blogs are not specific content - it's generic content. It could be anything and blog sites can be useful in many cases. By using HTTPS inspection you can block blogs that deal with inappropriate content like terrorism, porn etc while still letting normal content through. For the specific issue it sounds like it's a sequencing issue in the policies - make sure the allow is setup before the block and also be aware that there may be subdomains that feed content to the site also, which could be blocked. That whack-a-mole process that is needed if you are blocking a content category like Blogs will be avoided if you no not block Blogs but just subject it to HTTPS inspection instead.

If you are not using the VPN certificates for anything other than the SSL VPN I would probably suggest deleting and recreating a CA and cert set. Then use that for the SSL VPN. Follow the recommendations in the thread in smoothwall direct support.