moving to MDS

[AkosBakos]

Hi Community,

Has anyone fresh experience with moving Standalone SMS servers to MDS environment? I have some questions, and maybe someone can answer them 🙂

Akos

[Don_Paterson]

Can you share more details?

Standalone means that it includes SG in the SMS which you probably don't have. 

It is a new MDS or an existing where you will import to a new DMS (CMA in old money)?

What versions are involved?

[AkosBakos]

Sorry for the weak explanation

• I have 4 SMS different servers
• I want to merge them into one MDS server

Thats all 🙂

Akos

[Vincent_Bacher]

Then i'd suggest to first having a look at the sk shared by @TurgutKaplanogl 

[_Val_]

That should be a standard operation; it is documented in sk156072, as already mentioned

[Don_Paterson]

Assuming you are familiar with MDSM (Multi-Domain Security Management):

If not, start here: https://www.youtube.com/watch?v=edvVqKD_hYA) <-- that is free.

Your scenario is covered in the labs of the training course for MDSM - https://igs.checkpoint.com/courses/3010 <-- that is not free.

Planning is important.

That includes, for example and non-exhaustive list:

• IP addresses to be used:
  • MDS - Multi-Domain Servers (Primary and Secondary) and MDLS - Multi-Domain Log Server (if used)
  • DMS - Domain Management servers * 4 (plus any future DMS instances planned for the future)
  • DLS - Domain Log Servers * 4 (if you use virtual log servers - DLS (Domain Log Servers) - one per Domain)
  • SmartEvent server/s (if planned)
  • NAT addresses for some or all above.
  • Accounting/planning for the new IP addresses and changes (network and licenses). 
• Licenses
  • MDSM licenses and possible trade-in options
• Preparation of the MDS
  • Naming convention
    • MDS name
    • Domains and DMS instances names
• Pre-migration/pre-export configuration work on the SMS machines
  • Preparing the old management object and installing policy - for the SG/s to recognise the new management instance (imported SMS (to DMS))
  • Verify - That can be done via API (mgmt_cli) or migration tool (migrate_server verify)
• MDS network & firewall planning
  • Routing
  • Firewall rules and NAT (connecting DMS/CMA to managed firewalls/SGs)

With all the planning done and pre-sales and sales taken care of the actual migration can be straight forward.

Apart from the list above there are other things you need to think about, for example: You need to decide if you want to include logs (or not) when exporting.

The migration essentially comes down to:

migrate_server verify -v ...

mgmt_cli export-management ...

mgmt_cli import-management domain-name ...

Hopefully someone who has done it recently can share experiences/notes here.

If you share the versions you are working with and planning to install to (on the MDS) that might help too.

PS. See attached for the training course topology and the example spreadsheet that I share with students on the training course (as a way of capturing the IP addresses).

Note: The IP addressing in there is a bad example (does not scale) because it sticks to a non-MDMS training lab IP subnet plan (good for CCSA and CCSE but not so much MDSM)

[Alex-]

We're facing a similar scenario. For a site with SMS HA, I wonder if we need to delete the HA system from the Primary to avoid importing it in a CMA where it could be trickier to remove.

I'll run a few tests in a lab environment.

[Bob_Zimmerman]

Yes, I would take snapshots of every management ahead of time, then delete any secondary managements and log servers before attempting to migrate. It's easy to add a CMA on another management once you've migrated.

That said, unless you're an MSP, I personally wouldn't move towards an MDS.

I'm working to move my company away from our MDSs because it makes so much stuff more painful for minimal benefit. For example, global objects are normally differentiated by name (e.g, people put a "g_" in front of the name, or similar), but domain objects match based on the name of the object. If you allow somebody in one CMA to connect to a particular domain, then you want to promote the rule to be global, you now have to make global domain objects for the domain. The problem is once you have, you can't assign global policy to the CMA which has its own instances of those domains until after you have deleted the objects from the CMA's rules. So now you have to rename the domains in the CMA, publish, assign global policy, go back into the CMA, and replace the renamed domain objects with the new global versions.

[Alex-]

Thanks for the clarification.

Well, I don't call all the shots.

One of our high-security environments has a strict requirement of resource and information segregation going forward, so client A can't see logs, policies and objects from client B and so on.

Right now with the SMS, this isn't really possible. All gateways and VS, policies, logs and objects are in the same domain.

[TurgutKaplanogl]

Hello Akos,

You can follow this sk;

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

3-A and 3-B

Thank you