ibpalle

If you have changed the IP on the interface after you added the transparent proxy, edit and save the proxy policy again and restart the proxy service. When gateways/IPs are changed, sometime the transparent proxy has to be resaved and restarted as the Guardian conf rewrite isn't triggered by IP address changes. I am assuming the Smoothwall Guest Wifi IP address is the gateway for the clients?

Enable the option 'Exclude simple hostnames' please. That is the equivalent to 'Do not proxy for local addresses' in the Windows settings. Basically it excludes any request using just a hostname (like 'smoothwall' ) from going via the proxy.

You should have a transparent proxy configured to filter devices that are not using proxy settings and if you have different interfaces for the LAN and WIFI a transparent proxy should be configured for both. One option when setting up the transparent proxy that can be easily overlooked, is the HTTPS option - that should be enabled otherwise HTTPS traffic wont be intercepted.

We have had a few customers reporting that the KB did not solve their issue but when we looked into it, the errors were now from other devices like upstream firewalls, so if you are not using the Smoothwall as your firewall, make sure to update the certificates on other devices too.

The exceptions should be set on the clients - if the clients are using proxy settings. If you are using the proxy port for set for core auth, this should not happen - if the transparent proxy is using negotiate kerberos/ntlm then the proxy settings may not be used correctly by the client.

ChrisC is correct, please make sure to enable the new interface in the DHCP Global page. Once done, you can see DHCP logs in reports - realtime - system and select DHCP in the section dropdown list.

The http://smoothwall:813/?https://www.yahoo.com/ is a redirect to port 813 on Smoothwall where the negotiate Kerberos/NTLM is performed. If you are getting a 504 on that, then if you are using proxy settings, please make sure the option for bypass proxy for local addresses is enabled along with exceptions for your internal subnets. As an aside, it may be an idea to contact your account manager and setup a call to evaluate the auth methods being used. We have some new methods available that is far better suited than Kerberos/NTLM these days.

Yes, the KB was missing these steps: 1: In Certificates - Certificate authorities, find all the expired certs and click the tickbox to the right hand side to select them and then use the delete button at the bottom. The one CA that's specific to this case is the 'DST Root CA X3' 2: Clear guardian cert cache under Guardian » HTTPS inspection » Settings

Also https://kb.smoothwall.com/hc/en-us/articles/4407518085394

What error is the browser giving you when you go to an HTTPS inspected site? It may be needed to replace the CA - if it is an older one with a valid date range over three years, it will not be accepted by newer browsers.

The code column in the logs shows the HTTPD result code from the web server the Smoothwall spoke to so it's not a Smoothwall error as such. When you see a 0 it means Smoothwall blocked it outright without going to an external webserver. A 304 httpd result code is: https://httpstatuses.com/304

I took a look at the code yesterday for the BYOD section in Smoothwall. I was hoping I could find an easy way to replace the certificates with ones created in the certificates for services section. Unfortunately the certificate code in the BYOD section is not as modular as I would have liked which makes it tricky to find a way to modify the backend with minimum risk. Hoping to get some feedback from a dev - will let you know how I get on.

Hi Bruno I would recommend you take a look at our cloud filter extension - with managed devices and Azure, that will definitely be the best option when used in conjunction with the on-prem Smoothwall. One more thing to do, if active directory accounts are still used/synced with Azure is to install our iDex agent on the domain controllers. This will look for successful audit entries for domain logins and send that to the Smoothwall - meaning Smoothwall should know who you are by the time you start browsing if you have logged on to a domain account. Talk to the account manager to setup an auth review and rework - iDex is simple to setup. Core auth is not an active auth method - what it does is simply lookup the information in the user activity list found in services - authentication. If there is a user logged in on the IP address the proxy got the request from, the proxy will use that info. If there is no user logged in on that IP, the proxy will treat the request as unauthenticated. RADIUS, iDex, login scripts all work with core auth.

I believe the current state of the Google login on the SSL login page is that it's broken - Google made some changes a while back which unfortunately broke the Google directory login. I'd recommend looking at our cloud filter clients for Chromebooks if those are the devices you are wanting to log and identify.

Yes it is but https inspection has to be on for the filter to see the full URL. Without https inspection the filter will only be able to see the domain part.

It may be that the authentication is not working correctly so no usernames are currently being recorded. You may be able to verify this by going to the reports - realtime - webfilter to see if there are any usernames in this list. If there are no usernames, that would explain the lack of results. I would suggest raising a case with support so they can go through the auth setup and correct that. If there are usernames, look at the format of them - in some cases you could see usernames in the format of '[email protected]', sometimes 'DOMAIN\user' or maybe just 'user'. Make sure you are searching for the tight format if that is the case. In the services - authentication - settings there is an option to normalise usernames so everything is recorded in the DOMAIN\user format - if that is not enabled, please do.

If you are still behind a Smoothwall transparent proxy when testing this, make sure you add the 'Smoothwall products' to a Do not filter policy. Also remember to configure https://kb.smoothwall.com/hc/en-us/articles/360015978080 However, this will only take effect after the client goes into mode 2.

Please follow up with support - or pm me the ticket number. For this time of year, support ticket numbers are in a very good place.

For the phrase 'MDN-phrase' you would just enter as is without quotes in the URL patterns and add this to an allow or do not filter policy. The same goes for any URL pattern you add - if there is no need for regex variations, just enter the part of the url that's the common denominator.

A lot of applications use pinned certificates instead of certificate validation. This makes them incompatible with HTTPS inspection unfortunately. Only way out for those is finding the target domain and exclude that from HTTPS inspection. In some cases, there are web page based services that will do the same as the app, if HTTPS inspection is essential, those sites can be used instead of the apps.

The snmp software used in Smoothwall is from Net-SNMP - I think we just use the base MIB files from that project.

Yes, so did I. The check will be changed to also run after a replacement of the HTTPS inspection certificate is noticed.

Just a question - was the CA created and set today? If so, the alert should be gone by tomorrow - the check only happens once a day. You can force the check by running # /modules/guardian3/etc/actions/crondailyrandom/0090trigger_certificate_exp_warning On the CLI

Yes, In think somethings wrong with the check that removes the alert. Just saw this on another system. I'll see if I can test and bug it.

Is anything wrong on the browsing side? Does HTTPS inspection and blockpages for HTTPS pages still work fine? If so, it would mean the new CA is in use and working, just the message is duff which could be a bug. If the new CA is not set top be used by HTTPS inspection, try to make sure by going to guardian - https inspection - settings and select the new top level CA you created to replace the new one as the one to use for HTTPS inspection. Don't use the automatically generated one for now and see if that makes the message disappear. Also, there is a KB for the steps required to create and use a new CA located here: https://kb.smoothwall.com/hc/en-us/articles/360002833340