Problem accessing some websites even with them added to CFS allowed domains
12/20/2019 901 32433
This is a scenario based article based on a customer case. In this scenario, customer is unable to access Google maps by entering maps.google.com in the browser.User was able to determine the cause as Content Filter Service (CFS) - there were the block message of CFS but some websites failed without displaying them. The logs had website access denied or website blocked messages.
NOTE: In absence of an explicit block message from CFS, the first place to look for when website access fails is the SonicWall Logs. Here, there would be messages indicating the plausible cause of the failure. If the cause is CFS, the logs would generate Website Access Denied or Website Blocked messages. Here is an example of log messages indicating a website was blocked.
- Click Investigate in the top navigation menu.
- Click Event Logs.
The messages are different for different features.
EXAMPLE: IPS, GAV, App Control or App Rules will indicate explicitly the feature which did the blocking.
Depending on how Log Monitor has been configured to display messages, CFS log messages will display among other information the blocked URL and the CFS category. In the case of maps.google.com, the page returned a block page like this.
From the above block message, we can know the category (Search Engines and Portals) and the URL (http://www.google.com/maps) being blocked.
NOTE: In the some cases, when a webpage fails to load without a CFS block page, the cause could be a link within the page being blocked by CFS. In such cases, the URL in the CFS log message will not be the same as the one being accessed.
Now that the proximate cause was determined to be CFS, the next step was to find out the CFS setting which caused the failure.
This was the customer's CFS configuration:
- Customer was using CFS via Users and Zones.
- Customer had one CFS policy - the Default - configured with the following categories blocked.
2. Intimate Apparel/Swimsuit
6. Adult/Mature Content
8. Drugs/Illegal Drugs
9. Illegal Skills/Questionable Skills
10. Sex Education
13. Chat/Instant Messaging (IM)
15. Business and Economy
16. Abortion/Advocacy Groups
25. Political/Advocacy Groups
|28. Hacking/Proxy Avoidance Systems|
29. Search Engines and Portals
31. Web Communications
32. Job Search
34. Personals and Dating
35. Usenet News Groups
It is clear from this configuration that the category Search Engines and Portal (maps.google.com falls under this category) is enabled for blocking. But maps.google.com (which is what the user entered in the browser) is allowed under the allowed domains.
Unchecking or allowing the Search Engines and Portals category was not an acceptable solution. When going to Google Maps the page is redirected to google.com/maps. The block page URL had already indicated this. But, CFS currently does not have a mechanism to allow or block URLs. Therefore, to allow google.com/maps one must allow google.com in the allowed domains. This will entail allowing other Google Apps. The user could block other Google Apps individually but this would still mean allowing google.com - the search engine.
In conclusion, this solution, albeit limited, was the only way to allow Google Maps when using CFS with the Search Engines and Portals category blocked.