Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Mike_Jensen
Advisor

Static Hide Behind Gateway NAT

I have a scenario where I would like to create static hide behind gateway NAT rules (see screen shot) so internal networks are able to be NAT'ed to the gateway clusters external IP address. 

I am using the cluster object in the translated source and a NAT does occur, the problem is the  translated source being applied is the gateway clusters internal private RFC 1918 IP and not the external public IP.

Is there a way I can manipulate this to choose the translated destination IP I need?

I am trying to avoid creating a duplicate object.

Some more background on this - I have two data centers, each with a external cluster and internal cluster.  I want certain internal networks to have hide behind gateway installed on both datacenter's external gateways but not on the internal gateways.  With object NAT I can only choose one gateway cluster or all.

If there is a way to install the hide behind on two clusters and not all that would be ideal.

0 Kudos
11 Replies
the_rock
Legend
Legend

I would say if you want everything behind the gw natted to external IP, then choose option in 1st screenshot. If you want only specific networks, then you can opt out for 2nd one.

Andy

0 Kudos
Mike_Jensen
Advisor

I tried the "Hide Internal networks behind the Gateway's external IP" like you have in the 1st screen shot but it doesn't work.

On page 70 of the R81.20 ClusterXL Administration Guide "The option Hide internal networks behind the Gateway's external IP (in the ClusterXL object properties > NAT pane) is not supported."

This is in the Active-Active Mode in ClusterXL, I am active/standby, but I am left with the impression this option isn't supported either way in R81.20 since it won't work for me.

In your second screen shot - is there a way I can have the object NAT installed on only 2 gateway cluster and not all?

0 Kudos
the_rock
Legend
Legend

Option 2 has to be supported, I have customers who use it on load sharing or HA cluster.  Why would 1st one not work? What do you see in the captures?

Andy

0 Kudos
Mike_Jensen
Advisor

Option 1 flat out doesn't do anything.  The log cards don't show any NAT being performed on the internet traffic.

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_ClusterXL_AdminGuide/CP_R81....

Take a look at page 70.

 

0 Kudos
the_rock
Legend
Legend

I just did, right. As far as option 1, well, if it fails, do some tcpdumps and fw monitors and see what gives. It works, for sure.

Also, make sure what I attached is checked.

Andy

 

0 Kudos
the_rock
Legend
Legend

K, I see what you meant, shows active-active, but active standby it works 100%.

0 Kudos
emmap
Employee
Employee

Manual NAT rules exist per policy, so you can add one for each gateway in their respective policies. If the gateways are sharing the policy, use the 'install on' field to set a NAT rule per gateway. 

The NAT behaviour for your rule there will hide the traffic behind the interface VIP that the traffic egresses the gateway on. If you want it to hide behind a specific IP regardless of egress interface, replace the gateway object on the 'translated source' side with a host object reflecting that IP. 

0 Kudos
Mike_Jensen
Advisor

In my scenario with the rule with the gateway cluster object the translated source is taking the IP that the traffic ingresses the gateway on and not the interface it egresses to the internet.

If I create a host object for the IP of a cluster VIP will that cause issues like a duplicate object will, since the cluster object includes all IP's of the cluster?

0 Kudos
PhoneBoy
Admin
Admin

Duplicate objects for the same IP are allowed, though we display a warning.
For gateways/clusters, as long as the "duplicate" is a host object, you should be fine.

0 Kudos
emmap
Employee
Employee

It shouldn't talk the ingress VIP, there's something curious going on there.

But yea, as Phoneboy said, no harm in setting a host object with a cluster VIP for this.

0 Kudos
the_rock
Legend
Legend

I agree there, does not hurt to try.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 07 Oct 2025 @ 09:30 AM (CEST)

    CheckMates Live Denmark!
    CheckMates Events