Problem accessing some websites even with them added to CFS allowed domains
07/27/2022 1,019 People found this article helpful 477,700 Views
Description
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.
Resolution
Resolution for SonicOS 7.X
This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.
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.
- Navigate to Device|Log|settings
- Select logging level to Inform and alert level to Alert as shown in the below screen
- Click Monitor in the top navigation menu.
- Select Logs|system Logs
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.
- 1. Violence/Hate/Racism
2. Intimate Apparel/Swimsuit
3. Nudism
4. Pornography
5. Weapons
6. Adult/Mature Content
7. Cult/Occult
8. Drugs/Illegal Drugs
9. Illegal Skills/Questionable Skills
10. Sex Education11. Gambling
12. Alcohol/Tobacco
13. Chat/Instant Messaging (IM)
14. Arts/Entertainment
15. Business and Economy
16. Abortion/Advocacy Groups
17. Education
22. Games
24. Military
25. Political/Advocacy Groups28. Hacking/Proxy Avoidance Systems
29. Search Engines and Portals
30. E-Mail
31. Web Communications
32. Job Search
34. Personals and Dating
35. Usenet News Groups
36. Reference
37. Religion
38. Shopping - 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.
Resolution for SonicOS 6.5
This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.
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.
- Goto Manage|Log settings|Base setup
- Select logging level to Inform and alert level to Alert as shown in the below screen
- 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.
1. Violence/Hate/Racism 2. Intimate Apparel/Swimsuit 3. Nudism 4. Pornography 5. Weapons 6. Adult/Mature Content 7. Cult/Occult 8. Drugs/Illegal Drugs 9. Illegal Skills/Questionable Skills 10. Sex Education | 11. Gambling 12. Alcohol/Tobacco 13. Chat/Instant Messaging (IM) 14. Arts/Entertainment 15. Business and Economy 16. Abortion/Advocacy Groups 17. Education 22. Games 24. Military 25. Political/Advocacy Groups | 28. Hacking/Proxy Avoidance Systems 29. Search Engines and Portals 30. E-Mail 31. Web Communications 32. Job Search 34. Personals and Dating 35. Usenet News Groups 36. Reference 37. Religion 38. Shopping |
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.
Related Articles
Categories
Was This Article Helpful?
YESNO