ibpalle

Often after a move to iDex, there's leftover items in the authentication exceptions in web proxy - authentication - exceptions. Exceptions there are meant for when various software cant respond to an active proxy auth request, like NTLM or Kerberos. With iDex, RADIUS on BYOD and/or login scripts, auth exceptions should no longer be needed. Anything going to a destination exempt from authentication would show up as unauthenticated.

Has the option to isolate clients been set on the Wifi SSIDs? If it is, does it make a difference without?

If you run the command: # /etc/actions/secondboot/9400http After a reboot, does the admin UI start then?

A certificate Authority only serves to validate certificates created by it - there will be no confusion having older CAs installed at the same time a new one is rolled out. CAs can be valid for just under 3 years. Use the top level CA Smoothwall creates for HTTPS inspection, not the 2nd level CA also generated - that one only has a lifespan of 1 year. The top level CA has just under three.

Correct, if there is a transparent proxy on the VLAN interface, web traffic will be handled by the proxy, not the firewall rules. If the transparent proxy is not needed on the interface, it can be removed.

Are localhost and internal subnets excluded from proxying?

Does the MDM enforce proxy settings that are different from the ones the iDex client requires? (localhost 8080)

Does the portal.smoothwall.cloud show the current policies on your SW ?

By the way, we publish a pdf with all categories and descriptions of them on our KB here - updated whenever changes are made to the category list. https://kb.smoothwall.com/hc/en-us/articles/360004511520

Soz, my bad. It's in the Web infrastructure section.

The 'Smoothwall products' category is part of the blocklist under the 'IT and Technical' header so you should have it available. Please update the Leeds 48 asap - there have been multiple changes to address Azure AD setups, which hopefully will address the issue you are seeing.

Is the diagnostics page showing mode 1 or mode 2 for the extension? If 1, that would mean that client hasn't received the config from the cloud controller yet. Could you make sure the category 'Smoothwall products' is in a 'Do not filter' policy in your filter config?

I'd definitely look into using the iDex agent on domain controllers to handle user identification and using Kerberos/ntlm as a backup method.

Not all apps honour proxy settings so I always recommend a mix - proxy settings are good for apps and browsers generally as they tell the app that a proxy is in use but for all other traffic, the transparent will intercept that.

Check the transparent proxy config on Smoothwall - is HTTPS filtering enabled? Most likely not - once enabled, also remember to check the authentication policy for the transparent proxy and set the behaviour to allow transparent incompatible and filter others by cert.

Using port 801 is still going through the proxy so while filtering isn't applied the issue may be the just the proxy. Try removing proxy settings - you should have firewall rules that allow outgoing https for the IP address of the server too.

As paulkerton said, this is a security requirement which was introduced a couple of years ago. We have a KB detailing how to do this here: https://kb.smoothwall.com/hc/en-us/articles/360002833340

The Smoothwall RADIUS service forwards auth requests to the AD, it does not generate them. For some reason the username is sent twice for auth - once with the normal username then, 20 seconds later apparently, with the /024 in front, which obviously fails to authenticate since the username is wrong. The Wifi controller/APs are the ones that sends the request to the RADIUS server - what's the Wifi controller you are using?

No you should not. We are carrying a big backlog at the moment which is why chasing for ticket response can be needed. One consequence is that a lot of our tickets are 3-4 word P1 mails and technically speaking not a P1 issue. Each one of those needs sorting in turn and there's no way of knowing if it will take 20 minutes or the full day. I know all here do provide good descriptions when they submit cases so likely preaching to the choir here when I say that they help immensely. Gives us a good idea on what to expect and thus makes it easier to plan for. We are taking steps, new people coming in and some new processes and methods being introduced. The cloud backup is one that should help immensely with restoring failed systems - btw, the cloud backup was introduced on Leeds-45. https://kb.smoothwall.com/hc/en-us/articles/360020722900 Hopefully in a month or two we will start seeing improvements on the backlog - until then, unfortunately keep chasing the important tickets and do check out our knowledge base too - you never know. Feedback to account managers/Support admins and here, we do read everything. Also - please be nice to the supporters

Yet another thing to blame Matt Hancock for - as if there wasn't enough already.

There is no content mod to remove those sections - I'll put the suggestion to the team. With safesearch and HTTPS inspection enabled, it looks like there simply wasn't enough content for the filter engine to recognise it as inappropriate.

Is HTTPS inspection turned on for the web search category and is the content mod - safesearch via connect header enabled?

There are 2 types of RADIUS setups on Smoothwall. The RADIUS accounting and RADIUS authentication options in services - authentication - directories are when Smoothwall should use an external RADIUS service. The RADIUS options in services - authentication - BYOD are for enabling Smoothwall to act as a RADIUS authentication and accounting service. Currently this only interfaces with Active Directory, not any other directory type. The BYOD options are used for 802.1x user auth and accounting.

Only the public parts of the Smoothwall VPN certificates is present in the ovpn file. There is no user certificate. If a user had access to the certificate information or the ovpn file they would be able to try a connection - obviously they need a username and password that works in order to be able to connect. The certificate information is embedded in the ovpn file now, there is no need for the certificate included in the client archive generated on the Smoothwall. That is the public key for the server certificate.

When looking at memory usage, the real indicator is swap usage. On the graph shown, only the yellow part is active memory use - the rest is caching. There is no swap being used at all. High memory usage is perfectly normal and expected behaviour - if the swap grows (you can click on the graph to get a daily, weekly, monthly, yearly overview) then there could be a problem. The caution alert messages you are seeing on the dashboard are triggered by the alert settings you can find in reports - alerts - alert settings. The firewall alerting is likely still set to default values and triggers too much. I'd disable those alerts and enable them when you need to check for things like recurrence of dos attacks or similar. It's a fine alert to use when you know what you are looking for, not so useful as a generic one.