ibpalle

And what is that used for? The RADIUS accounting for the BYOD section does not require the Smoothwall itself to send RADIUS accounting anywhere so if you are only sending accounting messages to the Smoothwall, you do not need any entry in the directories section.

Do not inspect bypasses HTTPS inspection, which in turn prevents content mod and anti malware policies from applying as well. The same is valid for Do not filter - HTTPS inspection, Content Mod and Anti malware policies are all bypassed, se essentially they are the same thing. You can use either - you don't have to use both.

Hi Mark Yes - if there is no authentication going on for the AD connection, it can be removed. Make certain you have the correct group mappings under the iDex directory before you disable the AD connection. Is the RADIUS entry you mentioned initially in the directories section or did you mean the BYOD feature?

Azure is used for the cloud filter extension to map Azure users so that's needed. iDent is used to login users based on their AD Account logins processed on the DCs. Active Directory is used for any auth method that involves NTLM/Kerberos, used for SSL VPN and for RADIUS authentication in the BYOD section. Not certain what the RADIUS entry you have is used for - could you elaborate on that?

The 2nd method is about enabling Youtube safety modes, not about allowing specific videos so they should not be contradicting each other as such. The first method is about allowing access to individual videos and from the sounds of it, you can get that working but then the problem is that when you access that video it's not in safesearch mode? Since that is for a single video, not the whole of youtube, is that really a problem?

Yes, I meant the domain name suffix. Looks like I need to run a DNS training session for our support team Glad it's looking better for your network.

For the BYOD I tend to add your AD domain name as a search domain in DHCP settings. I assume the 172.16 60 1 is the Smoothwall itself? Then in the network - firewall - Smoothwall access make sure that the services for DNS, port 80 and 442 is allowed as well along with any other service needed (possibly RADIUS)

It may be an idea to try using forwarders on your internal AD DNS servers - point them to the Smoothwall as DNS forwarder - it should reduce the outgoing DNS requests and possibly make for a smoother DNS path generally. For the Smoothwall DHCP clients I am assuming the first IP in the subnet is the Smoothwall itself, so we should be good there.

The wait states show delays when waiting to put or retrieve content from disks or RAM - it does fluctuate and is supposed to. The load average of 6.7 isn't high - once you get into the 20-30s the web interface will start becoming slower and that's where it may indicate an issue. If the problem can somewhat be attributed to DNS, have a look at the DNS path on your network, you may be able to optimise this. Internal DNS servers - what are they suing as forwarders? ISP DNS , root servers, Watchguard DNS proxy or Smoothwall DNS proxy? Clients on youir domain will likely use your internal DNS servers but what about BYOD users? What we normally do when the Smoothwal is the firewall as well, is set the Smoothwall to resolve externally using ISP or other publicly available DNS services and internally via conditional DNS forwarders, use your internal AD DNS servers. Clients are then set to use either internal AD DNS or the Smoothwall as DNS and then youir internal AD DNS servers are set to use Smoothwall as their DNS forwarder. This will reduce the amount of external lookups and make the Smoothwall system a DNS cache for your entire network. I assume the Watchguard have a DNS proxy service as well, in which case, that can be used instead of the Smoothwall.

This feedback is basically what we overwhelmingly get from our Monitor customers. Integration and management of the alerts as well as the human moderation is a big timesaver for our customers.

IDS/IPS - that's right. I always forget to check that one.

The certificate should have no play in this - hostname and IP stays the same correct?

There is something else missing - the proxies wont prevent you from removing the IP. Check port forwards, firewall policies, smoothwall access policies and any LLB pools that may have been defined and make sure the IP you are removing is not specifically listed in any of them. Any policy in the networking area that specifically lists the IP that is to be removed, will cause these types of error messages.

The feature is available in the Guardian - quick links - policy tester. It can also be accessed by creating a user portal, where teachers can login using the AD credentials, and then check if a URL is available.

Setup a 2nd interface with a temporary IP and make sure that access to the admin UI is allowed on that interface in network - firewall - smoothwall access. Connect directly to that interface if you can using a laptop with ethernet and a static IP on the same subnet. Once there, go through the config and go through the config in network - config and set any policy that relies on the 192.168.1.1 address to be a generic rule and not list that interface directly. Once done, you can delete the IP, then add a VLAN with the physical interface as the carrier.

Hmm, doesn't sound like something we can correct on the Smoothwall as such. Does this happen only on the update to iOS15, then a re-sync is needed but after that it's generally fine?

When you say the system won't resolve anything without proxy settings, then please check the DNS setup for the system. When a system is using proxy settings, the system sends all it's requests directly to the proxy. The proxy does the DNS lookup. When a system is behind a transparent proxy and is not using proxy settings, the system does it's own DNS lookups. If you have web access with proxy settings but are getting name resolution errors from your browser without proxy settings, DNS could be the culprit.

What do you mean 'drop the connection' ? And yes, the policy needs to be enabled and the option for HTTPS is sometimes overlooked.

Create a location object in Guardian - policy objects - locations and setup an additional auth policy for the proxy with that location set in the where field. Set auth to be none and set the unauthenticated requests to be treatred as any group you would like in the third step.

No need to use Smoothwall for DHCP in order to use Smoothwall as the gateway. What does a traceroute show going to 8.8.8.8 ?

It does look like that - not certain how to address that

The system should append the search domains to the simple hostnames in order to be able to resolve them, so that is the correct behaviour. Can the client navigate to http://smoothwall/getcert?

And what is the gateway IP set in the routing table for the guest wifi? If the Smoothwall is directly on the Guest WIFI subnet, why not use the Smoothwall as the gateway?

Tried that as well without going via the Smoothwall HTTPS filter and browser is still giving cert errors. This works fine though https://accessitlibrary.com/ Also got a permission denied when accessing https://accessitsoftware.com/updates.

Can that client actually resolve the smoothwall hostname? Try a ping of just smoothwall on a command line console.