NAT Architecture for Check Point Firewalls

Scope and assumptions

This methodology is for CheckPoint Security Gateways using manual NAT rules. It was first written for releases before R80 and has been revised against the R81 documentation. IPv6 translation (NAT66, NAT64) is not covered.

• The gateway applies the first manual NAT rule that matches a connection and does not look at the rest. Everything here follows from that.
• Automatic NAT is not used. No object has "Add automatic address translation rules" ticked.
• "Translate destination on client side" is enabled for manual NAT rules in Global Properties.
• Bidirectional NAT is not relied on. It only applies to automatic rules.
• The security policy is matched on the original, untranslated addresses. Write Access rules with the public object for inbound services. See Security Policy Best Practices for Check Point Firewalls.

Ground rules

1. The five sections are always in the same order. Create them as section titles in the NAT rulebase and never move a rule out of its section to make something work.
2. Inside a section, the most specific rule goes first: a specific service above Any, a host above a network, a network above a group.
3. One connection, one rule. If Source and Destination both need translating, one rule does both.
4. Every rule has a comment: who asked for it, why, and the change reference. Even you will forget.
5. The two halves of a static NAT carry the same comment, so the pair can be found together.
6. In a policy package installed on more than one gateway, set Install On for every rule. Do not leave it as Policy Targets.
7. Use a naming convention that shows the address and the purpose, as in the examples.

Where a rule goes

Look at which fields the rule defines. Read the table from the top and stop at the first row that fits.

Reading the examples

Addresses are from the documentation ranges. The colour of a translated field, and of the bar at the left of each rule, shows what the rule does.

• No NAT
• Static NAT
• Hide NAT
• Port translation
• More than one translation

01Specific NAT and Specific NAT Exceptions

Uses

• Prevent NAT between CheckPoint management servers and CheckPoint firewalls/gateways/other.
• Prevent NAT between two hosts for a specific service etc.
• Breakout a single port to a specific host.
• Double NAT (source and destination), such as associated with Extranet firewalls.
• Hairpin NAT: a client on the same subnet as a server, reaching it by its public address. The Source must be translated as well as the Destination, or the server replies directly and the connection fails.
• NAT required by a site-to-site VPN peer, for example overlapping address space.

Discussion

Section for NAT rules that need to be extra specific for invoking or preventing NAT. These very specific rules go at the top because they override all the other rules.

Order inside the section matters as much as the order of the sections. Management exemptions come first. After that, a rule for a specific service goes above a rule for the same Source and Destination with service Any, or the Any rule will match first and the service rule will never be used.

Only one manual NAT rule is applied to a connection. If a connection needs its Source and its Destination translated, both translations must be in a single rule, and that rule belongs here.

Requirement

Two or more fields defined for Original Packet; one or more fields defined for Translated Packet.

or

Service field defined for Original Packet, with or without Source or Destination; zero or more fields defined for Translated Packet.

or

CheckPoint gateways/hosts defined for Source and Destination field defined for Original Packet, zero fields defined for Translated Packet.

or

Any rule that does not meet the requirement of sections 2 to 5.

02Destination NAT

Uses

• NAT a Destination IP to a different IP.
• NAT a Destination subnet to an equal sized subnet.

Discussion

Mostly used for publicly available services; web servers, mail, etc. Placed above the No NAT section so local/internal/dmz users experience these services in the same way Internet users do.

This holds when the client and the server are on different firewall interfaces. A client on the same subnet as the server needs a hairpin rule in section 1.

A manual static NAT is two rules: the inbound half here, and the outbound half in section 4. Give both rules the same comment so the pair can be found and changed together.

Every address translated here needs the gateway to receive traffic for it. See Proxy ARP and routing.

Requirement

Destination is only field defined for Original Packet and Destination is only field defined for Translated Packet.

03No NAT

Uses

• Preventing NAT between internal systems, preserving source IPs for accurate logging.
• Preserve IPs DMZ servers and network management systems; syslog, SNMP, authentication etc.
• Prevent NAT between the DMZ App server host/subnet and the DMZ database server host/subnet.
• Prevent NAT across a site-to-site VPN.

Discussion

Prevent NAT between specific subnets/hosts. I recommend you create a group containing all the IP blocks, including public IPs, used within a given DataCenter. Then use this group in both the source and destination fields of a "No NAT" rule. Placing the Destination NATs above the No NAT section ensures they will continue to work as intended, even when the Destination NAT IPs are included in the No NAT section.

Site-to-site VPN: either tick "Disable NAT inside the VPN community" on the community, or add a No NAT rule here between the local and remote encryption domains. Pick one way and use it for every community. If a peer requires NAT, that rule goes in section 1.

Every rule in this section has the same result, so the order inside it does not change behaviour. Keep the single DataCenter rule first and add narrower rules only when they document something the group does not.

Requirement

Source and Destination are defined for Original Packet; Translated Packet is kept Original/Original/Original.

or

Source only, or Destination only, defined for Original Packet; Translated Packet is kept Original/Original/Original. Place these at the bottom of the section.

04Source Static NAT

Uses

• Statically NAT outbound connections.

Discussion

NAT outbound services/servers to Internet; outbound Mail and regularly scheduled FTP transfers are two of thousands of potential examples. Situated below No NAT section to preserve the intent of the No NAT section, given that the destination of the source static NAT rule is Any.

This is the outbound half of a static NAT. The inbound half is in section 2 and carries the same comment.

Requirement

Source is only field defined for Original Packet; Source only field defined and is Static NAT for Translated Packet.

05Hide NAT

Uses

• Users outbound to the Internet for browsing and patch downloads.
• General population of servers outbound to the Internet for patch downloads.

Discussion

Bottom of the NAT rulebase to act as catchall rules for outbound traffic. Section could be broken into two; Specific/Host Hide NAT followed by a General/Subnet/Group Hide NAT section. Group objects containing Network objects are preferred.

A hide address has a limited pool of source ports. Give large populations their own hide address, as below, so one busy network cannot use up the ports another depends on.

Requirement

Source is only field defined for Original Packet; Source only field defined and is Hide NAT for Translated Packet.

Proxy ARP and routing

Automatic NAT rules make the gateway answer ARP for the translated address. Manual NAT rules do not. Because this methodology uses only manual rules, every translated address must reach the gateway some other way. Choose one of these for the environment and write down which.

Route it

Have the upstream router send the NAT block to the gateway, or to the cluster address. No ARP is needed, nothing has to be kept in step with the rulebase, and it works the same on a cluster. This is the preferred way.

Manual proxy ARP

For a translated address inside a subnet the gateway is directly connected to, add a proxy ARP entry on the gateway, on every cluster member, and enable "Merge manual proxy ARP configuration" in Global Properties, then install policy.

# Gaia Clish, on each member
> add arp proxy ipv4-address 203.0.113.10 interface eth1 real-ipv4-address 203.0.113.2
> save config
# after policy install, confirm the gateway has it
# fw ctl arp

Automatic, R80.10+

From R80.10 the gateway can create proxy ARP for manual NAT rules itself. It is off by default; see sk114395. If it is turned on, do not also keep manual entries for the same addresses.

Auditing

• Automatic rules: any automatically generated rule in the NAT rulebase means an object has automatic NAT ticked. Find the object, move the translation into the correct section as a manual rule, and untick it.
• Dead rules: from R81 the NAT rulebase has a hit count. A rule with no hits over a long period is either no longer needed or is shadowed by a rule above it.
• Shadowed rules: for each rule in section 1, check that no rule above it has the same or wider Source, Destination and Service.
• Pairs: every static rule in section 2 that should also work outbound has a partner in section 4 with the same comment, and the reverse.
• Placement: every rule sits in the section the decision table gives for it.

Version notes

R80.10 and later

Optional automatic proxy ARP for manual NAT rules (sk114395).

R81 and later

NAT rules accept security zones, access roles, updatable objects, domain objects and data center objects, and the NAT rulebase has a hit count. Negated objects and groups with exclusion are reported as not supported in NAT rules; use plain groups.

Automation

The Management API can add a NAT rule at a chosen position. A script that creates rules can use the decision table to choose the section, and can refuse a rule that does not fit one.