can't install ThreatPrevention policy after hardware replacement

[Wolfgang]

Recently we changed the hardware of one node in VSX VSLS-Cluster. Following a hardware failure we had to replace the node.
Because there are no changes to VSX-configuration we restored the node from backup. Everything was fine except the installation
of the ThreatPrevention Policy on this node. Installation failed with the following error message:

Gateway: VSX-NODE02 Policy: My_policy Status: Failed - Policy installation failed on the gateway. If the problem persists, contact Check Point support (Info: , <2ba958b0-419f-4154-844d-e12436eb9459>)

TAC case is open and after some remote sessions and debugs we're advised to recover the node via vsx_util reconfigure. We discussed this more then once and followed. But the issue is still the same. Threat prevention policy does not install on this node with the same error.

Any ideas what's going wrong?

[Timothy_Hall]

Sometimes there is the need to reinstall the Access Control policy first after major changes are made to Threat Prevention, and this will cause the TP policy installation to fail.  But there is a different message to that effect when that occurs which does not match your situation.

The "Policy installation failed on the gateway" message just means that the policy was successfully transferred to the gateway, but when it attempted to actually apply it to the INSPECT engine an error occurred.  Generally you will need to start a debug on the gateway and then have it try to reinstall the policy by running the fw amw fetch local command.  In my experience this type of failure is caused by the following:

1) Resource shortage on the gateway, usually memory but could be disk space, this failure will tend to come and go

2) There is an error in the compiled TP policy (duplicate reference, syntax error, etc.) that should have been caught by the SMS but was not due to something bizarre in your configuration or a bug in the SMS code generation itself.  The gateway will do a quick sanity check of the policy it is about to install, if it sees something wrong it will abort the policy load to INSPECT with this error.  The gateway debug can help find what this issue is, I believe the needed debug flag is "policy".

3) Bug in the policy loading code on the gateway (not common).

A workaround I've seen fix this is unchecking all TP blades on the gateway, reinstalling AP/TP policies, then re-enabling the TP blades you are using one by one in the following order, with an AC/TP policy reinstall between each one, which will sometimes refresh and shake loose whatever is causing the error:

1) IPS

2) AV

3) AB

4) TX

5) TE

[Wolfgang]

Hello @Timothy_Hall 

we disabled all TP-blades, did a policy install and enabled again one TP-blade, install both policies access and TP.

Results are the same error messages.

We had no ressource problem on the gateway, memory is fine.

[Timothy_Hall]

Bummer, must be an error in the compiled TP policy that the SMS created and the gateway is catching in its sanity check prior to loading it.  TAC will have to run a debug to figure it out.

[Miktator]

Was it solved? I have the same error

[Wolfgang]

@Miktator we had to modify all tp_conf.json files.

$FWDIR/conf/tp_conf.json
$FWDIR/CTX/CTX00001/conf/tp_conf.json
$FWDIR/CTX/CTX00002/conf/tp_conf.json.......

[Miktator]

Can you tell me what changes you made?

[Wolfgang]

@Miktator no, I can‘t provide the solution here, the rules does not allow these. I‘ll sent a PM to you with the SR number. Open a TAC case and reference the mentioned SR.

[StackCap43382]

Hi

Can you send over the SR to me as well please.

The character string is slightly different but cant push threat prevention policy after partial rebuild. 

Cheers

[Miktator]

Wolfgang  SR was 6-0003060624 and  mine was 6-0003323669.

Of course the vendor's solution helped us, but unfortunately we still had to do a clean installation on the gateway.
I asked the Vendor Engineer to create a knowledge base article on this problem, but I couldn't find it, so here is the solution:
1. Backup the original "tp_conf.json" file on the Gateway -
# mv $FWDIR/conf/tp_conf.json /var/tmp/tp_conf.json.backup
2. Place the provided file in #$FWDIR/conf/
3. Reboot the Gateway.

[StackCap43382]

Thanks!

Have forwarded to TAC, hopefully it helps them. 

[StackCap43382]

So tac shot this down as our (UID?) does not match but the symptoms are the same: (Info: <8e5cebdd-1cc0-40d4-9639-69a52904f3b3>) 

So at this point if you are googling this error code and not finding an SK this is related to the TP policy we just don't have a fix yet. 

Waiting for R&D. 

[StackCap43382]

So the end result was a rebuild of the firewall using ISOM.

GW back up and running.