- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Installing Policies on an HA cluster one member at...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Installing Policies on an HA cluster one member at a time
We have some soon-to-be-replaced 23000 gateways running r80.40 take 211 in a cluster. In the last few months it has become increasingly difficult to install policy updates on the firewalls with typically the active member of the cluster failing to install the policy and therefore the whole installation fails. I have tried failing over onto the standby and pushing policy and again it will still fail on the new active firewall.
Is a temporary tactic to uncheck the box 'For gateway clusters, if installation on a cluster member fails, do not install on that cluster' and have the install succeed on the standby member, then failover to the standby member, then push the policy again and this time it should then succeed on the new standby firewall? Thereby the new policy is installed on both firewalls.
We have the new firewalls in place and are being built by Checkpoint PS, but with the Christmas change freeze about to start we are not in a position to start using the new firewalls before Jan but we need to make minor changes to the policy.
- Labels:
-
ClusterXL
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you can do this, yes.
Note this is something that ElasticXL "fixes" insofar as policy installation happens to the SMO only, which is responsible for copying the policy to the other members.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you can do this, yes.
Note this is something that ElasticXL "fixes" insofar as policy installation happens to the SMO only, which is responsible for copying the policy to the other members.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Accepting this as it was the first response. I have now tried the method and it worked. I think the two firewalls had different policies for less than 10 minutes.
I will look into the other methods listed here as well. I think though as it is an old setup about to be pulled out I dont really want to start trying out something new, but something to look into for the new environment should there be similar issues.
Thank you all for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is indeed a workaround for this issue
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What about doing fw fetch -m individually on cluster members? If I recall correctly, it pulls the policy from the server that is defined in masters file and writes it to kernel individually. But I'm not sure about the sync between members after that point. Maybe someone can add to it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Indeed fw fetch <Security Management Server name> will also work:
Seems the -c flag also allows to fetch policy from a Cluster member
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hypothetically, let's say that I did it with -m flag and forgot to do the same on the other member. Will the policies ever get synced between members, or do I need to come back and do a -c anyway?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not sure you even need the -m flag
But yes, you can either fetch the policy (on the other cluster member) directly from the Security Management Server or from the other cluster using -c
