VSX cluster to normal ClusterXL migration

[Thanux89]

I'm planning to perform a VSX to non-VSX migration. VSX gateways are configured in domains that differ from VS's (best practice).

When planning the migration, I plan to configure the entire cluster in the current VS-hosted domain in MDS.

The current VS vs0 IP is a VLAN inside the bond interface.

I plan to use the same policy base used for the VS.

In that sense, what would be the best approach to combine the management?

[AkosBakos]

Hi @Thanux89 

This few lines can generate pages as answer.

Narrow down it a little bit.

• Do you want to migrate all VS into simple cluster?
• Do you want to handle the policies totally separately from the users point of view (MDS functionality)
• Or one CheckPoint domain with the clusters?

Akos

I

My ideoa: One

[Thanux89]

Please refer to my answers

• Do you want to migrate all VS into simple cluster? No 1 VS = 1 Cluster
• Do you want to handle the policies totally separately from the users point of view (MDS functionality) Need to use the existing policy which is pushed for VS
• Or one CheckPoint domain with the clusters? Use the existing CMA with the new cluster

What I think is I need to configure policies for the management connectivity as the current VS do not have policies for management.

VSX cluster is in different CMA and management policies are in that CMA not the CMA where the VS exists.

[AkosBakos]

Ahh see. Yes you need to configure the basic rules on the top of the ruleset (MGMT access, SNMP, DNS, NTP, etc) but it depebdsz on the "GlobalSeettings", what is set there. The impled rules are allowed etc.

• Did you count whit the IP address of the clsutering?
  • The simple cluster needs 3 IPs/clsuter interface.
• You need to recreate the Cluster object -> you can't convert the VS object into sipmle cluster object
  • This can be a "painful" step

It can be a long story, and hard to summarize in one post 🙂

Akos

[Thanux89]

Yes, VS is referring to bond interface and having bunch of VLANs and they are /29 so the plan is using the VS IP as the cluster IP and use two new IP addresses for each device. What I’m not sure is will the CMA allow the same IP to be in two different gateways (VS and the new cluster)

If this is possible can do a parallel build by only having the management UP.

[AkosBakos]

Hi Thaunux89,

Q: "What I’m not sure is will the CMA allow the same IP to be in two different gateways (VS and the new cluster)"

This is really a good question. unfortunately I dont have experience suck kind of scenario. You need to test it with one IF 🙂

Have you thought about to create a new CMA for the simple cluster, migrate here the policy, and build it here?

Akos

[Thanux89]

Yes, that’s the last option, where it involves some work as I need to export policies and objects to the new CMA and build everything fresh on the new CMA where no impact at all.

[AkosBakos]

If i were you, I would choose this way.

There are tools for moiving packages beteen CMAs.

https://community.checkpoint.com/t5/API-CLI-Discussion/Python-tool-for-exporting-importing-a-policy-...

Akos

[PhoneBoy]

It's worth noting the process of moving between a VS and a regular gateway is a LOT easier in R82 with VSnext since it is easily available in Gaia OS (the "gateway" side of the configuration).
Even the VS object is now just a regular gateway object with VSnext.

Meanwhile, even with legacy VSX, the existing security policy (except for the VS objects themselves) can be used.
If you need to move it to a different domain, you can use a tool like: https://community.checkpoint.com/t5/API-CLI-Discussion/Python-tool-for-exporting-importing-a-policy-...