CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


Tim Hall has done it again! He has just released the 2nd edition of "Max Power".
Rather than get into details here, I urge you to check out this announcement post.
It's a massive upgrade, and well worth checking out. -E

 

Results 1 to 5 of 5

Thread: NAT Rule Layout/Architecture

  1. #1
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    13

    Default NAT Rule Layout/Architecture

    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
    Code:
    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
    Code:
    Any   ->   NAT-192.0.0.1-www   ->   Any ; Original   ->   Host-10.12.237.1-WebServer(static)   ->   Original
    3. No NAT
    Code:
    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
    Code:
    Host-192.168.1.1-MailServer -> Any -> Any ; NAT-192.0.0.1(static) -> Original -> Original
    5. Hide NAT
    Code:
    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
    Last edited by alienbaby; 2015-07-30 at 12:54.

  2. #2
    Join Date
    2007-06-04
    Posts
    3,267
    Rep Power
    16

    Default Re: NAT Rule Layout/Architecture

    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

  3. #3
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    13

    Default Re: NAT Rule Layout/Architecture

    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.
    Last edited by alienbaby; 2010-11-04 at 12:34.

  4. #4
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    13

    Default Re: NAT Rule Layout/Architecture

    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.

  5. #5
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    13

    Default Re: NAT Rule Layout/Architecture

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

Similar Threads

  1. LDAP Architecture (tree)
    By Toleukhan in forum SmartDirectory/LDAP/Active Directory
    Replies: 7
    Last Post: 2011-02-01, 16:18
  2. Security Architecture Engineer Needed at Chase Paymentech in Salem NH
    By lpyhtila in forum Employment/Consulting Opportunities For Check Point Administrators
    Replies: 3
    Last Post: 2010-09-23, 18:35
  3. About MEP architecture and VPN availability
    By TommyBoay in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 2
    Last Post: 2010-03-16, 05:50
  4. VPN / ISP redundancy architecture
    By underattack in forum ISP Redundancy
    Replies: 1
    Last Post: 2007-08-16, 03:47
  5. Checkpoint Architecture
    By Binary_01 in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 1
    Last Post: 2006-10-23, 12:31

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •