Hi,
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:
https://supportforums.cisco.com/docs/DOC-31116
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) 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
- 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
