Migrate management to AWS

[Ob1lan]

Hi,

We are soon getting rid of a datacenter and are planning the migration of hosted ressources to AWS.

This will include our Check Point management appliance (R81, OpenServer), that manages 40+ firewalls worldwide. We have a lot of small business firewalls in remote offices (1430/1450) and other models like 3100, etc... 

We would like to avoid any impact, and in some cases we won't have remote hands (no personnel onsite to grant us a remote session to connect the firewall with console). So, do you have some sort of guidelines/procedures on how to handle that task ? 

The new management in AWS will have different IP addressing, so I guess we'll have to reset the SIC on the gateways, right ? Can all that be done remotely, is there any trick to perform that smoothly ?

Thanks in advance for your advises, much appreciated. 

Regards

[the_rock]

I saw someone asked similar question before, but dont recall there was an easy way to do this though. Since it would be brand new management, even if its on-prem, you would definitely need to establish SIC on the gateways, so that step can be done remotely, but its a bit risky, because it would not be easy to troubleshoot it if it fails, as it may require console access. It might involve unloading the policy, which is just a simple command, but then the rest could be a bit tricky. I will let experts give you suggestions, but personally, Im not aware of one click solution to this, sorry,

[genisis__]

I also believe there is a requirement to use private addressing in the cloud so if you are using public address space internally this may be something to consider (if the above is actually correct).

I suspect a number of us are now looking to migrate the management layer into the cloud but I've seen very little on this.  Would be great to have a walk through for a SMS and for MDS.

[PhoneBoy]

Assuming you are migrating the management server using the migration tools, you shouldn’t need to reset SIC even if you change IP.
A few things off the top of my head:

• The management instance in AWS will have private addressing on its interfaces.
• It’s assumed the NAT will be done by AWS when the elastic IP is assigned.
• The main IP of the management server (in the General tab of the object) should reflect the assigned elastic IP.
• Gateways are migrated to the new management server by simply pushing policy from it (assuming all of the above was done successfully)

it might be tricky to ensure that no logs are lost as part of this migration process.
Logs should probably be migrated separately and you may want to shut down the original management at some point before copying the logs over.
This should cause logs to queue up on the gateways, which will continue to operate normally.
The logs will stream to the new management once policy is pushed.

[Ob1lan]

Thanks for your comment ! Looks like this is the approach we'd like to achieve. 

Do you have any guidelines for that or maybe a step-by-step guide or a successful scenario ? 

As we have 40+ gateways, we'd like to phase the work over 2-3 weeks, and need assurance we could rollback if anything wrong happen. Can we have 2 management servers working at the same time, with the same DB (as I'll indeed use the migration tools to export the DB from the current and import in AWS) ?

Thanks for your help !

[PhoneBoy]

I don’t think it’s much more complicated than I described above.
I’ve done almost this exact thing in the lab when I rebuild my management server on a different IP and it generally works.
I would try it in the lab just so you can see how it works.

Theoretically, you can keep both management servers up in parallel.
However, you’ll have to keep the configuration in sync somehow.
And I’m not sure how VPNs would handle this (thinking about fetching the CRL).
Not even sure you need to do this over the course of 2-3 weeks as it shouldn’t take you that long to actually push policy to all the gateways.

[Ob1lan]

Thanks. I'm indeed worried about how the numerous S2S VPN we have will be behaving. I'll try to start a lab and test all this.

[Ob1lan]

Hi @PhoneBoy 

Also, I was wondering if adding a secondary management server in AWS and following R81 guide for Management HA would do the trick ? Could that work in this situation ? I would imagine having that HA environment and once synchronised, promoting the AWS instance as primary, and decomission the old one.

What's your opinion on this approach ?

[Ob1lan]

Hi @PhoneBoy ,

So I've managed to launch an EC2 instance from the AMI found in the marketplace, so far so good. I've configured it as a Management HA, so it syncs with the primary/current management appliance alright. I've tested and made the AWS one active, and push policies, all looks fine !

But my next question relates to the sizing of the EC2 instance. So far I've chose a m5.2xlarge, but the CPU usage is 98%. I'll move to a m5.4xlarge, which doubles the CPU cores.

My concern is about the storage. How can I determine the Iops and Throughput I need to set for the gp3 disks ? Is there any guidelines based on the number of gateways we manages, etc... ?

Thanks in advance.

Regards

[nzmatto1]

Looks like it's been a while, but did you get this all going?   I'm trying to do the same, one manager on prem, and the other in the cloud but the management HA wont form because the version numbers are different. I've logged a case but thought I'd mention it in case you hit that and fixed it. 

[PhoneBoy]

Management HA is only supported between members that have the exact same version/JHF level.
You will have to use the standard migration tools (migrate_server) if the versions are different.