Checkpoint Gateway Migration

[Maradona_Mathew]

hi there,

I need to consolidate multiple standalone checkpoint gateway devices to one single higher end model of hardware. Both old and new gateway will be registering to the same Security Management server. Could you please help to break up the procedure and give me the steps. Relatively new checkpoint user. 

Gateway and Management Server Version Gaia 77.30 

Best Regards,

Matthew 

[PhoneBoy]

The exact steps are going to depend on current state of the environment, proposed state of the environment, and constraints you have to work around (i.e. the gateway protecting X can only be down during Y times).

At an extremely high-level:

1. Depending on the target version of gateway, you may need to upgrade your management. Note that all new appliances only support R77.30 and above. If you're running a lower version of code on your management, you will need to do that first.
2. Stage the new gateway OS in the lab (configure networking, routes needed, etc). Depending on whether or not the new gateway will assume the IP addresses of an existing gateway, you may or may not necessarily establish SIC with the management at this point, but at least establish the one-time password so the gateway is ready when the time comes. 
3. Create a combined policy that includes all the appropriate rules from all the gateways that are being replaced. While you can certainly copy/paste all the rules, you should take the opportunity to review the rules in detail to see what rules are actually needed or not as well as put some thought into the order of rules. You should use the "Verify Policy" option in SmartConsole/SmartDashboard to make sure there are no obvious mistakes. 
4. Develop a plan for doing the actual cutover, accounting for the cables that need to be swapped, routes that need to be changed, ARP caches that may need to be flushed, etc. Make sure you have a backout plan in case things go sideways. 
5. During the actual cutover will probably be the time you establish SIC and push policy to the device. 

I'm probably missing a few minor steps above, but it should be a good starting point. 

I strongly encourage engaging the services of a local partner or Check Point Professional Services to assist with this task.

[Maradona_Mathew]

Hello Dameon,

Thanks a lot for your reply. In my case, the software version ( R77.30 ) is same on all the appliance (management & gateway). All the gateways (OLD and NEW) is connected to same management server as well.

New Gateway is added and enabled with all the routes and interface configurations, layer 2 & layer 3 reachability checked. Just that IP address given is another one in place of the live gateway. SIC connection also established.

In regards your point 3, is there an alternate way other than copy paste policy from each firewall. Just wondering if that is the best practise ?

I have VPN tunnels terminating on one of the gateways which will be moved to the new box. Would there be an option to copy and paste the VPN configurations as well?

Please let me know. Thanks.

Present setup - 4 Checkpoint standalone Gateway 

Expected Setup - 1 Checkpoint cluster replacing all the 4 above gateways. All running with same software version now. 

[PhoneBoy]

You can use copy/paste of the rules as a starting point for a new rulebase.

You can, of course, rebuild the policy from scratch, but if the policy is complex, you might miss something.

Either way, it's a manual task, it just depends on how you want to approach it. 

The VPN configuration is mainly three items:

• The VPN Community, which should remain the same except the new gateway object will have to be added to the existing community.
• The rules that trigger VPN, where the VPN column is relevant.
• The various VPN settings on the Security Gateway object. This includes various settings under IPSec VPN, which will have to be adjusted manually. Topology and/or Encryption Domain settings will have to be adjusted manually as well.

[Sven_Glock]

Hi Maradona,

have you already thought about migrating to VSX?

This will provide the the possibility to keep old policies as they are and having virtual systems

in the same way you have physical clusters today.

VSX is a bit more expensive, but it helps to seperate policies and ressources.

BR

Sven