ibpalle

All of those things affect SIP - what does the provider tell you is needed on the firewall? When you plug in the phone system to the Smoothwall, was the config on the phone system changed to allow for NAT e.g.? One issue with SIP is the source IP of the caller is included in the SIP package content and if that isn't change to the NAT IP on the phone system config, then SIP will fail as return traffic tries to go to the internal address of the phone system, which will never work. Did the provider tell you anything about port forwards? It's not really unusual to have a NAT in place on the network and the provider should be able to tell you what is required when the system is behind a NAT.

You shouldn't need to fight the Smoothwall on this - the provider should give you the requirements for their solution on the firewall side. The SIP proxy and the SIP helper mentioned above is rarely required so definitely turn those off unless the provider says they are needed.

Those groups are not default groups built in to the Smoothwall so you can rename/delete them as you like but be sure to check the group mappings in the services - authentication - directories section. Renaming them to a more appropriate name and adjusting the category objects (Groups and custom) used by them will help clean the config up.

Configure the 'secret knock' setting in Guardian » Client interfaces » Cloud Filter. Then add the service 'Cloud filter bypass' in Network » Firewall » Smoothwall access. This will tell the cloud filter extension clients to contact the onprem so onprem won't filter them.

Too many redirects is often caused by using proxy settings and not excluding the proxy itself - could that be the case?

For the safeguarding report on the Smoothwall, remember that the instant alert and the notification summary can be enabled separately. My normal recommendation is a daily and weekly summary for all categories with no instant alert and then three additional configurations for instant email alert for abuse, suicide and bullying but no summary notification. Adjust as needed.

Try a do not filter for just the address 'connectivitycheck.gstatic.com' There is a new category in the software section called Captive Portal which includes the above address and others.

Just a thought - some installs have avoided replacing their CA so they are still using a CA that have expiry in 20232 or similar. I think replacing their CA with a newly created one, which is only valid for the correct 3 years may solve it but haven't tested.

The 'Capture Portal' category may need HTTPS exclusion on-prem to allow for urls like connectivitycheck.gstatic.com to be processed without interference.

I may be incorrect here but I think Senso does HTTPS inspection as well. Applications generally have a hard time with HTTPS inspection which is why their target domains often have to be excluded from HTTPS inspection. With both Senso and Smoothwall in place, it may be needed to install the Senso Certificate Authority on the Smoothwall in system - certificates - certificate authorities so Smoothwall can validate certificate created by Senso.

Depends - is this an alert from the cloud portal or a daily summary from the safeguarding notifications on the Smoothwall? If you run a report, usernames will be case sensitive as well I believe. Also, take a look at the reports - logs - web filter and select the date and approximate time, then add other filters to see if you can find the log entry there.

All web traffic that is going through the cloud filter extension.

You can look at the logs from the cloud filter clients in the filter section too - there is a log viewer there. The logs will likely be transferred to the local Smoothwall just not in real time. You can see real time logs on the device itself as well: https://kb.smoothwall.com/hc/en-us/articles/360006892380-Checking-that-Cloud-Filter-Policies-Work-Real-time-log-viewer

Yes, that looks good, it's not constant, which is normal as well. At house cleaning time, log rotation or early morning hours when everyone fires up their PCs. And the values shown in the alert are not excessive at all. Set the alert setting I mentioned before to 8.

The load is often generated by disk access and if this is a VM disk is often slow. Is this a parent for a cluster? Is it a firewall and is has a lot of logging options been enabled? On the console. if you run the command top, you can see the distribution of load. The third line from the top looks like this: %Cpu(s): 0.7 us, 0.1 sy, 0.0 ni, 97.9 id, 1.0 wa, 0.0 hi, 0.3 si, 0.0 st What's the value for wa? Thjose are wait states which indicates disk is having to do a lot of work.

What is the load value? The load average is an amalgation of disk, cpu and memory activity so not just cpu usage. Is it just because you are getting warnings that you think load is high? The alert, by default, triggers at a value of 1, which is silly - a default we havent changed in the install image but we usually change it during the install. In reports - alerts - alert settings, find the load average alert - if it's still set to one, set it to a reasonable value. On a 4 core system, set it to 4 - on anything higher than that, set it to 8.

Yes - due the the link going to a redirect URL, where the address does not match the certificate ID. Take a look at this thread: /forums/internet-related-filtering-firewall/236494-smoothwall-help.html

Pearson.com seems OK certificate wise.

The regex listed is specifically for one domain ^[A-Za-z0-9.-]*\.medigold-health\.com - medigold-health.com. I'm not a regex shark myself but adding this and change the domains for the links you are seeing blocked could work. Not certain if there are too many domains you are encountering this error on to add all of them to the url patterns field. Add them to a do not inspect policy or a do not filter policy - that will bypass certificate validation for those addresses.

There's a discussion on this here: /forums/internet-related-filtering-firewall/236494-smoothwall-help.html

Yes, setup an interface with the external role and you ISP internet connection details. I'd suggest you talk with your account manager and have them setup a rework session to reconfigure the Smoothwal.

If the smoothwall is not the firewall only web traffic will be seen on the smoothwall - no firewall policies will apply. Either Smoothwall is being used as a non-transparent proxy or as a fake gateway and transparent proxy - in either case, no firewall policies are likely to apply.

Check in network - configuration - interfaces. If the role listed for the interface the proxy is configured on is 'Bridge' then firewall policies won't have any effect. Is the Smoothwall your firewall as well as filter or do you have another firewall?

You can enable auditing of traffic is the network - settings - advanced to see all traffic going to, from or through the Smoothwall system. Is this Smoothwall a firewall or a bridge deployment?

No. You need to create a new CA. The original seems no longer to be present. Create an entirely new CA, download and distribute that to the clients. Then once done, set it as default CA. Old and new can be on the client systems at the same time.