This can happen if a duplicate NAT rule is added to the CSM NAT table with only one difference from the existing rule: the new rule should have different description.
In such a case rules differ from CSM point of view and it tries to deploy both of them, but from ASA point of view rules are identical and second configuration statement overwrites the first one.
For example configuration delta can look like this:
nat (inside,outside) 100 source static obj-A obj-B description D1
nat (inside,outside) 200 source static obj-A obj-B description D2
In this case ASA puts into its config the following statement into position 100, despite explicit line numbers provided by CSM:
nat (inside,outside) source static obj-A obj-B description D2
This creates discrepancy between CSM and ASA rule tables: CSM now has one more NAT statement than ASA. If after that new NAT statements are added on CSM below position 100, they are shifted in ASA config, which creates config delta on every deployment. Even worse, it was observed that after editing NAT policy, rules can start moving from one position to another on every deployment, rule order is changed and user traffic can stop.
So, there are two bugs here:
- CSM should not deploy duplicate NAT rules with different descriptions
- ASA should honor NAT line numbers in the above scenario, instead of ignoring them, and should print "ERROR: duplicate NAT detected", instead of overwriting one line with another
NB. The "description" field is not part of a NAT statement from ASA point of view. For example, if the following is configured:
nat (inside,outside) 100 source static obj-A obj-B description D1
then the following CLI removes this statement:
no nat (inside,outside) source static obj-A obj-B description D2
