ibpalle

Currently the extension has been blocked by Google - we have no idea why yet. This does not look like we can get it back online anytime soon - I'll update here as soon as I know more.

As mentioned, we are looking into what is going on and I'll update here as soon as we find out. Obviously we will announce if any of our features will be removed - just wanted to mention the cloud filter extension as it's the replacement, not just for the CfCB but for all OS.

The only thing the Connect for Chromebook does is login on the SSL Login page. With the cloud filter extension all the same policies are still in use and the setup is simpler and requires no proxy settings. I's an improvement in every way for Chromebooks so take a look.

Looks like the Connect for Chromebooks extension is having an issue in the Google store at the moment. We are looking into that currently - I'll update this thread when I have news. And just to repeat - Connect for Chromebooks will be removed at some point as we now have the cloud filter extension instead so if you have time, please look into our new extension.

Not certain what could cause this - as far as I am aware, no changes were made to the extension. The SSL Login will work as it's not related to the connect other in that it's the same method the connect client use for authentication. I would recommend taking a look at installing our cloud filter extension instead goping forward - it's included in the license and allows for a lot easier filtering on the Chromebooks, both local and remote and does not require proxy settings.

If one of the MACs access a file server, does an iDex entry then show up for the user? Since the iDex entry only shows after a successful AD login I'd like to see if an iDex login is seen after using AD credentials to access a resource in the domain. Sometimes MACs and AD logins depend on what type of software is used for joining the domain.

Is iDex still working for the non MAC devices?

Once you have created the config options on the Smoothwall, make sure you logout of the admin interface and leave it logged out for about 10 minutes, to make sure the config is transferred to the cloud instance and then to the clients. As long as there is someone logged into the admin UI, the config wont be replicated.

You would likely need a way to identify the Chromebook - a static MAC address mapping in DHCP to always give it the same IP or make sure reverse DNS is working and get the hostname of the Chromebook and add that to a location, which you can then use for policies. The Chromebook policy would have to be for that location and that user if you have other users using the same Chromebook as well.

The logs will be transferred to the on-prem smoothwall so you should be bale to run reports on the username there. In the cloud portal, you can also find a log viewer in the filter section. There you will see the most recent logs retrieved from the device. Since logs have to be transferred by the device itself to the cloud and then from there to the on-prom, there is a delay. I believe the device tries to deliver logs every 5 mins.

You can increase the login timeout for now in services - authentication - settings. If this is for BYOD devices, then set a long DHCP lease time and set the timeout to be high. The reason for the high lease time in DHCP is that the login will persist so if another device gets the same IP before the login expires, they will be browsing as the previous user.

Hi Bodminman I believe we had an exchange via support - the proxy needed to be enabled as it had been disabled during setup.

I must admit I rarely enable any of the Youtube restricted modes in new setups and rely on the content filtering in Smoothwall instead of the Youtube modes. Both moderate and restricted are giving results that doesn't make sense at times. With HTTPS inspection on for Youtube the content filtering in Guardian is easier to control and is consistent with your overall filter policies.

In the reports - realtime or logs section. Go to system logs and select system in the section dropdown list. You should see login events with username and IP there.

In Smoothwall we do have a new category added for Google Meet - could be an idea to allow that. Check the logs as well to see if anything's getting blocked. If you are running a Smoothwall it may be an idea to look at this KB where we publish a list of our categories - a good reference document for DSLs and anyone receiving reports. https://kb.smoothwall.com/hc/en-us/articles/360004511520

So apparently the link matches our online games category - what url are we looking at? The main one, not the specific that is shown in the block message.

Most likely some content delivery services are being blocked - either due to https issues or by way of a specific policy. Try to take a look at the reports - realtime - webfilter when you access the article. Add your IP and the word 'denied' in the category field to see exacly what's being blocked and which policy causes it.

The check for the alert runs overnight so right after renewing, the alert will still show - as you also noticed, it's gone the following day. We are changing the check to run after a new CA has been set as well.

Lots of possible reasons and actions to look at here. 1: Ensure the Smoothwall certificate Authority is installed on your devices. 2: Use the KB here and add IPs to Guardian - web filter - exceptions and add domains to the pac file in web proxy - web proxy - automatic configuration. I assume you have added internal subnets and AD Domains here already. 3: Check your DHCP if option 252 has been added - that is a way of getting proxy settings using auto discovery as well as DNS.

The alerts can be adjusted from the reports - alerts - alert settings. I normally turn that alert off as I see it being used to monitor external blocks after a DOS attack or similar.

Here is a script we sometimes place on systems to make sure the mac1x chain gets removed - normal warnings to apply here with regards to accessing console and running scripts so ... Add a file called /etc/actions/secondboot/9999deletemac1x Edit and add this to the file: #!/bin/bash #This script deletes the mac1x chain from iptables to resolve MAC to IP address Binding issue with BYOD/RADIUS setups #Note: This DELETES the chain it DOES NOT flush the chain /sbin/iptables -F mac1x /sbin/iptables -D INPUT 1 /sbin/iptables -D FORWARD 1 /sbin/iptables -F mac1x /sbin/iptables -X mac1x Save and chmod +x the file. Reboot or clear the mac1x and run this script

When you are experiencing issues that could be DOS, it may be an idea to enable auditing in network - settings - advanced - that will record all network traffic going to, through to from the Smoothwall. Otherwise just blocked traffic gets recorded in the firewall logs. Leave the auditing on for an hour or so, then look through the logs. There is an alert for specific port access too that can be set once you find the relevant data - set that up to monitor if the traffic starts picking up again after the initial resolution.

Yes, without https inspection only the domain part of the URL would be visible to the Guardian filter. You can add to the standard categories using the features in the categories section - you can't see what's in our blocklist. It's considered IP so contents is not publicly available.

That is what I assumed, so my question was if there was any specific reason why there's a RADIUS accounting entry in the directories section - that is not needed for the BYOD functions to work. Smoothwall is a RADIUS accounting service - it does not need to talk to one. What the RADIUS accounting entry pointing to?

No, with do not inspect, only https inspection would not apply. If porn is blocked and someone goes to Playboy, it will still get blocked.