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