View Full Version : How can I tell what database revision of a policy is on a gateway

2014-10-10, 11:40
I know cpstat fw -f policy will tell me the policy name installed on a gateway but how can I tell the database revision of the policy? I am having a problem due to sk86961 and having to rebuild a gateway which had a failed disk at the same time, I can fetch the policy on the second node of the cluster after it was rebuilt but would like to check it's the same version as the primary node currently. (I can't push the policy currently, a maintenance window has been agreed for next Tuesday).

R75.4 IPSO

Thanks in advance,


2014-10-10, 14:37
If you have the SmartWorkflow blade for your Security Management Server you can compare the running policy on the Security Gateway with the one displayed in the SmartDashboard. So you would:

1. Take a revision of your current config
2. Restore the revision you suspect is loaded on the gateway
3. Click Install Policy, then in the Install Policy dialog popup window hit the "Compare Policies" button. (if you don't have the SmartWorkflow blade this button will not appear).
4. If the comparison report shows no differences, the revision you are currently looking at is the same as the one loaded on the gateway.
5. If any changes are noted in the report that revision isn't the one currently loaded on the gateway, try restoring another candidate revision and go back to step 3.
6. Restore the revision you took in step 1 to get back where you started.

I believe you are able to enable SmartWorkflow for a limited trial period on the later releases without having to use a demo license, if you do this to gain the Compare Policies functionality be sure to select the first option "Use SmartWorkflow for visual change tracking" instead of the latter option "Use SmartWorkflow to track, review and require approval for changes" which will start enforcing full change control and confuse the heck out of you unless you understand how SmartWorkflow operates.

2014-12-22, 12:20
Thanks for your reply but it wasn't what I was looking for. According to Check Point, there is currently no way to find out the actual Database Revision of a policy.

2014-12-23, 15:34
While I hope you've resolved the initial problem by now, I think there may be a simpler solution (should the problem occur again, or someone else search this thread in the future).
- You should be able to copy the running policy from the active cluster member to the one you're having trouble with. All you should need is the contents of the folder $FWDIR/state/local/FW1

That said, I think your mention of database revision brings up an interesting topic. I wouldn't expect the "revision" data/version to be contained anywhere within the database or policy, since the revision is basically a form of backup taken outside of the policies themselves. In fact, the database and policies would have no idea whether they're available in a revision or not. It would be completely possible for a policy to be installed on a gateway, revisions created and deleted (without reinstalling that particular policy on that particular gateway), and the policy on that gateway still be active "under" a revision that no longer exists.

Not to excuse the lack of this working for you (but rather to try and understand it), remember that the feature is called "Database Revision Control" and not "Policy Revision Control" (even though a revision does contain a copy of every policy). Each policy should really only have a single active "version" that is installed on all targets of that policy. If you are regularly making changes that are installed only on individual gateways or clusters, you should consider having individual policies. If that's not possible (for any number of reasons), you could consider using "save as" and giving each policy revision a unique name, maybe containing date stamp. This would allow you to identify the currently active revision by the installed policy name. Keep in mind, however, that maintaining a large number of policies (especially once they're outdated) can be space-consuming, especially since every policy is contained in every database revision. Make sure you clean both out regularly.

Just wanted to mention a few ideas that came up while catching up on this thread. I know there are very subjective reasons for using features in different ways, and they're in no way invalid. However, when we try and use a feature outside of its intended purpose, it may not work the way we hope.