Showing results for 
Search instead for 
Did you mean: 

Ehsan M.

ASA 5520 Upgrade From 8.2 to 9.1

To All Pro's Out There,

I have 2 x ASA 5520 in Active/Standby state (Routed, Single context) running 8.2(3) image. They are working great and everybody is happy. Now it's time for us to upgrade to the latest and greatest version: 9.1 and as you know there are some architectural changes Cisco made to NAT statements and Access Lists. As one can tell, we have a monster environment in terms of NAT statements and access list that are currently configured on the appliances.
In order to make the upgrade process "less" painful, I was able to find a loaner ASA 5520 device so I can practice the upgrade process offline and if needed, I use it in production (in conjunction with existing Primary and Secondary devices) should it be helpful. I currently don't have any plans on how to move forward with these 3 devices and put together an smooth upgrade. I am asking advice from experts that perhaps have done this in the past and know some Do's and Don’ts and can provide me some options toward getting best result: Minimum downtime and Smooth upgrade.

I appreciate all the help in advance.

Jouni Forss


My personal approach from the start has been to learn the new NAT configuration format on the ASA CLI and manually convert the configurations for the new ASA software. I am under the impression that the automatic conversion that the ASA does by rebooting straight into a new software level causes quite a lot of configurations and they arent really optimal.

In your case it seems that you have a pretty much better situation than most people that dont have the chance to use a test device to test out the setup before actually putting it in production.

What you can basically do is

  • Insert the 8.2 configuration to the test ASA and boot it straight to the higher software levels and see what the conversion has done to the ASA configurations.
  • You can use "packet-tracer" command to test if correct NAT rules are still hit after the conversion

So far I have been lucky in the sense that most of the upgrades I have done have involved new hardware which has basically let me configure everything ready and just switch devices for the customer. So far everything has went really well and there has been only a 1-2 mistakes in NAT configurations because of misstyping some IP address or interface name which basically resulted from a lot of copy/paste when building the configurations. And these couple of mistakes have been from around 150 firewall migrations (of which most from FWSM Security Context to a ASA Security Context)

If you have time to put into this then I would suggest you try to learn the new NAT format and write your NAT configurations yourself. Converting the existing configurations should essentially give you the tools to then maintain that firewall configuration easily in the future and apply that knowledge elsewhere.

If you want to read a bit about the new NAT configuration format then I would suggest having a look at the NAT 8.3+ document I made:

My personal approach when starting to convert NAT configurations for the upgrade is

  • Collect all NAT configurations from the current ASA including any ACLs associated with the Policy type NATs and NAT0 configurations
  • Divide NAT configurations based on type   
    • Dynamic NAT/PAT
    • Static NAT
    • Static PAT
    • NAT0
    • All Policy Dynamic/Static NAT/PAT
  • Learn the basic configuration format for each type of NAT configuration
  • Start by converting the easiest NAT configurations   
    • Dynamic NAT/PAT
    • Static NAT/PAT
  • Next convert the NAT0 configurations
  • And finally go through the Policy NAT/PAT configurations
  • Finally go through the interface ACLs and change them to use the real IP address as the destination in all cases since the NAT IP address is not used anymore. In most common screnarios this basically usually only involves modifying the "outside" interfaces ACL but depending if the customer has some other links to external resourses then its highly likely that same type of ACL changes are required on those interfaces also.

The most important thing is to understand how the NAT is currently working and then configure the new NAT configuration to match that. Again, the "packet-tracer" command is a great tool to confirm that everything is working as expected.

One very important thing to notice also is that you might have a very large number of Identity NAT configurations between your local networks interfaces of the ASA.

For example

static (inside,dmz) netmask

In the new software you can pretty much leave all of these out. If you dont need to perform NAT between your local interfaces then you simply leave out all NAT configurations.

Naturally you can also use these forums to ask help with NAT configuration conversions. Even though its a very common topic, I dont personally mind helping out with those.

So to summarize

  • Try out the ASAs automatic configuration conversion when simply booting to new software levels on the test ASA you have
  • Learn the new NAT configuration format
  • Ask for help here on CSC about NAT configuration formats and help with converting old to new configurations.

Personally if I was looking at a samekind of upgrade (which I will probably be looking at again soon) I would personally do the following

  • Convert the configurations manually
  • Lab/test the configurations on an test ASA
  • During Failover pairs upgrade I would remove the Standby device from network, erase its configurations, reboot it to new software, insert manually written configurations.
  • Put the upgraded ASA to the device rack and have cables ready connected to the customer devices if possible (or use existing ones)
  • Disconnect currently active ASA running 8.2 and connect the new ASA to the network while clearing ARP on the connected routers to avoid any problems with traffic forwarding.
  • Test connectivity and monitor ASAs connection and xlate tables to confirm everything is working

Will add more later if anything comes to mind as its getting quite late here

Hope this helps

- Jouni

Dear Jouni,

Can you please upload the below document in pdf please?

Thanks in Advance



That document has been created through this site in its own editor so I would imagine it would require some work to get it properly set into a separate document.

Though you can view it as a PDF through the link in the top right corner of the page when you have the document open. You can also right click it to save it to your computer.

It doesnt really convert it to PDF very well though. The spacing of the text etc are a problem.

- Jouni

I did an 8.2 to 9.0 migration last year on 5520's (later replaced by 5525-x), and had the same luxury of a test lab.  In my case I was also doing some subnet renumbering and making some routing changes, so I was much better off using the same tactic Jouni is recommending of:

  1) load a clone of a production config on spare firewalls with old 8.2 firmware

  2) upgrade spares to 9.0, letting the configuration autoconvert

  3) use the result of the autoconvert to guide rewriting the config from scratch

  4) deploy the new configs and new firmware simultaneously on the production firewalls

My organization tolerates short network maintenance outages off-hours, which made the deployment a lot easier.

Since the new NAT design uses real addresses in the ACL's, I had a bunch of network object groups to adapt, plus a bunch of new network objects.  I was able to get rid of a lot of nat0 stuff, since I only need to NAT when going outside.  I basically ended up reducing to one inbound static nat mapping per exposed private server, one outbound dynamic nat mapping per private subnet, and a couple of nat0 mappings associated with 3rd party IPsec tunnels. I had to put the nat0 stuff in phase I so it would take priority over the dynamic maps; the rest of my actual nat is all the new-style phase II network object stuff.

Also, since 9.x uses new IPv6 syntax, I did some IPv6/IPv4 unification on rules for things that are already dual-stacked like my DMZ DNS servers, and then made sure to use "any4" rather than "any" on my v4-only rules.

On 8.2 I had an IPsec tunnel related bug where about every 6 weeks or so subsets of my cross-firewall subnets would stop communicating until I did a reload.  On 9.0 with more consolidated routing that hasn't happened, but in the conversion from IKE1 and shared passphrases to IKE2 and certificates - which is not required but seemed like a good idea - I picked up an occasional problem with SA rekey failures instead.  Turning on "sysopt conn preserve-vpn-flow" to avoid resetting my TCP sessions has helped ammeliorate the consequences of those, since the automatic fallback to redoing phase I negotiations happens fast enough that the IPsec tunnel comes back up anyway before too many packets get lost.

Overall, 9.0 is an improvement for me, and you shouldn't hesitate to get off 8.2.

-- Jim Leinweber, WI State Lab of Hygiene

Content for Community-Ad