Checkpoint NAT Concepts and Server Side NAT Explanation - NETSEC

Latest

Learning, Sharing, Creating

Cybersecurity Memo

Thursday, July 16, 2015

Checkpoint NAT Concepts and Server Side NAT Explanation

Checkpoint have four main NAT concepts we will need to know their difference when implement a NAT rule:
a. Automatically NAT vs Manual NAT
b. Static NAT vs Dynamic NAT (Hide)
c. Source NAT vs Destination NAT
d. Client Side Destination NAT vs Server Side Destination NAT

Checkpoint Firewall NAT is quite different than any other firewall vendors, especially on destination NAT. For first three NAT concepts, Automatically NAT / Manual NAT, Static NAT / Dynamic NAT, Source NAT / Destination NAT, are easy to understand, and almost all vendors are using same way to handle packets. But on the part regarding source NAT and destination NAT, for all other vendors, they are acting same, which is doing destination NAT first at inbound traffic to firewalls, then do source NAT at outbound traffic before packets leave firewalls. Checkpoint is having two different place to handle destination NAT, which is client side (inbound side) or server side (outbound side).



Please keep following diagram in mind, not all packets will go through all those steps. There are three or maybe more different paths for Checkpoint firewall to fast deliver the packets to destination, that is why Checkpoint can be so fast without a hardware acceleration.

When starting configuration a NAT rule, you can use automatic NAT and manual NAT depending on your preference and situation. Make sure you have well understanding the difference between them. In some cases, manual NAT will need extra configuration at Proxy Arp or route.

The setting for client / server side translation is in the SmartDashboard Menu -> Policies -> Global Properties -> NAT - Network Address Translation:


By default, both Translate destination on client side options are checked. If you unchecked it, it will become Translation destination on server side.

Notes:  Rule > NAT - The kernels will  always process the rules before the NAT at inbound and outbound process.

Running this basic fw monitor will show you the 4 primary points, iIoO (pre-inbound, post-Inbound, pre-outbound, post-Outbound).

For the full firewall chain (which can differ based on what blades are active), you can run the following fw monitor:
fw monitor -p all -e "accept host (<HOSTIP>);"

Topology:

There is a ipsec site to site vpn tunnel between Cisco ASAv and Checkpoint R77.30. Checkpoint is using Server end NAT.
192.168.2.34 is on gateway's eth0, and 172.17.3.34 is on gateway's eth1. 172.17.3.100 will be NAT-ed to 192.168.2.100.  10.1.1.100 will access 192.168.2.100 which is NATed to 172.17.3.100 at server side (outbound).

We will see how packets flow through Checkpoint firewalls with server side NAT settings.

Server side Translation Process Explanation:

a. Inbound Process
1. The packet that was sent to Server's NATed IP 192.168.2.100, arrives on the "Source/Client" side at the inbound interface eth0 of the Security Gateway (Pre-Inbound chains).
2. The packet passes the Security Policy rules (inside Virtual Machine).
3. If accepted, the connection is recorded in the Connections Table (Table ID 8158).
4. The packet is matched against NAT rules for the Destination. The packet is translated if a match is found - in this case, no translation occurs because we are using server side translation (outbound).
5. The packet passes additional inspection (Post-Inbound chains).

b. OS Kernel
6.However, since the default routing table will not contain the correct route for NATed IP address 192.168.2.100, the packet can not be routed correctly. The packet arrives at the TCP/IP stack of the underlying operating system, and should routed to the outbound interface eth1.
7.If the correct static host/network route for "Destination/Server" was added into the routing table of the underlying operating system, the packet will be routed corrected to the outbound interface eth1. In this case, we will need to add route for 192.168.2.100/32 with gateway 172.17.3.34

c. Outbound Process
8.The packet goes through the outbound interface eth1 (Pre-Outbound chains).
9.The packet passes the Security Policy rules (inside Virtual Machine).
10.The packet is matched against NAT rules for the Destination. The packet is translated if a match is found - in this case, from IP 192.168.2.100 to IP 172.17.3.100.
11.The packet is matched against NAT rules for the Source (if such rules exist). The packet is translated if a match is found - in this case, no translation occurs.
12.The packet passes additional inspection (Post-Outbound chains).13.The packet leaves the Security Gateway machine on the "Destination/Server" side for server 172.17.3.100.

Reference:

a. sk85460: Explanation about Client side NAT and Server side NAT
b. Check Point - Client vs Server Side NAT


2 comments:

  1. hi,

    about this nat-ed, I have a question, is there a way a to disable NAT for traffic pass every interface in firewall, whenever traffic pass firewall the source and destination always the same. I ask this question because I want to move the nat-job to the internet-edge-router.
    THx

    ReplyDelete
    Replies
    1. You could easily create a NAT rule at the top with source any, destination any and keep same for NAT-ed source and destination.

      This NAT rule will make all traffic passing without NAT-ing them.

      Delete