2.2 Manual NAT Rules (Source, Destination, Bi-directional & Port Translation)

2.2 Manual NAT Rules (Source, Destination, Bi-directional & Port Translation)

Network Address Translation (NAT) is a core component of Check Point firewall architecture, enabling IP address obfuscation, IP conservation, and controlled access between private enterprise networks and external public networks. In Check Point R82, NAT is broadly divided into Automatic NAT (configured directly within host, network, or address range object properties) and Manual NAT (configured directly in the SmartConsole NAT Rulebase table).

While Automatic NAT is convenient for simple outbound internet access or 1:1 static server mappings, Manual NAT provides granular control. It allows security engineers to construct complex translation rules combining specific Source, Destination, and Service conditions—essential for scenarios such as Port Address Translation (PAT / Port Forwarding), Bi-directional NAT, and non-standard port mappings.

---

NAT Rulebase Order of Evaluation (Critical Exam Topic)

Check Point R82 enforces a strict, immutable three-section hierarchy when evaluating NAT rules against incoming packet streams. Understanding this order is vital for passing the CCSE R82 exam:

1. Manual Source NAT Rules: Located at the top of the NAT Rulebase table (Section: Manual Rules - Source). Evaluated first.
2. Automatic NAT Rules: Middle section containing system-generated rules derived from object properties (Section: Automatic Rules).
3. Manual Destination NAT Rules: Bottom section of the NAT Rulebase table (Section: Manual Rules - Destination). Evaluated last.

Operational Impact of Rule Order

If a packet matches a rule in the Manual Source NAT section, packet translation occurs immediately, and subsequent Automatic or Manual Destination rules are bypassed. Conversely, because Automatic NAT rules are evaluated before Manual Destination NAT rules, an automatic static NAT rule on a host object will override a manual destination NAT rule created for that same host unless an explicit manual source rule takes precedence.

---

Source NAT Mechanics: Hide NAT vs. Static NAT

Source NAT alters the originating IP address (and optionally the source port) of outbound packets.

1. Hide NAT (Many-to-One)

Hide NAT maps an entire internal network subnet or IP range to a single public IP address (typically the external interface IP of the Security Gateway or an assigned pool IP).

• Port Allocation: The gateway allocates unique ephemeral source ports (ports > 1024) from its dynamic translation table (nat_alloc).
• Capacity Limit: A single Hide NAT IP address can support approximately 65,000 concurrent socket connections per destination IP.
• Initiation Scope: Hide NAT operates strictly one-way. Outbound connections initiated from internal hosts are allowed, but external hosts on the internet cannot initiate inbound connections to internal Hide NAT addresses.

2. Static NAT (One-to-One)

Static NAT assigns a permanent, dedicated public IP address to a single internal private host IP.

• Initiation Scope: Supports bi-directional connection initiation. Internal hosts can initiate outbound traffic, and external hosts can initiate inbound connections using the mapped public IP.
• Port Preservation: Original source and destination transport ports remain unchanged unless explicit port translation rules are added.

---

Destination NAT & Port Translation (PAT / Port Forwarding)

Destination NAT modifies the destination IP address and/or destination transport port of inbound packets. This is primarily used to expose internal DMZ servers to the internet using public IP addresses without exposing internal network topology.

Field Structure in Manual NAT

In SmartConsole, a Manual NAT rule consists of six core fields split between Original and Translated headers:

Example Scenario: Web Server Port Forwarding (PAT)

An enterprise hosts an internal web server on private IP 192.168.10.50 listening on standard HTTPS port 443. The organization wants external users to connect to public IP 203.0.113.50 on custom port 8443.

Manual NAT Rule Construction:

• Original Source: Any
• Original Destination: Public_Web_Server_203.0.113.50
• Original Service: HTTPS_Custom_8443 (TCP 8443)
• Translated Source: Original (Keeps the remote user's client IP)
• Translated Destination: Internal_Web_Server_192.168.10.50
• Translated Service: HTTPS (Translates destination port to TCP 443)

---

Bi-Directional NAT Mechanics

Bi-directional NAT translates both the source and destination IP headers simultaneously within a single connection. This is necessary when:

• An internal user accesses a DMZ server using its public IP address (Loopback NAT / Hairpin NAT), requiring the gateway to rewrite the client's source IP so reply traffic routes back through the firewall.
• Overlapping IP address subnets exist between two merging corporate networks across a VPN tunnel.

In SmartConsole, checking the Bi-directional NAT checkbox on a manual rule automatically creates the inverse translation rule for return traffic.

---

Proxy ARP Considerations on Gaia OS

When a Manual or Automatic Static Destination NAT rule utilizes a public IP address that resides within the same IP subnet as the gateway's external physical interface—but that IP is not physically assigned to any network interface on the gateway—the Security Gateway must answer ARP requests on behalf of that NAT IP.

If Proxy ARP is not configured, upstream routers will send ARP requests for the public NAT IP, but no device will respond, resulting in complete connection timeout.

Configuring Proxy ARP on Gaia OS

Method 1: Gaia Clish Command Line (Recommended)

# Add a proxy ARP entry mapping public NAT IP 203.0.113.50 to external interface eth0
add proxy-arp ipv4-address 203.0.113.50 interface eth0

# Save configuration permanently
save config

Method 2: $FWDIR/conf/localarp.net File Edit $FWDIR/conf/localarp.net on the gateway and append: <NAT_IP_Address> <Interface_MAC_Address>

# Verify active Proxy ARP entries in gateway kernel
fw ctl arp

---

CLI NAT Troubleshooting & Inspection Tools

Security engineers troubleshoot NAT issues using Gaia OS kernel diagnostic tools:

# Display NAT allocation table summary and memory usage
fw ctl tab -t nat_alloc -s

# Dump active NAT dynamic translations in kernel memory
fw ctl dump nat

# Capture packets before and after NAT translation engine
fw monitor -e "accept host(192.168.10.50);"

Note: In fw monitor, inspect point i (pre-inbound) shows the packet before NAT, while inspect point O (post-outbound) shows the packet after translation.