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.