How to tell which NAT rules will be the winner?

[brian1027]

Hi,

We have a couple of checkpoint fwls (R81.10) active-standby mode.

I am trying to apply a NAT rule but it is bit difficult for me to test prior to applying it.

There is a existing NAT rule as below as an example:

Rule 1: Org Source: 10.160.0.0/12, 10.0.0.0/8   Org Destination: 8.8.8.0/24  Original Service: Any
             Translated source: 125.125.125.1  Translated destination: original  translated service: original

My question is when we create another NO-NAT rule below Rule 1 as below, would this be picked up by Rule 2 instead of Rule 1 ?

Rule 2: Org source: 10.160.0.0/23, 10.0.0.0/8  Org Destination: 8.8.8.8  Original service: HTTP 

             Translated Source: original   Translated Destination: original  Translated service: HTTP

I have some users who need to access 8.8.8.8 in HTTP (tcp 80) over a GRE tunnel without being NAT'd by checkpoint. 

If the Rule 2 is not picked, what is the criteria that checkpoint use to select the right NAT rules?

In this case, Original Sources can't be more specific because two different type of users are connected to the same network. But I can make Destination address more specific (/32 address) and specific service (tcp 80). 

Thanks for your help in advance.

[Nik_Bloemers · Accepted solution]

The NAT rulebase is worked through top down, and the first match will be applied. So your NO-NAT rule should probably be above your NAT rule. It does not work like IP routing, where the most specific match is used.

[brian1027]

Thanks Nik,

There are two type of users in this scenario:

User A: need to access 8.8.8.1-7 over the normal internet and their address is NAT'd into 125.125.125.1

User B: need to access only 8.8.8.8 over the GRE tunnel and their address must NOT NAT'd.

These users are both connected to same source range say 10.160.0.0/12 range.

User A never needs to access 8.8.8.8 but 8.8.8.1-7, but User B only needs to access 8.8.8.8.

I made destination address more specific for Rule 2.

If I place Rule 2 above Rule 1, will this then work ?

Thanks in advance. 

[Nik_Bloemers]

Yes, that should work. The NO NAT rule (which would be rule #1) shall then only be hit for 8.8.8.8, for the other 8.8.8.x IP addresses it will continue to look through the NAT rulebase and hit the second rule.

[brian1027]

Makes perfect sense!

Much appreciated Nik

[Timothy_Hall]

Just to further clarify that for the top section of the NAT policy consisting of Manual NAT rules, it is indeed top-down first fit.  Just like in the old Highlander movies: "There can be only one!".  One and only one manual NAT rule can be matched there (first fit).

However if no manual NAT rules are matched in that top section the evaluation continues into the Automatic NAT rule section, at that point it is still top-down but not quite first fit.  Suppose that no top manual rules are matched, and an Automatic rule is found matching the source IP for a NAT operation.  If the NAT global property "Allow bi-directional NAT" is set (the default), evaluation will continue through the rest of the Automatic section looking for another NAT rule matching the destination IP.  If one is found two NAT rules have now been matched (sometimes called "dual NAT"), and the second matching NAT rule is shown in the log card as "NAT Additional Rule".  But only one Automatic rule can match the source, and another match the destination; for example you can't have more than one NAT rule match the source, it just takes the first one.

Also be aware that there are two levels of caching present in an attempt to avoid full-fledged NAT rulebase lookups in F2F/slowpath, which can be quite costly with thousands of NAT rules.  This caching process is mostly transparent but good to be aware of.  The Level 1 cache is SecureXL NAT templates, and the Level 2 cache is a state table called fwx_cache.  If we don't get a hit in either of those generated from prior NAT rulebase lookups, we start a full NAT rulebase lookup.  The Hit Counts added in R81 for NAT rules have been reported to be wildly inconsistent, and I suspect this is due to L1/L2 NAT cache hits not incrementing the NAT rule hit counters, which I assume only happens during a full NAT rulebase lookup.