Support Center > Search Results > SecureKnowledge Details
Deploying a Check Point Cluster in Oracle Cloud Infrastructure (OCI) Technical Level

Note:  The current recommended version for Oracle Cloud is R80.40 with the latest GA Jumbo.

Table of Contents:

  1. Overview
  2. Prerequisites
  3. Method of Operation
  4. Solution Topology
  5. CloudGuard Cluster Deployment
  6. Configuring OCI Cluster in Check Point Security Management
  7. Known Limitations
  8. Related Documentation
  9. Adding Additional Secondary IPs to OCI Cluster

[1] Overview

Oracle Cloud Infrastructure combines the elasticity and utility of public cloud with the granular control, security, predictability and bringing the agility and fast-paced innovation of cloud computing - performance, high availability and cost-effective infrastructure services

Check Point CloudGuard for Oracle extends advanced Threat Prevention security to protect customers' OCI environments from malware and other sophisticated threats. As a Oracle certified solution, CloudGuard enables you to easily and seamlessly secure your workloads, data and assets while providing secure connectivity across your cloud and on-premises environments.

This article will guide you in deploying a Check Point CloudGuard High Availability cluster in Oracle Cloud Infrastructure.

[2] Prerequisites

It is assumed that the user is familiar with general Oracle concepts, features, and terms. These include the following:

[3] Method of Operation

A traditional Check Point cluster environment uses multicast or broadcast in order to perform state synchronization and health checks across cluster members.

Since multicast and broadcast are not supported in Oracle, the Check Point cluster members communicate with one another using unicast. In addition, in a regular ClusterXL working in High Availability mode, cluster members use Gratuitous ARP to announce the MAC Address of the Active member associated with the Virtual IP Address (during normal operation and when cluster failover occurs). 

In contrast, Oracle implements this by making API calls to OCI. When an Active cluster member fails, the Standby cluster member is promoted to Active and takes ownership of the cluster resources. As part of this process the member:

  • Associates the cluster's Private and Public Secondary IP addresses attached to the Primary vNIC
  • Associates any pair of Secondary Public/Private IP attached to the Primary vNIC (for any published service)
  • Associates the Secondary Private IP attached to the Secondary vNIC

Oracle API Authentication

In order to make API calls to Oracle automatically, the cluster members need permission to perform the API calls in the actual compartment. This is achieved using Oracle Identity Manager.

In this article, we will guide you in doing the following:

  • Create a Dynamic Group with a proper rule defining only both cluster members as part of the Dynamic Group
  • Create a policy for the defined Dynamic Group

[4] Solution Topology

To best explain the configuration steps, we will use the following example environment. When you follow the configuration steps below, make sure to replace the IP addresses in the example to reflect your environment.

[5] CloudGuard Cluster Deployment

Show / Hide this section
Follow the instructions below in order to deploy Check Point's CloudGuard Cluster solution in Oracle. Perform the steps from the Oracle portal using the preferred compartment(s).

1. Sign in to your OCI tenant account.

2. Select the relevant CloudGuard listing from the Oracle Cloud Marketplace.

3. Create a new VCN or choose an existing VCN (for example VCN with CIDR Block ). 

4. Add two subnets to your VCN: one public subnet and one private subnet.

  • Frontend public subnet (Ex. -
  • Backend private subnet (Ex. -

OPTIONAL:  Each subnet can be placed in its own independent VCN.  In this scenario the VCN CIDR will only contain only one subnet that consumes the entire CIDR of the VCN. 
Example:  VCN defined as would have one subnet also using

5. Create a public subnet: for example, frontend (CIDR Block 

OPTION:  The Frontend subnet can also be private.  In this case the default route for the Frontend subnet needs to be set to use a Target Type of Service Gateway and a Destination Service of All <Region> Oracle Services in Oracle Services Network in order for the API calls to be successful.

6. Create a private subnet: for example, backend (CIDR Block


Final VCN configuration with two subnets: frontend and backend.


    7. Configure your VCN's Security List to allow all traffic on all protocols.  We will be allowing Check Point to control and monitor all traffic.


    8. Create both CloudGuard cluster members. 

    9. By default, the Primary vNIC on each instance will be attached to the frontend subnet.

    10. Add a Secondary vNIC to each cluster member.

    Note: The Primary vNIC should be connected/attached to the frontend subnet; the Secondary vNIC should be connected to the backend subnet.

    Note: It is very important that you make sure both vNICs of each cluster member are configured with the check box for Skip source/destination check.

    11. Choose one of the cluster members (only one) and add a new Secondary Private IP to the Primary vNIC.

    12. Create a reserve Public IP and attach it to the Secondary Private IP you created in step 11. This will serve as the cluster IP.

    13. Create one more Secondary private IP and attach it to the member's Secondary vNIC of the chosen member from step # 11 (secondary VIP for outbound traffic).

    14. Add the following new routing tables to the Private Subnet (the backend subnet, which should be configured after adding the Additional Secondary vNIC) and the Public subnet, respectively. This rule redirects the traffic to the Secondary Private IP of the Secondary vNIC (traffic goes through the VIP).

    15. Add the following Route Table to the Public Subnet (Frontend).

    16. Create a Dynamic Group and include both members in this Dynamic Group (in this example, we will name it cp_cluster_group). You can create the rules which define the Dynamic Group by using the OCI Rule Builder: create two separate rules, one for each member. If you are not using the OCI Rule Builder, you can manually define a single rule to include both members, as appears below.

    17. Create the policy and allow the defined Dynamic Group to use resources in the compartment to which it belongs.

    18. Connect to both CloudGuard members using the Private Key match to the Public Key you used when you created the instance (ssh –i privateKey admin@<cluster-member-public-ip>) and set the password by running the following command:

    > set user admin password

    - insert your password <XXXXX>

    > save config

    > exit

    19. Connect to the members using a web browser with the member public IP and complete the Blink wizard information to finish configuration.


    User name : admin

    Password: XXXXX

    20. Configure the CloudGuard members and Cluster in the Management SmartConsole (see below).

    Best Practice: Apply latest GA Jumbo Hotfix Accumulator to each cluster member

    [6] Configuring OCI Cluster in Check Point Security Management

    Show / Hide this section

    CloudGuard Network Security Gateway

    The CloudGuard Network Security Gateway can be managed in several ways, including the following:

    • A standalone configuration in which the Security Gateway acts as its own management.
    • Centrally managed, in which the management server is located on-premises outside the virtual network. 
    • Centrally managed, in which the management server is located in the same virtual network.

    CloudGuard Cluster Configuration

    1. Connect with Check Point SmartConsole to the Check Point Management Server.

    2. Create a new Check Point Cluster: in the Cluster menu, click on Cluster...

    3. Select Wizard Mode.

    4. Insert the cluster object's name (e.g., checkpoint-oci-cluster). In the Cluster IPv4 Address field, enter the public address (Secondary Public IP address of the Primary vNIC) allocated to the cluster and click on the Next button.

    Note: To see the Cluster IP address in the OCI portal, select the CloudGuard Active Member's Primary VNIC and then choose the Secondary Public IP (Secondary Public IP of the Primary vNIC; Primary vNIC is the first vNIC of the deployed instance).

    Example cluster configuration:

    5. Click on the Add button to add the cluster members.

    6. Configure cluster member properties:

    1. In the Name field, insert the first cluster member's name (e.g., member1).
    2. In the IPv4 Address field: If you are managing the cluster from the same VCN, then insert the member's Primary Private IP address of the Primary vNIC. Otherwise, insert the member's Primary public IP address of the Primary vNIC.
    3. In the Activation Key field, insert the SIC (Secure Internal Communication) key you defined forthe CloudGuard member during FTW configuration.
    4. In the Confirm Activation Key field, re-enter the key and click on InitializeThe Trust State field should show: "Trust established."                                                                                              
    5. Click OK.


    7. Repeat steps 5-6 to add the second CloudGuard cluster member. Click on the Next button.


    8. In the new window, click on Finish:

    9. Click on the Finish button.

    10. Review the cluster configuration and configure the cluster interfaces:

    1. Click on cluster object checkpoint-oci-cluster.
    2. Click on Network Management.
    3. Double-click on eth0.
    4. Click on General.
    5. Choose Network Type Cluster and insert the member's Secondary private IP address of the Primary vNIC (definition of first VIP).
    6. Click OK.
    7. In Network Management, double-click on eth1.
    8. Click on General.
    9. Choose Network Type "Cluster + Sync" and insert the member's Secondary private IP address of the Secondary vNIC (definition of the second VIP).
    10. Click OK and exit the cluster object configurations dialog.



    11. To provide Internet connectivity to the internal subnet (publish services) use NAT Rules.

    12. Configure and install the Security policy on the cluster.

    [7] Known Limitations

    Show / Hide this section
    • NTP must be configured in order for failover to work properly > Oracle API requirements
    • CloudGuard Controller is not yet supported for OCI.
    • To inspect East/West traffic, each backend subnet that requires inspection needs to exist in its own VCN and routed to the backend VNIC via LPGs or DRG.
    • You can assign up to 32 pairs of private and public IPs for publish services.

    Show / Hide this section

    [9] Adding Additional Secondary IPs to OCI Cluster

    Show / Hide this section
    If secondary IPs other than the main cluster IP need to be attached to the Active cluster member, the following must be done:

    1. Attach all desired secondary IPs to the Active cluster member in the OCI console.

    2. Push policy to the gateways.

    Give us Feedback
    Please rate this document