Create a Post
Showing results for 
Search instead for 
Did you mean: 

Application control/Url filtering, disabled if updates doesn't work?

Sorry if this has been answered before. I have been searching some, but I coudn't find anything.


We have intermittent problems with updates for application control/url filtering. Sometimes it works, sometimes it doesn't. Today it doesn't work, and by chance I looked in the firewall with cpstat appi.

And it doesn't show anything? status is 0.

Update status says failed. Subscription status says valid & contract up to date.

When i look at top_last_hour or top_last_day there's no info.


How do you determine if application control actually works? And does it stop working if it can't update?

5 Replies


Updates for App Control / URL Filtering are mostly app signature, url and categories updates. For example a new application may be added to the High Risk category.

Best way to know if it's working is to actually test some web pages or applications.

I think that the real deal here is to know why the updates are failing, you can check connectivity with Check Point by following this SK: 

How to verify that Security Gateway and/or Security Management Server can access Check Point servers... 




I can see application control in the logs, so I guess it's working? I guess it just can't identify the traffic that we had problems with today.

It's odd that there's no data when using cpstat though.


Connectivity is ok-ish. we have the same problem as Could not connect to "cws checkpoint com" . I.e. all tests are OK, sometimes it works, sometimes it doesn't.


We were in contact with the support and got a new database-handler-program (i think), and that helped for a short while. But then the errors returned.


Supposedly, it should work better if we update to 80.30. We're running 80.10 still.


The issue you speak off is probably due to categorization of certain URLs, the gateway has a cache for this that is periodically flushed and in some cases it's tagged as Uncategorize, this can be changed in the fail open (let the connection pass) fail close (wait for categorization). 

For application control keep in mind that you need HTTPS Inspection to get the most out of it, most of the information for these decisions are in the datagram of the packet which is encrypted when using TLS.

¿Can you post here the logs so we can check?


Application Control uses a database of signatures.  Once that database is downloaded to the gateway it can continue to be used even if the Internet is not reachable.  The only real effect is that the APCL blade won't have the latest updates and will throw an "Attention" status, and may classify some traffic as "unknown" instead of some brand-new (or recently updated) application.

On the other hand, Check Point URLF does not use a fixed categorization database that is downloaded to the gateway (this is a common misconception as many older products like Websense and SurfControl work this way), all categorizations are cloud-based via the rad process running on the gateway.  If a requested site is not listed in the urlf_cache_tbl table a lookup is sent to the cloud by rad, as categorizations are received they are stored in the urlf_cache_tbl table for up to one week.  When the response is received the user is allowed/denied access and the categorization result is added to the table. 

If you have the URL categorization handling set to "Hold" the user's connection is not allowed to proceed to an uncategorized site until a response is received from the cloud.  With this setting if there are Internet connectivity problems users will see delays or timeouts only when trying to connect to sites that are not already in the cache; the failures will look sort of random.  You can set the URLF handling to "Background" and the users will be let go before a categorization is received, but this may allow users to briefly visit sites that they shouldn't prior to the cloud categorization being returned.


New 2021 IPS/AV/ABOT Immersion Self-Guided Video Series
now available at
0 Kudos

Thanks for the detailed explanation.

I was unaware that the URLF is only cached, that's good to know. We have APPI/URLF set to background due to the intermittent connection issues.

I can conclude that it's at least working as intended, albeit not optimal.