NAT with ECMP / multiple default routes

[Markus_Marquard]

Hi, in my scenario I have a Gateway with multiple (two) equal cost default routes. I am trying to get NAT properly done but I am running into issues.

As there are two equal cost default routes learned by OSPF, the external interfaces have different ip addresses in different subnets leading to internet routers to two different ISPs.

So the source ip address of packets going out on each external interface shoud get NATted to the interface's address, right?

From my understanding, it is not possible to use a static NAT rule in this scenario because we cannot configure ONE static address for hide nat, we have always take into account that we have TWO external interfaces. So I came up with just enabling the AUTO HIDE NAT by enabling it in the Gateway properties.

Unfortunately we have issues with it, as we are seeing packets going out on one external interface with the NATted source address of the other external interface (and vice versa). This leads to packets get dropped or irregular routing.

It happens on R77.30 as well as on R80.10 and is reproduceable also in a very basic setup.

Is there any other way to get this working? ECMP default routes from OSPF with hide nat? What is your experience?

[PhoneBoy]

The decision to NAT usually happens before the packet is routed.

Perhaps try disabling "Translate destination on client side" in Global Properties:

[Roman_Niewiadom]

I think he has to enable the option "Translate destination on client side" by "Automatic NAT rules". 

Is this enabled: 1st translate, 2nd route

Is this disabled: 1st route, 2nd translate

[Markus_Marquard]

Yes, it is enabled and it is the only way which makes sense to me. Otherwise we will run into other trouble.

Anyway, this setting is related to destination nat. The issue we have is about the source (hide) nat, which is done to the wrong interface ip address.

It is also occurring for connections originating from the firewall itself, e.g. connections to Checkpoint update service. I don't know the exact architecture of the NAT engine and the operating system kernel for routing in this case. But for sure the NAT engine must already know the final destination interface to do correct source/hide NAT. This seem not to work correctly in our case when we have two routes to the same destination (default in our case).

Also it seems not to be related to OSPF ECMP, it also happens with just having two equal-cost static default routes in place.

[Timothy_Hall]

NAT policy is checked for a new connection right after the Network Access Policy Layer (Firewall policy) issues an Accept for the connection.  Once this NAT determination has been made, it cannot be changed under any circumstances for the life of that connection.

If the destination IP of the packet is subject to NAT and "translate destination on client side" is checked (the default), the actual NAT operation on the destination IP only will occur prior to routing by IP (between i and I) on the so-called "client side" of the firewall kernel.

If the source IP of the packet is subject to NAT, the actual NAT operation on the source IP will not occur until after routing by IP (between o and O) on the "server side" of the firewall kernel.

It doesn't matter whether the NAT was set up using the Automatic or Manual technique, or if it is a Static or Hide NAT, the two statements above will always hold true.  Whether the destination is NATted prior to routing can be controlled in the NAT global properties individually for both Automatic and Manual NATs, but where the source IP is NATted cannot be changed.

Check out Policy-Based Routing (PBR) which allows you to do all kinds of crazy things.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.