Migrate from 5100 R82 to 3970 R82.10 gateways keeping the config

[Secret-goblin-5]

We just got the new 3970s to replace our old 5100s, I did not know the new ones are ARM chips and run on a different kernel.

I need the config from the old gateways transferred across, but as they are different versions I do not think a migrate export will work.

How do I copy the config across, not loosing things like VTI tunnels to AWS and custom local paths etc?

[Chris_Atkinson]

Migrate export / migrate server is for moving between management servers so not relevant here.

Depending on requirements a parallel build (mirroring gaia config etc) and cable swap would be typical.

[Secret-goblin-5]

How do I mirror the config?

Manually?

That can't be the actual answer!

[Lesley]

Step 3 and 4 here are the backup methods you can move from old hw to new hw. 

https://support.checkpoint.com/results/sk/sk108902

[Secret-goblin-5]

Note: A Gaia backup, unlike a Gaia snapshot, can be restored on the same or a different appliance running the same Check Point Gaia OS version and hotfixes.

The OS versions are different, will it still work?

[Vincent_Bacher]

Usually in the guides you see something like 

Note - You can only do a migration using the same Gaia version on the source and target computers.

but you may just try and see what happens when importing the backup on the new device. 😉

[Lesley]

Maybe it will work, if not, install same version / software on new unit and if import is good upgrade to desired version

[Don_Paterson · Accepted solution]

There is this SK too:

Backing up Gaia system level configuration
https://support.checkpoint.com/results/sk/sk102234

That is all about the Gaia configuration and not the Security Gateway/firewall software (Policy and SIC Certificate/Trust with the management server).

That would have to be setup again as a separate task (SIC reset and Trust established with the new appliance).

After you do the load configuration:

You can do a show configuration on the old and new systems and compare the outputs to check for differences.

Gaia gets it's config from a small config database of it's own (on the disk of the appliance ) and the configuration is stored in there.

If you see differences in the outputs they may not be valid for your specific config and only for a new R82.10 feature/s that you don't use.

Note: After running load configuration it can take a few minutes to complete the adoption of the new configuration, and I would recommend a reboot before going further. After the reboot run show configuration again to check that the new configuration loaded in successfully and is applied..

Other things to consider.

Post-Migration Tasks

• Reconfigure any hardware-specific settings (interface names may differ).
• Re-establish SIC with the Security Management Server via SmartConsole.
• Check that R82.10 is the selected version (available in the R82 SmartConsole/Server version).
• Install the security policy from management.
• Update licenses for the new hardware.

Other references:

https://support.checkpoint.com/results/sk/sk105883

"Gaia System Backup performs backup of the configuration only. Therefore, the machine of the restore should match with same model, installation parameters and hotfixes to the machine where the backup was taken. "

I believe that this is still valid (my understanding):

Gaia Backup Restore: Appliance Model and Version Compatibility

Key Limitations

Based on official Check Point documentation and support articles, Gaia backups have strict limitations regarding restore operations:

Limitation	Applies To
Restore must use the same Gaia version	All Gaia versions
Restore must use the same appliance model	All Gaia versions
Restore must use the same hotfixes/Jumbo	All Gaia versions

Important: You cannot restore a Gaia backup to a different appliance model or to a system running a different Gaia version (including different Jumbo Hotfix levels or hotfixes).

[Secret-goblin-5]

Will try this, but I cannot be the first person who has replace their Check Point hardware, surely there is a method for doing this already.

[Don_Paterson]

One thing I left out of the last reply was that you probably need to edit the text file that save configuration produces and make changes to match the new platform (interface name difference) before doing the load configuration.

You definitely are not the first. 

I'll keep looking to see if there is anything new that I have missed or don't know about but the Gaia Backup/Restore feature is specific to the appliance and is sensitive to the software versions.

Will share anything significant in here.

[Vincent_Bacher]

As a pragmatic person, in such a case, instead of putting a lot of effort into experiments, I would simply configure the new device manually, but this option does not seem to be desirable in this case.

[Don_Paterson]

That is my preferred approach, knowing how Check Point works.

I would do a side by side config and then look for any specific file level customisations, which should ideally be documented.

{EDIT}

Adding:
Also probably consider creating a new Gateway/Cluster object for the new appliance/s, considering the hardware platform change.

Then replacing the old object with the new object wherever it is used (Right click > Where Used > Replace).

[Vincent_Bacher]

---

Adding:
Also probably consider creating a new Gateway/Cluster object for the new appliance/s, considering the hardware platform change.

Then replacing the old object with the new object wherever it is used (Right click > Where Used > Replace).

---

What's about just establishing SIC and then at Platform click "Get"?

[Don_Paterson]

Yes, that's a good option too, and should also work for rollback if that is needed.

SIC resetting on rollback (if that was needed) would also need to be done on the old boxes. 

[the_rock · Accepted solution]

I cant speak for anyone else, but what I always do is this and never had an issue. First, something like this on existing fws:

from expert -> clish -c "show configuration" > /var/log/hostname_date.txt

That file will contain output of show configuration

Then, you can copy bits and pieces from it to new firewal (same for other firewall), make sure new interfaces match, once all that is verified, when time comes for cutover, you follow below:

https://community.checkpoint.com/t5/Security-Gateways/Replace-Upgrade-Cluster/td-p/69216

I must have done this 20 times, at least, never had a problem.

Good luck!

Andy

[Vincent_Bacher]

Same here.

Of course, you also have to think about whether you have touched any files.
Classic example is $FWDIR/boot/modules/fwkern.conf

But that's what comprehensive documentation and operating manuals are for (ahem). 😄

[the_rock]

Yes sir, agree 💯

[Secret-goblin-5 · Accepted solution]

Followed the two solutions I marked below to resolve

https://support.checkpoint.com/results/sk/sk102234

Even though the instructions imply you must be on the same version you really dont need to be,

I grabbed the old config, then grabbed the new config.

I placed them both in Notepad++ and used the "compare" feature to check for differences.

I them modified the old config with the settings from the new config (interface names etc)

Lastly I imported it into the new firewalls.

Tomorrow I will find out if it worked when I physically install the new firewalls and add them to Smart Console etc.

[the_rock]

Hey @Secret-goblin-5 

Just my personal honest opinion, I would NOT recommend to anyone to run that command on-failure continue from clish and here is why. Just as a test, what I did in my lab once was added a line in the config that contained words "homer simpson" and guess what, it took it, so you are risking big time having config copied over that could be totally inaccurate.

Just something to consider. Of course, we are all adults here, I cant and would not even try force anyone to do something, all I can do is tell you about my experience.

Andy

[Don_Paterson]

Sounds good.

Seeing as you will create a new object, and just in case.

The Manage policies and layers window in SmartConsole allows you to clone a policy package.

Depending on the circumstances you could consider cloning the existing policy package and then populate that one with the new gateway object, and then the old one remains untouched and offers a potentially quicker rollback (should that be needed.

It's a bit of extra work cleaning up later (and playing with the policy package names) but could come in handy.

References:

How to rename or clone a policy in SmartConsole / SmartDashboard

https://support.checkpoint.com/results/sk/sk96406

https://community.checkpoint.com/t5/Management/How-can-we-quot-Save-As-quot-or-clone-an-existing-Pol... 

https://support.checkpoint.com/results/sk/sk183514 

"Policy name cannot be longer than 31 characters"

[the_rock]

Good references, Don.