Check Point NAT — Auto vs Manual, Hide vs Static, and the Proxy-ARP Trap

The one rule that confuses every L1 candidate

Interview question: "Static NAT for the web server is configured. It pings from inside. Internet users can't reach it. Why?"
Wrong answers Ram has heard: "Firewall rule missing." "DNS not resolved." "ISP blocking 443." Sometimes one of those is true — but 9 out of 10 times the real cause is one of these three: missing Proxy-ARP entry, anti-spoofing rejecting pre-NAT IP, or rule-base order putting a manual hide rule in front of the static. Knowing which one in 30 seconds is what separates L1 from L2.

💡 The hotel front-desk analogy (the only mental model you need)

A 200-room Lucknow hotel has one phone number printed on Google. Guests in 200 rooms can all dial out — the front desk rewrites caller-ID to the hotel's main line and keeps a register: "Mr Sharma's call from Room 142 just placed → I'll route the reply back to Room 142". That's Hide NAT. Many to one. Outbound only. The world can't dial INTO a specific room.

Now imagine the same hotel publishes a dedicated counter for VIPs: "Counter 7, Mr Sharma". The counter has its own listed number. Anyone outside can dial Counter 7 directly and reach Mr Sharma. Mr Sharma can dial out from Counter 7 too. That's Static NAT. One to one. Both directions. Useful for publishing servers.

3 things you'll be tested on before we begin

① Hide NAT — the rule every corporate network ships by default

500 laptops at Wipro share one ISP link with the public IP 203.0.113.5. Every outbound HTTPS/DNS/SMTP session gets PAT'd through that one IP. The firewall keeps a stateful table mapping (internal-IP, internal-port) → (203.0.113.5, rewritten-port). When Google replies to 203.0.113.5:62117, the firewall looks up the table and ships the reply back to Sneha's laptop on its original port.

To enable: open the Network object for 10.20.5.0/24 → NAT tab → tick "Add Automatic Address Translation rules" → Translation Method = Hide → Hide behind the Gateway's external IP (or a specific IP). Install Policy. Done.

What you can't do with Hide NAT

You can't publish a server. Hide NAT is one-way only — outbound flows initiate; inbound new connections die at the firewall. For that you need Static NAT (next section). And don't try to Hide-NAT IPsec or GRE — Hide only works for TCP/UDP/ICMP. For protocol pass-through use Static or IP Pool NAT.

② Static NAT — publishing a server, with the proxy-ARP catch

Static NAT maps one private IP to one public IP, both directions. When you configure it via the object's NAT tab, SmartConsole creates two auto-NAT rules:

1. Outbound: internal → external rewrites source 10.50.5.10 → 203.0.113.10
2. Inbound: external → internal rewrites destination 203.0.113.10 → 10.50.5.10

For inbound traffic to actually arrive, the upstream ISP router must believe the gateway "owns" 203.0.113.10. That's where Proxy-ARP comes in. With Automatic NAT, Proxy-ARP auto-installs when (a) the global Auto-ARP flag is enabled AND (b) the translated IP is in the same subnet as a gateway interface. Skip either and traffic vanishes.

The Proxy-ARP fix (CLI, in Gaia)

add arp proxy ipv4-address 203.0.113.10 interface eth0 real-ipv4-address 203.0.113.1
save config

fw ctl arp
proxy 203.0.113.10 (00:1c:7f:00:00:01) on eth0

③ The 5-tier NAT Rule Base order (CCSA's favourite question)

When both Auto and Manual NAT exist, the gateway evaluates rules in this exact order:

The L1 trap: someone writes a Manual Hide rule for a network and expects it to override an Auto Static for a host inside that network. It doesn't. Auto Static for the host (tier 1) fires before Manual (tier 5). The fix is to either convert the auto rule to manual (so everything is in tier 5 and order is visible), or exclude the host from the manual rule's source range.

The 4 NAT methods compared (cheat-sheet)

④ The troubleshooting playbook — fw monitor stages

The most powerful NAT debug tool on Check Point is fw monitor. It captures packets at four inspection points relative to the firewall kernel:

i  (small i) — pre-inbound  : before FW VM, ingress side. Original src/dst.
I  (cap I)   — post-inbound : after FW VM, ingress. Post-DNAT visible from here.
o  (small o) — pre-outbound : before FW VM, egress. Pre-SNAT.
O  (cap O)   — post-outbound: after FW VM, egress. Post-SNAT visible only here.

What gets rewritten where:

• Destination NAT happens between i and I. So at I and onwards you see the post-DNAT destination IP.
• Source NAT happens between o and O. So only at O do you see the post-SNAT source IP.
• At i and o you see the original (pre-NAT) addresses on both sides.

fwaccel off    # only if you need to see SecureXL flows (R80.20+ usually unnecessary)
fw monitor -e 'accept host(10.50.5.10);' -m iIoO -o /var/log/nat_debug.cap
fwaccel on

[vs_0][fw_2] eth0:i[60]: 122.176.45.89 -> 203.0.113.10 (TCP)
[vs_0][fw_2] eth0:I[60]: 122.176.45.89 -> 10.50.5.10  (TCP)   ← post-DNAT
[vs_0][fw_2] eth1:o[60]: 122.176.45.89 -> 10.50.5.10  (TCP)
[vs_0][fw_2] eth1:O[60]: 122.176.45.89 -> 10.50.5.10  (TCP)   ← egress to DMZ

Anti-spoofing + NAT — the trap that sinks 30% of static-NAT debugs

Anti-spoofing runs BEFORE NAT on ingress. It checks the source IP of the packet as it arrives — i.e. the pre-NAT (original) source. So the interface's topology must list the pre-NAT networks that legitimately arrive on that interface.

The fail pattern: you publish a server with Static NAT 10.50.5.10 → 203.0.113.10 on DMZ interface. Then the inside DMZ topology gets set to "Network defined by gateway IP and Net Mask" which somehow now includes 203.0.113.0/24 instead of 10.50.5.0/24. Anti-spoofing sees inbound traffic with src=122.176.45.89, says "not in my DMZ topology", drops. Log reason: Address spoofing.

NAT-in-VPN — the checkbox most engineers miss

You build a site-to-site VPN. Tunnel comes up. Phase 1 + Phase 2 success. But traffic doesn't cross — peer firewall logs "according to the policy the packet should not have been decrypted". Why? Because your LAN traffic is getting Hide-NAT'd before entering the tunnel, and the VPN encryption domain on the peer expects to see the original 10.x address, not your Hide-NAT'd public IP.

Fix: in the VPN community Advanced → tick "Disable NAT inside the VPN community". Now the gateway skips Hide-NAT for traffic destined to peers in this community. Original IPs reach the peer; their encryption domain matches; traffic flows.

The 5 mistakes that cost L1 candidates the interview