• Transport par défaut de la licence Smart modifié dans la version 9.22 : dans la version 9.22, le transport par défaut de la licence Smart est passé de Smart Call Home à Smart Transport. Vous pouvez configurer l’ASA pour utiliser Smart Call Home au besoin en utilisant la commande transport type callhome . Lorsque vous effectuez une mise à niveau vers la version 9.22, le transport passe automatiquement à Smart Transport. Si vous effectuez une rétrogradation, le transport est rétabli à Smart Call Home, et si vous souhaitez utiliser Smart Transport, vous devez préciser transport type smart .

• Les commandes de redistribution OSPFv3 qui précisent une carte de routage correspondant à une liste de préfixes seront supprimées dans la version 9.20(2) : lorsque vous passez à la version 9.20(2), les commandes de redistribution OSPFv3 où la carte de routage indiquée utilise une liste de préfixes d’adresse IP correspondante seront supprimées de la configuration. Bien que les listes de préfixes n’aient jamais été prises en charge, l’analyseur a toujours accepté la commande. Avant la mise à niveau, vous devez reconfigurer OSPFv3 de manière à utiliser les cartes de routage qui précisent une liste de contrôle d’accès dans la commande match ip address.

  Rappel

  La redistribution des cartes de routage avec la liste de préfixes IPv4 sur OSPFv2 est prise en charge.

• ASDM 7.19(1) requiert la version 8u261 d’Oracle Java ou une version ultérieure.– Avant de passer à ASDM 7.19, assurez-vous de mettre à jour Oracle Java (si utilisé) à la version 8u261 ou plus récente. Cette version prend en charge TLSv1.3, qui est nécessaire pour mettre à jour le lanceur ASDM. OpenJRE n’est pas concerné.

• Prise en charge des images signées ASDM dans la version 9.18(2)/7.18(1.152) et les versions ultérieures : l’ASA valide maintenant si l’image ASDM est une image signée numériquement par Cisco. Si vous essayez d’exécuter une ancienne image ASDM avec une version ASA intégrant ce correctif, ASDM sera bloqué, et le message « %ERREUR : signature non valide pour le disque de fichier0:/<nom du fichier> » s’affiche sur l’interface de ligne de commande d’ASA. La version 7.18(1.152) d’ASDM et les versions ultérieures sont rétrocompatibles avec toutes les versions d’ASA, même celles ne disposant pas de ce correctif. (CSCwb05291, CSCwb05264)

• Problème de mise à niveau de la version 9.18(1) si vous avez activé HTTPS/ASDM (avec authentification HTTPS) et SSL sur la même interface avec le même port : si vous activez à la fois l’accès SSL (webvpn > activer l’interface) et l’accès HTTPS/ASDM (http ) sur la même interface, vous pouvez accéder à AnyConnect à partir de l’adresse https://ip_address et à ASDM à partir de l’adresse https://ip_address/admin, tous deux sur le port 443. Cependant, si vous activez également l’authentification HTTPS (aaa authentication http console), vous devez définir un port différent pour l’accès ASDM à partir de la version 9.18(1). Assurez-vous de modifier le port avant de procéder à la mise à niveau à l’aide de la commande http . (CSCvz92016)

• Assistant de mise à niveau ASDM : en raison de la migration de l’API ASD, vous devez utiliser ASDM 7.18 ou une version ultérieure pour effectuer une mise à niveau vers ASA 9.18 ou une version ultérieure. Comme ASDM est rétrocompatible avec les versions d’ASA antérieures, vous pouvez mettre à niveau ASDM vers la version 7.18 ou une version ultérieure pour n’importe quelle version d’ASA.

• Prise en charge des images signées ASDM dans la version 9.17(1.13)/7.18(1.152) et les versions ultérieures : l’ASA valide maintenant si l’image ASDM est une image signée numériquement par Cisco. Si vous essayez d’exécuter une ancienne image ASDM avec une version ASA intégrant ce correctif, ASDM sera bloqué, et le message « %ERREUR : signature non valide pour le disque de fichier0:/<nom du fichier> » s’affiche sur l’interface de ligne de commande d’ASA. La version 7.18(1.152) d’ASDM et les versions ultérieures sont rétrocompatibles avec toutes les versions d’ASA, même celles ne disposant pas de ce correctif. (CSCwb05291, CSCwb05264)

• Aucune prise en charge du VPN SSL sans client dans les versions 9.17(1) et les versions ultérieures : le VPN SSL sans client n’est plus pris en charge.

  • webvpn : les sous-commandes suivantes sont supprimées :

    • apcf

    • java-trustpoint

    • onscreen-keyboard

    • port-forward

    • portal-access-rule

    • rewrite

    • smart-tunnel

  • group-policy webvpn : les sous-commandes suivantes sont supprimées :

    • port-forward

    • smart-tunnel

    • ssl-clientless

• Assistant de mise à niveau ASDM : en raison d’un changement interne, à partir de mars 2022, l’assistant de mise à niveau ne fonctionnera plus avec les versions antérieures à ASDM 7.17(1.152). Vous devez procéder à une mise à niveau manuelle vers la version 7.17(1.152) ou une version ultérieure pour utiliser l’assistant.

• Prise en charge des images signées ASDM dans la version 9.16(3.19)/7.18(1.152) et les versions ultérieures : l’ASA valide maintenant si l’image ASDM est une image signée numériquement par Cisco. Si vous essayez d’exécuter une ancienne image ASDM avec une version ASA intégrant ce correctif, ASDM sera bloqué, et le message « %ERREUR : signature non valide pour le disque de fichier0:/<nom du fichier> » s’affiche sur l’interface de ligne de commande d’ASA. La version 7.18(1.152) d’ASDM et les versions ultérieures sont rétrocompatibles avec toutes les versions d’ASA, même celles ne disposant pas de ce correctif. (CSCwb05291, CSCwb05264)

• Les utilisateurs SNMPv3 utilisant le hachage MD5 et le chiffrement DES ne sont plus pris en charge, et les utilisateurs seront supprimés lors de la mise à niveau vers la version 9.16(1) : assurez-vous de modifier toute configuration utilisateur pour utiliser des algorithmes de sécurité plus élevés à l’aide de la commande snmp-server user avant d’effectuer la mise à niveau.

• Action de la clé d’hôte SSH requise dans la version 9.16(1) : en plus de RSA, nous avons ajouté la prise en charge des clés d’hôte EDDSA et ECDSA pour SSH. L’ASA essaie d’utiliser les clés dans l’ordre suivant, si elles existent : EDDSA, ECDSAA, puis RSA. Lorsque vous effectuez une mise à niveau vers la version 9.16(1), l’ASA utilisera la clé RSA existante. Cependant, nous vous recommandons de générer des clés de sécurité élevée dès que possible à l’aide de la commande crypto key generate {eddsa | ecdsa] . De plus, si vous configurez explicitement l’ASA pour utiliser la clé RSA avec la commande ssh key-exchange hostkey rsa , vous devez générer une clé de 2 048 bits ou plus. Pour des raisons de compatibilité avec les mises à niveau, l’ASA utilisera des clés hôtes RSA de plus petite taille uniquement lorsque le paramètre par défaut de la clé hôte est utilisé. La prise en charge de RSA sera supprimée dans une version ultérieure.

• Dans la version 9.16 et les versions ultérieures, les certificats avec des clés RSA ne sont pas compatibles avec les chiffrements ECDSA : lorsque vous utilisez le groupe de chiffrement ECDHE_ECDSA, configurez le point de confiance avec un certificat qui contient une clé compatible avec ECDSA.

• ssh version commande supprimée dans la version 9.16(1) : cette commande a été supprimée. Seule la version 2 du protocole SSH est prise en charge.

• Lors de la mise à niveau vers la version 9.16 ou une version ultérieure, il se peut que vous voyiez un numéro de série de certificat différent. Dans la version 9.16, l’ASA a commencé à utiliser OpenSSL, ce qui entraîne un calcul différent des valeurs négatives dans les certificats. Il se peut donc que vous voyiez un numéro de série différent après la mise à niveau. Cette modification n’a pas d’incidence sur le fonctionnement. (CSCvv30338)

• Fonctionnalité SAMLv1 supprimée dans la version 9.16(1) : la prise en charge de SAMLv1 a été supprimée.

• Aucune prise en charge des groupes DH 2, 5 et 24 dans la version 9.16(1) : la prise en charge a été supprimée pour les groupes DH 2, 5 et 24 dans la configuration des groupes DH SSL. La commande ssl dh-group a été mise à jour pour supprimer les options de commande group2, group5 et group24.

• L’ASA 9.15(1) et les versions ultérieures ne prennent pas en charge les ASA 5525-X, ASA 5545-X et ASA 5555-X.L’ASA 9.14(x) est la dernière version prise en charge. Pour le module ASA FirePOWER, la dernière version prise en charge est la version 6.6.

• Cisco annonce l’abandon de la fonctionnalité pour le VPN SSL sans fil avec la version 9.17(1) de l’ASA.La prise en charge limitée restera valable pour les versions antérieures à la version 9.17(1).

• Pour le Firepower 1010, la présence d’identifiants de VLAN non valides peuvent causer des problèmes. Avant d’effectuer une mise à niveau vers la version 9.15(1), assurez-vous de ne pas utiliser de VLAN pour les ports de commutation de la plage de 3968 à 4047. Ces identifiants sont pour un usage interne uniquement, et la version 9.15(1) comprend une vérification pour vous assurer de ne pas utiliser ces identifiants. Par exemple, si ces identifiants sont utilisés après la mise à niveau d’une paire de basculements, la paire de basculements passera à l’état suspendu. Consultez le bogue CSCvw33057 pour en savoir plus.

• Abandon de la fonctionnalité SAMLv1 : la prise en charge de SAMLv1 est abandonnée.

• Suppression du chiffrement à faible sécurité dans l’ASA 9.15(1) : la prise en charge des chiffrements moins sécurisés suivants utilisés par IKE et IPsec a été supprimée :

  • Groupes Diffie-Hellman : 2 et 24.

  • Algorithmes de chiffrement : DES, 3DES, AES-GMAC, AES-GMAC-192, AES-GMAC-256, NULL, ESP-3DES, ESP-DES, ESP-MD5-HMAC

  • Algorithmes de hachage : MD5

  Remarque

  Les chiffrements SSH et SSL de faible sécurité n’ont pas encore été supprimés.

  Avant de passer d’une version antérieure de l’ASA à la version 9.15(1), vous devez mettre à jour votre configuration VPN afin d’utiliser les algorithmes de chiffrement pris en charge dans la version 9.15(1), faute de quoi l’ancienne configuration sera rejetée. Lorsque la configuration est rejetée, l’une des actions suivantes se produit, selon la commande :

  • La commande utilisera le chiffrement par défaut.

  • La commande sera supprimée.

  Il est particulièrement important d’appliquer un correctif à votre configuration avant la mise à niveau pour les déploiements de mise en grappe ou de basculement. Par exemple, si l’unité secondaire est mise à niveau vers la version 9.15(1) et que les chiffrements supprimés sont synchronisés avec cette unité à partir de l’unité principale, l’unité secondaire rejettera la configuration. Ce rejet peut entraîner un comportement imprévu, comme l’impossibilité de rejoindre la grappe.

  IKEv1 : les sous-commandes suivantes sont supprimées :

  • crypto ikev1 policy priority:

    • hash md5

    • encryption 3des

    • encryption des

    • group 2

  IKEv2 : les sous-commandes suivantes sont supprimées :

  • crypto ikev2 policy priority:

    • prf md5

    • integrity md5

    • group 2

    • group 24

    • encryption 3des

    • encryption des

    • encryption null

  IPsec : les sous-commandes suivantes sont supprimées :

  • 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

  Carte de chiffrement : les sous-commandes suivantes sont supprimées :

  • crypto map name sequence set pfs group2

  • crypto map name sequence set pfs group24

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

• Réintroduction de la configuration du point de distribution CRL : l’option de configuration de l’URL statique du CDP, qui a été supprimée dans la version 9.13(1), a été réintroduite dans la commande match-certificate .

• Option de restauration des contrôles de validité du certificat de contournement : l’option de contournement de la vérification de la révocation en raison de problèmes de connectivité avec le serveur CRL ou OCSP a été restaurée.

  Les sous-commandes suivantes ont été restaurées :

  • revocation-check crl none

  • revocation-check ocsp none

  • revocation-check crl ocsp none

  • revocation-check ocsp crl none

• Prise en charge des images signées ASDM dans la version 9.14(4.14)/7.18(1.152) et les versions ultérieures : l’ASA valide maintenant si l’image ASDM est une image signée numériquement par Cisco. Si vous essayez d’exécuter une ancienne image ASDM avec une version ASA intégrant ce correctif, ASDM sera bloqué, et le message « %ERREUR : signature non valide pour le disque de fichier0:/<nom du fichier> » s’affiche sur l’interface de ligne de commande d’ASA. La version 7.18(1.152) d’ASDM et les versions ultérieures sont rétrocompatibles avec toutes les versions d’ASA, même celles ne disposant pas de ce correctif. (CSCwb05291, CSCwb05264)

• Échec de l‘assistant de mise à niveau ASDM Cisco.com sur le Firepower 1000 et 2100 en mode appareil : l’assistant de mise à niveau ASDM Cisco.com ne permet pas d’effectuer de mise à niveau vers la version 9.14 (Outils > Vérifier la présence de mises à jour ASA/ASDM). L’assistant peut mettre à niveau ASDM de la version 7.13 à la version 7.14, mais la mise à niveau de l’image ASA est grisée. (CSCvt72183) Comme solution de contournement, utilisez l’une des méthodes suivantes :

  • Utilisez Outils > Mettre à niveau le logiciel à partir de l’ordinateur local pour ASA et ASDM. Notez que l’image ASDM (7.14(1)) dans l’ensemble 9.14(1) comporte également le bogue CSCvt72183. Vous devez télécharger la nouvelle image 7.14(1.46) pour assurer le bon fonctionnement de l’assistant.

  • Utilisez Outils > Vérifier la présence de mises à jour ASA/ASDM pour procéder à la mise à niveau vers ASDM 7.14 (la version sera 7.14(1.46)). Utilisez ensuite le nouveau ASDM pour mettre à niveau l’image ASA. Notez que l’erreur Erreur d’installation fatale pourrait s’afficher. Dans ce cas, cliquez sur OK. Il convient alors de définir l’image de démarrage à l’écran Configuration > Device Management > System Image/Configuration > Boot Image/Configuration (Configuration, Gestion des appareils, Image/Configuration du système, Image/Configuration de démarrage). Enregistrez la configuration et rechargez l’ASA.

• Pour les paires de basculements en version 9.14(1) ou toute version ultérieure, l’ASA ne partage plus les données du moteur client SNMP avec son homologue.

• Aucune prise en charge dans ASA 9.14(1) ni toute version ultérieure pour les OID cnatAddrBindNumberOfEntries et cnatAddrBindSessionCount (CSCv22526).

• Problème de mise à niveau pour les problèmes liés à la version 9.14(4)24 et à RADIUS pour les utilisateurs mobiles AnyConnect : pour restaurer la fonctionnalité RADIUS, procédez à une mise à niveau vers la version 9.18(4)22 ou une version ultérieure.

• Mise à niveau du Firepower 2100 en mode plateforme : lorsque vous effectuez une mise à niveau vers la version 9.14 ou une version ultérieure, si votre EtherChannel (port-canal) a été désactivé au moment de la mise à niveau, vous devrez activer manuellement l’EtherChannel et ses interfaces membres après la mise à niveau.

• Problème de rétrogradation du Firepower 2100 en mode plateforme à partir de la version 9.13/9.14 à la version 9.12 ou à une version antérieure : pour un Firepower 2100 disposant d’une nouvelle installation de la version 9.13 ou 9.14 que vous avez convertie en mode plateforme : si vous rétrogradez le périphérique à la version 9.12 ou à une version antérieure, vous ne pourrez pas configurer de nouvelles interfaces ni modifier des interfaces existantes dans FXOS (notez que la version 9.12 et les versions antérieures ne prennent en charge que le mode plateforme). Vous devez soit restaurer votre version à la version 9.13 ou à une version ultérieure, soit effacer votre configuration à l’aide de la commande de configuration d’effacement FXOS. Ce problème ne se produit pas si vous avez initialement effectué une mise à niveau vers la version 9.13 ou 9.14 à partir d’une version antérieure. Seules les nouvelles installations sont concernées, comme un nouveau périphérique ou un périphérique recréé. (CSCvr19755)

• Le mot clé tls-proxy et la prise en charge de l’inspection chiffrée SCCP/Skinny ont été supprimés de la commande inspect skinny .

• Assistant de mise à niveau ASDM : en raison d’une modification interne, l’assistant est uniquement pris en charge par ASDM 7.10(1) ou les versions ultérieures. De plus, en raison d’une modification de nom d’image, vous devez utiliser ASDM 7.12(1) ou une version ultérieure pour effectuer une mise à niveau vers ASA 9.10(1) ou une version ultérieure. Comme ASDM est rétrocompatible avec les versions d’ASA antérieures, vous pouvez mettre à niveau ASDM, quelle que soit la version d’ASA que vous utilisez. Veuillez noter que les ASDM 7.13 et 7.14 ne prenaient pas en charge les ASA 5512-X, 5515-X, 5585-X ou ASASM. Vous devez effectuer une mise à niveau vers ASDM 7.13(1.101) ou 7.14(1.48) pour rétablir la prise en charge d’ASDM.

• ASAv nécessite une mémoire de 2 Go dans la version 9.13(1) et les versions ultérieures. À compter de la version 9.13(1), la mémoire minimale requise pour l’ASAv est de 2 Go. Si votre instance d’ASAv actuelle fonctionne avec moins de 2 Go de mémoire, vous ne pouvez pas effectuer de mise à niveau vers la version 9.13(1) à partir d’une version antérieure. Vous devez régler la taille de la mémoire avant la mise à niveau. Consultez le guide de démarrage pour ASAv pour en savoir plus sur les allocations de ressources (vCPU et mémoire) prises en charge dans la version 9.13(1).

• Problème de rétrogradation du Firepower 2100 en mode plateforme à partir de la version 9.13 à la version 9.12 ou à une version antérieure : pour un Firepower 2100 disposant d’une nouvelle installation de la version 9.13 que vous avez convertie en mode plateforme : si vous rétrogradez le périphérique à la version 9.12 ou à une version antérieure, vous ne pourrez pas configurer de nouvelles interfaces ni modifier des interfaces existantes dans FXOS (notez que la version 9.12 et les versions antérieures ne prennent en charge que le mode plateforme). Vous devez soit restaurer votre version à la version 9.13, soit effacer votre configuration à l’aide de la commande de configuration d’effacement FXOS. Ce problème ne se produit pas si vous avez initialement effectué une mise à niveau vers la version 9.13 à partir d’une version antérieure. Seules les nouvelles installations sont concernées, comme un nouveau périphérique ou un périphérique recréé. (CSCvr19755)

• Modification de la MTU de la liaison de commande de grappe dans la version 9.13(1) : à partir de la version 9.13(1), de nombreux paquets de contrôle de grappe sont plus volumineux que dans les versions précédentes. La MTU recommandée pour le lien de contrôle de grappe a toujours été de 1 600 ou plus, et cette valeur est appropriée. Cependant, si vous définissez la MTU à 1 600, mais que vous n’avez pas réussi à faire correspondre la MTU aux commutateurs de connexion (par exemple, vous avez laissé la MTU à 1 500 sur le commutateur), vous commencerez à voir les effets de cette incompatibilité avec les paquets de contrôle de grappe abandonnés. Assurez-vous de définir tous les périphériques de la liaison de commande de grappe sur la même MTU, soit 1 600 ou plus.

• À partir de la version 9.13(1), l’ASA établit une connexion LDAP/SSL uniquement si l’un des critères de certification suivants est satisfait :

  • Le certificat du serveur LDAP est de confiance (existe dans un point de confiance ou dans le groupe de confiance d’ASA) et est valide.

  • Un certificat d’autorité de certification des serveurs émettant la chaîne est de confiance (existe dans un point de confiance ou dans le groupe de confiance d’ASA), et tous les certificats d’autorité de certification subordonnés de la chaîne sont complets et valides.

• Le serveur local de l’autorité de certification est supprimé dans la version 9.13(1) : lorsque l’ASA est configuré en tant que serveur local d’autorité de certification, il est en mesure d’émettre des certificats numériques, de publier des listes de révocation de certificats (CRL) et de révoquer en toute sécurité les certificats émis. Cette fonctionnalité a été abandonnée et, par conséquent, la commande crypto ca server a été supprimée.

• Suppression des commandes des points de distribution de la CRL : les commandes de configuration d’URL statique du CDP, à savoir crypto-ca-trustpoint crl et crl url , ont été supprimées avec d’autres logiques connexes. L’URL du CDP a été déplacée pour correspondre à la commande de certificat.

  Remarque

  La configuration de l’URL du CDP a été améliorée pour permettre plusieurs instances du remplacement du CDP pour une seule carte (consultez le bogue CSCvul05216).

• Option de suppression des contrôles de validité du certificat de contournement : l’option de contournement de la vérification de la révocation en raison de problèmes de connectivité avec le serveur CRL ou OCSP a été supprimée.

  Les sous-commandes suivantes sont supprimées :

  • revocation-check crl none

  • revocation-check ocsp none

  • revocation-check crl ocsp none

  • revocation-check ocsp crl none

  Ainsi, après une mise à niveau, toute commande revocation-check qui n’est plus prise en charge passera au nouveau comportement en ignorant le caractère de fin none.

  Remarque

  Ces commandes ont été restaurées ultérieurement (consultez le bogue CSCtb41710).

• Abandon du chiffrement à faible sécurité : plusieurs chiffrements utilisés par les modules ASA IKE, IPsec et SSH sont considérés comme étant non sécurisés et ont donc été abandonnés. Ils seront supprimés dans une version ultérieure.

  IKEv1 : les sous-commandes suivantes sont abandonnées :

  • crypto ikev1 policy priority:

    • hash md5

    • encryption 3des

    • encryption des

    • group 2

    • group 5

  IKEv2 : les sous-commandes suivantes sont abandonnées :

  • crypto ikev2 policy priority

    • integrity md5

    • prf md5

    • group 2

    • group 5

    • group 24

    • encryption 3des

    • encrypted des (cette commande est toujours disponible uniquement lorsque vous disposez de la licence de chiffrement DES)

    • encryption null

  IPsec : les commandes suivantes sont abandonnées :

  • 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 : Les commandes suivantes sont abandonnées :

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

  • ssh key-exchange group dh-group1-sha1

  SSL : Les commandes suivantes sont abandonnées :

  • ssl dh-group group2

  • ssl dh-group group5

  • ssl dh-group group24

  Carte de chiffrement : les commandes suivantes sont abandonnées :

  • 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

• Dans la version 9.13(1), le groupe Diffie-Hellman 14 est maintenant la valeur par défaut pour la commande group sous crypto ikev1 policy , ssl dh-group et crypto ikev2 policy pour IPsec PFS à l’aide de crypto map set pfs , crypto ipsec profile , crypto dynamic-map set pfs et crypto map set ikev1 phase1-mode . L’ancien groupe Diffie-Hellman par défaut était le groupe 2.

  Lors de la mise à niveau à partir d’une version antérieure à la version 9.13(1), si vous devez utiliser l’ancienne valeur par défaut (Groupe Diffie-Hellman 2), vous devez configurer manuellement le groupe DH en tant que groupe 2, sans quoi vos tunnels passeront par défaut au groupe 14. Comme le groupe 2 sera supprimé dans une version ultérieure, vous devez déplacer vos tunnels dans le groupe 14 dès que possible.

• Prise en charge des images signées ASDM dans la version 9.12(4.50)/7.18(1.152) et les versions ultérieures : l’ASA valide maintenant si l’image ASDM est une image signée numériquement par Cisco. Si vous essayez d’exécuter une ancienne image ASDM avec une version ASA intégrant ce correctif, ASDM sera bloqué, et le message « %ERREUR : signature non valide pour le disque de fichier0:/<nom du fichier> » s’affiche sur l’interface de ligne de commande d’ASA. La version 7.18(1.152) d’ASDM et les versions ultérieures sont rétrocompatibles avec toutes les versions d’ASA, même celles ne disposant pas de ce correctif. (CSCwb05291, CSCwb05264)

• Assistant de mise à niveau ASDM : en raison d’une modification interne, l’assistant est uniquement pris en charge par ASDM 7.10(1) ou les versions ultérieures. De plus, en raison d’une modification de nom d’image, vous devez utiliser ASDM 7.12(1) ou une version ultérieure pour effectuer une mise à niveau vers ASA 9.10(1) ou une version ultérieure. Comme ASDM est rétrocompatible avec les versions d’ASA antérieures, vous pouvez mettre à niveau ASDM, quelle que soit la version d’ASA que vous utilisez.

• Améliorations de sécurité SSH et nouvelles valeurs par défaut dans la version 9.12(1) : consultez les améliorations de sécurité SSH suivantes :

  • La version 1 du protocole SSH n’est plus prise en charge; seule la version 2 est prise en charge. La commande ssh version 1 sera migrée vers ssh version 2 .

  • Prise en charge de l’échange de clés SHA256, groupe Diffie-Hellman 14. Il s’agit désormais du paramètre par défaut (ssh key-exchange group dh-group14-sha256 ). L’ancienne valeur par défaut était le groupe 1 SHA1. Assurez-vous que votre client SSH prend en charge le groupe Diffie-Hellman SHA256 14. Si ce n’est pas le cas, une erreur de ce type pourrait s’afficher :« Impossible de convenir d’un algorithme d’échange de clés ». Par exemple, l’outil OpenSSH prend en charge le groupe Diffie-Hellman 14 SHA256.

  • Prise en charge du chiffrement d’intégrité HMAC-SHA256. La valeur par défaut est désormais l’ensemble de chiffrements à haute sécurité (hmac-sha1 et hmac-sha2-256, comme défini par la commande ssh cipher integrity high ). L’ancienne valeur par défaut était l’ensemble moyen.

• Le chiffrement NULL-SHA TLSv1 est abandonné et supprimé dans la version 9.12(1) : étant donné que NULL-SHA n’offre pas de chiffrement et n’est plus considéré comme étant sécurisé contre les menaces modernes, il sera supprimé lors du recensement des chiffrements pris en charge pour TLSv1 dans la sortie des commandes/options du mode tls-proxy et show ssl ciphers all . Les commandes ssl cipher tlsv1 all et ssl cipher tlsv1 custom NULL-SHA seront également obsolètes et supprimées.

• Le groupe de confiance par défaut est supprimé dans la version 9.12(1) : afin de se conformer à l’exigence de PSB, SEC-AUT-DEFROOT, l’ensemble d’autorités de certification de confiance « par défaut » est supprimé de l’image ASA. Par conséquent, les commandes crypto ca trustpool import default et crypto ca trustpool import clean default sont également supprimées, ainsi que les autres logiques connexes. Cependant, dans les déploiements existants, les certificats qui ont été précédemment importés à l’aide de ces commandes resteront présents.

• La commande ssl encryption est supprimée dans la version 9.12(1) : dans la version 9.3(2), l’abandon de la commande a été annoncé et celle-ci a été remplacée par ssl cipher . Dans 9.12(1), ssl encryption est supprimé et n’est plus pris en charge.

• En raison d’une modification interne, l’assistant de mise à niveau ASDM est uniquement pris en charge par ASDM 7.10(1) ou les versions ultérieures. De plus, en raison d’une modification de nom d’image, vous devez utiliser ASDM 7.12(1) ou une version ultérieure pour effectuer une mise à niveau vers ASA 9.10(1) ou une version ultérieure. Comme ASDM est rétrocompatible avec les versions d’ASA antérieures, vous pouvez mettre à niveau ASDM, quelle que soit la version d’ASA que vous utilisez.

• Problèmes de mémoire ASA 5506-X avec de grandes configurations sur la version 9.9(2) et les versions ultérieures : si vous effectuez une mise à niveau vers la version 9.9(2) ou une version ultérieure, des parties d’une très grande configuration peuvent être rejetées en raison d’une mémoire insuffisante en présentant le message suivant : « ERREUR : mémoire insuffisante pour installer les règles ». Une option consiste à saisir la commande object-group-search access-control pour améliorer l’utilisation de la mémoire pour les listes de contrôle d’accès. Cependant, vos performances risquent d’en pâtir. Sinon, vous pouvez rétrograder le périphérique à la version 9.9(1).

• Prise en charge des images signées ASDM dans la version 9.8(4.45)/7.18(1.152) et les versions ultérieures : l’ASA valide maintenant si l’image ASDM est une image signée numériquement par Cisco. Si vous essayez d’exécuter une ancienne image ASDM avec une version ASA intégrant ce correctif, ASDM sera bloqué, et le message « %ERREUR : signature non valide pour le disque de fichier0:/<nom du fichier> » s’affiche sur l’interface de ligne de commande d’ASA. La version 7.18(1.152) d’ASDM et les versions ultérieures sont rétrocompatibles avec toutes les versions d’ASA, même celles ne disposant pas de ce correctif. (CSCwb05291, CSCwb05264)

• Avant la mise à niveau vers la version 9.8(2) ou une version ultérieure, le mode FIPS exige que la clé de basculement comporte au moins 14 caractères. Avant de procéder à la mise à niveau vers la version 9.8(2) ou une version ultérieure en mode FIPS, vous devez modifier le failover key ou le failover ipsec pre-shared-key pour être à au moins 14 caractères. Si votre clé de basculement est trop courte, lorsque vous mettez à niveau la première unité, la clé de basculement sera rejetée, et les deux unités deviendront actives jusqu’à ce que vous définissiez la clé de basculement à une valeur valide.

• Ne mettez pas à niveau ASAv vers la version 9.8(1) sur Amazon Web Services : en raison du bogue CSCve56153, il est conseillé de ne pas effectuer la mise à niveau vers la version 9.8(1). Après la mise à niveau, l’ASAv devient inaccessible. Passez plutôt à la version 9.8(1.5) ou à une version ultérieure.

• Problème de mise à niveau de la version 9.7(1) à la version 9.7(1.x) ou tout version ultérieure pour VTI et VXLAN VNI : si vous configurez à la fois Virtual Tunnel Interface (VTI) et des interfaces VNI (Virtual Network Identifier), vous ne pouvez pas effectuer de mise à niveau sans temps d’arrêt pour le basculement. Les connexions sur ces types d’interfaces ne seront pas répliquées sur l’unité de secours tant que les deux unités n’utiliseront pas la même version. (CSCvc83062)

• (d’ASA 9.6(2) à ASA 9.7(x)) Incidence sur la mise à niveau lors de l’utilisation de l’authentification par clé publique SSH : en raison des mises à jour de l’authentification SSH, une configuration supplémentaire est requise pour activer l’authentification par clé publique SSH; par conséquent, les configurations SSH existantes utilisant l’authentification par clé publique ne fonctionnent plus après la mise à niveau. L’authentification par clé publique est la valeur par défaut pour l’ASAv sur Amazon Web Services (AWS), donc les utilisateurs AWS verront ce problème. Pour éviter la perte de connectivité SSH, vous pouvez mettre à jour votre configuration avant d’effectuer la mise à niveau. Vous pouvez également utiliser ASDM après la mise à niveau (si vous avez activé l’accès ASDM) pour corriger la configuration.

  Remarque

  Le comportement d’origine a été restauré dans la version 9.8(1).

  Exemple de configuration d’origine pour un nom d’utilisateur « 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
  
  

  Pour utiliser la commande ssh authentication , avant d’effectuer la mise à niveau, saisissez les commandes suivantes :

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

  Nous vous recommandons de définir un mot de passe pour le nom d’utilisateur plutôt que de conserver le mot clé nopassword , s’il est présent. Le mot clé nopassword signifie que tout mot de passe peut être saisi, et non qu’aucun mot de passe ne peut être saisi. Avant la version 9.6(2), la commande aaa n’était pas requise pour l’authentification par clé publique SSH, le mot clé nopassword n’était donc pas déclenché. Maintenant que la commande aaa est requise, elle permet également l’authentification par mot de passe normale pour un mot clé username si le mot clé password (ou nopassword ) est présent.

  Après la mise à niveau, la commande username ne requiert plus le mot clé password ou nopassword . Vous pouvez exiger qu’un utilisateur ne puisse pas saisir de mot de passe. Par conséquent, pour forcer l’authentification par clé publique uniquement, saisissez la commande username  :

  
  
  username admin privilege 15
  
  

• Incidence sur la mise à niveau lors de la mise à niveau de l‘ASA sur le Firepower 9300. En raison de modifications de nom des droits de licence sur le serveur principal, lors de la mise à niveau vers l‘ASA 9.6(1)/FXOS 1.1(4), la configuration de démarrage peut ne pas être analysée correctement lors du rechargement initial; la configuration qui correspond aux droits du module complémentaire est alors rejetée.

  Pour un ASA autonome, après le rechargement de l’unité avec la nouvelle version, attendez que tous les droits soient traités et présentent l’état « Autorisé » (afficher toutes les licences ou Surveillance > Propriétés > Licence Smart), puis rechargez simplement (recharger ou Outils > Rechargement du système) sans enregistrer la configuration. Après le rechargement, la configuration de démarrage sera analysée correctement.

  Pour une paire de basculements, si vous disposez de droits complémentaires, suivez la procédure de mise à niveau dans les notes de mise à jour de FXOS, mais réinitialisez le basculement après avoir rechargé chaque unité (failover reset ou Surveillance > Propriétés > Basculement > État, Surveillance > Basculement > Système, ou Surveillance > Basculement > Groupe de basculement, puis cliquez sur Réinitialiser le basculement).

  Pour une grappe, suivez la procédure de mise à niveau dans les notes de mise à jour de FXOS; aucune autre action n’est requise.

• 9.5(2) Nouvelle licence de transporteur : la nouvelle licence de transporteur remplace la licence GTP/GPRS existante et comprend également la prise en charge de l’inspection SCTP et Diameter. Pour le module de sécurité ASA Firepower 9300, la commande feature mobile-sp migrera automatiquement vers la commande feature carrier .

• 9.5(2) Commandes de mandataire pour courriels abandonnées : dans la version 9.5(2), les commandes de mandataire pour courriels (imap4s , pop3s et smtps ) et les sous-commandes ne sont plus prises en charge.

• 9.5(2) Commandes CSD abandonnées ou migrées : dans la version 9.5(2), les commandes CSD (csd image , show webvpn csd image , show webvpn csd , show webvpn csd hostscan et show webvpn csd hostscan image ) ne sont plus prises en charge.

  Les commandes CSD suivantes seront migrées : csd enable migre vers hostscan enable ; csd hostscan image migre vers hostscan image .

• 9.5(2) Certaines commandes AAA avandonnées : dans la version 9.5(2) de l’ASA, ces commandes et sous-commandes AAA (override-account-disable et authentication crack ) ne sont plus prises en charge.

• 9.5(1) Nous avons abandonné la commande suivante : timeout gsn

• Problème de mise à niveau des ASA 5508-X et 5516-X lors de la mise à niveau vers la version 9.5(x) ou une version ultérieure : avant d’effectuer la mise à niveau vers la version ASA 9.5(x) ou une version ultérieure, si vous n’avez jamais activé la réservation de trames étendues, vous devez vérifier l’empreinte mémoire maximale. En raison d’un défaut de fabrication, une limite de mémoire logicielle incorrecte a peut-être été appliquée. Si vous effectuez la mise à niveau vers la version 9.5(x) ou une version ultérieure avant d’appliquer le correctif ci-dessous, votre périphérique plantera au démarrage. Dans ce cas, vous devez rétrograder à la version 9.4 à l’aide de ROMMON (charger une image pour la gamme ASA 5500-X à l’aide de ROMMON), effectuer la procédure ci-dessous, puis effectuer de nouveau la mise à niveau.

  1. Entrez la commande suivante pour vérifier la condition de défaillance :

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

     Si une valeur inférieure à 456 384 512 est renvoyée pour « Empreinte de mémoire maximale », la condition de défaillance est présente, et vous devez effectuer les étapes restantes avant d’effectuer la mise à niveau. Si la mémoire affichée est de 456 384 512 ou plus, vous pouvez ignorer le reste de cette procédure et la mettre à niveau comme d’habitude.

  2. Accédez au mode de configuration globale :

     
     ciscoasa# configure terminal
     ciscoasa(config)#
     
     

  3. Activez temporairement la réservation de trames étendues :

     
     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
     

     Remarque

     Ne rechargez pas l’ASA.

  4. Enregistrez la configuration :

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

  5. Désactivez la réservation de trame étendue :

     
     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.

     Remarque

     Ne rechargez pas l'ASA.

  6. Enregistrez de nouveau la configuration :

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

  7. Vous pouvez maintenant effectuer une mise à niveau vers la version 9.5(x) ou une version ultérieure.

• 9.4(1) Le mandataire du téléphone des communications unifiées et le mandataire du moteur de médias interentreprises sont abandonnés. Dans la version 9.4 de l’ASA, les mandataires du téléphone et le mandataire du moteur de médias interentreprises ne sont plus pris en charge.

• 9.3(2) Prise en charge de la version 1.2 du protocole Transport Layer Security (TLS) : nous prenons désormais en charge la version 1.2 du protocole TLS pour la transmission sécurisée des messages pour ASDM, Clientless SSVPN et AnyConnect VPN. Nous avons introduit ou modifié les commandes suivantes : ssl client-version, ssl server-version, ssl cipher, ssl trust-point et ssl dh-group. Nous avons abandonné la commande suivante : ssl encryption

• 9.3(1) Suppression de l’authentification de domaine AAA Windows NT : nous avons supprimé la prise en charge de NTLM pour les utilisateurs de VPN d’accès à distance. Nous avons abandonné la commande suivante : aaa-server protocol nt

Vérification du certificat du serveur de mise à jour automatique

9.2(1) Vérification du certificat du serveur de mise à jour automatique activée par défaut. La vérification du certificat du serveur de mise à jour automatique est maintenant activée par défaut; pour les nouvelles configurations, vous devez explicitement désactiver la vérification de certificat. Si vous effectuez une mise à niveau à partir d’une version antérieure et que vous n’avez pas activé la vérification de certificat, la vérification de certificat n’est pas activée, et l’avertissement suivant s’affiche :

AVERTISSEMENT : Le certificat fourni par les serveurs de mise à jour automatique ne sera pas vérifié. Pour vérifier ce certificat, utilisez l’option avec le certificat de vérification.

La configuration sera migrée vers la configuration explicite sans vérification :

auto-update server no-verification

Incidence sur la mise à niveau pour la connexion à ASDM

Incidence sur la mise à niveau pour la connexion à ASDM lors de la mise à niveau d’une version antérieure à la version 9.2(2.4) à la version 9.2(2.4), ou toute version ultérieure. Si vous effectuez une mise à niveau d’une version antérieure à la version 9.2(2.4) vers la version 9.2(2.4) d’ASA ou une version ultérieure et que vous utilisez l’autorisation de commande et les rôles d’utilisateur définis par ASDM, les utilisateurs avec un accès en lecture seule ne pourront pas se connecter à ASDM. Vous devez modifier la commande more avant ou après la mise à niveau pour être au niveau de privilège 5; seuls les utilisateurs de niveau Administrateur peuvent apporter cette modification. Veuillez noter que la version 7.3(2) et les versions ultérieures d’ASDM comprend la commande more au niveau 5 pour les rôles d’utilisateur définis, mais les configurations préexistantes doivent être corrigées manuellement.

ASDM :

1. Choisissez Configuration > Gestion des périphériques > Utilisateurs/AAA > Accès AAA > Autorisation, puis cliquez sur Configurer les privilèges de commande.

2. Sélectionnez Plus, puis cliquez sur Modifier.

   

3. Définissez le niveau de privilège sur 5 et cliquez sur OK.

4. Cliquez sur OK, puis sur Appliquer.

Interface de ligne de commande :

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

• La MTU maximale est maintenant de 9 198 octets : si votre MTU a été définie à une valeur supérieure à 9 198, la MTU est automatiquement réduite lors de la mise à niveau. Dans certains cas, cette modification de la MTU peut entraîner une non-concordance de la MTU. Assurez-vous de configurer tout équipement de connexion pour utiliser la nouvelle valeur MTU. La MTU maximale que l’ASA peut utiliser est de 9 198 octets (vérifiez la limite exacte de votre modèle à l’aide de l’interface de ligne de commande). Cette valeur n’inclut pas l’en-tête de couche 2. L’ASA vous a permis de définir une MTU maximale de 65 535 octets, ce qui était inexact et pourrait causer des problèmes.

• Migration des listes de contrôle d’accès IPv6 : les listes de contrôle d’accès IPv6 (ipv6 access-list ) seront migrées vers les listes de contrôle d’accès étendues (access-list extended ); les listes de contrôle d’accès IPv6 ne sont plus prises en charge.

  Si les listes de contrôle d’accès IPv4 et IPv6 sont appliquées dans la même direction d’une commande d’interface (access-group ), les listes de contrôle d’accès sont fusionnées :

  • Si les listes de contrôle d’accès IPv4 et IPv6 ne sont utilisées nulle part ailleurs que dans le groupe d’accès, le nom de la liste de contrôle d’accès IPv4 est utilisé pour la liste de contrôle d’accès fusionnée; la liste de contrôle d’accès IPv6 est supprimée.

  • Si au moins une des listes de contrôle d’accès est utilisée dans une autre fonctionnalité, une nouvelle liste de contrôle d’accès est créée avec le nom IPv4-ACL-name_IPv6-ACL-name. La ou les listes de contrôle d’accès en cours d’utilisation continuent d’être utilisées pour d’autres fonctionnalités. Les listes de contrôle d’accès qui ne sont pas utilisées sont supprimées. Si la liste de contrôle d’accès IPv6 est utilisée pour une autre fonctionnalité, elle est migrée vers une liste de contrôle d’accès étendue du même nom.

• Migration du mot clé « tout » de la liste de contrôle d’accès : maintenant que les listes de contrôle d’accès prennent en charge les protocoles IPv4 et IPv6, le mot clé any représente désormais « tout le trafic IPv4 et IPv6 ». Toutes les listes de contrôle d’accès existantes qui utilisent le mot clé any seront modifiées pour utiliser le mot clé any4 , qui désigne « tout le trafic IPv4 ».

  En outre, un mot clé distinct a été introduit pour désigner « tout le trafic IPv6 » : any6 .

  Les mots clés any4 et any6 ne sont pas disponibles pour toutes les commandes qui utilisent le mot clé any . Par exemple, la fonctionnalité NAT utilise uniquement le mot clé any ; le mot clé « tout » représente le trafic IPv4 ou le trafic IPv6 selon le contexte dans la commande NAT en particulier.

• Exigences en matière de NAT statique avec traduction de port avant la mise à niveau : dans la version 9.0 et les versions ultérieures, les règles statiques de NAT avec traduction de port limitent l’accès à l’adresse IP de destination pour le port spécifié uniquement. Si vous essayez d’accéder à l’adresse IP de destination sur un port différent non couvert par une règle NAT, la connexion est bloquée. Ce comportement est également valable pour la NAT Twice. De plus, le trafic qui ne correspond pas à l’adresse IP source de la règle NAT Twice sera abandonné s’il correspond à l’adresse IP de destination, quel que soit le port de destination. Par conséquent, avant de procéder à la mise à niveau, vous devez ajouter des règles supplémentaires pour tout autre trafic autorisé vers l’adresse IP de destination.

  Par exemple, la règle NAT Object suivante permet de traduire le trafic HTTP vers le serveur interne entre le port 80 et le port 8080 :

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

  Si vous souhaitez que d’autres services puissent atteindre le serveur, comme FTP, vous devez les autoriser explicitement :

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

  Ou, pour autoriser le trafic vers d’autres ports du serveur, vous pouvez ajouter une règle NAT statique générale qui correspondra à tous les autres ports :

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

  Pour la NAT Twice, la règle suivante permet d’autoriser le trafic HTTP de l’adresse 192.168.1.0/24 vers le serveur interne et de le traduire entre le port 80 et le 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
  
  

  Si vous souhaitez que les hôtes externes atteignent un autre service sur le serveur interne, ajoutez une autre règle NAT pour le service, par exemple FTP :

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

  Si vous souhaitez que d’autres adresses sources atteignent le serveur interne sur tous les autres ports, vous pouvez ajouter une autre règle NAT pour cette adresse IP spécifique ou pour n’importe quelle adresse IP source. Assurez-vous que la règle générale est classée après la règle spécifique.

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

• Migration de la configuration pour le mode transparent : dans la version 8.4, toutes les interfaces en mode transparent appartiennent désormais à un groupe de ponts. Lors de la mise à niveau vers la version 8.4, les deux interfaces existantes sont placées dans le groupe de ponts 1, et l’adresse IP de gestion est attribuée à la BVI (Bridge Group Virtual Interface). La fonctionnalité reste la même lors de l’utilisation d’un groupe de ponts. Vous pouvez désormais profiter de la fonctionnalité de groupe de ponts pour configurer jusqu’à quatre interfaces par groupe de ponts et créer jusqu’à huit groupes de ponts en mode unique ou par contexte.

  Remarque

  Remarque : Dans la version 8.3 et les versions antérieures, en tant que configuration non prise en charge, vous pourriez configurer une interface de gestion sans adresse IP et vous pourriez accéder à l’interface en utilisant l’adresse de gestion des périphériques. Dans la version 8.4, l’adresse de gestion des périphériques est attribuée aux BVI, et l’interface de gestion n’est plus accessible en utilisant cette adresse IP; l’interface de gestion nécessite sa propre adresse IP.

• Lors de la mise à niveau vers la version 8.4(2) à partir des versions 8.3(1), 8.3(2) et 8.4(1), toutes les configurations NAT d’identité incluront désormais les mots clés no-proxy-arp et route-lookup pour maintenir les fonctionnalités existantes. Le mot clé unidirectional est supprimé.

Consultez le guide suivant qui décrit le processus de migration de la configuration lorsque vous passez d’une version antérieure à la version 8.3 du système d’exploitation Cisco ASA 5500 à la version 8.3 :

Migration du Cisco ASA 5500 vers la version 8.3