topic Re: R82 Management behind 3rd party NAT - Call for EA customers in Cloud Firewall

R82 Management behind 3rd party NAT - Call for EA customers

DanaEiny — Sun, 11 Feb 2024 08:14:27 GMT

Hi All,

R82 will introduce a new ability to simplify the use of management in public cloud.

The feature, known as “Management behind NAT”, simplifies the experience of managing GWs from a public cloud management using public IPs (As public IPs are netted be the CSPs).
We are looking for EA customers to join R82 EA program.

R82 EA program benefits:

Ability to try out and influence Check Point products
Direct R&D support
Check Point full assistance with all steps

Customers' requirements: (one of the following)

Customers with MDS in Public Cloud + Gateways in a remote network
Customers with 3rd party NAT devices that don't want to use dummy objects
Customers of Management behind NAT that use the registry SKs

Background:

R81.20 and below solution was mainly designed for NAT performed by another Check Point Gateway.

Illustration from the Management admin guide.

Issues with existing solution:

The solution sometimes required manual work-around (edit registry values) on the Gateways as described in sk171055 & sk171665
When the NAT was done by a 3^rd party NAT device or by a public cloud vendor the NAT configuration required the usage of dummy objects.

Main use-case for that is MDS in the Public Cloud - sk181701

MDS in Public Cloud topology:

R82 Main changes:

All configurations are in SmartConsole, no need to update registry values on the Gateways – See “Connection from Security Gateways to this server” in the screenshot below
Increased granularity to allow override configurations on the gateway object – for environments with both:

Gateways that communicate with the original IP address
Gateways that communicate with the translated IP address

Add support for NAT by 3^rd party NAT device or public cloud - See “Do not create automatic NAT rules” in the screenshot below.
The new capabilities are supported (for now) only on R82 gateways

The “Management/Log” is a new tab in the Gateway object

We will be delighted to have you as an EA customer and provide close support during the process.

Please contact me if you are interested or if you have any questions.

Re: R82 Management behind 3rd party NAT - Call for EA customers

the_rock — Sun, 11 Feb 2024 13:59:25 GMT

Very good feature indeed!

Andy

Re: R82 Management behind 3rd party NAT - Call for EA customers

genisis__ — Mon, 04 Mar 2024 20:31:46 GMT

Perhaps not the correct thread for this question, but does anyone know if Checkpoint have finally removed the need for local.arp when doing manual NAT in R82?

Re: R82 Management behind 3rd party NAT - Call for EA customers

the_rock — Mon, 04 Mar 2024 20:34:19 GMT

I never recall having to this after R81 base.

Andy

Re: R82 Management behind 3rd party NAT - Call for EA customers

genisis__ — Tue, 05 Mar 2024 10:34:58 GMT

Is this documented anywhere that the requirement for local.arp is no longer needed for manual NAT from R81.10?

Re: R82 Management behind 3rd party NAT - Call for EA customers

the_rock — Tue, 05 Mar 2024 12:11:16 GMT

Not that I know of.

Re: R82 Management behind 3rd party NAT - Call for EA customers

AmirArama — Wed, 06 Mar 2024 22:51:58 GMT

You don't need to deal direcrly with local.arp file. But you have a clish command set arp proxy for that.

Re: R82 Management behind 3rd party NAT - Call for EA customers

genisis__ — Thu, 07 Mar 2024 12:49:36 GMT

That is what I though, so the idea is entries are added via CLISH and in turn this is added to the local.arp file, now for VSX I can add an entry in the CLI however no local.arp file is created and entries added.
I was looking at SK30197 (old downloaded pdf)