Skip to main content

Checkpoint – Automatic NAT vs Manual NAT

Checkpoint – Automatic NAT vs Manual NAT



Checkpoint  Checkpoint – Automatic NAT vs Manual NAT



NAT (Network Address Translation) can be configured in our Checkpoint FW in 2 two different ways: Manual or Automatic

Automatic NAT

To configure the automatic NAT, the SERVER object properties has a NAT section.
So for example, if we want our host with internal private IP 10.10.50.50 to be published in Internet with public IP 80.80.100.100:
Checkpoint host general properties
Checkpoint host NAT properties
(I we only wanted to apply outbound IP masquerading, we should have applied hide NAT type.
In this example, we are also trying to publish to Internet to receive incoming connections, so static NAT type.)
For more details, visit my post Checkpoint – Hide NAT vs Static NAT
This NAT configuration automatically performs 2 actions:
1. Creation of the corresponding NAT rule
Original PacketTranslated Packet
SourceDestinationServiceSourceDestinationService
Any80.80.100.100AnyOriginal10.10.50.50Original
2. Configuration of the corresponding Proxy ARP
After applying the automatic NAT configuration, the firewall will start reply to the ARP request asking for the 80.80.100.100 public IP. Then the firewall will 'NAT' the packet and route it to the proper gateway or to the final destination.
Its very important to apply the NAT section of the host only to the gateway we want (Instead of all, the default option)
Checkpoint NAT apply gatewayCheckpoint NAT apply gateway
Otherwise, in a VSX environment, all VS firewalls can start to reply those ARP request, and so, steal packets among them.


Manual NAT

To configure manual NAT, instead of using the NAT section of our HOST object we can add rules on the NAT section of our firewall policy.
To recreate the same NAT configuration as the previous example, there must also be another HOST object with the public IP configured
Checkpoint host general properties
And then we can create the NAT rule:
Checkpoint NAT rule
As I said, the automatic NAT method configures the proxy ARP automatically.
When using manual NAT, the proxy ARP must be added manually. Check this post "Checkpoint – Proxy ARP for manual NAT on VSX" for more information


Manual NAT vs Automatic NAT

Then, if manual NAT requires more configurations, why should I use it?? Good question.
Sometimes we need to perform NAT based on destination port (or any combination based on the source IP, destination IP, port…)
For example:
When accesing the public IP, the destination internal IP the firewall NATs to depends on the destination port:
Checkpoint NAT rule
Or this rule allows us to access three different internal servers on the same port with a single public IP (based on the original packet destination port)
Checkpoint NAT rule
So, if the NAT rule is simple, better use Automatic NAT. Otherwise, your only option is using the Manual NAT method.

Comments

Popular posts from this blog

How to modify SSH/HTTP/Telnet time out in Cisco ASA firewall?

How to modify SSH/HTTP/Telnet time out in Cisco ASA firewall? By default tcp idle timeout is 1:0:0 hh:mm:ss. If in case you need to modify it you can do it by MPF (Modular Policy Framework). Let us setup a custom timeout when traffic is coming from particular host 10.77.241.129. !— Match the traffic using the access-list —! object-group service DM_INLINE_TCP_1 tcp port-object eq www port-object eq ssh port-object eq telnet access-list outside_mpc extended permit tcp host 10.77.241.129 <source ip> any object-group DM_INLINE_TCP_1 !— Define the class map Cisco-class –! class-map Cisco-class match access-list outside_mpc !— Call this class-map into policy map and set the connection reset after 10 min when traffic is coming from particular host —! policy-map Cisco-policy class Cisco-class set connection timeout idle 0:10:00 reset !— Apply the policy-map Cisco-policy on the interface. —! service-policy Cisco-p...

Checkpoint firewall common commands part 2

Checkpoint firewall common commands part 2 For basic firewall informaton gathering: fgate stat -Status and statistics of Flood-Gate-1. fwaccel <stat|stats|conns>  – View status, statistics or connection table of SecureXL. fw getifs -Show list of configured interfaces with IP and netmask. cpstat <app_flag> [-f flavour] -View OS, HW and CP application status. Issue cpstat without any options to see all possible application flags <app_flag> and corresponding flavours. Examples: cpstat fw -f policy – verbose policy info cpstat os -f cpu – CPU utilization statistics cpinfo -y all   -List all installed patches and hotfixes. cpd_sched_config print -Show task scheduled with CPD scheduler. enabled_blades -View enabled software blades avsu_client [-app <app>]   , get_version <app>  -Get signature version and status of content security .Without the -app option “Anti Virus” is used. show co...

FortiGate: Upgrading the firmware via CLI

FortiGate: Upgrading the firmware via CLI To use the following procedure, you must have a TFTP or FTP server that FortiDB can connect to. You must also log in using the “admin” administrator account. Start the FTP or TFTP server. Copy the new firmware image file to the FTP or TFTP server. Log into the CLI. Verify that FortiDB can connect to the FTP or TFTP server. For example, if the IP address of the TFTP server is 192.168.1.168, enter the CLI command: execute ping 192.168.1.168 Enter the following command to copy the firmware image from the TFTP server to FortiDB: execute restore image ftp execute restore image tftp Where is the name and location of the firmware image file and or is the IP address of the FTP or TFTP server. For example, if the firmware image file name is image.out and the IP address of the FTP or TFTP server is 192.168.1.168, enter: execute restore image tftp image.out 192.168.1.168 FortiDB responds with the message: This oper...