NAT Rule Layout/Architecture

[alienbaby]

I'd like to start a discussion on efficient/best NAT rule layout. Here is my current thinking on NAT rulebase architecture.


NAT Architecture

Summary:

The goal of this architecture is to create a methodology that allows for the long term management of Large and Small NAT rulebases, preserving the intent of the rulebase over years of changes without breaking previously working configuration. This methodology is intended to account for every possible NAT rule scenario. Automatic NAT rules are not used with this methodology.

Version: 0.6

Sections:

1. Specific NAT and NAT Exceptions

Requirement: Two or more fields defined for Original Packet AND one or more fields defined for Translated Packet
Or
Requirement: Source or Destination AND Service field defined for Original Packet AND zero or more fields defined for Translated packet.
Or
Requirement: CheckPoint gateways/hosts defined for Source and Destination field defined for Original Packet AND Translated Packet is kept Original/Original/Original.


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

Keep in mind that NAT policy ignores the Topology section of an object; only the General Settings IP address is used/enforced.

Uses: Prevent NAT between CheckPoint management servers and CheckPoint firewalls/gateways/other.

Prevent NAT between CheckPoint firewalls and internal services (DNS, Authentication, NTP, SNMP, syslog etc.) [Override implied Cluster NAT]
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
Specifically NAT traffic before/after passing through a VPN

2. Destination NAT

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


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

Uses: NAT a Destination IP to a different IP.

NAT a Destination subnet to an equal sized subnet.

3. No NAT

Requirement: Source AND Destination are defined for Original Packet AND Translated Packet is kept Original/Original/Original.


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, insures they will continue to work as intented, even when the Destination NAT IPs are included in the No NAT section.

Uses: Preventing NAT between internal systems, preserving source IPs for accurate logging on the receiving system.

Preserve IPs of 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 between one VPN Encryption Domain (group/host/subnet) and another VPN Encryption Domain (group/host/subnet).

4. Source Static NAT

Requirement: Source is only field defined for Original Packet AND Source only field defined for Translated Packet as Static NAT.


Discussion: NAT outbound services/servers to Internet; outbound Mail and regularly scheduled FTP transfers are two of thousands of potential examples. Arranged below No NAT section to preserve the intent of the No NAT section, given that the destination of a Source Static NAT rule is always Any.

Uses: Statically NAT outbound connections.

5. Hide NAT

Requirement: Source is only field defined for Original Packet AND Source only field defined for Translated Packet as Hide NAT.


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.

Uses: Users outbound to the Internet.

General population of servers outbound to the Internet.

Examples:

1. Specific NAT and NAT Exceptions

Firewalls-London(group)     -> CheckPoint-Management01           -> Any      ; Original              -> Original                -> Original
CheckPoint-Management01     -> Firewalls-London(group)           -> Any      ; Original              -> Original                -> Original

Net-192.168.1.0_24-Internal -> Host-192.0.0.1-Extranet_Customer1 -> Any      ; NAT-192.0.2.1(hide)   -> Original                -> Original
Net-192.168.1.0_24-Internal -> Host-192.0.0.1-Extranet_Customer1 -> TCP-8080 ; NAT-192.0.2.1(hide)   -> NAT-192.168.2.1(Static) -> Original
Net-192.168.1.0_24-Internal -> Host-192.0.0.1-Extranet_Customer1 -> TCP-8080 ; NAT-192.0.2.1(hide)   -> Original                -> TCP-23
Net-192.168.1.0_24-Internal -> Any                               -> TCP-8080 ; NAT-192.0.2.1(hide)   -> Original                -> TCP-23

Host-Customer12             -> NAT-192.0.0.1-ExtranetWeb01       -> TCP-8080 ; Original              -> Original                -> TCP-20012-Customer12
Host-Customer47             -> NAT-192.0.0.1-ExtranetWeb01       -> TCP-8080 ; Original              -> Original                -> TCP-20047-Customer47
Host-Customer99             -> NAT-192.0.0.1-ExtranetWeb01       -> TCP-8080 ; Original              -> Original                -> TCP-20099-Customer99

2. Destination NAT

Any   ->   NAT-192.0.0.1-www   ->   Any ; Original   ->   Host-10.12.237.1-WebServer(static)   ->   Original

3. No NAT

Net-Internal(group)         -> Net-Internal(group)         -> Any ; Original -> Original -> Original
Net-DMZs(group)             -> Net-DMZs(group)             -> Any ; Original -> Original -> Original
Net-Internal(group)         -> Net-DMZs(group)             -> Any ; Original -> Original -> Original
Net-DMZs(group)             -> Net-Internal(group)         -> Any ; Original -> Original -> Original

Net-192.168.1.0_24-Internal -> Net-10.1.1.0_24-DMZ1        -> Any ; Original -> Original -> Original
Net-10.1.1.0_24-DMZ1        -> Net-192.168.1.0_24-Internal -> Any ; Original -> Original -> Original

4. Source Static NAT

Host-192.168.1.1-MailServer -> Any -> Any ; NAT-192.0.0.1(static) -> Original -> Original

5. Hide NAT

Net-Internal_Networks(group) -> Any -> Any ; NAT-192.0.0.42(hide) -> Original -> Original
Net-DMZs(group)              -> Any -> Any ; NAT-192.0.0.43(hide) -> Original -> Original
Net-192.168.12.0_24-Wireless -> Any -> Any ; NAT-192.0.0.44(hide) -> Original -> Original

[mcnallym]

The first thing that springs to my mind with that idea is that the source and destination nats for a server are not located together,

ie

Src = Internal Mail Server, Dst = Any Srv=Any
xlatesrc=Public Mail Server, xlateDst = Original, xlateSrv = Original

Src = Any Dst = Public Mail Server, Srv = Any
xlatesrc = Original, xlateDst= Internal Mail Server, xlateSrv = Original.

With your suggestion then they are going to be potentially spaced far apart in the two different sections with the No NAT inbetween them.

Personally I like my inbound and outbound NATs for a Server togther, so that can locate them easily as I am troubleshooting. Can then have a Section Header for the Server, so can quickly locate the NAT for the Service that I am having an issue with.

I then tend to order the servers in what we find the most traffic is for, ie mail up towards the top etc

[alienbaby]

I'm all about supportability in the designs I produce. I see this architecture being both supportable (due to Section Labels) and functional; given that the resulting policy reduces the number to incidences caused by daily adds/moves/changes.

Some of my NAT rulebases are over 600+ rules. With rulebases that large, insuring intended behavior is a higher priority. I want to be sure the traps, syslog, etc. are received by the various management platforms with the real/physical IP of the originating server. I also want to be sure that Internal Users have the same experience for NAT'd DMZ servers that Internet users have. I need to insure that a firewall admin adding new NAT policy doesn't break previous policy or that new policy isn't shadowed by previous policy; resulting in a troubleshooting sessions after the policy is installed.

In the No NAT section, I always want 'Internal IP Blocks' to 'Internal IP Blocks' Original/Original/Original.
If such a rule is above the destination NAT, and 'Internal IP Blocks' includes a sites/organizations Public IP blocks, then Destination NATs cease to function for internal users.

[alienbaby]

This architecture has worked very well. Following the original post, I blindly converted one of my more complex NAT policies (200+ rules). With no prior analysis and using the rules stated, I rearranged the policy.

The resulting policy has now been running for 2+ months with no reported issues.

[alienbaby]

Edited original post to add examples and clarify the NAT sections.