ibpalle

QUIC is UDP traffic. Proxies don't intercept UDP. Not sure if that's possible with UDP being connectionless.

Just an aside. When we had corporate looking at out filtering it was often the complexity and number of options that turned them off initially. However, once they decided to go with Smoothwall, they would often come back later with 'You know, those advanced features we didn't think we needed? Well, we do - can we have some additional training please'. But yes, filtering requirements are very different for corporate and education.

If the browser is in QUIC mode, then traffic wont be passing through the proxy and thus won't be inspected. With the cloud filter extension, filtering is done in the browser, after the browser has received/decrypted the traffic so TLS inspection and QUIC isn't relevant in that case.

Just to mention - the content modification for removing QUIC header will not work if QUIC is already in use - that's why the QUIC blocking in the firewall is important.

@mrstrong Yes - there are many ways to arrange policies and this is our recommended starting point. It makes it easier to follow the mantra of better to not block than to allow. Simple basic everyone policies just blocking the real nasties that no one should have access to and then use the group policies to flesh the categories out. You can also make the students folder apply to unauthenticated and default users too, getting rid of policy 6.

Reason all group specific policies are below the everyone is that everyone is for blocking content that no-one should have access to as well as allowing categories like software updates. If IT staff need access to anything that is blocked for everyone, remove it from the everyone policy and make sure it's added to the group specific policies for the other groups. That way you keep the staggered approach and avoid having any confusing sequencing in the policy list - remember, it's always recommended to not block, rather than allowing.

One snag with RADIUS traffic is that it sometimes comes from APs, rather than the controller IP. To check where the traffic is coming from, enable incoming traffic audit in network - settings - advanced temporarily. Then go to the reports - realtime - firewall and filter for ports 1812 and 1813. The source IPs should be listed. Make sure those match the authorised client settings in services - authentication - BYOD. Also - the accounting is what logs the user in. Auth can be done by other servers if need be.

It's in Web proxy - Web proxy - settings - advanced. Called 'Resume interrupted NTLM connections'

You should be able to manage them either on-prem or in the cloud portal. If both are unavailable, something isn't right. Open a ticket and pm me the number - I'll check our backend config.

If you logged in as local admin, not domain admin, that may not have caused a domain login event and thus no iDex info.

Yes - if there are policies that affects that traffic before the internal networks policy then the traffic wouldn't be sent via the ipsec tunnel. That would explain you seeing traffic going to the Smoothwalls but no further. It gets shunted out via the external gateway and disappears forever...lost...alone...

Should be simple enough - all routes are added by the VPN engine so you don't need any additional ones adding. Firewall policies are the only ones that need to be added manually. Have you added and policies in the SNAT and LLB policies section? Make sure the policy for traffic to internal networks is at the top of that list.

If the Smoothwalls could talk to each other but not the subnets, the most likely cause is routing seen from the clients side. Is the Smoothwall the gateway for the remote subnets? If you had another solution for VPN before, there may be a static route in place? The firewall policy should be LAN and IPSEC in both incoming and outgoing interface. As for Smoothwall access over SSL and VPN, make sure there is an access policy for the SSL VPN and IPSEC interface in Smoothwall access.

It has been off/on before a few times so some could not be aware of the current state.

Just port 8443 as I understand it. Since we do not support reverse DNS lookup for firewall policies, the IPs have to be used, as you correctly say. An alert can be configured, use the DNS name resolution alert in the health monitor. It will tell you if the IPs have changed and you can then add the new ones to the address object if they have. Keep the old ones in there in case they revert possibly.

We try to avoid - not rule it out by default. An alternative to a bridge is using a single NIC smoothwall as gateway, the Smoothwall will intercept web traffic and forward all other traffic to the 'real' gateway. Policy based routing can be used as well.

Running as a VM is definitely possible - we try to avoid complext network configurations like bridges on VM installs but otherwise they are fine. Only caveat is the disk subsystem. Smoothwall logs a lot and if the disk subsystem is shared by many VMs the disk IO may cause issues.

The Youtube advert blocking is currently not working - Youtube has changed their ways ;( Obviously they don't wan't us blocking their ads. We will keep trying.

Then it looks like the cloud filter extension isn't installed on the users device. The Smoothwall on-prem filter won't know about Google logins unless the user logs in manually.

Are other users on Chromebooks getting filtered fine? If so I would assume you are using the cloud filter extension and that it hasn't been pushed to the device the user is using - that ot the secret knock isn't working for that user for some reason.

Hello Danny11717 Depends on how users authenticate to the system. Sounds like the user isn't getting authenticated at all from your description. Is this an AD user logging into a Windows laptop and is the username a member of the correct groups in AD? In the services - authentication - directories you should be able to see group mappings from the directory so you can see which group the user should be part of.

HyperV isn't an issue. There is one if you are using VMware and VMWare tools. The UI will tell you. No refund! Just like we aren't charging extra for all the additional features we add constantly

Hello everyone The new Smoothwall release 'Maiden' is finally live. We have a knowledge base article here on preparing the upgrade. https://kb.smoothwall.com/hc/en-us/articles/5885066421916-Prepare-to-update-to-Maiden Personally I would recommend everyone to take a look and plan on updating. The new kernel in Maiden has improved performance in almost all areas. Sometimes a little, sometimes a lot.

In such cases it's often the IP ranges in the tenancies that needs a look. Make sure all tenants are selected in the iDex and AD directory entries on the Services - authentication - directories as well. If the proxy can't match a tenant IP to a request that's when the disconnect happens.

Yup. Use 1 to find the interesting ones and 2 for details.