topic Blades URL Filtering and Application Control "Not Responding" ?!... in Firewall and Security Management

Blades URL Filtering and Application Control "Not Responding" ?!...

dipisitrese — Fri, 18 Feb 2022 15:38:38 GMT

Hello all,

Blades "URL Filtering" and "Application Control" are seen as "Not Responding" from our SmartConsole.
However, these two Blades have their Licenses active and not expired.

Could it be a cosmetic display issue? How can I be sure that the Blades continue to work?

Thanks a lot.

_____________

Technical infos :

Product version Check Point Gaia R81.10
OS build 335
OS kernel version 3.10.0-957.21.3cpx86_64
OS edition 64-bit

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

Chris_Atkinson — Fri, 18 Feb 2022 15:48:13 GMT

With reference to sk111944 has the machine been restarted recently?

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

dipisitrese — Fri, 18 Feb 2022 15:52:52 GMT

Yes, one week ago.
The solution could be in the SK111944 ?

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

Chris_Atkinson — Fri, 18 Feb 2022 15:56:47 GMT

Check the file contents as listed in the SK. If it looks ok and the problem persists with the latest JHF installed please contact TAC to investigate further.

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

dipisitrese — Fri, 18 Feb 2022 16:05:39 GMT

Indeed we already provided to our Support-Registred the content of this file and we are waiting for a feedback...

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

dipisitrese — Fri, 18 Feb 2022 16:06:54 GMT

(
:status (0)
:status_short_desc ()
:status_long_desc ()
:app_update_status (up-to-date)
:app_update_description ("Gateway is up to date. Database version: 31012201.")
:app_next_update_description ("The next update will be run as scheduled.")
:app_db_version (31012201)
:urlf_status_code (0)
:urlf_status_short_description ()
:urlf_status_long_description ()
:appi_rad_status_code (0)
:appi_rad_status_description ("Application Control Engine is up and running")
:urlf_rad_status_code (0)
:urlf_rad_status_description ("URL Filtering engine is up and running")
:app_subscription_expiration_date ("Sun Dec 31 00:00:00 2023")
:app_subscription_status (valid)
:app_subscription_description ("Contract is up to date.")
:urlf_subscription_expiration_date ("Sun Dec 31 00:00:00 2023")
:urlf_subscription_status (valid)
:urlf_subscription_description ("Contract is up to date.")

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

dipisitrese — Fri, 18 Feb 2022 16:08:19 GMT

Is it a positive false ?...

The Blades continue to work despite of the warning on the SmartConsole ??

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

Juan_ — Fri, 18 Feb 2022 16:31:55 GMT

Yeah mate it keeps working.

Just check the logs:
blade:"URL Filtering" or blade:"Application Control"

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

the_rock — Fri, 18 Feb 2022 17:35:39 GMT

It could be false positive, but I would do what was suggested by @Chris_Atkinson and @Juan_

Re: Blades URL Filtering and Application Control "Not Responding" ?!...

Timothy_Hall — Sat, 19 Feb 2022 00:32:20 GMT

Probably just a cosmetic issue, but restarting all services as it says in sk111944 to resolve it is a bit of a blunt force instrument.

Generally when you are retrieving status from a gateway, the updates are provided by the cpd daemon on the gateway. If that daemon is having issues it may log something into $CPDIR/log/cpd.elg that is helpful. However I have seen restarting just the cpd daemon on the gateway clear a number of status issues (and doing so will not cause an outage). Obviously this is not a long-term solution but can help identify where the problem is located.

There is also a daemon called cpstat_monitor but I believe that one is just for the advanced Traffic/System Counters reports provided by the monitoring blade and not for general status.

Finally there are a number of status databases maintained by cpd that can get corrupted in various ways (such as the SMS running out of disk space) causing strange status behavior. The primary indicator of this condition is high CPU utilization by cpd or it occasionally crashing. See these SKs:

sk101484: CPD is consuming high CPU utilization (>90%) or CPD is terminated on the Security Gateway

sk109940: CPD daemon consumes CPU at high level and exits periodically.