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.
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
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
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.
static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0
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
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
Will add more later if anything comes to mind as its getting quite late here
Hope this helps
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.
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