R81.20 Error when rebooting gateway

[BorisL]

Hello.

We are experiencing the strangest behaviour.

When we reboot the FW, we see in the startup messages that when the local rule base is to be loaded we get the message that file /opt/CPsuite-R81.20/fw1/state/local/FW1/local.ifs is not found.

In exploring the /opt/CPsuite-R81.20/fw1/state/local/FW1/ directory, we see that the only content is another FW1 directory

/opt/CPsuite-R81.20/fw1/state/local/FW1/FW1, which contains all the files.

Then have to copy all the contents of the latter to /opt/CPsuite-R81.20/fw1/state/local/FW1/ and upon reboot, the firewall starts normally.

Can anybody explain what could be happening here and how to solve it?

BR.

Boris

[the_rock]

Cant recall ever seeing that message. Will check in the lab shortly in regards to that file. Was this always there or you just noticed it recently?

Andy

[BorisL]

Hi Andy,

It has happened twice.

We first got erros installing the policy. We had to supress the fast update to get the install to work. Then, when we rebooted the FW, we got that message and discovered that the FW1 files were not where they were supposed to be and copied them back to /opt/CPsuite-R81.20/fw1/state/local/FW1/.

Very strange indeed how that directory got copied one level below where it should be.

[the_rock]

Just checked one of my lab boxes and below is what I see. Now, on another lab appliance, also R81.20, works 100% fine, I do NOT see this file and though I just rebooted that VM, no unusual messages. Might be worth check with TAC?

For the context, BOTH are on R81.20 jumbo 84, as I always install latest jumbo fix in my lab the day it comes out.

Andy

[Expert@CP-GW:0]# cd /opt/CPsuite-R81.20/fw1/state/local/FW1
[Expert@CP-GW:0]# more local.ifs
R81.20-CP-LAB-POLICY
[Expert@CP-GW:0]#

[BorisL]

We have Open Server (VSEC on  AWS instance). Not an appliance.

[Expert@FW_AMZ_ES_INT_R81_20:0]# cd /opt/CPsuite-R81.20/fw1/state/local/FW1
[Expert@FW_AMZ_ES_INT_R81_20:0]# more local.ifs
Standard

[the_rock]

Same here, no appliance in the lab, just eve-ng. But regardless, it would show same on the physical box too. Its simply name of the policy installed.

Andy

[BorisL]

What I am saying is that at reboot, the directory was empty. Only one subdirectory also called FW1 with all the files.

[the_rock]

Same here on one of my fws, but I never see those logs.

Andy

[PhoneBoy]

If you push policy to the gateway again, does the problem come back? (I.e. does the policy get loaded in $FWDIR/state/local/FW1/FW1)

[BorisL]

We have been working normally with the FW until a policy install fails with an error. (I did not recall the exact text of the error). To make further policy installs after the error we have to do it turning off Policy Acceleration.

So I guess I would have to wait until we get a  new error and then check $FWDIR/state/local/FW1.  

[the_rock]

Wait...you are saying all is fine if you turn off acceleration before policy install?

Andy

[BorisL]

Yes. Disabling acceleration avoids the error in policy installation.

We found this: https://support.checkpoint.com/results/sk/sk180414 

I agree that the deletion or misplacement of the files in $FWDIR/state/local/FW1/ FW1 is a bug.

The problem is that we do not have the time or resources to investigate bugs with TAC. As I have said before in this community, with all due respect,  I beleive that TAC should investigate bugs without burdening customers. And, as the SK I just mentioned says, it seems to be a known bug.

[the_rock]

I agree with you 100%.

Andy

[the_rock]

I will add I never had to disable acceleration when pushing policy in R81.20. Once or twice in R81.10 though.

Andy

[PhoneBoy]

While it's clear there's an issue with Accelerated Policy Installation, the symptoms you describe are a bit different from the SK and the related TAC case, which are specific to Multi-Domain and certain files not being pushed during policy install.
While your issue has a similar workaround (disable Accelerated Policy Installation), the underlying issue is likely different.

[PhoneBoy]

That definitely sounds like a bug.
I assume TAC is involved?