ibpalle

Can you see the log entries for access to Vimeo in the Guardian logs? Is QUIC outgoing being blocked for users? (UDP ports 80 and 443)

In the Smoothwall UI in the network - firewall - smoothwall access is the DNS service port open on the interface with IP of 10.107.89.250 ?

If you can't see office.com in the filter logs, it's unlikely to be a filtering issue - could be you are excluding the office365 IPs so that traffic is not intercepted. Is the error in the browser generated by the proxy or the browser itself?

Connection timed out - if that is an error generated by the proxy it means the proxy cant get to the site. You should see code 503 in the code column of the web filter log viewer for access to office.com. If the Smoothwall is also the firewall check that external routing is set correctly in networking - configuration - SNAT and LLB policies and if it's not, make sure the Smoothwall IP is not blocked on the upstream firewall.

What is the error in the browser or is it just for applications? The HTTPS method set in your Smoothwall for the transparent proxy the users are going through, what option is selected there? It should be 'Allow transparent incompatible and filter others by cert' Are you excluding the office IPs from being intercepted by the transparent proxy as per the first post?

As far as I am aware, we do support nested groups in AD. There is a caching time though - normally set to 10 mins so if you have just mapped or moved users/groups, you may first see the change after 10 minutes in the mappings.

Ping by IP, hostname or host and domain name? It may be that IP and host.domain.name works but hostname does not.

Reverse lookup is good to add - it gives you the ability to use hostnames in the locations. Apart from that, it's mainly important for Kerberos.

Does not look completely healthy to me. What are your internal DNS servers using as forwarders? Or are they using root hints? Take a look at this KB https://kb.smoothwall.com/hc/en-us/articles/360003640159 especially the 'Optimize internal DNS servers' section because I think using the Smoothwall as a DNS forwarder for your internal AD DNS servers may help in this case.

Nothing there looks excessive as such. What is the DNS resolution time on the Smoothwall and on a client in your network?

Do you have an available free interface that you could use instead as a test? Could be a hardware issue.

8192 is the new default - it should be sufficient. The queue was set low due to memory limitations when we were still running 32 bit OS. Given the memory amounts we have available now there are no issues running 32k values in that field. It's a hard one to quantify (similar to slow DNS issues at times) but test the different values, see if it gives you an improvement and go with that. I don't think you will ever see improvements going below the 8k mark though.

There is no listing for install dates for all updates but you can see the most recent date in the system - maintenance - system restore as the last system restore point will have been taken at the time the last update was applied. Other than that, you would have to look through the logs manually.

A separate subnet from what is already in use.

Just a quick check - look at Network - settings - advanced. What's the size of the 'SYN backlog queue size' dropdown set to? An older default of 1024 is a bit too low for todays amount of cloud services so set this to the 32k value. Otherwise, check bandwidth usage in the morning, load average and look at DNS lookup as well in the network. If you use the Smoothwall as firewall it can be useful to set your internal DNS servers to use Smoothwall as DNS forwarder for them. This reduces external DNS lookups immensely.

Try running this command on the console: # iptables -F mac1x And see if you get connectivity back. There is an underlying security rule that matches MAC addresses with IPs for RADIUS and this can create issues in certain cases. If this command returns access for you, mention that to the support team.

According to the Google KB article, any of those ports can be used apparently but I believe Smoothwall will be sending to port 587. 'On your device or in your app, connect to smtp-relay.gmail.com on one of these ports: 25, 465, or 587.'

SMTP transaction logs will be in the /var/log/messages file but there is no viewer in the UI so command line access is where to have a look. However, take a look at this: https://support.google.com/a/answer/176600?hl=en from https://kb.smoothwall.com/hc/en-us/articles/360003683819 and use smtp-relay.gmail.com As well as enable the auth and TLS options.

Disclaimer: Smoothwall parent company have just acquired Quostodio mentioned below. This company: https://www.qustodio.com/en/ - provides parental control software for most devices and have had very good feedback from parents. However, I have not had the chance to test this yet so can't for sure say https inspection will interfere.

Good site too for PAC file reference: https://findproxyforurl.com/

Correct - HTTPS inspection is irrelevant as the extension filters once the browser has received the page and decrypted it. The filtering is done by the extension - it's not a redirect to a proxy hosted elsewhere.

Try to add the intermediate CA used as pete suggests. This can be uploaded to the Smoothwall in the system - certificates - certificate authorities section. You can download the intermediate CA from you local certificate store in crt or pem.

Normally missing group info means that Smoothwall does not know what group the user is a member of. Make sure group/OU mappings are correct and up to date in the services - authentication - diorectories and check the users group membership.

It may be possible to create a Kerberos keytab file for the domain and upload that to the Smoothwall in Services » Authentication » Kerberos keytabs - the help contains a lot of info for this page. Once done, use the Kerberos script you can download from https://download.smoothwall.net/support/. How to go about creating a keytab for the OpenLDAP domain and make sure DNS and domain names are resolved correctly will likely be an adventure though.

What is the domain name? server.local? You could try just adding dc=local and see if it catches everything below that and work down from there. There are limited authentication options though - I think we are down to just being able to use the login page with that type of directory.