How convert stand-alone (all-in-one) to distributed policy.

[Garrett_DirSec]

Hello Community --

Customer currently has stand-alone (all-in-one) legacy Check Point appliance running R77.30 (very recent HFA) and I'm upgrading environment to distributed platform running R80.40 on HyperV.

We have the target platform installed, configured, and waiting for "migrate import". 

However, the current R80.40 migration tool "does not support conversion of all-in-one to distributed deployment".    The tool produces this error upon "migrate import <>" on target new SmartCenter.

Based on some upgrade experiences in past, is this a job for support to wave a rubber chicken and purge gateway properties of "all-in-one" configuration from "migrate export <>" file?    I know for fact they can do numerous inexplicable behind-the-scenes procedures that only make me cringe. 

Alternatively, I figure there are ways to leverage fact target is virtual platform and first complete upgrade/migration to R80.40 as stand-alone platform (SmartCenter + Gateway) and then update the result platform to remove gateway portion (GUIDBEdit here I come  IsGateway=0 or similar along with updating object properties).

Ideally, I'd like support to purge the "migrate file" of gateway references but I realize this may create an issue with any gateway references in policy.   maybe these just become "any" and I can update once gateway SIC established?

Any insight would be appreciated.    I did search for various aspects of this topic and found nothing.

thanks -GA

[G_W_Albrecht]

It has even been discussed a lot here 😎 !  There currently is only one option, to do the change in R77.30 following sk61681 - How to migrate from StandAlone configuration to Distributed followed by the upgrade. We have sk154033 - How to migrate R80.x standalone management environment to a distributed environment but it only works in R80.10, so that would be one more step to upgrade from R80.10 > R80.40...

[Garrett_DirSec]

Hello @G_W_Albrecht -- thanks for the quick reply and suggestion!      The primary issue I find with the R77x SK solution (SK61681) are the "production affecting" operations.    I'm going to go out on limb and suggest that most standalone deployments are "small in scope" (aka.  SMB) and the security policy, configuration, and NAT rules are relatively simple (ie. not hundreds of rules).     

Assuming remote-access VPN setup using UDIR and LDAP authentication, we don't need to worry about any "local" accounts to migrate.    If not, this would be good update for customer to setup (with all the end-user operational and training issues) prior to upgrade.

I like the idea of leveraging API and upgrade temporarily direct to R80.40 stand-alone (vm), use API to pull policy from temp VM, and import policy into new distributed R80.40 SmartCenter.     update any policy install target issues, NAT and VPN and off to the races. 

reference:

Python tool for exporting policy HERE

[G_W_Albrecht]

In production environments i have found that slow migration using VMs is the most appropriate way. The SK61681 does not give the steps, but obviously you need do a migrate first, import it into fresh R77.30 JTx VM and do all from SK61681 with this VM.

[PhoneBoy]

Actually, we have a procedure for converting a standalone R80.40 to distributed: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
I know the SK says "not for R80.20 and above" but this really only applies to R80.20/R80.30 which have different ISOs for gateways/standalone and management where the management HA sync will fail due to the different Linux kernels in use.

[Garrett_DirSec]

HA... thanks @PhoneBoy .    I wondered about that when I saw the kernel mismatch statement.   thanks! 

[PhoneBoy]

The internal notes for the SK say it should work in R80.40 because the kernel is the same. 
I asked for this to be added to the public part of the SK 🙂

As for why not sk85900, I haven't looked at a recent migrate export, but I suspect that the relevant lines of configuration either don't apply or additional steps are needed above and beyond what's in the SK.
I haven't looked, to be honest.

[StellaShteinbuk]

Hi All,

I've updated sk154033 regarding R80.40

[Garrett_DirSec]

Hello @PhoneBoy and @StellaShteinbuk  - I just made the following feedback on SK154033.

Hello -- this article talks about HALF the procedure of migration from standalone to distributed.  All the clean up is missing.
Example: how do delete the HA sync configuration.
how to remove the OLD standalone object.
how to update Logging (smartconsole to NEW mgmt instance still refers to log server on OLD mgmt instance).
please fix.

[PhoneBoy]

From various SKs, it seems you can just delete the other management object as the SKs I saw were for what happens when that goes awry.
I assume you can just do a "where-used" and replace the previous standalone object with the new gateway object where appropriate.
And, again, you'll have a new gateway created with the new management, so I assume the logging settings would be the default.
Any other gateways managed by that standalone gateway would need to be updated. 

However, you're correct: this could be better documented. 

[Garrett_DirSec]

Hello @PhoneBoy .   sincere thanks for the ongoing comments and suggestions.

Yes, we did the following:

1. changed ACTIVE smartcenter node of HA sync to the new SmartCenter-only instance. 
2. we updated VPN community to new gateway-only instance.
3. we updated log preferences for new gateway-only instance (point to new smartcenter-only instance).
4. we leveraged the 'where used' feature of original standalone instance to update security policy and remove all references.
5. we unselected all features of standalone object.   the ONLY remaining checkbox is "NPN / Secondary".   

Check attached screenshot.   only NPM is selected on device we want to delete.   If we right-click on standalone object, the "DELETE" option is greyed out. 

However, even though our new SmartCenter-only instance is ACTIVE/primary in HA Sync, the option to right-click DELETE is available. 

[PhoneBoy]

This seems like it’s along the lines of a few SKs I saw where the public answer is “open a TAC SR.”
You might try deleting the object via the API/CLI and see if it either works or provides a useful error message, versus blocking it like SmartConsole is doing.

[Garrett_DirSec]

hello @PhoneBoy - thanks for follow-up.     SR open with TAC and I will post update.   customer out of town for week.   thx

[Garrett_DirSec]

Hello @G_W_Albrecht and @PhoneBoy .   sincere thanks for both your input on topic.

Why can't I following the procedure in the sk85900 that involves editing the "migrate export <>" file to allow it to import?     It may still fail on import. 

I would still need to disable object properties and various clean-up if successful.  

thoughts?  -Garrett

[G_W_Albrecht]

sk85900 can be performed while on R77.30. I would suggest to contact TAC and ask for the best procedure here if you experience troubles...