3.1 NAT Overview in Check Point
Key Takeaways
- NAT translates private IP addresses to public addresses so internal hosts can reach the Internet and external hosts can reach published servers
- Check Point supports two NAT methods: Hide NAT (many-to-one) and Static NAT (one-to-one)
- NAT is configured in the Security Gateway's NAT Rule Base or via Automatic NAT in object properties
- NAT rules translate traffic; they do not allow or deny it — Access Control policy still governs the connection
- NAT is stateful: the gateway tracks translations in its connections table so return traffic is automatically reverse-translated
Why Check Point Gateways Perform NAT
Network Address Translation (NAT) is the process of rewriting IP addresses (and typically ports) in packet headers as those packets cross a Security Gateway. On Check Point Quantum Security Gateways running R82, NAT solves two real problems that the CCSA exam expects you to articulate.
First, IPv4 address scarcity: RFC 1918 private space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) is used inside almost every enterprise, but those addresses are not routable on the Internet. Without translation, an internal host at 10.1.1.50 cannot receive a reply from a public web server because no public router knows a path back to 10.1.1.50. NAT rewrites the source to a public address owned by the gateway so the return path exists.
Second, hiding internal topology: even if an organization owned enough public addresses for every host, exposing internal addressing to the Internet reveals network structure that attackers can enumerate. NAT presents a single (or small set of) public address to the outside, concealing the count, layout, and identity of internal hosts.
A third benefit the exam sometimes frames as a side effect: consistency of addressing for published services. An external client always reaches the published server by its public IP regardless of how the internal numbering changes, because the gateway rewrites the destination to the private address on the inside.
Where NAT Lives in Check Point
On a Check Point gateway, NAT is not a separate daemon — it is a function of the Firewall kernel (fw kernel) driven by the installed Security Policy. You configure NAT in one of two places:
- Automatic NAT — set in the Properties of a network object (host, network, or range) under the NAT tab in SmartConsole. When you enable Automatic NAT, Check Point generates the corresponding rules in the NAT Rule Base for you at policy install time.
- Manual NAT — written directly as rows in the NAT Rule Base inside the Access Control policy (the dedicated NAT layer shown in SmartConsole below the Access Control layers).
Both methods produce the same artifact: rows in the NAT Rule Base that the gateway installs and consults at runtime. The difference is authoring convenience and the ancillary configuration (ARP, anti-spoofing) that Automatic NAT handles for you.
The NAT Rule Base
In SmartConsole the NAT Rule Base is a separate grid from the Access Control ordered/inline layers. Each NAT rule has these key columns:
| Column | Meaning |
|---|---|
| Original Source | The pre-translation source IP/network |
| Original Destination | The pre-translation destination IP/network |
| Original Service | The pre-translation TCP/UDP/ICMP service |
| Translated Source | What the source is rewritten to |
| Translated Destination | What the destination is rewritten to |
| Translated Service | What the service port is rewritten to (port translation) |
| Install On | Which gateway(s) the rule installs to |
A special placeholder called Original can be placed in a Translated column to mean "do not translate this field." This is how you build rules that translate only the source, or only the destination, leaving the other side untouched.
NAT Is Stateful
The gateway does not perform NAT as a stateless rewrite. It installs a translation in the connections table (viewed with fw tab -t connections -u or in SmartConsole's connection views). When the reply comes back, the gateway looks up the connection, reverses the translation, and forwards the packet to the original internal host. This statefulness is what makes asymmetric routing and load sharing across ClusterXL members safe — state synchronization keeps the translation table consistent across cluster members.
NAT Rules Translate, They Do Not Permit
A common CCSA trap: candidates assume a NAT rule also allows the traffic. It does not. NAT rules only rewrite addresses; Access Control rules still decide allow or drop. If a NAT rule translates the destination of inbound HTTP to an internal web server, but no Access Control rule permits HTTP from the original source to the translated destination (or to the original destination — R82 evaluates Access Control on the original, pre-NAT addresses), the connection is dropped. The two policies are evaluated independently, and both must succeed for a connection to establish.
Two Methods, Two Use Cases
The exam will repeatedly contrast the two NAT methods, so anchor them now:
- Hide NAT — many internal hosts share one public address (the gateway's or another). Outbound only; no inbound initiation. The CCSA phrase is "Hide behind the gateway."
- Static NAT — one internal host mapped to one public address. Bidirectional; supports inbound connections to published servers. Requires proxy ARP so the gateway answers for the public address on its external segment.
Everything else in this chapter — Automatic vs Manual, proxy ARP, rule placement — is a variation on these two methods.
On a Check Point R82 Security Gateway, where are Manual NAT rules authored?
A NAT rule that translates an inbound destination to an internal web server is installed, yet external clients still cannot reach the server. What is the most likely missing piece, assuming the gateway owns the public IP?