Sonic Wall Content Filtering

I have been using SonicWall for years. Never really thrilled with their support (primarily a language barrier until recently) but their content filtering seems to be problematic. I spend more time on the phone with them trying to keep it running correctly than it is worth.

Does anyone else use SonicWall for content filtering and in your opinion is it easy to keep running? Any comments about sonic wall in general?
LVL 15
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Blue Street TechLast KnightCommented:
Hi Lockdown32,

I think you know what I'm going to say about SonicWALL (I'm a big fan) To me two generations back I was ready to hop off the train. The performance was just not there but since then the bugs, performance and security features/functions have grown so much I don't look back to that time I was ready to jump ship. Currently, they have one of the fastest deployments of security clouds on the market and their countermeasures are first to near first in market.

Whitelisting Overview

In terms of Content Filtering, there is not a great understanding of it foundational as it relates to web 2.0. I'm currently writing an article about it because of this gap in the thought process. Web 2.0 changes things because whitelisting becomes more strenuous when you have to investigate the website sources due to the heavy use of external services, CDN, analytics, etc.

Content Filtering Engines

With SonicWALL you have three (3) different engines to utilize; two within the SonicWALL and one third-party integration: a) CFS via Users & Zones (Security Services > Content Filter > SonicWALL CFS); b) Websense Enterprise (Security Services > Content Filter > Websense Enterprise (third-party)); and CFS via App Rules (Security Services > App Rules).

How to know when to use each Engine

• SonicWALL CFS via Users & Zones (native engine) - Traditionally and for lower traffic volumes this what everyone typically uses.
• Websense Enterprise - If you already use Websense this provides integration functionality.
• CFS via App Rules - This is used in higher traffic volumes because it is a separate isolated engine that will aid in faster processing.

User Assignments

You have five (5) different methods to apply these to your user base:
1. Local Users (Users > Local Users) - used for small environments;
2. RADIUS - my recommendation for any network with a domain - this allows you do perform all sorts of authentication & authorizations for network resources such as VPNs, Wireless APs, 802.1X switches, etc.  &
3. RADIUS + Local Users  - Similar to the above but just adds local users.
4. LDAP - a less secure way than RADIUS to integrate into a Windows domain but ease manageability opposed to Local Users.
5. LDAP + Local Users - same as above only adds Local Users in addition to your LDAP Users


What is your SonicOS version? CFS 4.0 greatly differs from CFS 3.0 among other items URI listings. Also, CFS 4.0 does not allow usage of CFS Via App rules, which need to be reconfigured to work in CFS 4.0. Until the release of SonicOS Enhanced, HTTPS filtering was exclusively IP-based meaning IP addresses must be used rather than domain names in the Allowed or Forbidden lists. You can use the nslookup command in a CMD window to convert a domain name to its IP address(es). Keep in mind there may be more than one IP address associated with a domain, and if so, all must be added to the Allowed or Forbidden list, respectively. However, if you are running SonicOS 5.8 or higher HTTPS filtering has changed to both IP & hostname based.

Are you filtering HTTPS content, which almost all most major websites are now running?

Some items to keep in mind:
  • Allowed or Forbidden Domains list interpret domains & handle wildcarding differently than the Custom List. The Allowed or Forbidden Domains list wildcard by default so you should only put the domain ( in the entry opposed to or *
  • Do not include the prefix http:// or https:// in your entry.
  • Remove redundant objects - they only cause issues. e.g. if you have, * &, remove all but "".
  • CFS inspects the header packet therefore will not be filtered and would need to be added as such in the Allowed or Forbidden Domains list, respectively.
  • The Custom List is an exception in that it is explicit in nature meaning wildcarding does not take place by default therefore, does not equal & vice versa.

FYI: HTTPS sites are silently blocked without displaying a CFS block page by design.

I hope this helps. Let me know if you have any other questions!
LockDown32OwnerAuthor Commented:
The biggest problem I have found and seem to always be fighting is the Authentication via the SSO Agent. The CFS is so simple. People either have full internet or have nothing. It is only a 30 user network. I remember using Barracuda and it was virtually flawless.

   I look at SonicWall and can't help but feel it is a fighter/bomber scenario. They just have too much built in to it at this point trying to do everything and as a result it doesn't do anything real well. Then it went from SonicWall to Dell to yet someone else.

   So your vote would be to ditch SonicWall?
Blue Street TechLast KnightCommented:
I think I updated my post while you were submitting your reply. Please re-fresh to see my changes.

No, I am not saying to ditch your SonicWALL unless it is an EOL in which case I'd upgrade and stay with SonicWALL. We have all of our clients almost exclusively on SonicWALL and the user-bases range drastically from companies like your to 55,000 user environments. In Web 2.0 testing is critical and like I said previously there can be many caveats meaning things aren't straight forward because of the third-party service provider model heavily used in Web 2.0.

I'd have to see your config to determine why you are having so many issues/frustrations. When you say, "fighting Authentication via SSO Agent" how is that relating to having issues with CFS? I understand that if users can't login due to some issue with SSO then the correct policy will not apply but I don't see the direct connection to CFS issues but rather indirect or subsequent of.

Let me know.
SolarWinds® IP Control Bundle (IPCB)

Combines SolarWinds IP Address Manager and User Device Tracker to help detect IP conflicts, quickly identify affected systems, and help your team take near instantaneous action. Help improve visibility and enhance reliability with SolarWinds IP Control Bundle.

Blue Street TechLast KnightCommented:
Have you implemented an SSO ByPass Group to reduce SSO Agent errors?
LockDown32OwnerAuthor Commented:
It is a very simple setup. There are two AD groups. "Full Internet" and "No Internet". All users fall in to one of these groups and the two groups and brought in to the Sonic Wall via LDAP. The users are brought in to the Sonic Wall through their SSO agent. So yesterday a user by the name of tdragoo couldn't get internet. As it turns out she did not authenticate via the SSO agent so the SonicWall had no idea who she was or what group she belonged to hence no internet. Always something going on along these lines.

   Then..... I call in one week with and issue. The tech says to allow everything in the Default CFS Policy. Still issues so I call in again and this tech says "oh... the previous tech told you wrong. You have to block everything in the Default CFS Policy". Still issues so I call in again and guess what? Right back to "the previous tech told you wrong. Allow everything in the Default CFS Policy". I kind of jumped his at that point and told him he damn well better be sure. He put me on hold and came back and apologized. He was incorrect. So I can't tell you how many time this has happened. Just spinning my wheels being told different things every time I call in.

   I told them it isn't rocked science. If they belong to "Full Inter" they get it all. If they belong to "No Internet" they get nothing. I just can't believe the amount of time I have to spends on the phone the them.

   It has to be approach EOL. It is a TZ205. Services expire April of 2018. Maybe time to move up to a more supported model?
LockDown32OwnerAuthor Commented:
Sorry. I missed your previous. "SSO Bypass Group"? Do you mean if all my users are between 100-200 (IP) to exclude (1-99) and (200-254) from being scanned by the SSO Agent? Yes...
Blue Street TechLast KnightCommented:
I see...that help clarify things for me. I will try to address each of your points:
So yesterday a user ... couldn't get internet. As it turns out she did not authenticate via the SSO agent so the SonicWall had no idea who she was or what group she belonged to hence no internet.
This is the default behavior meaning if a user doesn't login to Windows with their username (e.g. they login anonymously or under another username that has no group) they will not gain access to the Internet based on the Principal of Least Privilege. To clarify did she not authenticate or did the SSO agent fail? The way you worded it seems that "...she did not authenticate...".

The tech says to allow everything in the Default CFS Policy.
Unequivocally, your default CFS policy should be the most restrictive (block all) for the least privileged users (for everyone). The proof and reason behind this is that "Allows" always win using "OR" logical statements which is how SonicWALL processes and determines what wins when a user has multiple CFS policies. Furthermore, if you set the Default CFS policy to allow all; there is no way to block anything. SonicWALL and all good security relies on the Principal of Least Privilege method of access so this means if a user doesn't end up in a group for whatever reason, isn't part of a group (rogue or otherwise) or a service on a port is not defined the action is blocked...that function is a security Best Practice. So, in your case when you actually defined a group to allow everything the Principal of Least Privilege model is already broken because it means that the least privilege or default has access to everything when in fact it should have no access until authenticated. Now in terms of security no user should ever be in an actual "everything allowed" state because even the least restrictive group should still have the following categories blocked:
28. Hacking/Proxy Avoidance Systems
54. Advertisement (optionally, but for data privacy - required)
59. Malware
60. Radicalization and Extremism (in most cases)

I told them it isn't rocked science. If they belong to "Full Inter" they get it all. If they belong to "No Internet" they get nothing. I just can't believe the amount of time I have to spends on the phone the them.
Your setup seems very black/white so I completely understand your frustration and eagerness to reduce if not remove your support call volume/time on this aspect. CFS is one of the worst aspects of security IMO because it typically interjects, falsely, the idea that the company or IT are taking a moral position when in fact CFS is not about morals at all; its about productivity (which could be a part of company ethics but not morals) and security. This falsehood pretense seems to enrage users more so than if they can't access something for a seemingly "technical" reason. Also, most of the time they report ambiguously like "I can't use the internet" when they can but one or two sites are being blocked, etc.

So the root of the issue sounds like an SSO agent one. Windows firewall, endpoint AV and local services failing to run can block SSO queries from communicating from he SSO agent and the user machine. Where is the SSO agent, e.g. on a DC on a designated server, etc? I would put out a GPO specifically for SonicWALL SSO, if you haven't already, that makes sure NETAPI or WMI (depending on which you are using to query) services are running, file & print sharing is enabled, overrides for local firewall rules allowing access to the required services, etc. This would service as your override for SSO so that in the event a machine has exceptions the override takes care of them.

How are you currently probing the users? When the SSO agent attempts to identify a user in a Windows domain, if the agent uses NetAPI or WMI then that tries to communicate directly with the user's PC from which the traffic is originating. This can cause problems when traffic is coming from non-Windows devices that do not respond to these Windows messages, or with Windows PCs if personal firewalls on them are blocking it. The result can be that the agent may get overloaded with multiple threads waiting for requests that are not getting replied to.

Enabling Probe users for either NetAPI over NetBIOS, NetAPI over TCP, or WMI (and selecting the correct NetAPI/WMI protocol that the SSO agent is configured to use) can avoid these problems. Before sending a request to the agent to identify a user via NetAPI or WMI, SonicWALL will probe the machine from which the traffic originated to check if it responds on the port used by the NetAPI or WMI protocol. If it does not then the device will fail SSO immediately without the agent getting involved. However, this setting will not affect an agent that reads user login information from the domain controller/s. NetAPI will provide faster, though possibly slightly less accurate, performance and WMI will provide slower, though possibly more accurate, performance.

CFS Policies by IP Address Range Option

I don't know how your DHCP/IP Pooling schema is setup in relation to your CFS Groups and how you are determining if a user ends up in a particular CFS group (allow/deny all) or not but if you can't get this SSO issue resolved you may consider implementing CFS via Users & Zones and assigning CFS Policies by IP Address Range. You could essential have two ranges for both policies and as long as they are in the specified range it would simplify your CFS issues thereby removing your SSO altogether. Just a thought.

Sorry. I missed your previous. "SSO Bypass Group"? Do you mean if all my users are between 100-200 (IP) to exclude (1-99) and (200-254) from being scanned by the SSO Agent? Yes...
Yes, assuming non-user devices, IP phones, servers, etc are included in the IPs being excluded, but you should also be including traffic from particular users such as Windows Service Users: IUSR_* and IWAM_* in the bypass as well. Also add Local User under the SSO Agent (Action > Windows Service Users). I'd recommend checking Log user name as Unknown (SSO Bypassed) for SSO bypass under SSO > Enforcement in the SonicWALL that way during troubleshooting the logs will show this for all SSO bypassed traffic and you can more easily dismiss via sorting, etc.

I hope this helps!
LockDown32OwnerAuthor Commented:
When someone or something does not authenticate it inherits the Default CFS Policy which blocks everything. All I can tell you is that she did not show up in the list of users.

   The problem support had was exactly as you pointed out. Users have multiple CFS policies and they kept going back and forth between "the first block it hits it quits processing and is blocked" and "the first allow it hits it quits processing and is allowed". I couldn't believe it to a week and four techs to finally come up with concurrency. So the policies are set right at this point. The CFS Default Policy is block everything.

   The SSO agent is on the one and only DC. The AV does not have a firewall (it does but it is disabled). The Windows Firewall is in effect but they never went through the ports I needed to open.

   The CFS Policies are assigned by group membership. The DHCP range is 100-200 but also includes cell phones which won't authenticate. There are only 30 computers so static IPing wouldn't be a big deal but that would only allow me to search a smaller SSO range wouldn't it?
Blue Street TechLast KnightCommented:
It is vital for devices who do not require user authentication via SSO such as: Macs, iPads, Printers, IP Phones, and Smartphones or Servers that do not run with an AD logged in user. By excluding these devices you will significantly reduces errors due to congestion and agent not responding issues. In addition, to the service users previously mentioned above, usernames used by Windows services such as video card software, e.g. NVIDIA's Update, can cause issues and need to be bypassed from SSO agent.

The SSO agent should not be installed on the AD server but rather its own server preferably. The SSO agent may not respond to the SonicWALL query for information on the IP because typically AD has to process other requests and can lead to performance issues. If you are receiving a specific Agent did not respond error you may want to consider adding another SSO Agent depending on the amount of users being queried for SSO Authentication.

If you can specify the exact error in the Logs or TSR report of the SonicWALL that would greatly help me pinpoint the issue. Here is an overview of common errors in the meantime. Typically, most errors are related to what I have mentioned previously:
  • Local ports* being blocked by Windows Firewall, Defender, Antivirus, 3rd party apps or anything else;
  • File & Print Sharing being disabled;
  • The SSO agent service not running under Domain Admin or not having Admin Rights - this an occur when not configured correctly or if configured correctly but the password expires.

*Local ports that need to be opened on all machines where SSO is desired should be as follows:
NetAPI Ports = 139445
WMI = 1351726
SSO Agent Default Port = 2258
TSA Agent Default Port = 2259

Let me know if you have any other questions or if you find out the specific errors.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Blue Street TechLast KnightCommented:
Did that make sense with regards to the exclusions? Any other questions?
LockDown32OwnerAuthor Commented:
Thanks Blue Streak Tech. I had the right ports open and everything was configured properly. I don't have much choice. The SSO agent must be run on the AD. It is the only computer they have that is up 24/7. I think what was missing was the SSO Exclude Range. I had to go back and static IP all the workstations but right now the ones that need authentication are grouped together in a tight little 40 IP range. Thanks for all your help!
Blue Street TechLast KnightCommented:
You're pleasure!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.