topic Re: Oracle Cloudguard upgrade from 80.40 in Cloud Firewall

Oracle Cloudguard upgrade from 80.40

ishuyell — Sun, 11 Dec 2022 08:02:39 GMT

Hi,

Is there a guide or steps to follow for upgrading OCI Cloudguard from R80.40 to R81.10? Already checked sk162365 .

Thanks

Re: Oracle Cloudguard upgrade from 80.40

PhoneBoy — Mon, 12 Dec 2022 14:42:56 GMT

You can’t do an in-place upgrade on Oracle yet to the best of my knowledge.
Which means doing an advanced upgrade for the management, which is covered in the Install/Upgrade guide.

Re: Oracle Cloudguard upgrade from 80.40

avivs — Mon, 12 Dec 2022 16:14:10 GMT

Supported platforms, versions & configuration for in-place upgrade in CloudGuard products is described in sk177714 - CloudGuard for Public Cloud In-Place upgrade packages.

At the moment, only Azure & AWS are supported.

Re: Oracle Cloudguard upgrade from 80.40

ishuyell — Mon, 12 Dec 2022 16:16:43 GMT

Yes, I understand that. I was looking for a guide to upgrade the gateway and not for in-place upgrade.

Re: Oracle Cloudguard upgrade from 80.40

avivs — Mon, 12 Dec 2022 16:30:05 GMT

With In-place upgrade not supported on Oracle, the only option for upgrading the version of the gateway is to deploy a new gateway.

Re: Oracle Cloudguard upgrade from 80.40

fpaez — Fri, 05 May 2023 22:30:46 GMT

Hi,

I understand that we have to deploy new gateways, but this involves creating new public IPs, and new floating IPs for failovers, we know how to manage Check Point but cloud providers have their own procedures to move resources between VMs and I think the idea of the question in this post is to have the correct procedure to do that for OCI Cloud, for other cloud providers (AWS, Azure) the procedure is very clear and you can replicate it on a lab, and we want to do the same on OCI. In my case, we need to upgrade from R80 to R81.10

Best regards,

RFP

Re: Oracle Cloudguard upgrade from 80.40

Jeff_Engel — Mon, 22 May 2023 13:14:24 GMT

Hi @fpaez ,

Apologies for not seeing this post sooner! Here are the steps I have used for this procedure(also should not require new public IPs):

1.) Document all VCNs/subnets/etc for the current Standby member

eth0 >

eth1 >

VCN >

Frontend subnet >

Backend subnet >

2.) Document all Gaia static routes

3.) Stop the Standby member

4.) Create new R80.40(or whatever the relevant target version is) firewall instance using upgraded shapes with same amount of OCPU's as existing and use Hardware-assisted SRIOV/VFIO networking

5.) Create backend interface and attach to appropriate VCN/subnet...check Gaia to make sure backend real IP is set on eth1...might need to be done manually

6.) Complete first-time configuration and apply same jumbo hotfix(if needed) as installed on Active cluster member

7.) Ensure that CoreXL instances match on both cluster members...update and reboot if needed

8.) Re-apply static routes to new firewall instance

9.) Add new firewall instance OCID to the proper OCI Dynamic Group so that cluster API calls will continue to work

10.) In SmartConsole, reset SIC on existing Standby member object and update IP address to match newly built firewall

11.) Establish SIC

12.) Update cluster topology - Network Management > Get Interfaces with Topology...ensure new firewall instance IP's are reflected

13.) Push policy and verify cluster state

14.) During maintenance window, test a failover

15.) Detach/attach licenses as needed

16.) Repeat above steps for remaining cluster member

Also recommend talking to your local Oracle engineer and Check Point architect. Please reach out if you need further assistance or have questions.

Best Regards,

Jeff