Scribd
Upload
21 views6 pages

Multi-Domain Management Server (MDS) NAT Configuration For Public Clouds

This document provides instructions for configuring NAT and static routes on Check Point devices in public clouds to allow communication between devices and security gateways using public IP addresses. It includes steps for configuring dummy gateways and host objects in SmartConsole and enforcing the use of NATed IPs on security gateways.

Uploaded by

Zoumana Diomande
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
21 views6 pages

Multi-Domain Management Server (MDS) NAT Configuration For Public Clouds

This document provides instructions for configuring NAT and static routes on Check Point devices in public clouds to allow communication between devices and security gateways using public IP addresses. It includes steps for configuring dummy gateways and host objects in SmartConsole and enforcing the use of NATed IPs on security gateways.

Uploaded by

Zoumana Diomande
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Multi-Domain Management Server (MDS) NAT configuration for public clouds

ProductMulti-Domain Security Management

VersionR80.40 (EOL), R81, R81.10, R81.20

PlatformAWS, Azure, Google Cloud Platform

Last Modified2023-11-30

Solution

This article explains how to configure Primary MDS, Secondary MDS, and MLM behind
Public/Elastic IP addresses in public cloud platforms (AWS, Azure, and GCP).

Background:

Public cloud providers do NAT when a Virtual Machine communicates with its Public/Elastic IP
address.

When MDS in a public cloud communicates with a Security Gateway with its Public/Elastic IP
address, it is required to configure static NAT configuration for each CMA/CLM object that is
behind a Public/Elastic IP address.

Example environment:

1. Domain_A_Server is the active CMA.

2. Domain_A_SEC_Server is the standby (backup) CMA.

3. Domain_A_CLM_Server is the main Log Server.

4. Domain_A_Server and Domain_A_SEC_Server are the backup Log Servers.

Dummy objects configuration in SmartConsole

1. Log in to the active CMA.

2. Create a new dummy Gateway object:

a. In the Gateway’s general properties, set a dummy IPv4 address (for example
1.2.3.4).

b. Make sure that only the Firewall blade is enabled.

c. Navigate to the Network Management tab.

d. Click Action and create an interface in the subnet range for each relevant object
requiring NAT configuration.

e. Network interface configuration:

i. From the General tab, click Modify.


ii. Below Lead to, select:

1. Override.

2. This Network (internal).

3. Network defined by the interface IP and Net Mask.

iii. Below Anti-Spoofing, disable Perform Anti-Spoofing based on interface


topology.

iv. Click OK.

f. Publish the changes.

Example:
Configure Active, Standby CMAs and CLMs in SmartConsole

1. Log in to the active CMA.

2. Edit the relevant Check Point Host objects.

3. Navigate to the NAT tab:

1. Click on Add Automatic Translation rules.

2. Select Translated method - Static.

3. Enter the Public CMA/CLM address in the IPv4 Address field.

4. In Install on Gateway select the dummy gateway.

5. Click on Apply for Security Gateway control connections.

4. Publish the changes.


5. Install database-relevant Check Point Host objects.

Example:

Enforcing the Security Gateway to use the NATed IP (based on sk171055):

1. Connect to the Security Gateway with SSH and enter Expert mode.

2. Run these commands:

a. ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 FORCE_NATTED_IP -n 1 fw


fetch -f

b. cpwd_admin stop -name FWD -path "$FWDIR/bin/fw" -command "fw kill


fwd"

c. cpwd_admin start -name FWD -path "$FWDIR/bin/fw" -command "fwd"

3. From the active CMA, install the policy on the Security Gateway.

Follow these instructions for each Security Gateway that must communicate with the
CMA/CLM with its public/elastic IP address.
Note: The configuration can be done automatically for Auto Scale Instances (Gateways)
managed by Cloud Management Extension (CME). You can do this by configuring a custom
gateway script that runs the command above on each provisioned Gateway. To Configure a
custom gateway script, refer to Cloud Management Extension Administration Guide > CME
Structure and Configurations > Configuration Templates (gateway-configurations) > Supported
Configuration Template parameters > General Parameters > CUSTOM_GATEWAY_SCRIPT.

Logs and fetch policy (optional)

Follow these steps if you want to override the default values:

1. Log in to the active CMA.

2. Edit the Security Gateway object.

3. Navigate to the Logs tab.

4. Update the tables with the relevant Check Point Host objects.

5. Navigate to Fetch Policy tab.

6. Update the tables with the relevant Check Point Host objects.

7. Click OK.

8. Publish the changes.

Example:
Note: Logs configuration can be done automatically for Auto Scale Instances (Gateways)
managed by Cloud Management Extension (CME). To configure Log Server settings, refer
to Cloud Management Extension Administration Guide > CME Structure and Configurations >
Configuration Templates (gateway-configurations) > Log Server parameters

You might also like