Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
DanaEiny
Employee
Employee

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

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:

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

 

Customers' requirements: (one of the following)

  1. Customers with MDS in Public Cloud + Gateways in a remote network
  2. Customers with 3rd party NAT devices that don't want to use dummy objects
  3. 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.

DanaEiny_0-1707639248552.png

 

 

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 3rd 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:

DanaEiny_1-1707639248559.png

 

 

R82 Main changes:

  1. 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
  2. Increased granularity to allow override configurations on the gateway object – for environments with both:
    1. Gateways that communicate with the original IP address
    2. Gateways that communicate with the translated IP address
  3. Add support for NAT by 3rd party NAT device or public cloud -  See “Do not create automatic NAT rules” in the screenshot below.
  4. The new capabilities are supported (for now) only on R82 gateways

 

DanaEiny_2-1707639248561.png

 

 

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

DanaEiny_3-1707639248563.png

 

 

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.

(1)
7 Replies
the_rock
Legend
Legend

Very good feature indeed!

Andy

0 Kudos
genisis__
Leader Leader
Leader

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?

0 Kudos
the_rock
Legend
Legend

I never recall having to this after R81 base.

Andy

0 Kudos
genisis__
Leader Leader
Leader

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

0 Kudos
the_rock
Legend
Legend

Not that I know of.

0 Kudos
AmirArama
Employee
Employee

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

0 Kudos
genisis__
Leader Leader
Leader

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)

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.