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.
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
CFS Custom List had the following websites allowed:
HTTPS content filtering was enabled.
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.