Automatic NAT Problem

[Murat_Akdag]

Hi everyone,

We had a automatic NAT problem during our migration from R80.10 to R80.30

There is a object with automatic static nat (Ip address is: 10.10.10.10 Automatic Static Natted Ip adress: 30.30.30.30 )

Somehow one of our colleague created another object with same method (Ip Adress is: 10.10.10.20 Automatic Static Natted Ip adress: 30.30.30.30 )

Before the upgrade, requests from internet to 30.30.30.30 were NATted to 10.10.10.10. But after upgrade equests from internet to 30.30.30.30 were NATted to 10.10.10.20. 

When we are looking to the SIEM logs we can see that change of NATted IP fits upgrade window. We exported the database from R80.10 and imported to fresh installed R80.30 management server.

I know creating same object with same NAT IP is not right thing to do but my real problem is can a upgrade cause such a problem.

Regards.

[_Val_]

all you need to do is to remove one of the conflicting objects or change NAT settings for it.

[mdjmcnally]

The upgrade won't cause this.

However you can make changes to the policy / objects etc and not push them to the Gateway/Cluster.  So you would have the change present on the Management Server but not the Gateway/Cluster.

When the Gateway/Cluster is upgraded you do policy installs so would then push the additional change out.

I would believe that the additional object is named so that alphabetically before the original object so is what would be matched as would be before the original automatic nat rule.

So whilst the object would be there before hand it wouldn't take affect till the policy installation.

The Audit Log on the checkpoint will tell you which account made the new object and when.  SIEM logs will only tell you when the traffic started NAT to different address.

Just remove the automatic NAT from the new Object and install to resolve.   

But the upgrade itself won't cause an object to be created like that.

[Christopher__C2]

You have two automatic static NAT rules, whichever one is found in the policy will be used first.

With Manual NAT rules, you have specific control over the order.  This is not really going to be true with automatic rules. There is no documented / supported method I'm aware of to determine which will be first.

When upgrading R80.10 to R80.20, the entire database is exported and imported. And so, yes, things that should not matter what order they are in may change in order.  And because there is no support for determining what order these might be in, there is no effort made on the export / import to make sure they are in the same order.

Also remember that if the rule for 10.10.10.10 comes first, traffic from a source address of 10.10.10.10 is translated to 30.30.30.30. And traffic with a destination of 30.30.30.30 is translated to 10.10.10.10. (I'm sure we all understand this.) Bit also traffic from source of 10.10.10.20 will still be translated to 30.30.30.30, because there will be a rule in the NAT policy to match and translate this.

And this is one of the properties of the connection in the state table, and the connection will work.  But, port numbers can conflict and get stepped on, and this again, shouldn't really be done just kinda coincidentally works...