messages log error for https inspection

[Chris_Hoff]

Hello,

Has anyone ever seen in their /var/log/messages file the following:

[ERROR]: nrb_rb_https_inspection_get_possible_blades: rulebase structure is corrupt   (null)

I am seeing these at the kernel on different firewall workers, and will usually have a connection from an internal IP to an external IP on either port 80 or 443 associated with the line. 

Wondering if anyone else has ran into this, and if there was a fix. This is in an R80.40 with JHFA 118. 

[the_rock]

I actually remember customer contacting me about this exact message and TAC said to install jumbo 120 and they went away after that. I never really got an explanation what those messages even mean, which would have been nice. O well 🙂

[James_Moler]

We're on R80.40 T125 and seeing these messages. 120 has some CPU issues with processes spinning out of control so we went to 125.

[_Val_]

Please take it with TAC.

[kbleb]

Also seeing on T125. It is associated with connectivity issues. We also see a lot of logs with https action of "error" and users get "site not responding"

[the_rock]

Hm...maybe my customer got lucky in their case, but I agree with you. It definitely appears it would be a bigger connectivity issue, for sure.

[kbleb]

In our case, these errors were concurrent with smartlog message "Internal system error in HTTPS Inspection due to categorization service error". Sometimes it would be the exact same source & destinations, other times the timing would be the same down to the second, but the src/dest would be different. Sometimes I also had /var/log/messages entries about corrupt https inspection policy for DNS traffic from VPN users to internal DNS (?).

TAC was telling me the https inspection policy must be corrupt, even though we hadn't changed anything and hey how can it be corrupt for one second every so many minutes, and not corrupt one second later, and how can setting categorization mode to background "uncorrupt" the https inspection policy?

Today I found new sk176925 about the related error which has cause: "Timeout occurs because the values configured in the $FWDIR/conf/rad_conf.C file on the Security Gateway do not match the environment."

I found we are indeed seeing the timeout errors mentioned in that SK so I will try out the settings.

Since we made no changes when this started on December 1st, and the issue is intermittent from second to second even, I am reading "timeouts do not match the environment" to mean "Checkpoint's categorization service is slow" and the solution will mask the fact that the service is slow, and if we put things back to "hold" mode then user experience will be however slow the categorization service is the first time someone in the org visits a particular website.