- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: NAT rule hiding source IP of external address
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
NAT rule hiding source IP of external address
Seems like a pretty basic question, but been searching for days and still haven't found an answer.
I simply want to Source Nat / "Hide" traffic from certain internet IP addresses coming in via the external network. In this packet flow:
198.51.100.111 (Internet IP) ---> 203.0.113.222:8080 (Checkpoint External IP) ---> 10.10.10.111:80 Web server on internal network
The NAT Policy rule is written like so:
Source: All_Internet
Original destination: 203.0.111.222
Original Service: HTTP_proxy
Translated source: = Original
Translated destination: 10.10.10.111
Translated Services: http
Usually the web server would see the source IP 198.51.100.111 on traffic from internet. I instead want it to see the Checkpoint's internal interface IP address of 10.10.10.1
What should be in the "Translated source" field for this to work?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
just take the gateways interface from the objectslist.
There should be an entry named <yourgateway>_<interface-name>.
Select the interface which heads towards to http server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
GCP is slightly different story.
You need to create a dynamic host object for each gcp internal lb ip. So one object for management vpc and additional one for your service-networks vpc. Than use the according object as translated source.
Please refer link below how to create dynamic objects.(Section Firewall and Natrules -> Create dynamic objects.)
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_and_Above_CG_Autoscaling_Man...
additional reference:
sk121637
https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_IaaS_HighAvailabilty_for_G...
HtH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I opened a case last week and the best solution they could provide was create local dynamic objects on each individual member with its internal IP address, i.e.
# On Cluster member-a
dynamic_objects -n LocalGateway-eth2 -r 10.10.10.2 10.10.10.2 -a
# On Cluster member-b
dynamic_objects -n LocalGateway-eth2 -r 10.10.10.3 10.10.10.3 -a
Then write a NAT rule with Translated Source = LocalGateway-eth2, NAT method = Hide
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
just take the gateways interface from the objectslist.
There should be an entry named <yourgateway>_<interface-name>.
Select the interface which heads towards to http server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the response.
In SmartConsole, the gateway is called 'gateway1', with External interface eth0 and Internal interface eth1.
There is indeed object called gateway1_eth1, but it's a network group that lists the RFC 1918 blocks:
- 10.0.0.0/255.0.0.0
- 172.16.0.0/255.240.0.0
- 192.168.0.0/255.255.0.0
I certainly do not remember creating this, so assume it was auto-discovered by looking at static routes during the import process.
The object with the internal IP was simply called "gateway1" which makes sense. This gateway is deployed in AWS so eth1 is the management interface (I think CheckPoint calls this the "main" interface).
I've set that as the translated source, verified NAT method was set to "hide", and it's doing exactly what I want. The web server is receiving traffic from 10.10.10.1 now
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How would this work in a cluster scenario where the two members share an external IP address, but the internal IP addresses are standalone?
Reason I ask is for the next step I have to get this configuration working on a cluster deployed in GCP. There's a dynamic object called LocalGatewayExternal which automatically references the external interface, but I can't find a corresponding one for the internal interface.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is no such thing as a VIP in public cloud deployments. High Availability is handled by mapping the external IP address to the external NIC of the active cluster member, and pointing the default route to the internal NIC of the active. Failover is then handled via API call
The guide, which I'm attaching, mentions creating a dynamic object called LocalGatewayExternal which represents the external NIC. On a guess, I created a Dynamic Object called LocalGatewayInternal and that seems to represent the main (management) interface of the local gateway. This works in our case because the management and internal networks are peered, but ideally I'd really like the internal interface to be used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're using the Checkpoints to terminate site-to-site VPNs to customers, so doing standalone w/ load balancer is not an option. We need an HA deployment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
GCP is slightly different story.
You need to create a dynamic host object for each gcp internal lb ip. So one object for management vpc and additional one for your service-networks vpc. Than use the according object as translated source.
Please refer link below how to create dynamic objects.(Section Firewall and Natrules -> Create dynamic objects.)
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_and_Above_CG_Autoscaling_Man...
additional reference:
sk121637
https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_IaaS_HighAvailabilty_for_G...
HtH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I opened a case last week and the best solution they could provide was create local dynamic objects on each individual member with its internal IP address, i.e.
# On Cluster member-a
dynamic_objects -n LocalGateway-eth2 -r 10.10.10.2 10.10.10.2 -a
# On Cluster member-b
dynamic_objects -n LocalGateway-eth2 -r 10.10.10.3 10.10.10.3 -a
Then write a NAT rule with Translated Source = LocalGateway-eth2, NAT method = Hide
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Maarten,
I have condition, cluster gateway using the interface to nat all internal behind gateway is enable.
may question is there available to create specific NAT Loopback using IP external of the cluster? like on the SK110019, https://support.checkpoint.com/results/sk/sk110019 , I mean if we configure NAT with that condition (R81.10) is any impact for another traffic, cause the config enable the hide all internal behind gateway?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
NAT rules are enforced in order.
Not sure where the gateway/cluster objects "Hide All Behind Gateway" falls in the order, but I believe it will apply if no other rule does.
