• Smart licensing default transport changed in 9.22—In 9.22, the smart licensing default transport changed from Smart Call Home to Smart Transport. You can configure the ASA to use Smart Call Home if necessary using the transport type callhome command. When you upgrade to 9.22, the transport is automatically changed Smart Transport. If you downgrade, the transport is set back to Smart Call Home, and if you want to use Smart Transport, you need to specify transport type smart .

• OSPF redistribute commands that specify a route-map that matches a prefix-list will be removed in 9.20(2)—When you upgrade to 9.20(2), OSPF redistribute commands where the specified route-map uses a match ip address prefix-list will be removed from the configuration. Although prefix lists have never been supported, the parser still accepted the command. Before upgrading, you should reconfigure OSPF to use route maps that specify an ACL in the match ip address command.

• ASDM 7.19(1) requires Oracle Java version 8u261 or later—Before you upgrade to ASDM 7.19, be sure to update Oracle Java (if used) to version 8u261 or later. This version supports TLSv1.3, which is required to upgrade the ASDM Launcher. OpenJRE is not affected.

• ASDM signed-image support in 9.18(2)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)

• 9.18(1) upgrade issue if you enabled HTTPS/ASDM (with HTTPS authentication) and SSL on the same interface with the same port—If you enable both SSL (webvpn > enable interface) and HTTPS/ASDM (http ) access on the same interface, you can access AnyConnect from https://ip_address and ASDM from https://ip_address/admin, both on port 443. However, if you also enable HTTPS authentication (aaa authentication http console), then you must specify a different port for ASDM access starting in 9.18(1). Make sure you change the port before you upgrade using the http command. (CSCvz92016)

• ASDM Upgrade Wizard—Due to ASD API migration, you must use ASDM 7.18 or later to upgrade to ASA 9.18 or later. Because ASDM is backwards compatible with earlier ASA versions, you can upgrade ASDM to 7.18 or later for any ASA version.

• ASDM signed-image support in 9.17(1.13)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)

• No support for Clientless SSL VPN in 9.17(1) and later—Clientless SSL VPN is no longer supported.

  • webvpn—The following subcommands are removed:

    • apcf

    • java-trustpoint

    • onscreen-keyboard

    • port-forward

    • portal-access-rule

    • rewrite

    • smart-tunnel

  • group-policy webvpn—The following subcommands are removed:

    • port-forward

    • smart-tunnel

    • ssl-clientless

• ASDM Upgrade Wizard—Due to an internal change, starting in March 2022 the upgrade wizard will no longer work with pre-ASDM 7.17(1.152) versions. You must manually upgrade to 7.17(1.152) to use the wizard.

• ASDM signed-image support in 9.16(3.19)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)

• SNMPv3 users using MD5 hashing and DES encryption are no longer supported, and the users will be removed when you upgrade to 9.16(1)—Be sure to change any user configuration to higher security algorithms using the snmp-server user command before you upgrade.

• SSH host key action required in 9.16(1)—In addition to RSA, we added support for the EDDSA and ECDSA host keys for SSH. The ASA tries to use keys in the following order if they exist: EDDSA, ECDSA, and then RSA. When you upgrade to 9.16(1), the ASA will fall back to using the existing RSA key. However, we recommend that you generate higher-security keys as soon as possible using the crypto key generate {eddsa | ecdsa} command. Moreover, if you explicitly configure the ASA to use the RSA key with the ssh key-exchange hostkey rsa command, you must generate a key that is 2048 bits or higher. For upgrade compatibility, the ASA will use smaller RSA host keys only when the default host key setting is used. RSA support will be removed in a later release.

• In 9.16 and later, certificates with RSA keys are not compatible with ECDSA ciphers—When you use the ECDHE_ECDSA cipher group, configure the trustpoint with a certificate that contains an ECDSA-capable key.

• ssh version command removed in 9.16(1)—This command has been removed. Only SSH version 2 is supported.

• When you upgrade to 9.16 or later, you might see a different certificate serial number—In 9.16, the ASA started using OpenSSL, which causes negative values in certificates to be computed differently, so you may see a different serial number after upgrading. This change does not affect operation. (CSCvv30338)

• SAMLv1 feature removed in 9.16(1)—Support for SAMLv1 was removed.

• No support for DH groups 2, 5, and 24 in 9.16(1)—Support has been removed for the DH groups 2, 5, and 24 in SSL DH group configuration. The ssl dh-group command has been updated to remove the command options group2, group5, and group24.

• No support in ASA 9.15(1) and later for the ASA 5525-X, ASA 5545-X, and ASA 5555-X—ASA 9.14(x) is the last supported version. For the ASA FirePOWER module, the last supported version is 6.6.

• Cisco announces the feature deprecation for Clientless SSL VPN effective with ASA version 9.17(1)—Limited support will continue on releases prior to 9.17(1).

• For the Firepower 1010, invalid VLAN IDs can cause problems—Before you upgrade to 9.15(1), make sure you are not using a VLAN for switch ports in the range 3968 to 4047. These IDs are for internal use only, and 9.15(1) includes a check to make sure you are not using these IDs. For example, if these IDs are in use after upgrading a failover pair, the failover pair will go into a suspended state. See CSCvw33057 for more information.

• SAMLv1 feature deprecation—Support for SAMLv1 is deprecated.

• Low-Security Cipher Removal in ASA 9.15(1)—Support for the following less secure ciphers used by IKE and IPsec have been removed:

  • Diffie-Hellman groups: 2 and 24

  • Encryption algorithms: DES, 3DES, AES-GMAC, AES-GMAC-192, AES-GMAC-256, NULL, ESP-3DES, ESP-DES, ESP-MD5-HMAC

  • Hash algorithms: MD5

  Note	Low-security SSH and SSL ciphers have not yet been removed.

  Before you upgrade from an earlier version of ASA to Version 9.15(1), you must update your VPN configuration to use the ciphers supported in 9.15(1), or else the old configuration will be rejected. When the configuration is rejected, one of the following actions will occur, depending on the command:

  • The command will use the default cipher.

  • The command will be removed.

  Fixing your configuration before upgrading is especially important for clustering or failover deployments. For example, if the secondary unit is upgraded to 9.15(1), and the removed ciphers are synced to this unit from the primary, then the secondary unit will reject the configuration. This rejection might cause unexpected behavior, like failure to join the cluster.

  IKEv1: The following subcommands are removed:

  • crypto ikev1 policy priority:

    • hash md5

    • encryption 3des

    • encryption des

    • group 2

  IKEv2: The following subcommands are removed:

  • crypto ikev2 policy priority:

    • prf md5

    • integrity md5

    • group 2

    • group 24

    • encryption 3des

    • encryption des

    • encryption null

  IPsec: The following subcommands are removed:

  • crypto ipsec ikev1 transform-set name esp-3des esp-des esp-md5-hmac

  • crypto ipsec ikev2 ipsec-proposal name

    • protocol esp integrity md5

    • protocol esp encryption 3des aes-gmac aes-gmac- 192 aes-gmac -256 des

  • crypto ipsec profile name

    • set pfs group2 group24

  Crypto Map: The following subcommands are removed:

  • crypto map name sequence set pfs group2

  • crypto map name sequence set pfs group24

  • crypto map name sequence set ikev1 phase1-mode aggressive group2

• Re-introduction of CRL Distribution Point configuration—The static CDP URL configuration option, that was removed in 9.13(1), was re-introduced in the match-certificate command.

• Restoration of bypass certificate validity checks option—The option to bypass revocation checking due to connectivity problems with the CRL or OCSP server was restored.

  The following subcommands were restored:

  • revocation-check crl none

  • revocation-check ocsp none

  • revocation-check crl ocsp none

  • revocation-check ocsp crl none

• ASDM signed-image support in 9.14(4.14)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)

• ASDM Cisco.com Upgrade Wizard failure on Firepower 1000 and 2100 in Appliance mode—The ASDM Cisco.com Upgrade Wizard does not work for upgrading to 9.14 (Tools > Check for ASA/ASDM Updates). The wizard can upgrade ASDM from 7.13 to 7.14, but the ASA image upgrade is grayed out. (CSCvt72183) As a workaround, use one of the following methods:

  • Use Tools > Upgrade Software from Local Computer for both ASA and ASDM. Note that the ASDM image (7.14(1)) in the 9.14(1) bundle also has the bug CSCvt72183; you should download the newer 7.14(1.46) image to enable correct functioning of the wizard.

  • Use Tools > Check for ASA/ASDM Updates to upgrade to ASDM 7.14 (the version will be 7.14(1.46); then use the new ASDM to upgrade the ASA image. Note that you may see a Fatal Installation Error; in this case, click OK. You must then set the boot image manually on the Configuration > Device Management > System Image/Configuration > Boot Image/Configuration screen. Save the configuration and reload the ASA.

• For Failover pairs in 9.14(1)+, the ASA no longer shares SNMP client engine data with its peer.

• No support in ASA 9.14(1)+ for cnatAddrBindNumberOfEntries and cnatAddrBindSessionCount OIDs (CSCvy22526).

• Upgrade issue for 9.14(4)24 and RADIUS challenges for AnyConnect mobile users—To restore RADIUS functionality, upgrade to 9.18(4)22 or later.

• Upgrading the Firepower 2100 in Platform mode—When you upgrade to 9.14 or later, if your EtherChannel (port-channel) was disabled at the time of upgrade, then you will need to manually enable both the EtherChannel and its member interfaces after upgrade.

• Downgrade issue for the Firepower 2100 in Platform mode from 9.13/9.14 to 9.12 or earlier—For a Firepower 2100 with a fresh installation of 9.13 or 9.14 that you converted to Platform mode: If you downgrade to 9.12 or earlier, you will not be able to configure new interfaces or edit existing interfaces in FXOS (note that 9.12 and earlier only supports Platform mode). You either need to restore your version to 9.13 or later, or you need to clear your configuration using the FXOS erase configuration command. This problem does not occur if you originally upgraded to 9.13 or 9.14 from an earlier release; only fresh installations are affected, such as a new device or a re-imaged device. (CSCvr19755)

• The tls-proxy keyword, and support for SCCP/Skinny encrypted inspection, was removed from the inspect skinny command.

• ASDM Upgrade Wizard—Due to an internal change, the wizard is only supported using ASDM 7.10(1) and later; also, due to an image naming change, you must use ASDM 7.12(1) or later to upgrade to ASA 9.10(1) and later. Because ASDM is backwards compatible with earlier ASA releases, you can upgrade ASDM no matter which ASA version you are running. Note that ASDM 7.13 and 7.14 did not support the ASA 5512-X, 5515-X, 5585-X, or ASASM; you must upgrade to ASDM 7.13(1.101) or 7.14(1.48) to restore ASDM support.

• ASAv requires 2GB memory in 9.13(1) and later—Beginning with 9.13(1), the minimum memory requirement for the ASAv is 2GB. If your current ASAv runs with less than 2GB of memory, you cannot upgrade to 9.13(1) from an earlier version. You must adjust the memory size before upgrading. See the ASAv Getting Started Guide for information about the resource allocations (vCPU and memory) supported in version 9.13(1).

• Downgrade issue for the Firepower 2100 in Platform mode from 9.13 to 9.12 or earlier—For a Firepower 2100 with a fresh installation of 9.13 that you converted to Platform mode: If you downgrade to 9.12 or earlier, you will not be able to configure new interfaces or edit existing interfaces in FXOS (note that 9.12 and earlier only supports Platform mode). You either need to restore your version to 9.13, or you need to clear your configuration using the FXOS erase configuration command. This problem does not occur if you originally upgraded to 9.13 from an earlier release; only fresh installations are affected, such as a new device or a re-imaged device. (CSCvr19755)

• Cluster control link MTU change in 9.13(1)—Starting in 9.13(1), many cluster control packets are larger than they were in previous releases. The recommended MTU for the cluster control link has always been 1600 or greater, and this value is appropriate. However, if you set the MTU to 1600 but then failed to match the MTU on connecting switches (for example, you left the MTU as 1500 on the switch), then you will start seeing the effects of this mismatch with dropped cluster control packets. Be sure to set all devices on the cluster control link to the same MTU, specifically 1600 or higher.

• Beginning with 9.13(1), the ASA establishes an LDAP/SSL connection only if one of the following certification criteria is satisfied:

  • The LDAP server certificate is trusted (exists in a trustpoint or the ASA trustpool) and is valid.

  • A CA certificate from servers issuing chain is trusted (exists in a trustpoint or the ASA trustpool) and all subordinate CA certificates in the chain are complete and valid.

• Local CA server is removed in 9.13(1)—When the ASA is configured as local CA server, it can issue digital certificates, publish Certificate Revocation Lists (CRLs), and securely revoke issued certificates. This feature has become obsolete and hence the crypto ca server command is removed.

• Removal of CRL Distribution Point commands—The static CDP URL configuration commands, namely crypto-ca-trustpoint crl and crl url were removed with other related logic. The CDP URL was moved to match certificate command.

  Note	The CDP URL configuration was enhanced to allow multiple instances of the CDP override for a single map (refer CSCvu05216).

• Removal of bypass certificate validity checks option—The option to bypass revocation checking due to connectivity problems with the CRL or OCSP server was removed.

  The following subcommands are removed:

  • revocation-check crl none

  • revocation-check ocsp none

  • revocation-check crl ocsp none

  • revocation-check ocsp crl none

  Thus, after an upgrade, any revocation-check command that is no longer supported will transition to the new behavior by ignoring the trailing none.

  Note	These commands were restored later (refer CSCtb41710).

• Low-Security Cipher Deprecation— Several encryption ciphers used by the ASA IKE, IPsec, and SSH modules are considered insecure and have been deprecated. They will be removed in a later release.

  IKEv1: The following subcommands are deprecated:

  • crypto ikev1 policy priority:

    • hash md5

    • encryption 3des

    • encryption des

    • group 2

    • group 5

  IKEv2: The following subcommands are deprecated:

  • crypto ikev2 policy priority

    • integrity md5

    • prf md5

    • group 2

    • group 5

    • group 24

    • encryption 3des

    • encryption des (this command is still available when you have the DES encryption license only)

    • encryption null

  IPsec: The following commands are deprecated:

  • crypto ipsec ikev1 transform-set name esp-3des esp-des esp-md5-hmac

  • crypto ipsec ikev2 ipsec-proposal name

    • protocol esp integrity md5

    • protocol esp encryption 3des aes-gmac aes-gmac- 192 aes-gmac -256 des

  • crypto ipsec profile name

    • set pfs group2 group5 group24

  SSH: The following commands are deprecated:

  • ssh cipher integrity custom hmac-sha1-96:hmac-md5: hmac-md5-96

  • ssh key-exchange group dh-group1-sha1

  SSL: The following commands are deprecated:

  • ssl dh-group group2

  • ssl dh-group group5

  • ssl dh-group group24

  Crypto Map: The following commands are deprecated:

  • crypto map name sequence set pfs group2

  • crypto map name sequence set pfs group5

  • crypto map name sequence set pfs group24

  • crypto map name sequence set ikev1 phase1-mode aggressive group2

  • crypto map name sequence set ikev1 phase1-mode aggressive group5

• In 9.13(1), Diffie-Hellman Group 14 is now the default for the group command under crypto ikev1 policy , ssl dh-group , and crypto ikev2 policy for IPsec PFS using crypto map set pfs , crypto ipsec profile , crypto dynamic-map set pfs , and crypto map set ikev1 phase1-mode . The former default Diffie-Hellman group was Group 2.

  When you upgrade from a pre-9.13(1) release, if you need to use the old default (Diffie-Hellman Group 2), then you must manually configure the DH group as group 2 or else your tunnels will default to Group 14. Because group 2 will be removed in a future release, you should move your tunnels to group 14 as soon as possible.

• ASDM signed-image support in 9.12(4.50)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)

• ASDM Upgrade Wizard—Due to an internal change, the wizard is only supported using ASDM 7.10(1) and later; also, due to an image naming change, you must use ASDM 7.12(1) or later to upgrade to ASA 9.10(1) and later. Because ASDM is backwards compatible with earlier ASA releases, you can upgrade ASDM no matter which ASA version you are running.

• SSH security improvements and new defaults in 9.12(1)—See the following SSH security improvements:

  • SSH version 1 is no longer supported; only version 2 is supported. The ssh version 1 command will be migrated to ssh version 2 .

  • Diffie-Hellman Group 14 SHA256 key exchange support. This setting is now the default (ssh key-exchange group dh-group14-sha256 ). The former default was Group 1 SHA1. Make sure that your SSH client supports Diffie-Hellman Group 14 SHA256. If it does not, you may see an error such as "Couldn't agree on a key exchange algorithm." For example, OpenSSH supports Diffie-Hellman Group 14 SHA256.

  • HMAC-SHA256 integrity cipher support. The default is now the high security set of ciphers (hmac-sha1 and hmac-sha2-256 as defined by the ssh cipher integrity high command). The former default was the medium set.

• The NULL-SHA TLSv1 cipher is deprecated and removed in 9.12(1)—Because NULL-SHA doesn't offer encryption and is no longer considered secure against modern threats, it will be removed when listing supported ciphers for TLSv1 in the output of tls-proxy mode commands/options and show ssl ciphers all . The ssl cipher tlsv1 all and ssl cipher tlsv1 custom NULL-SHA commands will also be deprecated and removed.

• The default trustpool is removed in 9.12(1)—In order to comply with PSB requirement, SEC-AUT-DEFROOT, the "default" trusted CA bundle is removed from the ASA image. As a result, crypto ca trustpool import default and crypto ca trustpool import clean default commands are also removed along with other related logic. However, in existing deployments, certificates that were previously imported using these command will remain in place.

• The ssl encryption command is removed in 9.12(1)—In 9.3(2) the deprecation was announced and replaced by ssl cipher . In 9.12(1), ssl encryption is removed and no longer supported.

• Due to an internal change, the ASDM Upgrade wizard is only supported using ASDM 7.10(1) and later; also, due to an image naming change, you must use ASDM 7.12(1) or later to upgrade to ASA 9.10(1) and later. Because ASDM is backwards compatible with earlier ASA releases, you can upgrade ASDM no matter which ASA version you are running.

• ASA 5506-X memory issues with large configurations on 9.9(2) and later—If you upgrade to 9.9(2) or later, parts of a very large configuration might be rejected due to insufficient memory with the following message: "ERROR: Insufficient memory to install the rules". One option is to enter the object-group-search access-control command to improve memory usage for ACLs; your performance might be impacted, however. Alternatively, you can downgrade to 9.9(1).

• ASDM signed-image support in 9.8(4.45)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)

• Before upgrading to 9.8(2) or later, FIPS mode requires the failover key to be at least 14 characters—Before you upgrade to to 9.8(2) or later in FIPS mode, you must change the failover key or failover ipsec pre-shared-key to be at least 14 characters long. If your failover key is too short, when you upgrade the first unit, the failover key will be rejected, and both units will become active until you set the failover key to a valid value.

• Do not upgrade to 9.8(1) for ASAv on Amazon Web Services--Due to CSCve56153, you should not upgrade to 9.8(1). After upgrading, the ASAv becomes unreachable. Upgrade to 9.8(1.5) or later instead.

• Upgrade issue with 9.7(1) to 9.7(1.x) and later for VTI and VXLAN VNI—If you configure both Virtual Tunnel Interfaces (VTIs) and VXLAN Virtual Network Identifier (VNI) interfaces, then you cannot perform a zero downtime upgrade for failover; connections on these interface types will not replicate to the standby unit until both units are on the same version. (CSCvc83062)

• (ASA 9.6(2) through 9.7(x)) Upgrade impact when using SSH public key authentication—Due to updates to SSH authentication, additional configuration is required to enable SSH public key authentication; as a result, existing SSH configurations using public key authentication no longer work after upgrading. Public key authentication is the default for the ASAv on Amazon Web Services (AWS), so AWS users will see this issue. To avoid loss of SSH connectivity, you can update your configuration before you upgrade. Or you can use ASDM after you upgrade (if you enabled ASDM access) to fix the configuration.

  Note	The original behavior was restored in 9.8(1).

  Sample original configuration for a username "admin":

  
  
  username admin nopassword privilege 15
  username admin attributes
    ssh authentication publickey 55:06:47:eb:13:75:fc:5c:a8:c1:2c:bb:
    07:80:3a:fc:d9:08:a9:1f:34:76:31:ed:ab:bd:3a:9e:03:14:1e:1b hashed
  
  

  To use the ssh authentication command, before you upgrade, enter the following commands:

  
  
  aaa authentication ssh console LOCAL
  username admin password <password> privilege 15
  
  

  We recommend setting a password for the username as opposed to keeping the nopassword keyword, if present. The nopassword keyword means that any password can be entered, not that no password can be entered. Prior to 9.6(2), the aaa command was not required for SSH public key authentication, so the nopassword keyword was not triggered. Now that the aaa command is required, it automatically also allows regular password authentication for a username if the password (or nopassword ) keyword is present.

  After you upgrade, the username command no longer requires the password or nopassword keyword; you can require that a user cannot enter a password. Therefore, to force public key authentication only, re-enter the username command:

  
  
  username admin privilege 15
  
  

• Upgrade impact when upgrading the ASA on the Firepower 9300— Due to license entitlement naming changes on the back-end, when you upgrade to ASA 9.6(1)/FXOS 1.1(4), the startup configuration may not parse correctly upon the initial reload; configuration that corresponds to add-on entitlements is rejected.

  For a standalone ASA, after the unit reloads with the new version, wait until all the entitlements are processed and are in an "Authorized" state (show license all or Monitoring > Properties > Smart License), and simply reload again (reload or Tools > System Reload) without saving the configuration. After the reload, the startup configuration will be parsed correctly.

  For a failover pair if you have any add-on entitlements, follow the upgrade procedure in the FXOS release notes, but reset failover after you reload each unit (failover reset or Monitoring > Properties > Failover > Status, Monitoring > Failover > System, or Monitoring > Failover > Failover Group, and then click Reset Failover).

  For a cluster, follow the upgrade procedure in the FXOS release notes; no additional action is required.

• 9.5(2) New Carrier License—The new Carrier license replaces the existing GTP/GPRS license, and also includes support for SCTP and Diameter inspection. For the Firepower 9300 ASA security module, the feature mobile-sp command will automatically migrate to the feature carrier command.

• 9.5(2) E-mail proxy commands deprecated—In ASA Version 9.5(2), the e-mail proxy commands (imap4s , pop3s , smtps ) and subcommands are no longer supported.

• 9.5(2) CSD commands deprecated or migrated—In ASA Version 9.5(2), the CSD commands (csd image , show webvpn csd image , show webvpn csd , show webvpn csd hostscan , show webvpn csd hostscan image ) are no longer supported.

  The following CSD commands will migrate: csd enable migrates to hostscan enable ; csd hostscan image migrates to hostscan image .

• 9.5(2) Select AAA commands deprecated—In ASA Version 9.5(2), these AAA commands and subcommands (override-account-disable , authentication crack ) are no longer supported.

• 9.5(1) We deprecated the following command: timeout gsn

• ASA 5508-X and 5516-X upgrade issue when upgrading to 9.5(x) or later—Before you upgrade to ASA Version 9.5(x) or later, if you never enabled jumbo frame reservation then you must check the maximum memory footprint. Due to a manufacturing defect, an incorrect software memory limit might have been applied. If you upgrade to 9.5(x) or later before performing the below fix, then your device will crash on bootup; in this case, you must downgrade to 9.4 using ROMMON (Load an Image for the ASA 5500-X Series Using ROMMON), perform the below procedure, and then upgrade again.

  1. Enter the following command to check for the failure condition:

     
     ciscoasa# show memory detail | include Max memory footprint
     Max memory footprint        =    456384512
     Max memory footprint        =            0
     Max memory footprint        =    456384512
     
     

     If a value less than 456,384,512 is returned for “Max memory footprint,” then the failure condition is present, and you must complete the remaining steps before you upgrade. If the memory shown is 456,384,512 or greater, then you can skip the rest of this procedure and upgrade as normal.

  2. Enter global configuration mode:

     
     ciscoasa# configure terminal
     ciscoasa(config)#
     
     

  3. Temporarily enable jumbo frame reservation:

     
     ciscoasa(config)# jumbo-frame reservation
     WARNING: This command will take effect after the running-config
     is saved and the system has been rebooted. Command accepted.
     INFO: Interface MTU should be increased to avoid fragmenting
     jumbo frames during transmit
     

     Note	Do not reload the ASA.

  4. Save the configuration:

     
     ciscoasa(config)# write memory
     Building configuration...
     Cryptochecksum: b511ec95 6c90cadb aaf6b306 41579572
     14437 bytes copied in 1.320 secs (14437 bytes/sec)
     [OK]
     
     

  5. Disable jumbo frame reservation:

     
     ciscoasa(config)# no jumbo-frame reservation
     WARNING: This command will take effect after the running-config is saved and
     the system has been rebooted. Command accepted.

     Note	Do not reload the ASA.

  6. Save the configuration again:

     
     ciscoasa(config)# write memory
     Building configuration...
     Cryptochecksum: b511ec95 6c90cadb aaf6b306 41579572
     14437 bytes copied in 1.320 secs (14437 bytes/sec)
     [OK]
     
     

  7. You can now upgrade to Version 9.5(x) or later.

• 9.4(1) Unified Communications Phone Proxy and Intercompany Media Engine Proxy are deprecated—In ASA Version 9.4, the Phone Proxy and IME Proxy are no longer supported.

• 9.3(2) Transport Layer Security (TLS) version 1.2 support—We now support TLS version 1.2 for secure message transmission for ASDM, Clientless SSVPN, and AnyConnect VPN. We introduced or modified the following commands: ssl client-version, ssl server-version, ssl cipher, ssl trust-point, ssl dh-group. We deprecated the following command: ssl encryption

• 9.3(1) Removal of AAA Windows NT domain authentication—We removed NTLM support for remote access VPN users. We deprecated the following command: aaa-server protocol nt

Auto Update Server certificate verification

9.2(1) Auto Update Server certificate verification enabled by default. The Auto Update Server certificate verification is now enabled by default; for new configurations, you must explicitly disable certificate verification. If you are upgrading from an earlier release, and you did not enable certificate verification, then certificate verification is not enabled, and you see the following warning:

WARNING: The certificate provided by the auto-update servers will not be verified. In order to verify this certificate please use the verify-certificate option.

The configuration will be migrated to explicitly configure no verification:

auto-update server no-verification

Upgrade impact for ASDM login

Upgrade impact for ASDM login when upgrading from a pre-9.2(2.4) release to 9.2(2.4) or later. If you upgrade from a pre-9.2(2.4) release to ASA Version 9.2(2.4) or later and you use command authorization and ASDM-defined user roles, users with Read Only access will not be able to log in to ASDM. You must change the more command either before or after you upgrade to be at privilege level 5; only Admin level users can make this change. Note that ASDM version 7.3(2) and later includes the more command at level 5 for defined user roles, but preexisting configurations need to be fixed manually.

ASDM:

1. Choose Configuration > Device Management > Users/AAA > AAA Access > Authorization, and click Configure Command Privileges.

2. Select more, and click Edit.

   

3. Change the Privilege Level to 5, and click OK.

4. Click OK, and then Apply.

CLI:

ciscoasa(config)# privilege cmd level 5 mode exec command more

• Maximum MTU Is Now 9198 Bytes—If your MTU was set to a value higher than 9198, then the MTU is automatically lowered when you upgrade. In some cases, this MTU change can cause an MTU mismatch; be sure to set any connecting equipment to use the new MTU value. The maximum MTU that the ASA can use is 9198 bytes (check for your model’s exact limit at the CLI help). This value does not include the Layer 2 header. Formerly, the ASA let you specify the maximum MTU as 65535 bytes, which was inaccurate and could cause problems.

• IPv6 ACL Migration—IPv6 ACLs (ipv6 access-list ) will be migrated to extended ACLs (access-list extended ); IPv6 ACLs are no longer supported.

  If IPv4 and IPv6 ACLs are applied on the same direction of an interface (access-group command), then the ACLs are merged:

  • If both IPv4 and IPv6 ACLs are not used anywhere other than the access-group, then the name of the IPv4 ACL is used for the merged ACL; the IPv6 access-list is removed.

  • If at least one of the ACLs is used in another feature, then a new ACL is created with the name IPv4-ACL-name_IPv6-ACL-name; the in-use ACL(s) continue to be used for other features. ACLs not in use are removed. If the IPv6 ACL is in use for another feature, it is migrated to an extended ACL of the same name.

• ACL Any Keyword Migration—Now that ACLs support both IPv4 and IPv6, the any keyword now represents “all IPv4 and IPv6 traffic.” Any existing ACLs that use the any keyword will be changed to use the any4 keyword, which denotes “all IPv4 traffic.”

  In addition, a separate keyword was introduced to designate “all IPv6 traffic”: any6 .

  The any4 and any6 keywords are not available for all commands that use the any keyword. For example, the NAT feature uses only the any keyword; any represents IPv4 traffic or IPv6 traffic depending on the context within the specific NAT command.

• Static NAT-with-port-translation Requirement Before Upgrading—In Version 9.0 and later, static NAT-with-port-translation rules limit access to the destination IP address for the specified port only. If you try to access the destination IP address on a different port not covered by a NAT rule, then the connection is blocked. This behavior is also true for Twice NAT. Moreover, traffic that does not match the source IP address of the Twice NAT rule will be dropped if it matches the destination IP address, regardless of the destination port. Therefore, before you upgrade, you must add additional rules for all other traffic allowed to the destination IP address.

  For example, you have the following Object NAT rule to translate HTTP traffic to the inside server between port 80 and port 8080:

  
  object network my-http-server
    host 10.10.10.1
    nat (inside,outside) static 192.168.1.1 80 8080
  
  

  If you want any other services to reach the server, such as FTP, then you must explicitly allow them:

  
  object network my-ftp-server
    host 10.10.10.1
    nat (inside,outside) static 192.168.1.1 ftp ftp
  
  

  Or, to allow traffic to other ports of the server, you can add a general static NAT rule that will match all other ports:

  
  object network my-server-1
    host 10.10.10.1
    nat (inside,outside) static 192.168.1.1
  
  

  For Twice NAT, you have the following rule to allow HTTP traffic from 192.168.1.0/24 to the inside server and translate between port 80 and port 8080:

  
  object network my-real-server
    host 10.10.10.1
  object network my-mapped-server
    host 192.168.1.1
  object network outside-real-hosts
    subnet 192.168.1.0 255.255.255.0
  object network outside-mapped-hosts
    subnet 10.10.11.0 255.255.255.0
  object service http-real
    service tcp destination eq 80
  object service http-mapped
    service tcp destination eq 8080
  object service ftp-real
    service tcp destination eq 21
  nat (outside,inside) source static outside-real-hosts outside-mapped-hosts destination static my-mapped-server my-real-server service http-mapped http-real
  
  

  If you want the outside hosts to reach another service on the inside server, add another NAT rule for the service, for example FTP:

  
  nat (outside,inside) source static outside-real-hosts outside-mapped-hosts destination static my-mapped-server my-real-server ftp-real ftp-real
  
  

  If you want other source addresses to reach the inside server on any other ports, you can add another NAT rule for that specific IP address or for any source IP address. Make sure the general rule is ordered after the specific rule.

  
  nat (outside,inside) source static any any destination static my-mapped-server my-real-server 
  
  

• Configuration Migration for Transparent Mode—In 8.4, all transparent mode interfaces now belong to a bridge group. When you upgrade to 8.4, the existing two interfaces are placed in bridge group 1, and the management IP address is assigned to the Bridge Group Virtual Interface (BVI). The functionality remains the same when using one bridge group. You can now take advantage of the bridge group feature to configure up to four interfaces per bridge group and to create up to eight bridge groups in single mode or per context.

  Note

  Note In 8.3 and earlier, as an unsupported configuration, you could configure a management interface without an IP address, and you could access the interface using the device management address. In 8.4, the device management address is assigned to the BVI, and the management interface is no longer accessible using that IP address; the management interface requires its own IP address.

• When upgrading to 8.4(2) from 8.3(1), 8.3(2), and 8.4(1), all identity NAT configurations will now include the no-proxy-arp and route-lookup keywords, to maintain existing functionality. The unidirectional keyword is removed.

See the following guide that 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:

Cisco ASA 5500 Migration to Version 8.3