Remove nat0 ANY prior to 8.4 upgrade

[billmatthews]

We're upgrading from ASA 8.2 to 8.4.  Our current config as some NAT0 rules with any.  I inherited this config, so I'm not sure why they are written this way.  But apparently the NAT conversion tool has a bug (CSCtf57830) that prevents proper conversion when you have a nat0 any. 

Any suggestions on how I could work around this?

nat (inside) 0 access-list inside_nat0_outbound
access-list extended permit ip any 10.10.10.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip any 10.10.20.0 255.255.255.0

nat (dmz1) 0 access-list dmz1_nat0_outbound
access-list DMZ-VPN_nat0_outbound extended permit ip any any
access-list DMZ-VPN_nat0_outbound extended permit ip any 10.10.20.0 255.255.255.0

nat (dmz2) 0 access-list dmz2-nat
access-list dmz2-nat extended permit ip any object-group inside-networks

Thanks

Bill

[varrao]

Hi Bill,

The bug that you mentioned is already  resolved in version 8.3.2 and later, so I do not see any issue in conversion from 8.2 to 8.4, it should be done rightly.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtf57830

Thanks,

Varun

[billmatthews]

Thats what I was hoping, but not what we're experiencing.  We did the upgrade to 8.4 and it did not convert our ACLs due to this bug.  (see TAC case 620281041).  We've asked the case to be re-queued since our engineer is on vacation.

Anyway I also found this thread: https://supportforums.cisco.com/thread/2109261 which seems to indicate the bug isn't actually "fixed" -- they simply added a warning about it during the conversion process and marked it as fixed?

[varrao]

Hi Bill,

well yes, it does seems so, I checked at my end and Mike is right, it does seem to be the issue. If you are looking for the 8.4 nat converted statements for the above nat statements then let me know, i can definitely help you with that.

Thanks,

Varun

[billmatthews]

Hi Varun,

Thanks for the clarification.

The problem is that with those 8.2 statements in our config, the entire ACLs fail to convert.  So I assume I need to remove them prior to conversion, then re-add them in an 8.4 format after conversion?

Bill

[varrao]

Hi Bill,

Yes, you can remove the nat exempt statements from the configuration, so that the static acl's are migrated fine, and later add the exempt's as needed on the ASA.

Varun

[Marvin Rhoads]

Varun,

So the table posted here is incorrect in saying that the nat exempts will be migrated fine?

I have a migration coming up shortly with potentially the same issue. I will be moving from 8.0(2) to 8.4(3) and have nat0 commands, e.g.:

nat (inside) 0 access-list inside_nat0_outbound

access-list inside_nat0_outbound extended permit ip any xxx.xxx.xxx.0 255.255.252.0

access-list inside_nat0_outbound extended permit ip any xxx.xxx.xxx.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip host xxx.xxx.xxx.xxx xxx.xxx.xxx.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip xxx.xxx.0.0 255.255.0.0 xxx.xxx.0.0 255.255.252.0

access-list inside_nat0_outbound extended permit ip any xxx.xxx.xxx.0 255.255.255.0

So I should first do:

no nat (inside) 0 access-list inside_nat0_outbound

Perform the upgrade, let the software update the "access-list inside_nat0_outbound" by building objects and then reapply the nat exemption using the new syntax, e.g.:

nat (inside, any) source static [object, object] destination static [object, object]

I believe I will need a line as above for each of the five ACEs in the access-list above.

Yes?

[billmatthews]

Marvin, that's what our TAC engineer recommended, and it seemed to help.  The ACLs did get updated once the nat 0 was removed.

But just as a warning, we're still having lots of problems.  Our next problem was with dynamic NATs.  They were present in the config, but simply not matching traffic.  We had to remove them and switch to statics.  Our TAC engineer isn't sure why (yet).

[Marvin Rhoads]

Sorry to hear you had or are having ongoing problems, Bill.

FYI my upgrade this weekend went well. I ended up NOT having to manually configure any of my NATs. I had gone to the trouble of working them out on my own ahead of time just in case so as not to prolong the maintenance in the event that things went south.

I took two pair of ASAs from 8.0(3) directly to 8.4(3). The expected (or should I say hoped for ) conversion went as advertised. Customers did not notice any downtime at all as I moved the active-standby single context pairs throught their upgrade paces.