ASA Migration errors, warnings on NAT.

[Steve Coady]

Hello

I am migrating from an ASA5520/asa803-k8.bin to an ASA5545x/asa911-smp-k8.bin.

I have implemented the the manual migration with the following path (asa803-k8.bin; asa824-5-k8; 846-5-k8; 911-smo-k8) as advised by Cisco

TAC. I have attempted to also use the FWM tool, but have not had much success accessing it. Cisco TAC now states that tool is not available.

I am getting the following warning and errors when I migrate from 824 - to - 846.

WARNING: MIGRATION: ACE converted to real IP/port values based on dynamic/static Policy NAT. The new ACE(s) need to be checked for enforcing policy NAT ACL permit ip host 69.x.x.254 host 10.y.y.58.

The following 'nat' command didn't have a matching 'global' rule on interface 'switches' and was not migrated.
nat (inside) 1 0.0.0.0 0.0.0.0

The following 'nat' command didn't have a matching 'global' rule on interface 'DMZ_1' and was not migrated.
nat (inside) 1 0.0.0.0 0.0.0.0

The following 'nat' command didn't have a matching 'global' rule on interface 'DMZ_2'  (a sub-interface on ASA5520) and was not migrated.
nat (inside) 1 0.0.0.0 0.0.0.0)

The following 'nat' command didn't have a matching 'global' rule on interface 'BusinessPartner_1' (a sub-interface on ASA5520) and was not migrated.
nat (inside) 1 0.0.0.0 0.0.0.0

The following 'nat' command didn't have a matching 'global' rule on interface 'BusinessPartner_2' (a sub-interface on ASA5520) and was not migrated.
nat (inside) 1 0.0.0.0 0.0.0.0

The following 'nat' command didn't have a matching 'global' rule on interface 'InternalDMZ' (a sub-interface on ASA5520) and was not migrated.
nat (inside) 1 0.0.0.0 0.0.0.0

I am getting the same messages on all of these nat statements

                     nat (inside) 2 access-list NOPATNAT
                     nat (inside) 3 access-list Dylan_NAT_ACL
                     nat (inside) 4 access-list NEEDPAT
                     nat (inside) 5 access-list SJH-AMCOM_PNAT
                     nat (inside) 10 access-list DEVOSTATIC1
                     nat (inside) 1 0.0.0.0 0.0.0.0

I have been keeping a weekly log of ACL hits for the last 7 months and the ACL's that match these statements have not had any hits over that time.

This statement is not getting any errors/messages and they look the same. Not sure what the difference is.

                      nat (inside) 0 access-list NAT_EXEMPTION - I am getting hitcount increments on many of the ACLs for this.

I have a TAC case open but the techs seem as stumped as I am about these errors/warnings.

Can someone please provide some expert guidance on this very important migration issue.

[Jouni Forss · Accepted solution]

Hi,

Sadly I can not give you 100% certain answers but only guesses as to what might be causing these messages.

I personally had the chance to learn the new NAT configuration format while we started migrating customers from old FWSM devices to ASAs. Therefore all the migrations that I did were complete manual rewrite of the configurations. (I have not let the ASA convert the configuration by booting to new software)

Lets look at the first messages that all refer to the same "nat" configurations on the ASA. The error messages state that the ASA has not been able to find any matching "global" configurations for some other interface.

What I guess is happening here is that the ASA is simply going through the "nat" configurations and checking if any of the other interface (other than the interface mentioned in the "nat" command) has a "global" configuration with the same ID number (1) so that it can determine if it needs to convert a configuration for that interface.

To confirm what I am guessing above I would first list all the interfaces on the ASA (which is still running the 8.0 or 8.2 software)

show ip add

Then I would list all the current "global" configurations using ID 1

show run global 1

I would then check on the basis of the above commands output the interface which DON'T have a "global" configuration with ID 1. If those interfaces are the same for which the ASA gives the above mentioned log messages then it would seem to me that these messages are only meant as information to the admin but don't really require anything to be done about them.

If the above explanations matches what you are seeing on the device then I would imagine the same applies to the other "nat" / "global" configurations with the IDs you mention.

With regards to the ACLs used in the older configurations (8.0 and 8.2), to my understanding these ACLs will NEVER get any "hitcount" increments even though they are being used. I am not sure why this is but it seems to apply to every ASA I have ever used in the mentioned software levels.

With regards to the "nat" command using the ID 0 I would say that the reason you are not seeing any similiar messages is the fact that the ID 0 is meant for NAT0 / NAT Exempt configurations which do not used any matching "global" statement. So there cant be any "global" configurations with ID 0 which the ASA would check in the same way as it did for the other IDs. And when you think about it, the purpose of NAT0 is specifically to NOT perform NAT so there is not really any need for the command that tells the ASA the mapped/nat address ("global")

After writing this I did a quick Google Search and found this from a documentation describing the migration from older software to 8.3+

Error Message    The following 'nat' command didn't have a matching 'global' rule on interface '<name>' 
and was not migrated.

Explanation    Missing global command. If a nat command does not have a matching global command, the nat command will be removed and will not be migrated.

Recommended Action    If you intended to have a matching global command, you will need to recreate the configuration using the new NAT commands.

The actual document where the above description was can be found here:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa83/upgrading/migrating.html#wp68743

Hope this helps :)

- Jouni

[Steve Coady]

Jouni

Very helpful. I appreciate the guidance.

[Steve Coady]

Note:

While testing VPN anyconnect in lab, we found the "crypto map VPN interface outside" was missing in the migrated config.

That single line prevented all VPNs from working. 

[a12288 · Accepted solution]

We did a FWSM - ASA migration few months ago, and it was very successful which could be a good news to you, so rest assured.

Bad news is that we spent months to do the ACL/NAT/PAT conversation, manually! The tool might help and it also generated lots of unwanted staff which needs to be cleaned up, so we just decided not to use it.

Bottom line, you have to fully understand the ACL/NAT/PAT implementation in ASA version 9, its implementations is changed and comes up with some implicit behaviours. In a nutshell, trying to think about ASA v9 is a router instead of a tradition firewall.

Depends on how big, how complicated your ASA configuration is, perhaps you can post part of your config here, so we can help.

Leo

[Steve Coady]

Leo

Thank you for the response. Bad news. this config is "massive" as it is a culmination of years of configs. The ACL statements alone comprise approx 6k lines, no kidding!

I am not sure if it was ever cleaned up along the way.

[Steve Coady]

One other thing

I have been taking weekly logs of ACL and their hit counts. 80% of the ACL statements have never had a hit in the last 7 months.

Thanks again for the guidance.

[a12288]

Not too bad, our FWSM's ACL was close to the limit, around 14K lines.

How many vlans do you have, are there any of them sharing the security level, how do you handle the inter-vlan communication, etc, etc?  They will determine your efforts of migration.

In ASA v9, ACL decides the traffic flow, (not the NAT any more, again think ASA as a router). For example, if you have a ACL allow VLAN-a talks to VLAN-b (security level makes no difference any more), then you have no way to block the returning traffic by ACL either on VLAN-a or VLAN-b.

Trying your migrated configuration on LAB, simulate some traffics and fully understand how ASA v9 behaves, which will not only give you a smooth migration but also a good night sleep after migration.

We didn't even bother to clean up the ACLs, just migrate them (apple to apple) in order to avoid any finger pointing after migration. Quite frankly, work with system / app owners / admin to clean up ACLs accumulated in the past 10 years probably more challenging than to migrate them. Considering you have 6K lines of ACL, I won't recommend to clean them up, why bother?

In my own migration experience, ACL is the most challenging, tedious and painful part. 

Hope it helpful and could make your migration process less painful.

Leo