> Source: [sk180306](https://support.checkpoint.com/results/sk/sk180306)
# sk180306 - How to migrate Cloud Firewall Geo Cluster R81.10 or lower to R81.20 Cross AZ Cluster
| Property | Value |
|----------|-------|
| Solution ID | sk180306 |
| Date Created | 2022-11-27 |
| Last Modified | 2026-04-28 |
| Technical Level | General |
| Products | Cloud Firewall |
| Versions | R81 (EOS), R81.10 (EOS), R81.20 |
| OS | Gaia |
| Platform | AWS |
## Solution
Prerequirements
---------------
1. The Security Management Server/Multi-Domain Server must be version R81.20 or higher.
2. Deploy R81.20 Cloud Firewall (formerly CloudGuard) Cross AZ Cluster to the same VPC and Subnets of the old Cross AZ Cluster (Geo Cluster) using [Cloud Formation](https://console.aws.amazon.com/cloudformation/home#/stacks/create/review?templateURL=https://cgi-cfts.s3.amazonaws.com/cluster/cross-az-cluster.yaml&stackName=Check-Point-XAZ-cluster) or [Terraform](https://github.com/CheckPointSW/CloudGuardIaaS/tree/master/terraform/aws/cross-az-cluster) templates.
**Cloud Formation VPC Network Configuration example:**
3. Associate the Security Group of the old Cross AZ cluster members with the new cluster members:
1.
1. Navigate to **AWS Console** \> **EC2** \> **Instances** , select one of the old Cluster members, click Security tab and copy the **Security Group ID** .
2. Navigate to **AWS Console** \> **EC2** \> **Instances** , select one of the new Cluster members, click **Actions** \> **Security** \> Change Security Groups.
3. Add the copied Security Group ID and remove the Old Security Group for both interfaces.
4. Add license to the Cross AZ cluster members.
5. (Optional) Copy gaia configuration from Geo Cluster members to the Cross AZ one.
**Note:** For both manual and automatic migration options, the procedure will cause to traffic downtime during AWS route tables updates.
*** ** * ** ***
Instructions for automatic migration
------------------------------------
The instructions below explain how to migrate from old Cross Availability Zone Cluster solution (Geo Cluster) to the new one using **automatic migration utility** .
1. Log in to the Security Management Server/Multi-Domain Server via ssh and enter to the expert mode.
2. Install CME take 234 or higher on the Security Management Server/Multi-Domain Server.
3. Navigate to /opt/CPcme/features/migration_utility folder.
4. Run *./migrate_cloud_solutions.py* file with the following parameters:
|--------------------------|------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|--------------|
| **Parameter** | **Value** | **Description** | **Required** |
| cloud_platform | PLATFORM (**AWS** for now) | The cloud platform that the migration will be executed at | True |
| target_solution | TARGET_SOLUTION (**Cross-AZ-Cluster** for now) | The target solution to migrate to | True |
| --old-cluster-otp | OLD_CLUSTER_OTP | The one time password to establish SIC for the old cluster members | True |
| --cluster-name | CLUSTER_NAME | The Cluster name in the Management DB | True |
| --target-cluster-version | TARGET_CLUSTER_VERSION | The version of the Cross-AZ Cluster (R81.20 and above) | True |
| --mem-A-ip | MEM_A_IP | The IP of the new Cross-AZ member-A (private IP or public/elastic IP -- depends on cluster managing in the Management) | True |
| --mem-B-ip | MEM_B_IP | The IP of the new Cross-AZ member-B (private IP or public/elastic IP -- depends on cluster managing in the Management) | True |
| --vip | TARGET_CLUSTER_VIP | The virtual ip of the new Cross-AZ cluster | True |
| --target-cluster-otp | TARGET_CLUSTER_OTP | The one time password to establish SIC with the new cross-AZ cluster members | True |
| --pkg | PACKAGE | The policy package to install on the Cluster members | True |
| --domain-name | DOMAIN_NAME | The domain name which controls the cluster (in cases of MDS) | False |
For example:
*./migrate_cloud_solutions.py AWS Cross-AZ-Cluster --old-cluster-otp aaaa --cluster-name geo_cluster --target-cluster-version R81.20 --mem-A-ip 10.0.10.113 --mem-B-ip 10.0.20.89 --vip 1.2.3.4 --target-cluster-otp aaaaaaaa --pkg Standard*
### Notes:
1. **In the Management machine, a log file will be created** and the information about the migration process throughout the script execution will be written to there as well as to the screen.
The log file location: */var/log/migrate_cloud_solutions.log*
2. The script execution can be divided into 3 main phases:
a. Input validation.
b. Replacing the cluster object in the Management/MDS database from the old cluster object to the new cluster object.
c. Updating the AWS route tables to point to the new cross AZ cluster active member internal interface:
* The script will invoke the aws_had.py file on each of the new cross AZ cluster members with migration parameters as explained in the troubleshooting section 3. **In each cluster member, a log file will be created** . It will contain all the information related to the route tables updating. The log file location: *$FWDIR/log/aws_had_migrate.elg.*
* If the route tables were updated without errors, the line: *"migrated_from: Geo-Cluster"* will be added to*/etc/cloud-version.json* file on both members.
3. For more information about Cross Availability Zone Cluster and its configuration, refer to the admin guide: [Cloud Firewall for AWS Cross Availability Zone Cluster Deployment Guide](https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_for_AWS_Cross_AZ_Cluster/Content/Topics-AWS-CrossAZ-Cluster-DG/Getting_Started_with_CloudGuard_Network_for_AWS.htm)
### Limitations:
1. The script is not supported on Smart-1 cloud security Management.
2. The script does not take into account the case of continuing to use the same public IPs. In that situation, customers need to do it manually, refer to the **instructions for manual migration** in the *Using the same public IPs in AWS* section.
### Troubleshooting
1. Make sure that the input arguments are set correctly. If the input validation did not succeed - error will be written to the migration log file on a Management/MDS *(/var/log/migrate_cloud_solutions.log)* and the script execution will be stopped.
2. If the process of replacing the cluster object in the Management database failed - error will be written to the migration log file on the Management/MDS machine.
For example:
An error occurred in the api call of get-interfaces with topology because of a wrong sic.
The error appears in the log file is:
After the error, the script will restore the old cluster object that was before running the script, then the script execution will be stopped (That's why there is a need to insert the old cluster otp as one of the input arguments). In that case, check the information about the error in the log file *(/var/log/migrate_cloud_solutions.log)* .
3. If the process of updating the route tables failed - there are two possible reasons for that:
1. aws_ha_tests (that run in the beginning of invoking the aws_had file) failed. In that case error that the tests failed will be written to the member's log file. Customers need to check the cluster configuration and run again the aws_had file with the migration parameters as explained below.
2. aws_ha_tests passed and after that the route tables updating process failed. Customers can see in the member's log file (*$FWDIR/log/aws_had_migrate.elg* ) what are the route tables that need to be updated and can invoke again the aws_had file with the migration parameters for updating the route tables. On the active cross AZ cluster member, run *python3 $FWDIR/scripts/aws_had.py* with the following parameters:
a. migrate (for marking about migration that will be done).
b. --eth0-peer-list (the eth0 IPs of old cluster members).
c. --eth1-peer-list (the eth1 IPs of old cluster members).
For example: suppose that the eth0 and eth1 IPs of the old member A are 10.0.10.1, 10.0.11.1 respectively. Moreover, the eth0 and eth1 IPs of the old member B are 10.0.20.1, 10.0.21.1 respectively.
The invocation on the new cross AZ active member will be:
*python3 $FWDIR/scripts/aws_had.py migrate --eth0-peer-list 10.0.10.1 10.0.20.1 --eth1-peer-list 10.0.11.1 10.0.21.*
3. In both failure cases, error will be written also to the log file on the management/MDS *(/var/log/migrate_cloud_solutions.log)* with error for updating route tables' process failure. The script execution will be stopped.
*** ** * ** ***
Instructions for manual migration
---------------------------------
The instructions below explain how to move from the old Cross Availability Zone Cluster solution (Geo Cluster) to the new one **manually** .
1. Connect to the old Cluster members via SSH and, from Expert mode, stop the AWS HA daemon:
??????3 $?????/???????/???_??_???.?? ????
2. Connect to your Check Point Security Management Server with SmartConsole.
3. In the SmartConsole, open the old Cross AZ cluster object.
2023021219005113.png)
4. Navigate to **Network Management** and delete both Cluster interfaces.
2023021219030315.png)
5. Navigate to **General Properties** :
1. Change the Cluster IP from 0.0.0.0 to the Public Cluster IP address of the new Cross AZ Cluster.
2. Change the platform version to R81.20.
**To get the Public Cluster IP address in AWS Console:**
Navigate to **CloudFormation** service \> **Stacks** \> Choose the Cross AZ Cluster stack \> select the IP address with the key **"ClusterPublicAddress"** .
2023021219101117.png)
6. Navigate to **ClusterXL and VRRP,** select **High Availability** and **Use Geo Mode in a Cloud** .
7. Click **OK** (close the cluster object).
Note: if a Warning pops up, click OK on the warning window.
8. Reopen the cluster object.
9. Replace the cluster members:
1. Navigate to **Cluster Members** .
2. Open the cluster member.
2023021219124418.png)
3. Change the current IP address to the new Cluster member IP address.
4. Click **Communication** then click **Reset**
2023021219150419.png)
5. Enter the **One-time password** then click on Initialize.
2023021219165520.png)
6. Repeat steps b-e on the second cluster member.
10. Navigate to **Network Management** and click **Get Interfaces** \> **Get Interfaces With Topology** .
202302131627321.png)
11. Configure external interface:
1. Click the "eth0" interface.
2. In the General Section select Network Type as "Private".
3. Under the Topology Section click "Modify ..."
202302131629492.png)
4. Disable the Anti Spoofing by clearing **Perform Anti-Spoofing based on interface topology** checkbox.
5. Click **OK**.
12. Configure internal interface:
* Click the "eth1" interface.
* In the General Section, select Network Type as "Sync".
* Under the Topology Section click "Modify ..."
* Disable the Anti Spoofing by unchecking "Perform Anti-Spoofing based on interface topology".
* Click OK.
13. Publish the session with the changes.
202302131750143.png)
14. Install the policy on the Cluster as target machines with the needed Policy Package.
202302131752324.png)
202302131753555.png)
15. Validate that the Cluster works in High Availability with the command:
???????? ????
#### Change Routes in AWS manually:
1. Open AWS and Navigate to Console \> EC2 \> Instances.
2. Open Cluster member instance, then select the Networking tab and get the ID of the External and Internal Interfaces.
(Optional) Fill this table (for convenience):
|----------------------|-----------------------|-----------------------|
| | External Interface ID | Internal Interface ID |
| Old Cluster member A | | |
| Old Cluster member B | | |
| New Cluster member A | | |
| New Cluster member B | | |
**How to get the interface ID:**
202302131802257.png)
202302131808268.png)
3. Navigate to **AWS Console** \> **VPC** \> **Route tables** , search for the routes that contain the Old Cluster interfaces (eni), then change it with the new ones.
202302131813439.png)
202302141212141.png)
4. Validate that the traffic goes through the new Cross AZ cluster active member.
**Using the same public IPs in AWS:**
\*\* It is assumed that when deploying the Cross AZ Cluster, the "Allocate Elastic IPs" section was set to "False":
1. Open AWS and Navigate to Console \> EC2 \> Network \& Security \> Elastic IPs.
2. Find in the IPs list the public IP that is associated with the old cluster member A and click on it:
3. Click on "Associate Elastic IP address"
4. Under the "Resource type" bullet choose "Instance" and under "Instance" bullet choose the cross AZ cluster member A instance and under "Private IP address" bullet choose its private IP and then click on "Associate":
5. Do the same steps mentioned in steps 2-4 for cross AZ member B
---
# Agent Instructions
This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.
## Navigating This Knowledge Base
- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content