SIC re-establishment for VSX cluster after SMS migration from R81.20 to R82

[abutayyab]

Hello Everyone,

I have a Check Point VSX VSLS cluster running R81.20 (JHF 119). I also have a Check Point Security Management Server running R81.20 (JHF 119), deployed as an EC2 instance on AWS, which manages the VSX cluster members as well as virtual systems.

I am planning to upgrade the Security Management Server from R81.20 to R82. My approach is to deploy a new EC2 instance with Check Point SMS R82 (JHF 44) and import the output of migrate-server from the existing management server into this new instance. The hostname and IP address of the new management server will differ from those of the current one.

What I would like to understand is how SIC with the VSX cluster will be established after the migration. Specifically, I am unsure how the VSX gateways (and their virtual systems) will trust the new management server.

I am considering the following steps and would appreciate your feedback on whether this approach will work:

1. Set a new SIC password on the VSX cluster members using the cpconfig command.

2. Run vsx_util reconfigure from the new management server to establish SIC with the VSX cluster members and the corresponding virtual systems.

3. Install the security policy from the new management server.

Could you please confirm if this approach is valid, or suggest any recommended best practices or alternative steps for this scenario?

For safety, I have already taken snapshot backups of the Security Management Server and the VSX cluster members.

Regards,
Abdul Tayyeb R.

[Bob_Zimmerman]

Been a minute! Good to see you here!

I think you will need to use 'reset_gw' on the cluster member before you will be able to use 'vsx_util reconfigure' to reprovision that member.

Be aware there will be a hard outage. Firewalls running policies from different managements can't synchronize.

This is a lot easier if you can keep the management hostname the same. Then all you would need to do is update the management's object for itself and push policy (maybe with some 'fw unloadlocal' sprinkled in). If you know the new management's address ahead of time, building a dummy secondary management with that address and pushing policy before migrating can remove even the potential 'fw unloadlocal'.

[Wolfgang · Accepted solution]

@abutayyab do you know, there are in place upgrade packages available for SMS in AWS. You can save IP addresses and name.

In-Place Upgrade packages for CloudGuard Network

[abutayyab]

Thanks! I didn't know in place upgrades are available for Check Points running on AWS. A lot of time and effort was saved. I upgraded the Check Point to R82 successfully using this method.

[Lari_Luoma]

Hi!

It's important to understand that migrating to a new SMS with a new name and IP does not automatically invalidate the Internal Certificate Authority (ICA) certificate. The ICA certificate is tied to the original SMS configuration, and after migration, the new SMS will still retain the ICA certificate from the old SMS, including its original hostname and IP.

Because the certificate remains valid after the migration, SIC trust between the gateways and the management server does not break. However, since the IP-address of the SMS changes you'll have to add the new IP-address to the policy of before the migration.

If you want to reset the SIC on the SMS and make the ICA match the new name you'll have to run fwm sic_reset, but that will invalidate SIC for all gateways that the SMS manages. However, resetting the ICA is not mandatory unless you wan to establish a completely fresh trust or resolve specific issues.

The procedure in your post doesn't work if the VSX gateway has configuration. If you want to clean also the VSX gateway and start from scratch you can run reset_gw and then build the VSs with vsx_util reconfigure, but this is not necessary if only the SMS changes. You cannot run vsx_util reconfigure against a gateway that has configuration.

Look at this sk for instructions:
Take a look at https://support.checkpoint.com/results/sk/sk167639

If the VSs have problems establishing SIC, you can reset them one by one (follow https://support.checkpoint.com/results/sk/sk34098)

[abutayyab]

I was thinking of this approach initially, and many times I have seen reset_gw doesn't necessarily wipe out all configuration; some old VSX configuration is still there. And since this approach was very complicated, I went ahead with R82 in place upgrade. The upgrade was completed in an hour or so.