Part 8 - Network Address Translation

[_Val_]

In this part, we will discuss different types of Network Address Translation (NAT), set up Internet access for our lab, and review a common example of Port Forwarding.

Types of NAT

NAT settings are part of the Access Control policy, as we have mentioned in Part 7:

Check Point has two different ways of setting up Network Address Translation: Automatic NAT and Manual NAT. Each of them allows configuring two different types of NAT: Hide NAT and Static NAT:

Hide NAT translates multiple internal addresses into a single IP (many to one translation). That allows internal clients to open connections to external networks. Outside of your security gateway, these connections will look as originated from a single IP address. To perform such Address Translation, the Security Gateway will change both the IP address and source port on the outgoing packets. On the return traffic, the destination IP address and port will be translated back to their original values so the packets can reach the originating client machine.

This type of NAT does not allow access to internal resources from external networks.

Static NAT preforms one to one translation, changing only appropriate IP addresses of the packets: Source IP address on the Client to Server packets and Destination IP address on Server to Client ones.

Static NAT is commonly used to ensure reachability of DMZ resources from Internet.

Let’s review cases of Automatic and Manual NAT configurations on more details.

1. Automatic NAT

This way of setting NAT is quite simple. NAT parameters are configured on an object requiring Network Address Translation, with two clicks. You need to open that object and add appropriate settings in its NAT tab.

Let us configure Automatic NAT for our LanNetwork object. In SmartConsole, double-click on it and go to the NAT tab.

Mark “Add automatic address translation rules” checkbox.

The translation method menu has two options: Hide (which is the default one) or Static. Leave the default value and press OK.

This action will create Automatic NAT rules. Move to Security Policies > Access Control > NAT to see them:

In a similar manner, set up Automatic NAT for our DMZ-Srv object:

These settings will allow the server to reach the Internet but not allow hosts on the Internet to reach the server. If we want to make the DMZ server accessible from external network on all services, we create an automatic static NAT. An additional external IP address is needed for this.

If we only need to forward specific services, such as HTTP, we can configure Port Address Translation (port forwarding). We can only do that by adding manual NAT rules.

2. Manual NAT

Manual NAT rules need to be explicitly created in the NAT Policy rulebase.

In our case, we want to forward only HTTP traffic to our DMZ server when someone is trying to reach it from external networks.

Let’s take a look on our network diagram once more:

To allow access with HTTP to our DMZ server, we need to make some additional changes.

Create a new host object with the external IP address of our Security Gateway:

Now, let’s add our new manual static NAT rule.

Go to Security Policies > Access Control > NAT and add a new rule to the top of the rulebase:

Manual NAT allows creating more sophisticated rules for Network Address Translation. We can now work with all the available fields of the rule:

• Original Source
• Original Destination
• Original Service
• Translated Source
• Translated Destination
• Translated Services

Static or Hide NAT method can be used here. To choose a desired NAT method, right-click on the Translated Source / Translated Destination field, and choose either Static or Hide, as show below.

Create the manual NAT the rule in the following manner:

• Original Source: Any
• Original Destination: PublicIP (the object we have just created)
• Original Services: http
• Translated Source: Original (we are leaving Source IP address as is)
• Translated Destination: DMZ-Srv (Translated Destination should be our Windows Sever)
  Important: Use Static Nat Method here
• Translated Services: Original (Destination port stays unchanged)

Note: Letter “S” next to Translated Destination field symbol specifies Static NAT Method we have set.

Finally, we need to add an access rule allowing external users to reach DMZ server via HTTP service. To do so, go to Security Policy Rulebase and add a new rule called DMZ-Srv Access at the very top of the rulebase, with the following parameters:

• Name: DMZ-Srv Access
• Source: Any
• Destination: PublicIP
• Services & Applications: http
• Action: Accept
• Track: Log
    

Install Policy:

As before, choose only the Access Control policy to be installed:

Once policy is installed successfully, we can start testing.

 

Testing access

With all the changes above maid properly, Internet should now be accessible from the lab Internal Network. In addition, Port Forwarding should allow HTTP access to DMZ-Srv machine from external networks.

Our Access and NAT policies allow Lab User PC to access Internet Web resources, but ping should not be working for the routable Internet IP addresses:

To check Port Forwarding functionality, we should access the external IP address of our Security Gateway with HTTP. In our case, with a VMware Workstation based lab environment, we can use VMware host PC, through VMnet8 adapter.

Let’s test it:

Thus, we have completed the basic NAT settings.

In the next parts of our course, we will work with Application Control and URL Filtering.

----------------------------

Authors and contributors

Author - Evgeniy Olkov‌, CTO at TS Solution. 
Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine‌

Review and editing - Dameon Welch-Abernathy

[Don_Paterson]

Unless I am missing something the Manual NAT rule in the last example here cannot work unless a proxy ARP is configured.

The steps and description for that seems to be missing from this page/lab.

Makes me wonder what was configured to get the last screenshot.

Regards,

Don

[Timothy_Hall]

A manual Proxy ARP is not necessary in this case since port forwarding of http to the DMZ server is being accomplished using the firewall's existing external interface IP 192.168.206.5.  The firewall will already answer ARP requests for that IP address from the Internet perimeter router.  If the manual NAT example was using another IP address plucked from the subnet located between the firewall and the perimeter router (such as 192.168.206.155 assuming a /24 mask) then yes a manual static proxy ARP would be needed.

[_Val_]

On top what Tim said, we can also tackle the issue of not having a manual ARP proxy with external routing 

[Don_Paterson]

Understood. I see what i missed. 

Now the question is, is this the best NAT scenario for this course?

I've seen and done many types of NAT. Funky stuff and standard stuff and i am thinking that maybe the more common NAT scenario is better here, where a dedicated IP address is used. Or two. 

And then manual and automatic destination/static NAT rules can be covered. 

Doesn't Check Point generally recommend automatic NAT rules?

Thanks,

Don

[_Val_]

In this specific case, automatic static NAT would work too, and probably could be a more reasonable option. However, this is just an example of what's possible, and considering the fact manual NAT takes a bit more effort to set, is a good educational decision 🙂

[Thabo]

Hi

Please clarify in terms of the nat rule why in cp it creates two rules if i have an automatic hide NAT enabled i am not sure for rule no 3 does the original to original mean there is no NAT ?

Which better way is there to understand this NAT rules ?

Find attached.

Regards

[Don_Paterson]

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

[Don_Paterson]

https://training-certifications.checkpoint.com/#/courses/Security%20Administration%20R81.20%20(CCSA)

[Timothy_Hall]

This question about why an Automatic Hide NAT setup creates two rules comes up frequently in the CCSA classes I teach.  The purpose of the second rule created is obvious, which is implement the Hide NAT on the source IP for outbound connections, and also statefully change the destination IP address for the reply on the inbound.  So the second rule seems to do everything we want.

The first rule handles a corner case when two systems located on the same IP subnet try to communicate, but they don't do it directly and try to route the traffic through their default gateway instead (in this case the firewall itself).  Normally these two systems would just directly communicate without the need for a router, but an incorrectly defined or inconsistent subnet mask definition on these systems can cause this effect.  In this corner case the network is incorrectly configured, and the firewall trying to NAT this traffic as well would just make things worse.  So this first rule is an anti-NAT/no-NAT for that situation to keep from further complicating matters.

[Thabo]

@Timothy_Hallyou are a legend 😀.

Thank you @Don_Paterson .