Complete guide to Check Point Network Address Translation

Introduction to NAT

I've worked with firewalls for a long time. When I was younger, I imagined the day I could say, in a wise, weathered, veteran's voice, "I've been doing this for [insert embarrassingly large number here] years." These days I just say "a long time." My first real exposure to Network Address Translation came while managing Red Hat Linux 5.0 Hurricane systems, back when IP Chains and IP Masquerading defined how we handled traffic. To this day, I still think "IP Masquerading" is a far more elegant term than "NAT." With that perspective in mind, let's dig into every major aspect of how NAT works in the Check Point environment.

NAT is a mechanism that modifies IP addresses in packet headers as traffic crosses a firewall or router. It allows private, non-routable addresses to reach external networks by translating them into one or more public addresses. This conserves scarce IPv4 space, conceals internal addressing schemes, and supports network growth without readdressing. NAT also enables controlled access to internal resources by mapping public-facing addresses to specific private hosts. In Check Point, NAT is integrated into the inspection engine so that translation and security policies are enforced together in real time.

Source and destination translation represent the two core directions of NAT. Source translation rewrites the originating address of a packet, typically when internal hosts reach the internet. Hide NAT, the common form, lets many private hosts share a single public IP by using port numbers to separate sessions. Destination translation works in the reverse direction by rewriting the target address of inbound traffic, often with static one-to-one mappings to publish servers to the outside. Together, these techniques regulate how traffic enters and leaves the network, preserve routing consistency, and prevent exposure of internal addressing.

Check Point supports several NAT types beyond the automatic options. Static NAT creates a permanent one-to-one mapping between private and public IPs, ensuring translation is identical in both directions. Hide NAT consolidates many private hosts behind a single address. Dynamic NAT allocates addresses from a pool without guaranteeing persistent mapping. Manual NAT gives administrators full control, allowing complex or exceptional translation scenarios that Automatic NAT cannot address.

Traditional routers handle NAT mainly as a forwarding function, rewriting packet addresses with little regard for application state or policy context. Check Point embeds NAT into its firewall kernel, applying translation alongside access control and threat prevention. NAT rules follow the same logical order as firewall rules, are fully logged, and support features such as VPN exclusions and proxy ARP. This design not only preserves connectivity and IP space but also ties NAT directly to security enforcement and stateful inspection.

Check Point's NAT Architecture

In Check Point, NAT is a core function of the firewall kernel rather than an add-on. Every packet is evaluated by both the security policy and the NAT policy inside the same inspection engine. Translation follows a defined order: inbound packets are first matched against destination NAT rules, then inspected by the access control policy, and finally subjected to source NAT before leaving the gateway. This sequencing keeps routing decisions and security checks aligned with the translated addresses.

The NAT Table stores the translation rules and records both pre-NAT (the packet's original source and destination) and post-NAT (the rewritten addresses after translation) values. This dual view allows the gateway to rewrite addresses while maintaining consistent routing and inspection. When a connection matches a NAT rule, the kernel rewrites the packet headers accordingly and logs the mapping for visibility and troubleshooting. By structuring the NAT table this way, Check Point guarantees accurate packet handling and stateful awareness regardless of direction.

To keep traffic stateful, the firewall also maintains a Connection Table (also known as a State Table). Each entry ties original and translated source, destination, and service values together, ensuring return packets are matched without re-evaluating rules. This table also manages timeouts, port allocations for Hide NAT, and cleanup of idle sessions.

• The NAT table is a set of rules that define how source or destination IPs and ports are translated (for example, hide NAT, static NAT, or port forwarding). When a new connection matches a NAT rule, the firewall rewrites the packet headers according to that rule.
• The Connection Table records every active session passing through the firewall, including source/destination IPs, ports, protocol, and the translated values from the NAT table.

Why are two tables necessary? If the Connection Table already stores packet information with both the original and translated addresses, why maintain a separate NAT Table? The distinction lies in function. The NAT Table serves as the recipe, defining how translation is applied when the first packet of a connection is evaluated. The Connection Table is the finished dish, tracking those translations for the duration of the session. Together, they ensure accurate, consistent handling of NAT traffic.

Configuring NAT Rules in SmartConsole

One of Check Point's strengths is its centralized management and administration, made possible through tools like SmartConsole. From SmartConsole, administrators can configure the Security Policy, manage objects, and perform a wide range of tasks. These tasks include working with the NAT Rule Base. The NAT Rule Base provides a structured method to define how traffic is translated as it enters or leaves the gateway. 

Each NAT rule is made up of several columns that determine how translation is applied:

• Original Source / Destination – defines the traffic that the rule will match before translation.
• Translated Source / Destination – specifies what the original values will be changed to when the rule applies.
• Service – optionally limits the rule to specific ports or protocols rather than applying to all traffic.
• Install On – determines which gateway or gateway cluster the rule is enforced.

In Check Point land there are two types of NAT: Automatic and Manual. A NAT rule defined directly in the NAT Rule Base, similar in form to a Security Policy rule, is considered Manual NAT. Automatic NAT, on the other hand, is created through a Network Object or Host Object by selecting the NAT option and providing the translated address; the system then generates the rule automatically.

Manual NAT rules are almost always placed at the top of the NAT Rule Base, which means they take precedence. The firewall evaluates these rules first, from top to bottom, and only checks for automatic NAT if no manual rule matches the packet. This distinction matters because a well-placed manual rule can override automatic behavior, making it possible to handle exceptions or complex requirements without altering the broader NAT configuration.

While most administrators rarely need Manual NAT, it becomes essential in edge cases where Automatic NAT cannot accommodate the traffic flow. In those situations, a manual rule can resolve problems quickly. They also highlight the precision and flexibility of Manual NAT, while Automatic NAT remains the simpler option for routine situations.

Automatic NATs

Automatic NATs are called automatic because the rules themselves are generated by the system rather than manually written into the NAT Rule Base. When an administrator enables NAT within a host or network object and specifies a translated address, Check Point automatically creates the necessary NAT rules and supporting layer-two configurations behind the scenes. These elements are compiled into the gateway's policy during policy installation, ensuring consistency without requiring direct administrator intervention.

The automatic creation of ARP entries further simplifies management on supported operating systems. In earlier deployments, like when Check Point ran as an application on platforms like Nokia IPSO, administrators 'back then' were required to configure ARPs manually. Those implementations weren't truly automatic because of the extra ARO step involved. Today, Automatic NAT serves as a veritable easy button for NAT creation, handling both translation and the underlying network announcements with minimal effort.

Each network or host object in SmartConsole includes a NAT tab, which defines translation behavior for that specific object. This tab provides two primary options: Hide and Static. When a NAT is created through the object it is always referred to as an Automatic NAT.

Automatic Hide NAT is the most common form, used for outbound traffic from internal networks. It allows many internal IP addresses to share one public IP through port-level differentiation. Keep in mind that it is possible to split up outbound traffic into several external Hide addresses for large populations or separating teams, floors, departments, branches, networks, etc. or for administrative log clarity for example, but there are many reasons for using several Hide addresses. The firewall keeps a translation table that maps each session's source port to a unique entry, enabling simultaneous connections from many hosts. This approach conserves public IP space and simplifies configuration since no per-host rules are required.

Automatic Static NAT, by contrast, provides a permanent, bidirectional one-to-one mapping. The internal host always appears to external networks under its public IP, and inbound connections to that public IP are translated back to the private address. Static NAT is typically used for publishing internal resources like web or mail servers. Unlike Hide NAT, Static NAT preserves the original ports, making it ideal for services requiring consistent, inbound connectivity.

The two types share some similarities: both are configured at the object level, both integrate seamlessly into the policy, and both are automatically generated by the system. Their differences are functional as Hide NAT is used to control outbound traffic aggregation, while Static NAT ensures persistent address identity for inbound or bidirectional connections.

Pool NAT is a special case that combines elements of both Hide and Static NAT and is probably the least-used of the group. Typically, an administrator creates one when needed and then doesn't touch it again for years. Instead of using a single address, as in Hide NAT, or fixed one-to-one mappings, as in Static NAT, Pool NAT draws from a defined range of public IP addresses. Each new connection is assigned an address from the pool, improving scalability and reducing the risk of port exhaustion. Like Hide NAT, it's dynamic, but it distributes connections across multiple external IPs. Unlike Static NAT, it doesn't maintain a permanent relationship between specific internal and external addresses.

To create a Pool NAT in Check Point, first enable the feature in Global Properties, then define the pool and configure how it will be used. In SmartConsole, create a new Address Range object that represents the pool and assign it the range of public IPs intended for translation. Once the pool object is defined, configure it on the gateway that owns the external address range. Instead of selecting Hide behind gateway, select the Address Range object in the gateway's NAT Poolsection. The firewall will then use available addresses from that pool dynamically when processing outbound connections.

Pool NAT is especially useful in large environments or at network edges where thousands of connections originate from internal clients. It helps prevent port conflicts, balances traffic across multiple public IPs, and integrates cleanly with Check Point's centralized management framework. Because it uses the same NAT and connection tracking mechanisms as other translation types, it remains consistent, efficient, and easy to maintain over time.

Remember whenever the NATs are created through an object, Check Point automatically generates the necessary NAT Rule Base entries and ARPs. These rules appear in the compiled Automatic NAT section in the NAT Rule Base below any manual NAT entries, following the same logical top to bottom evaluation flow as a normal rule base. The NAT and ARP creation at the gateway takes place atomically during policy installation. If the policy is unloaded from the gateway then all NATs and ARPs are removed from the active kernel tables. The NATs and ARPs will be recreated at the next successful policy installation. 

Manual NAT Rules

Manual NAT is called manual because the administrator explicitly defines the translation rules instead of letting the system generate them automatically. Each rule is created directly in the NAT Rule Base, giving full control over order, scope, and interaction with other policies. Unlike Automatic NAT, these rules don't automatically generate supporting ARPs, so administrators must account for ARP entry creation and ongoing management. This required to ensure the gateway can respond at Layer 2 and route traffic correctly.

Creating Manual NAT rules follows the same structure as other NAT types, though for newcomers to Check Point, the process can feel like mental gymnastics at first. With a bit of practice the logic becomes clear. The administrator defines every element of the rule… the original source and translated source, the original destinations and the translated destination, along with the service to which the Manual NAT applies. Any of the previously discussed NAT types can be created this way, and when done directly in the NAT Rule Base, they are always referred to as Manual Hide NAT, Manual Static NAT, or Manual Pool NAT.

When creating the Static NAT manually the administrator has to create an object that represents the external ip address.

Manual NAT creation is mainly reserved for advanced cases that require more flexibility than an Automatic NAT. The common Manual NAT applications are the No NAT Rules and Double NAT Rules. The No NAT Rules are created so traffic from one network to another network explicitly avoids network address translation altogether. This commonly done for management traffic or networks in a site-to-site VPN connection… even though there are controls for NAT in the VPN configuration dialogue there is comfort found in placing a specific instruction at the top of the NAT Rule Base. In more complex environments, such as overlapping networks at two VPNed sites, administrators can configure Double NAT Rules, translating both source and destination addresses to avoid IP address conflicts. Outside of those cases Manual NATs are rarely needed, but they remain an essential tool for solving unique or nonstandard network requirements. Remember, the administrator is responsible for handling ARPs and any other supporting configuration.

It has been mentioned a few times that when creating a Manual Static NAT, the administrator is responsible for creating the corresponding ARP entry for the IP address. This can be done in the WebUI, CLISH or editing the $FWDIR/conf/local.arp file with standard Linux-eese.

# $FWDIR/conf/local.arp file
# IP_Address MAC_Address Interface_name
198.59.101.5 00:1C:7F:AB:CD:EF eth1

After editing this file, the ARP cache must be refreshed using a command such as arp -s 198.51.101.5 00:1C:7F:AB:CD:EF, or by performing a policy reinstall. Commands like arp -n and fw ctl arp outputs a list for verification. Keep in mind that if the policy is uninstalled, the ARP entry will remain active, and the gateway will continue to respond ("ARP up") for the address listed in the local.arp file. However, because the firewall kernel is removed, NAT will no longer function since the connection table is flushed, and traffic will stop forwarding. Doing this increases importance of the local.arp file, it is now considered an important upgrade item and should be backed up, copied, or preserved during in-place upgrades, RMAs, and hardware replacements.

The ARP entry can also be created through the WebUI or CLISH, which is often simpler for administrators. The WeBUI configuration is a simple fill in the field process. The CLISH example looks like this: 

set arp static <ip-address> <mac-address> interface <interface-name>
save config

However, these settings still need to be verified after an in-place upgrade to ensure persistence. ARP entries can be included in full device configuration backups, or the CLI commands used to create them can be re-run following an upgrade or hardware replacement. Whether it's easier to maintain the local.arp file or rely on configuration commands depends on the administrator's workflow. (Hint:  Automatic NATs are much easier to maintain.)

• insert screenshots

NAT64 and NAT46

Check Point added support for NAT64 and NAT46 translation starting in R80.40, expanding what the gateway can do when operating in mixed IPv4 and IPv6 environments. When both protocol stacks are enabled on an interface, the gateway can translate traffic between them using standard NAT logic. This gives organizations running dual-stack or transition networks a way to let IPv6-only hosts reach IPv4-only services without deploying a full protocol translation system.

The gateway supports IPv6-to-IPv4 Hide NAT and IPv6-to-IPv4 Static NAT, making it easy to bridge the gap between address families. For example, you can configure a manual IPv6-to-IPv4 Hide NAT so internal IPv6 clients use the gateway's IPv4 egress address when connecting to legacy IPv4 resources. The firewall rewrites source addresses, tracks the session, and handles return traffic normally acting as a gateway-based NAT64 solution.

It is worth noting that Check Point's NAT64/NAT46 is not a protocol translator. It doesn't implement RFC6146 and it doesn't include DNS64 capabilities. (In DNS64, an IPv4 address is embedded into the last 32 bits of a synthesized AAAA record to form a valid 128-bit IPv6 address.) If DNS64 is needed, that function must come from an external resolver. The 96-bit prefix used to build the IPv6 address directs traffic toward the NAT64 gateway. Check Point's implementation stays focused on address and port translation between IPv4 and IPv6 stacks—it doesn't modify application-layer data or perform name translation.

Carrier-Grade NAT (CGNAT)

Carrier-Grade NAT (CGNAT) is a large-scale implementation of Hide NAT used by internet service providers to allow thousands, or even millions, of private subscribers to share a smaller pool of public IPv4 addresses. It conserves IPv4 space, simplifies transition to IPv6, and provides centralized logging and policy enforcement at the network edge.

Check Point has supported CGNAT-like designs since R80.20, and recent software versions include refined tools for large NAT pools, port range management, and dynamic port reuse. Administrators can define extensive hide NAT pools and assign specific port ranges to maintain session tracking efficiency.

Performance and scalability are achieved through SecureXL and CoreXL, which distribute translation and inspection workloads across multiple cores. On larger Quantum appliances or Maestro environments, CGNAT configurations can handle tens of millions of concurrent translations while maintaining full logging, inspection, and acceleration.

A typical deployment might involve an ISP using Check Point Quantum gateways or Maestro environment to perform NAT for massive private address spaces. Outbound subscriber traffic is dynamically translated into public IP pools, optionally segmented per subscriber using sub-objects or dynamic objects. Because NAT processing occurs inside the unified inspection engine, all traffic remains subject to Check Point's security policy, identity awareness, and event logging.

In short, Check Point supports both cross-family NAT (NAT64/NAT46) for mixed IPv4/IPv6 environments and CGNAT for massive-scale IPv4 address sharing both of which can be integrated into the centrally managed security platform.

NAT Table and Kernel Debug

When troubleshooting NAT issues, it helps to understand what's happening inside the firewall kernel. The NAT process is tracked in internal kernel tables that show active translations, pending allocations, and the relationships between original and translated tuples. You can view these tables with commands like:

# Shows a summary active NAT allocations 
fw tab -t fwx_alloc_global -s

# Shows a table of active NAT allocations
fw tab -t fwx_alloc_global -u

# Shows pending or half-open NAT sessions
fw tab -t fwx_pending -u

To clear the NAT table of all entries for some reason the command fw tab -t fwx_alloc_global -x will do the job (use with caution, as this drops live sessions). For clearing just one NAT table entry the -d switch can be used with the hexadecimal key for the NAT entry is needed. Here is the workflow:

# Find the NAT entry
fw tab -t fwx_alloc_global -u | grep 203.0.113.5

# Output example:
0x1e86d9c0  10.1.1.10:45123 -> 203.0.113.5:12004

# Delete the entry using the hexidecimal key
fw tab -t fwx_alloc_global -d 0x1e86d9c0

For packet-level analysis, fw monitor remains the go-to tool. It captures packets as they traverse the firewall chain, allowing you to see both pre and post-NAT addresses. Combine this with fw ctl zdebug + drop to watch live kernel drops and reasons such as "Invalid NAT" or "No matching translation." These two tools together will tell you whether packets are reaching the gateway, being translated, or failing inspection.

When using SecureXL, remember that accelerated packets bypass portions of the kernel inspection chain. To see NAT translations clearly in fw monitor, disable acceleration temporarily with fw accel off, or use fw monitor -e all on newer versions where SecureXL visibility is improved. Always re-enable acceleration afterward to restore performance. 

The helpful commands list includes:

Finally, logs provide valuable context for NAT behavior. In SmartConsole's Logging Section, NAT-related fields such as NAT Source, NAT Destination, and NAT Rule Number confirm which rule was applied. If these fields are empty, it means the packet passed without translation. Together the commands, tables, monitors, debug tools, and logs paint a complete picture of how the firewall is handling address translation processing.

As always, when working on a production equipment, exercise caution before running diagnostic or kernel-level commands. Tools like fw monitor, fw ctl zdebug, and fw tab and the -x option can be powerful, but they can be invasive if used improperly can cause an outrage. Packet captures and deep kernel tracing consume CPU and memory, potentially degrading performance or interrupting live production traffic. Commands that modify or clear tables, such as removing entries from fwx_alloc_global, can immediately tear down active connections. If SecureXL or CoreXL acceleration is disabled for troubleshooting, remember to re-enable it afterward to restore normal performance. The safest approach is to perform detailed debugging during a scheduled maintenance window or in a lab environment whenever possible. Treat every investigation command as a surgical tool that can easily double as a hedge trimmer. Take care to be precise, deliberate, and used only when the effect is fully understood.

Best Practices

Getting NAT right in Check Point often comes down to understanding order, intent, and visibility. The NAT policy order of operations defines how traffic is translated and inspected: first, destination NAT is applied; second, the Access Control Policy is evaluated; and third, source NAT (Hide or Static) is applied on egress. Manual NAT rules are evaluated before automatic rules, from top to bottom, and only the first match applies. Confirm that rule order matches your intended flow especially if you are required to mixing automatic and manual translations.

When deciding whether to use object-based Automatic NAT or create a Manual NAT, the guideline is straightforward: use Automatic NAT for simple one-to-one or many-to-one scenarios that don't require special handling. It's clean, consistent, and automatically manages ARP creation. Reserve Manual NAT for complex or exceptional cases such as asymmetric routing, double NAT, or when precise control across multiple interfaces is required. Mixing the two is fine, but remember that manual rules take precedence because they appear above automatic rules in the NAT Rule Base. As a best practice, group similar rules together, document exceptions.

To avoid conflicts between automatic and manual NAT, don't define overlapping translations in both places. For example, avoid configuring Automatic NAT on a host that's already referenced in a Manual NAT rule unless you intend to override the behavior. The more common scenario is creating a Manual NAT for a specific host that intentionally overrides an Automatic NAT applied to a broader network object. Be cautious when the configuration is reversed, as it can produce inconsistent or unexpected results. When troubleshooting NAT issues, check for duplicate entries, mis-ordered rules, or missing ARPs as these are frequent sources of confusion.

Common mistakes include forgetting to configure proxy ARP for Manual NATs, mismatching internal and external interfaces, or installing policies before verifying routing and connectivity. Another subtle issue is creating Hide NATs on overlapping address ranges, which can cause traffic to egress through the wrong gateway. If in the troubleshooting weeds,  use fw monitor or fw ctl conn to confirm that the correct NAT rule is applied and that return packets match the same translation. And use fw ctl zdebug + drop to quickly expose why the packet was dropped.

Finally, logging and monitoring are key for verifying NAT behavior. In SmartConsole, enable logging on rules and review the NAT Source, NAT Destination, and NAT Rule Number fields. These confirm which rule was used and how traffic was rewritten. For deeper visibility, SmartEvent and CPView can display NAT throughput, hit counts, and session data in real time. Regular review of NAT hits and logs helps ensure that translations are functioning as intended, performance remains stable, and any misconfigurations are caught early.

NAT behaves predictably when designed deliberately: keep your rules ordered, your objects clean, your ARPs verified, and your logs enabled.

Summary & reference

There is an administrator out there somewhere that will go an entire career working with Check Point firewalls and never need more than Automatic NATs, a few well-placed No NAT rules, and a good reference image showing how Double NAT is configured. The platform's automation has matured to the point where most translation needs—whether Hide or Static—can be handled cleanly through object-based NAT without ever touching the manual rule base.

There was a time when every NAT had to be written manually, and administrators had to manage ARPs and rule ordering by hand. Those days are mostly gone. Automatic NAT exists to remove that overhead—it's called automatic because Check Point handles everything behind the scenes: rule creation, layer-two configuration, and policy integration.

If there's one takeaway, it's this: use Automatic NAT whenever possible. It's simpler, safer, and far easier to maintain. Manual NAT still has its place for edge cases and complex routing scenarios, but for everyday work, Automatic NAT is the practical choice.

Quick Reference

Static NAT using an Object:

1. Open the host or network object in SmartConsole.
2. Go to the NAT tab.
3. Select Add Automatic Address Translation.
4. Choose Static and enter the public IP.
5. Install policy.

Hide NAT using an Object:

1. Open the internal network or host object.
2. Go to the NAT tab.
3. Enable Add Automatic Address Translation.
4. Choose Hide and select either Hide behind Gateway or a specific IP.
5. Install policy.

Relevant SKs

sk30557 – Configuring NAT

sk172933 - NAT FAQ

sk30197 – Configuring Proxy ARP for Manual NAT

Further Reading

R82 Quantum Security Management Administration Guide – Sections on Configuring the NAT Policy, Working with Automatic NAT Rules, Working with Manual NAT Rules, Working with NAT64/46 Rules, and Advanced NAT settings.