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

CLI Commands for Troubleshooting FortiGate Firewalls

CLI Commands for Troubleshooting FortiGate Firewalls 2015-12-21 Fortinet , Memorandum , Network Cheat Sheet , CLI , FortiGate , Fortinet , Quick Reference , SCP , Troubleshooting Johannes Weber This blog post is a list of common troubleshooting commands I am using on the FortiGate CLI . It is not complete nor very detailled, but provides the basic commands for troubleshooting network related issues that are not resolvable via the GUI. I am not focused on too many memory, process, kernel, etc. details. These must only be used if there are really specific problems. I am more focused on the general troubleshooting stuff. I am using it personally as a cheat sheet / quick reference and will update it from time to time. Coming from Cisco, everything is “show”. With Fortinet you have the choice confusion between show | get | diagnose | execute . Not that easy to remember. It is “ get router info6 routing-table” to show the routing table but “ diagn...

Check Throughput of Interfaces - Palo Alto Networks NGFW

Check Throughput of Interfaces - Palo Alto Networks NGFW Following command shows brief interface throughput. > show system statistics session To see the complete statistics, run the show system state browser command > show system state browser Press Shift+L and click on Ports To enable tracking and updates press Y and U To see additional ports, press space bar

From MPLS to SD-WAN to SASE: An Evolution of Enterprise Networking

From MPLS to SD-WAN to SASE: An Evolution of Enterprise Networking The way we do business is changing. As critical business applications migrate to the cloud, and the mobile workforce continues to grow, networking and security solutions need to evolve in order to meet the changing business needs. Gartner believes (and we agree) that the future of networking lies with  SASE (Secure Access Service Edge)  – the convergence of networking and security into one cloud service. Here’s why. 1990s – 2000s: MPLS and the Era of Clear Network Boundaries? Back in the day, networking models were hardware-centric and manually configured. Applications, data, and services lived within private datacenters and relied on remote access solutions to connect remote workers. Dedicated network connectivity, known as MPLS, was the preferred approach for connecting remote locations. MPLS provides predictable performance, low latency and packet loss, and central management. However, MPLS is ...