NAT Ordering with Overlapping Encryption Domains
A Check Point R82 gateway sits between an internal network 10.10.0.0/16 and two partners. Partner A reaches an internal server farm at 10.10.5.0/24 and expects to see it as 192.168.100.0/24. Partner B reaches the same farm and expects 172.16.50.0/24. A VPN community covers Partner A only; Partner B connects over the internet with a site-to-site tunnel terminated on a different peer in the same community. The administrator created three manual NAT rules in this order: (1) source=Any, destination=192.168.100.0/24 -> translate to 10.10.5.0/24; (2) source=Any, destination=172.16.50.0/24 -> translate to 10.10.5.0/24; (3) source=PartnerA_net, destination=10.10.5.0/24 -> hide behind 192.168.100.1. Partner B reports intermittent connectivity and logs show the destination being translated twice.
1. Diagnose why Partner B fails and explain the interaction between the automatic and manual rules.
Read the worked answer
The manual rules are evaluated top-down before automatic rules, and rule 1 has source=Any, so it matches Partner B traffic as well as Partner A. Because rule 1 is a destination NAT rule, it rewrites the destination to 10.10.5.0/24; rule 3 then applies source NAT for Partner A. For Partner B, rule 1 matches, and the packet is translated to the real address, but rule 2 is never reached - the 'double translation' in the log is the destination NAT from rule 1 followed by the reverse translation on the return path.
Fix: scope rule 1 to source=PartnerA_net (or the correct VPN community object) so it cannot match Partner B. Better: use NAT rules keyed on the VPN community / peer object rather than Any, and put the more specific rules above the general ones. Remember manual NAT is first-match, and automatic NAT (object-level NAT) is inserted below manual rules.
2. The administrator wants Partner B to also see 10.10.5.0/24 as 172.16.50.0/24. What ordering and scoping changes are required, and how do you verify?
Read the worked answer
Scope each rule to its peer:
- Rule A: source=PartnerA_net, destination=10.10.5.0/24 -> source hide 192.168.100.1, destination translate to 192.168.100.0/24.
- Rule B: source=PartnerB_net, destination=10.10.5.0/24 -> destination translate to 172.16.50.0/24.
Order: specific source rules above any Any-source rule. Because manual NAT is top-down first-match, a rule with source=Any at the top will shadow everything below it.
Verification: use fw monitor on the gateway to see pre- and post-NAT addresses (i/I and o/O), check fw ctl zdebug + drop for drops, and confirm the return path is symmetric. Also confirm the encryption domain includes the translated addresses for the partner, otherwise the packet is routed in the clear or dropped by the VPN policy.