Table of Contents:

1. Introduction
2. Background
3. Supported upgrade paths
4. Upgrading CloudGuard for AWS Gateway from R77.30 to R80.10
5. Upgrading CloudGuard for AWS Security Management Server / StandAlone from R77.30 to R80.10
6. Upgrading CloudGuard for AWS Security Management Server from R80 to R80.10
7. Known Limitations

(1) Introduction

This article describes the recommended procedure for upgrading CloudGuard IaaS in the Public Cloud to Check Point CloudGuard IaaS R80.10 version.

For upgrade from R80.10, refer to:

Management: sk155632

Gateway: Updating the AMI/Version of the Auto Scaling group: sk112575: Updating the AMI of the Auto Scaling group

(2) Background

In-place upgrade of CloudGuard for AWS with CPUSE is not supported. If you tried to perform such an upgrade using CPUSE, then it would fail with an error, even though CPUSE verification might show "Upgrade is allowed":

Where the error is displayed?	Build of CPUSE Agent	Error text
Gaia Portal	1294 and lower	The package failed to install at DATE TIME Reason of failure: Failed to access an installation file.
	1298 and above	Operation failed. Upgrades in Public Cloud environments (AWS and Google Cloud Platform) are not supported.
Gaia Clish	1294 and lower	Result: Install of package Check_Point_R80.10_T421_Fresh_Install_and_Upgrade_from_R7X.tgz Failed Failed to access an installation file. Contact Check Point Technical Services for further assistance. Status: Install Failed (Reason: Failed to access an installation file.)
	1298 and above	Reason of failure: Internal error when running hook: /var/log/tmp/bundle_tmpdir_CheckPoint#CPUpdates#All#6.0#4#8#BUNDLE_R80_10_T421_PLgn4g/scripts/pre_R80.10_upgrade_verifications.sh. More information: Operation failed. Upgrades in Public Cloud environments (AWS and Google Cloud Platform) are not supported.

 

(3) Supported upgrade paths

The table below describes the supported versions for upgrading to R80.10:

Machine Role in AWS	Source version	Target version
Management Server	R77.30, R80	R80.10
Security Gateway	R77.30
StandAlone machine	R77.30

Notes:

• Any limitation related to Advanced Upgrade that appears in R80.10 Installation and Upgrade Guide applies to these procedures as well.
• Upgrade from R77.30/R80 to R80.20 is similar to R80.10.

(4) Upgrading CloudGuard for AWS Gateway from R77.30 to R80.10

There are two methods for upgrading CloudGuard for AWS Gateway instances:

Upgrade method	Action plan
"Side by Side"	This method allows upgrading with minimum down time: Deploy a new CloudGuard for AWS Gateway R80.10 instance from AWS CloudFormation Templates. Perform all the necessary configuration offline (no down time during this stage). Shift the traffic to the newly installed CloudGuard for AWS Gateway R80.10 instance.
"Keep the same network interfaces"	This method requires a longer downtime: Deploy a new CloudGuard for AWS Gateway R80.10 instance from the AWS Marketplace using the old instance's Network Interfaces (thus preserving the same configuration). Perform all the necessary configuration.

• Method #1: Upgrading "Side by Side"

  1. Deploy a new CloudGuard for AWS Gateway R80.10 using AWS CloudFormation Templates (in the same subnet(s) as the CloudGuard for AWS Gateway R77.30 Gateway).

  2. If the existing CloudGuard for AWS Gateway R77.30 is connected to additional internal subnets, add an interface and connect the new CloudGuard for AWS Gateway R80.10 instance to every desired subnet in your VPC (follow sk92916 - Adding a Network Interface to the Virtual Appliance for AWS).

  3. On your R80.10 Management Server, create the new CloudGuard for AWS Gateway object and initialize SIC with it.

  4. Configure the new CloudGuard for AWS Gateway R80.10 in the same way as the existing CloudGuard for AWS Gateway R77.30 (while still keeping the CloudGuard for AWS Gateway R77.30).

     Note: Do not to include VPN configuration (in order to avoid downtime to existing configuration).

  5. Install policy on the new CloudGuard for AWS Gateway R80.10 (traffic is still forwarded to the original CloudGuard for AWS Gateway R77.30).

  6. To perform the actual cutover (pay attention, actual downtime is expected through this phase):

     1. Elastic IP address:

        1. Option 1: Preserve the old Elastic IP address by moving it to the new CloudGuard for AWS Gateway R80.10 instance.

        2. Option 2: Configure public reference to the new IP address (e.g., DNS or other required 3rd party configuration).

     2. In SmartConsole, change VPN configuration to include the new CloudGuard for AWS Gateway parameters (IP address, certificate, VPN community, etc.).

     3. In SmartConsole, install policy to all involved firewalls in the environment (so that the new CloudGuard for AWS Gateway will be updated across all environments).

     4. Change AWS Route Table and Load Balancers configuration to point to the new CloudGuard for AWS Gateway R80.10 instance.

  7. To rollback:

     1. Undo all changes performed in Step 6.

     2. In SmartConsole, install policy.

  
  
  

• Method #2: Upgrade while keeping the same network interfaces

  1. Copy the configuration details from the existing CloudGuard for AWS Gateway R77.30 instance.

     1. Write down the Network Interfaces IDs as they appear in the AWS Console.

     2. Copy Firewall object configuration from the SmartConsole (Topology, VPN, Anti-Spoofing, Software blades configuration, etc.).

  2. Stop the CloudGuard for AWS Gateway R77.30 instance (downtime starts here).

  3. Go to the AWS Marketplace.

  4. Deploy a new CloudGuard for AWS Gateway R80.10 in the same subnet(s) as the CloudGuard for AWS Gateway R77.30 instance.

     Note: Make sure to select the same network interfaces you have used in Step 1 for the new CloudGuard for AWS Gateway R80.10 instance.

  5. In SmartConsole, change the version in the existing CloudGuard for AWS Gateway object from R77.30 to R80.10 and re-initialize SIC with the new CloudGuard for AWS Gateway R80.10 instance.

     1. Interfaces properties, such as topology and Anti-Spoofing should be reconfigured.

     2. For CloudGuard IaaS Controller, Identity Awareness blade should be reconfigured according to R80.10 and based on the configuration you have written down before the upgrade.

  6. In SmartConsole, install policy on the new CloudGuard for AWS Gateway R80.10 instance.

(5) Upgrading CloudGuard for AWS Security Management Server / StandAlone from R77.30 to R80.10

Action plan:

1. Export the management database from the source R77.30 Management Server / StandAlone machine.

2. Deploy a new CloudGuard for AWS R80.10 instance in the same subnet(s) as Management Server / Standalone machine (either from the AWS Marketplace, or AWS CloudFormation Templates)

3. Import the management database (exported from the source R77.30 machine) into a new CloudGuard for AWS R80.10 instance.

4. If an Elastic IP address is used, then move the Elastic IP address from the source (old) Management Server / StandAlone machine to the target (new) CloudGuard for AWS R80.10 instance.

For detailed instructions about exporting / importing of the management database, refer to the R80.10 Installation and Upgrade Guide - chapter "Advanced Upgrade with Database Migration".

Notes:

1. Instance configuration that is not part of the database should be reconfigured.
2. If different IP addresses are used on the source and target machine, license should be reassigned.

(6) Upgrading CloudGuard for AWS Security Management Server from R80 to R80.10

Currently, upgrade of CloudGuard for AWS from R80 to R80.10 requires close monitoring by Check Point Support.

Contact Check Point Support to get the relevant upgrade instructions.
For faster resolution and verification, please collect CPInfo files from the Security Management Server involved in the case.

(7) Known Limitations

Topic

Description

Upgrading Clusters in the same VPC

This will cause an outage when you initiate the upgrade Cluster deployment CloudFormation Template. This is due to the route table that is created in the new deployment will change the backend subnet where eth1 of the gateway is configured to be the next hop ENI of the new Cluster. This is expected behavior. To mitigate how long the outage is, simple change the default route of the backend subnet back to the ENI of the original Cluster Active member.