About dyang

Hi Sly, Thanks for your question.  You can see the default list of content types we use for container page logging by going to Device-->Setup-->Content-ID-->Content-ID Features-->Container Pages If you would like to generate logs for other content types, then you can create your own container page profile and add the content-types that you'd like to log.  Please note that if no other profile is specified and you have "log container page only", then it will use the default profile.  If you've created your own container page profile, then we will use that instead.  Alternatively, you can also uncheck the "log container page only", which means that you will log everything.  The impact here is obviously more logs, which could mean that you hit your log quota faster, and also potentially place a greater load on the device.  Given the number of page elements websites load these days, the recommendation is to add the content types of interest so that you're not flooded with logs. Hope this helps, Doris ... View more

Hi Brinkman, You can use a URL filtering profile, but you can only use the allow/block list and custom category portion of a profile - you cannot use any of the categories that are provided to you without a URL filtering license. --Doris ... View more

Hi everyone, If you are only using custom categories or the allow/block list, you can do this without having a URL filtering license.  The "test url" CLI command queries the cloud and the on-device database for a URL category, which means that you must have a URL filtering license in order to use that command.  So for Brinkman's case where he's only using the custom category, this CLI command is not applicable.  Brinkman, when you created your custom category, did you also attach it to a URL filtering object and attach that to your security policy?  From your description, it sounds like there's no URL filtering profile that's getting applied with the block. --Doris ... View more

panos, You mentioned that subsequent visits to the same URL when URL filtering is disabled does not present a delay.  What about if you revisit the same URL when URL filtering is still enabled? In other words, visit URL, get delay visit same URL -->delay? If you're only getting a delay in loading the page the first time you visit the URL, it could simply be due to the fact that the device is reaching out to the BrightCloud servers for a categorization.  The second time you go to the URL, the category should be cached in your DP, so the response should be much faster.  That said, by default, we only wait 5 seconds for a response.  Your delay should not be 30 seconds. ... View more

JValentine is correct.  When you use a URL category in your security rule (as opposed to a URL filtering profile), the only actions you have are allow or block.  So if you want to log and/or use a custom response page (block page, continue page, override), you will need to use a URL filtering profile. ... View more

Hi Edwin, I'm not sure where you're seeing the category "Symantec" with BrightCloud.  I just did a category lookup on the BrightCloud website and it comes up as malware: Webroot, Inc. --Doris ... View more

Hi sebbarmo, Unfortunately, that is a coverage/accuracy issue with the BrightCloud database itself.  Submitting the change requests to BrightCloud should help, but given that you are submitting multiple requests per day, please note that you can also submit a list of URLs to dbchange@brightcloud.com in lieu of submitting them individually via the website. If you'd like to have a more in-depth discussion regarding BrightCloud quality issues, please contact your SE so that we can set that up. Thanks, Doris ... View more

Hi Mike, Yes, "not-resolved" means the same thing in both BrightCloud and PAN-DB.  If you see this category come up, it means that there was either an issue connecting to the server (BrightCloud or PAN-DB), or that your MP may have been overloaded at the time and the DP exceeded the default waiting period (5 seconds) for an answer back from the MP. --Doris ... View more

Vincent is correct - by default, we wait 5 seconds for an answer from the cloud.  If we do not receive an answer back within that time, we will categorize the URL as category "not-resolved" and apply policy accordingly.  Assuming that an answer does come back after that 5 second period, the cache will update with the answer, so the next time you visit the site you will get the correct category, which is what you saw.  There are generally two scenarios in which you could get the "not-resolved" category.  Obviously if the BrightCloud servers are down, then you will not get an answer.  The second scenario is if your MP is currently overloaded and the requests are queued up.  ... View more

That is correct!  Enable dynamic url filtering in the URL filtering profile, and this should address your problem.  As an FYI, while this is a per profile setting, there is also a global setting if you would like to apply this to all URL filtering profiles on your device.  To do this, use the CLI command, " set deviceconfig setting url dynamic-url yes" --Doris ... View more

Hi sebbarmo, The "dynamic URL filtering" setting basically dictates whether or not you want your device to query the master database in the cloud for an answer, should there be a miss on the device cache and on-device database.  Given that you did not enable this setting, it makes sense that your "test url" output only returned an answer from the dynamic database. That said, if you actually use a browser to go to www.intaircoat.com do your logs show category "unknown" while the test url results show category "society"?  There shouldn't be a mismatch there. --Doris ... View more