Cisco ASA 5500 Migration to Version 8.3
This guide describes the configuration migration process when you upgrade from a pre-8.3 version of the Cisco ASA 5500 operating system (OS) to Version 8.3. If you upgrade directly to 8.4, then the 8.3 migrations are still applied; you do not need to upgrade to 8.3 first and then to 8.4. Due to additional configuration migration in Version 9.0 (see the 9.0 upgrade guide), we suggest that you upgrade to Version 8.4 first, and then to Version 9.0.
Upgrading the Software
To upgrade the software, see the upgrade instructions for your target version:
Information About Migration
This section describes the migrated features, automatic backup of the original configuration file, and saving your new migrated configuration. This section includes the following topics:
- Migrated Features
- Automatic Backup of the Old Configuration, NAT Migration File, Bootup Error Log
- Saving the Migrated Configuration
Migrated Features
The major changes in Version 8.3 that require migration are as follows:
- Real IP addresses in access lists, where access lists are used in supported features—When using NAT or PAT, you used to have to specify the mapped addresses and ports in an access list for all features that use access lists. Now, for several supported features, you must use the real, untranslated IP address and ports. (Other features continue to use the mapped IP address).
- NAT—The NAT feature has been redesigned for increased flexibility and functionality. All NAT and NAT-related commands have been redesigned.
- Named Network and Service Objects—Network and service objects are automatically created for NAT.
![]()
Note Although you can use named network and service objects in other features, such as access lists and object groups, objects are not automatically created for any feature other than NAT.
When upgrading from 8.3 or 8.4(1) to 8.4(2), migration for static identity NAT will occur to preserve existing functionality. See the “Sample NAT Migration from 8.3 and 8.4 to 8.4(2)” section for more information.
Automatic Backup of the Old Configuration, NAT Migration File, Bootup Error Log
The old startup configuration is automatically saved in flash memory. The NAT migration file and the bootup error log, which includes any migration messages, is automatically saved to flash memory as well.
Backup Configuration Files
The following old startup configuration files are saved in flash memory:
- Single mode configuration file or multiple mode system configuration— disk0: major_minor_maint_interim _startup_cfg.sav where major_minor_maint_interim is the old OS version number.
For example, 8_2_1_0_startup_cfg.sav.
- Multiple mode context configuration (if present in flash memory)— disk0: major_minor_maint_interim _ context _cfg.sav where major_minor_maint_interim is the old OS version number and context is the context name.
For example, 8_2_1_0_context1_cfg.sav.
If there is insufficient memory to save configuration files, an error message appears on the console of the ASA and is saved in the bootup error log file; any files saved as part of the migration will be removed, and the migration will be aborted.
NAT Migration File
When your NAT configuration is migrated, and the following file is added to the root directory: nat_ident_migrate. The presence of this empty file indicates that the configuration was migrated, and prevents re-migration at bootup.
Real IP Addresses in Access List Migration
When using NAT or PAT, mapped addresses and ports are no longer required in an access list for several features. You should now always use the real, untranslated addresses and ports for these features. Using the real address and port means that if the NAT configuration changes, you do not need to change the access lists. This section includes the following topics:
- Features That Use Real IP Addresses
- Features That Continue to Use Mapped IP Addresses
- Real IP Address Migration Naming Conventions
- Syslog Message Migration
- Sample Real IP Address Migration
- Real IP Address Migration Messages and Limitations
Features That Use Real IP Addresses
command), the IP addresses within the object group are migrated to the real IP addresses.
- access-group command
- Modular Policy Framework match access-list command
- Botnet Traffic Filter dynamic-filter enable classify-list command
- AAA aaa ... match commands
- WCCP wccp redirect-list group-list command
![]()
Note The WCCP wccp redirect-list group-list command is not automatically migrated. The WCCP access list is downloaded after startup, so automatic migration cannot occur. You need to manually change the wccp redirect-list group-list command to use an access list with the real IP address.
command. In this scenario, you needed to specify the mapped address of the inside host in the access list because that address was the address that can be used on the outside network. Starting in 8.3, you need to specify the real address in the access list.
Real IP addresses are now used in the following features instead of mapped addresses:
![]()
Note WCCP redirection is not automatically migrated. The WCCP ACL is downloaded after startup, so automatic migration cannot occur. You need to manually change the ACL to use the real IP address.
Features That Continue to Use Mapped IP Addresses
The following features use access lists, but these access lists will continue to use the mapped values as seen on an interface:
Real IP Address Migration Naming Conventions
- In most cases after migration, the new access-list commands will be recreated with the original name so there will be no changes to the configuration that references the access list name. If an access list is applied to two or more features, and the conversion results in different ACEs, then two different access lists will be created; the original access list is removed. The new access lists will have the original name with appended suffixes: oldname_ migration _X , where X is a number starting with 1.
- When contents of an object group need to be changed to the real IP addresses, a new object-group command called oldname_X is created, where X is a number starting with 1. The new object-group command is referenced in the access list.
Sample Real IP Address Migration
shows how access lists are migrated to use the real IP address. The NAT configuration is shown in the old configuration for reference. For NAT migration, see the “NAT Migration” section.
Real IP Address Migration Messages and Limitations
This section describes messages associated with real IP address migration. Some messages relate to configurations that cannot be migrated, and require user intervention. This section also lists any other conditions that do not result in a message. This section includes the following topics:
Real IP Address Migration Messages
When you first reload with 8.3, you see the following message:
lists other messages you might see.
For Interface IP Address in ACE, Real vs. Mapped Status Cannot Be Determined
keyword to identify the interface IP address, then the migration script cannot match the NAT command with the ACE, and it cannot know if the IP address in the ACE is real or mapped.
keyword.
For example, pre-migration, outside interface PAT is defined for an inside host:
keyword:
keyword.
To fix the access list after migration, change the access list to use the real IP address (10.2.2.2):
NAT Migration
The NAT feature has been redesigned for increased flexibility and functionality. All NAT and NAT-related commands have been redesigned. This section describes how your NAT configuration is migrated to the new NAT commands. For ASDM users, see the relevant “ASDM” subsections. This section includes the following topics:
- Old NAT Commands
- New NAT Commands
- Supporting Commands for NAT
- Preserving the Order of NAT Rules
- NAT Migration Guidelines and Limitations
- Sample NAT Migration from 8.3 and 8.4 to 8.4(2)
- Sample NAT Migration from 8.2 and Earlier
- NAT Migration Messages
![]()
Note Almost all NAT configurations will migrate seamlessly. In the rare cases when user intervention is required, you will be notified. There will never be an unreported loss of security after migration. See the “NAT Migration Messages” section.
Old NAT Commands
The following commands are no longer supported; they are migrated to new commands, and are then removed from the configuration.
- alias
- global
- nat (old version)
- nat-control
- static
- sysopt nodnsalias —This command is not migrated; instead, configure the dns option within the new NAT commands.
command was never supported in ASDM.
New NAT Commands
lists the new NAT commands. See also the “Supporting Commands for NAT” section.
]
]
]
]
![]()
Note The no-proxy-arp, route-lookup, pat-pool, and round-robin keywords were added in 8.4(2).
For ASDM, the existing NAT rules will be migrated to two new types of rules:
Configuration > Firewall > Objects > Network Objects/Groups > Add/Edit Network Object.
Supporting Commands for NAT
:
commands when an inline address (one that is entered directly in the command) is not feasible.
commands.
commands.
command that was formerly used in policy NAT.
commands.
See the “Network and Service Object Migration” section for more information about network and service objects, including naming conventions for these generated commands.
ASDM has supported named network objects for a number of releases; now, the platform has the commands to properly support them as well. In addition to showing all named network objects in the configuration, ASDM automatically creates objects for any IP addresses used in the configuration; these auto-created objects are identified by the IP address, and are not present as objects in the platform configuration. If you assign a name to one of these objects, then ASDM adds the named network object to the platform configuration.
![]()
Note ASDM no longer shows any objects derived from the name command. Previously, you might have used named objects derived from the name command in ASDM. If the name command IP address was not migrated (see the “Network and Service Object Migration” section), then these objects are replaced by auto-created objects identified by an IP address.
Preserving the Order of NAT Rules
In the old NAT configuration, the order that NAT commands were assessed depended on the type of NAT, and in some cases, the order in which the commands appeared in the configuration. The new NAT order uses a table with three sections:
- Section 1 (twice NAT rules)—These rules are assessed based on the order they appear in the configuration. For migration purposes, this section includes migrated policy NAT rules.
- Section 2 (network object NAT (generated) rules)—These rules are assessed according to internal rules; the order they appear in the configuration does not matter (For more information, see the Cisco ASA 5500 Series Configuration Guide using ASDM or the Cisco ASA 5500 Series Configuration Guide using the CLI ). For migration purposes, this section includes regular NAT rules.
- Section 3 (twice NAT rules that you specifically want to be evaluated after the network object NAT rules)—Like section 1, these rules are assessed in the order they appear in the configuration. However, they are assessed after section 1 and section 2 rules. This section is not used for NAT migration.
In the case of overlapping networks (for example, if a regular static NAT rule overlaps with a dynamic policy NAT rule), the regular static NAT rule will be migrated to section 1 instead of section 2 to preserve the order of the configuration. For example, the following old configuration has overlapping networks. In this case, the static command will be migrated to a twice NAT rule in section 1.
NAT Migration Guidelines and Limitations
- Dynamic identity NAT (the nat 0 command) will not be migrated. See the “NAT Migration Messages” section. Static identity NAT is treated like any other static command, and is converted depending on whether it is regular or policy NAT.
- NAT exemption (the nat 0 access-list command) is migrated differently depending on the release to which you are upgrading. See the “NAT Exemption” section for more information.
- When upgrading to 8.4(2) from 8.3(1), 8.3(2), or 8.4(1), migration for identity NAT will occur to preserve existing functionality. See the “Sample NAT Migration from 8.3 and 8.4 to 8.4(2)” section for more information.
- Regular NAT commands with the dns option will be migrated. The dns option in static PAT and policy NAT commands will be ignored.
- Connection Settings in old NAT commands—Options such as conn-max , emb-limit , norandomseq , or nailed will be moved to service policies.
The following naming conventions are used for the new service policies:
For other naming conventions related to NAT migration, see the “Object Migration Naming Conventions” section.
Sample NAT Migration from 8.3 and 8.4 to 8.4(2)
If you are already running 8.3(1), 8.3(2), or 8.4(2). then to preserve existing functionality, all identity NAT statements are migrated to use the following new keywords:
Starting in version 8.4(2), identity NAT now performs proxy ARP and uses the NAT configuration to determine the egress interface by default. To maintain the functionality that was in 8.3(1), 8.3(2), and 8.4(2), proxy ARP is disabled, and a route lookup is performed to determine the egress interface using the new keywords. If you want to enable proxy ARP (a rare requirement) or use the NAT configuration to determine the egress interface, you must manually remove the keyword(s) after migration.
keyword is present (for example, from an original migration of NAT exemption rules to 8.3(2) or 8.4(1)), then the keyword is removed.
lists static identity NAT migration examples.
Static NAT/PAT
lists static NAT/PAT migration examples.
Dynamic NAT/PAT
lists dynamic NAT/PAT migration examples.
NAT Exemption
command) is a form of policy NAT, and is converted to static twice NAT. Rules are created between the exempted interface and all lower-security level interfaces. For outside NAT, rules are created between the exempted interface and all higher-security level interfaces. If you enabled same security level communication, rules are also created between the exempted interface and same-security level interfaces.
These rules will be placed at the top of section 1.
command) is migrated to a twice NAT rule. See the following notes for the version you are upgrading to for specific information about how NAT exemption is migrated:
- For Version 8.3(1)—In some cases, you might see caveat #CSCtf89372. We recommend migrating directly to 8.4(2). For more information about this caveat, see the Bug Toolkit at the following URL:
- For Version 8.3(2) through 8.4(1)—The unidirectional keyword was added. The unidirectional keyword only allows traffic on the source network to initiate connections. This migration change was made to fix CSCtf89372. Because NAT exemption is normally bidirectional, you might need to remove the unidirectional keyword to restore the original function. Specifically, this change adversely affects many VPN configurations that include NAT exemption rules (see CSCti36048 for this new issue). To avoid manual intervention, we recommend migrating to 8.4(2) instead.
If you are impacted by this issue, you will see a syslog message like the following:
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src Outside:192.168.1.5 dst inside:10.10.5.20 (type 8, code 0) denied due to NAT reverse path failure
- For Version 8.4(2) and later—The unidirectional keyword is no longer added. Instead, the new no-proxy-arp and route-lookup keywords are added. Both the CSCtf89372 and CSCti36048 caveats are resolved in this release.
The examples in this section are for a system with three interfaces: inside (level 100), outside (level 0), and dmz (level 50).
lists NAT exemption migration examples.
NAT Control
command was used for NAT configurations defined with earlier versions of the ASA. The best practice is to use access rules for access control instead of relying on the absence of a NAT rule to prevent traffic through the ASA.
lists NAT control migration examples.
DNS Rewrite
option in static PAT and policy NAT commands will be ignored.
lists DNS rewrite migration examples.
Connection Settings
will be moved to service policies.
.
lists connection setting migration examples.
Source and Destination NAT
Before 8.3, policy NAT let you specify the source and destination addresses, but NAT was only performed on the source address. In 8.3 and later, you can also configure NAT for the destination address if desired. In the old configuration to achieve this functionality, you had to configure two separate NAT rules for source and destination NAT for a single connection. As part of migration the two, independent NAT rules are tied together to form a single twice NAT command.
lists source and destination NAT migration examples.
alias Command
command translates addresses on an IP network residing on any interface into addresses on another IP network connected through a different interface.
lists alias migration examples.
NAT Migration Messages
lists error messages you might see, and information about the messages.
Network and Service Object Migration
This section describes network and service object migration and includes the following topics:
Supported Features for Objects
Version 8.3 introduces named network and service objects for use with the following features:
- NAT—See the “NAT Migration” section for more information. You can no longer use a named IP address (using the name command) in NAT.
- Access lists— access-list command. You can no longer use a named IP address (using the name command) in an access list.
- Object groups— object-group network and object-group service commands. Named IP addresses are still allowed in object groups, as well as network objects.
Object Migration
commands) are substituted into existing commands in the following cases:
- For each network object NAT command, an object network command is created to represent the real IP address that you want to translate.
- When new nat commands require an object instead of an inline value, network and service objects are automatically created.
- If you use a named IP address in NAT (using the name command) and the names command is enabled, then a network object is created even if an inline IP address could be used in the new nat command.
- If an access-list command includes an IP address that was used in NAT, and the NAT migration created a network object for that IP address, then the network object replaces the IP address in the access-list command.
- If you use a named IP address in the access-list command (using the name command) and the names command is enabled, then an object replaces the name.
- For multiple global commands that share the same NAT ID, a network object group is created that contains the network objects created for the inline IP addresses.
Objects are not created for the following cases:
- A name command exists in the configuration, but is not used in a nat or access-list command.
- An inline value that is still allowed in the nat command.
- name commands used under object-group commands.
- IP addresses used in access-list commands that are not used in NAT or named with a name command.
![]()
Note The name commands continue to exist in your configuration for use with other features that do not yet support network objects.
ASDM has supported named network objects for a number of releases; now, the platform has the commands to properly support them as well.
only, do not have a name, and are not present as named objects in the platform configuration.
If you manually assign a name to one of these non-named ASDM objects, then ASDM adds the named network object to the platform configuration. If you do not add a name, it remains an ASDM-only object.
.
![]()
Note ASDM no longer shows any objects derived from the name command. Previously, you might have used named objects derived from the name command in ASDM. If the name command IP address was not migrated, then these objects are replaced by auto-created objects identified by an IP address.
Object Migration Naming Conventions
This section includes the following topics:
- name Command Naming Conventions
- Inline IP Address Naming Conventions
- Inline Protocol Naming Conventions
- Network Object Naming Conventions with Multiple global Commands with the Same NAT ID
For details about when a name or IP address is migrated, see the “Object Migration” section.
Inline IP Address Naming Conventions
For migrated IP addresses used inline, network objects are created using the following naming convention:
![]()
Note Only one instance of NAT can be enabled on an object. If you have more than one NAT policy applied on a given host or subnet, then a separate network object will be created: obj-a.b.c.d-01.
lists host and subnet inline object migration naming examples.
lists range inline object migration naming examples.
Downgrading from Version 8.3
When you upgrade to Version 8.3, your configuration is migrated. The old configuration is automatically stored in flash memory. For example when you upgrade from 8.2(1) to 8.3(1), the old 8.2(1) configuration is stored in flash memory in a file called 8_2_1_0_startup_cfg.sav.
This section describes how to downgrade, and includes the following topics:
Information About Activation Key Compatibility
Your activation key remains compatible if you upgrade to the latest version from any previous version. However, you might have issues if you want to maintain downgrade capability:
- Downgrading to Version 8.1 or earlier—After you upgrade, if you activate additional feature licenses that were introduced before 8.2 , then the activation key continues to be compatible with earlier versions if you downgrade. However if you activate feature licenses that were introduced in 8.2 or later , then the activation key is not backwards compatible. If you have an incompatible license key, then see the following guidelines:
–
If you previously entered an activation key in an earlier version, then the ASA uses that key (without any of the new licenses you activated in Version 8.2 or later).
–
If you have a new system and do not have an earlier activation key, then you need to request a new activation key compatible with the earlier version.
- Downgrading to Version 8.2 or earlier—Version 8.3 introduced more robust time-based key usage as well as failover license changes:
–
If you have more than one time-based activation key active, when you downgrade, only the most recently activated time-based key can be active. Any other keys are made inactive. If the last time-based license is for a feature introduced in 8.3, then that license still remains the active license even though it cannot be used in earlier versions. Reenter the permanent key or a valid time-based key.
–
If you have mismatched licenses on a failover pair, then downgrading will disable failover. Even if the keys are matching, the license used will no longer be a combined license.
–
If you have one time-based license installed, but it is for a feature introduced in 8.3, then after you downgrade, that time-based license remains active. You need to reenter the permanent key to disable the time-based license.
Detailed Steps
Step 1
Enter the following command:
is the path to the saved, pre-migration configuration (by default this was saved on disk0). If you need to revert to a pre-8.3 activation key, then you can enter the old activation key.
This command is a shortcut for completing the following functions:
).
).
).
). This sets the BOOT environment variable to the old image, so when you reload, the old image is loaded.
).
).
.
The Downgrade Software dialog box appears.
![]()
.
The Browse File Locations dialog box appears.
Step 3
Click one of the following radio buttons:
- Remote Server —Choose ftp , smb , or http from the drop-down list, and type the path to the old image file.
- Flash File System —Click Browse Flash to choose the old image file on the local flash file system.
to choose the pre-migration configuration file. (By default this was saved on disk0).
Step 5
(Optional) In the Activation Key field, enter the old activation key if you need to revert to a pre-8.3 activation key.
.
This tool is a shortcut for completing the following functions:
).
).
).
). This sets the BOOT environment variable to the old image, so when you reload, the old image is loaded.
).
).
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)