cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question

Migration of clusters from single SMS to multiple MDS

Hello mates,

I would like to have your opinion and some insight to the problematic which I am facing at the moment.

We have R77.30 SMS with 10 clusters. All of those 10 clusters are included in MyIntranet meshed community.

On every cluster we have rule that will allow any connection from all other gateways within MyIntranet VPN community.

Now, we need to move 5 clusters from current SMS to the MDS where we will create separate CMA for those 5 clusters.

Next 3 clusters from current SMS will be moved to the different MDS where we will create separate CMA for those 3 clusters.

Remaining 2 clusters from current SMS will be moved to the next different MDS where we will create separate CMA for those last 2 clusters.

Gateways managed by this SMS are based on Europe, USA and Africa.

We will not create new MDS, all MDS servers are already deployed and in production. We will just create new CMA on every MDS, based on location.

Means, first 5 clusters which are located in Europe, will be moved to the MDS located in Europe.

Next 3 clusters located in USA, will be moved to the MDS located in USA.

Remaining 2 clusters which are located in Africa, will be moved to the MDS located in Africa.

For better understanding I can create some basic drawing, as I am not sure if you can imagine the topology at the moment...

All the job during migration will be done based on migrate export / import. We will import package created on SMS on all 3 MDS.

My biggest concern is how can we handle communication between all 10 clusters each other. As I mentioned, the current SMS has MyIntranet meshed community where are all 10 clusters in it.

The plan is to remove not needed policy packages and Check Point devices from all MDS. If I am on Europe MDS, it has no sense to have policy packages for USA and Africa. We will also modify MyIntranet community to have only gateways for the same location. MyIntranet for Europe MDS will have clusters only located in Europe and so on.

For communication between Europe and USA, we will create new star community on MDS in order to establish VPN between Europe and USA.

I would like to discuss what are my options and what is the best way how to minimaze VPN disruption between Europe, USA and Africa to the lowest possible time.

SMS, MDS and all gateways are running R77.30.

If you have any questions, or suggestions, I will really appreciate that.

Thanks for every comment.

Kind regards,
Jozko Mrkvicka
Tags (3)
7 Replies
Admin
Admin

Re: Migration of clusters from single SMS to multiple MDS

The migrate export/import bits are simple enough.

You will probably want to do cleanup at multiple stages (before export, after import, and after certain configuration changes).

SIC is brought over with a migrate export/import, making it a pretty straightforward exercise to change management to the new CMA--just push policy from it when you're ready.

The tricky part will be restructuring the VPNs, which I imagine will take a level of coordination to minimize the downtime.

Hopefully you're not trying to manage the gateways through the VPN (i.e. doing SIC via VPN):  

It would be a good idea to have console/SSH access to the remote gateways to clear tunnels and the like when you're changing the configurations around.

0 Kudos

Re: Migration of clusters from single SMS to multiple MDS

Hi,

We are not managing gateways via VPN.

What we are playing around at the moment is the idea to do not create any additional site-to-site VPNs, instead of that we want to modify existing MyIntranet meshed community. To do so we have following plan:

  1. From Europe CMA, delete all Check Point devices for USA and Africa. Configure new Interoperable devices (or Externally managed VPN Gateways) for those USA and Africa gateways.
  2. Include them into Participating Gateways within MyIntranet Community.
  3. For all external gateway setup Shared Secret keys.
  4. Repeat the steps on USA and Africa CMA

Can Connection Persistence help us during migration ? To choose Keep all connections before migration, push policy on all gateways from CMO SMS. Once all changes are made on FMO CMAs, push all firewalls from their own CMAs. Will the tunnel survive ? Or will be down once we will push the first firewall ?

Kind regards,
Jozko Mrkvicka
0 Kudos
Admin
Admin

Re: Migration of clusters from single SMS to multiple MDS

I don't believe this will keep the VPN tunnels active as technically you are changing the VPN peers.

Granted, the peer ends up being the same IP, but you are now using different objects for said peers.

0 Kudos

Re: Migration of clusters from single SMS to multiple MDS

This is valid also for already established connections ? Basically, from my perspective, all connections will be cut.

To be honest, I really don't know if I got that features for Connection Persistence correctly. All these settings are valid only for new connections, or only for already established, or both of them ? Is someone able to clarify what all options really do, because from official help I don't know it for sure:

Check Point Security Gateway provides the best combination between security and connectivity, thereby maintaining maximum connectivity without compromising security.

In Check Point Stateful Inspection, a packet is matched against the Policy Rule Base only when a new connection is established.

If the Action for a matched connection is Accept, then an entry is created in the connections table so all future packets that belong to this connection are accepted without referring to the policy.

When a new policy is installed, existing connections are marked as "old". When a new packet that belongs to an "old" connection is encountered, it is matched against the policy. If the policy match result is Accept, the entry will revert back to a normal state and the connection will continue uninterrupted. If the result is Drop or Reject then the packet is dropped and the connection entry is deleted from the table.

  • Keep all connections keeps all control and data connections open until the connections have ended. The newly installed policy will be enforced only for new connections.
  • Keep Data Connections keeps all data connections open until the connections have ended. Control connections that are not allowed under the new policy will be terminated.

Rematch Connections means that all connections not allowed under the new policy will be terminated, unless the service has Keep connections open after policy has been installed is enabled in the Service Properties window.

Kind regards,
Jozko Mrkvicka
0 Kudos
Admin
Admin

Re: Migration of clusters from single SMS to multiple MDS

When you push a new policy to a gateway, it's possible your new policy may forbid connections that are both previously allowed and currently established.

"Keep All Connections" effectively grandfathers in these established connections—this is probably the option you want.

"Keep Data Connections" does this only for so-called data streams (protocol specific).

"Rematch Connections" subjects everything to being rechecked by the new policy.

Note if the connection relies on a VPN Tunnel and the tunnel can't come up, then it doesn't matter if there's an established connection for it already.

Highlighted

Re: Migration of clusters from single SMS to multiple MDS

Hello guys, Dameon Welch-Abernathy‌,

Currently I am trying to perform some actions from my LAB and found something interesting. I did migrate export and imported it into LAB MDS. I have created separate CMA.

Within this CMA I have 2 clusters, both in MyIntranet Community.

As I want to go aproach mentioned  here (modify existing MyIntranet community), I need to remove Check Point Objects.

So I did remove one of 2 clusters from CMA.

First thing I noticed - The license was automatically removed from both members of deleted cluster ! Obviously, SIC was valid and I had SIC communication from both members.

Second thing I noticed - the SIC communication from both members of deleted cluster was completely destroyed and I was not able to perform rollback (push policy from original SMS), because "Peer SIC Certificate has been revoked". 

As we are forced to have tested back-out method (rollback), I am not sure if we will have green light if rollback is not possible. We thought that we will simply push the policy from original SMS and all will be fine in case we will face some issues during migration.

The question is if this is designed solution to revoke SIC on members if Check Point objects is removed and there is still valid communication from management towards members.

It might be possible workaround to add some "dummy" route on MDS to avoid communication with members to be deleted. Simple forward packets to some other way where it wil be lost.

Kind regards,
Jozko Mrkvicka

Re: Migration of clusters from single SMS to multiple MDS

Another fun fuct (well, not really funny, as it happened in production already) was that we hit Gateway's SIC certificate is getting revoked every few days .

It turned out that we added loop routes only for gateways, not for SMSes. So we have deleted all not needed clusters without any issue, but in fact we faced active - active state of SMS and MDS. We did export from Primary (at that time Standby) SMS. Of course that once we have imported it into MDS, the CMA went to active state. It is quite interesting behaviour which caused gateways to revoke SIC communication. We will need to re-establish all SIC certificates from original SMS, perform export once again and ensure that communication between SMS and MDS is not possible.

Kind regards,
Jozko Mrkvicka