Configurations prises en charge

L'outil de migration Secure Firewall peut totalement migrer les configurations suivantes :

• Objets et des groupes de réseau

• Objets de service, à l’exception des objets de service configurés pour une source et une destination

  Remarque

  Bien que l’outil de migration de pare-feu sécurisé ne migre pas les objets de service élargis (configurés pour une source et une destination), les règles ACL et NAT référencées sont migrées avec toutes leurs fonctionnalités.

• Groupes d’objets de service, à l’exception des groupes d’objets de service imbriqués

  Remarque

  Puisque l’imbrication n’est pas prise en charge sur le centre de gestion, l’outil de migration Cisco Secure Firewall élargit le contenu des règles référencées. Les règles sont toutefois migrées avec toutes les fonctionnalités.

• Objets et groupes FQDN IPv4 et IPv6

• Prise en charge de la conversion IPv6 (interface, routes statiques, objets, ACL et NAT)

• Règles d'accès appliquées aux interfaces dans la direction entrante et ACL globales

• NAT automatique, NAT manuel et NAT d’objet (conditionnel)

• Routes statiques, Routes ECMP et PBR

• Interfaces physiques

• VLANs secondaires sur les interfaces non migrées vers Défense contre les menaces.

• Sous-interfaces (l’ID de sous-interface est toujours défini sur le même numéro que l’ID de VLAN lors de la migration)

• canaux de port

• Virtual tunnel interface (VTI)

• Groupes de ponts (mode transparent uniquement)

• IP SLA Monitor

  L’outil de migration Cisco Secure Firewall crée des objets IP SLA, mappe les objets avec les routes statiques spécifiques et fait migrer ces objets vers centre de gestion.

  Le moniteur SLA IP définit une stratégie de connectivité à une adresse IP surveillée et suit la disponibilité d’une route vers l’adresse IP. La disponibilité des routes statiques est vérifiée périodiquement en envoyant des demandes d'écho ICMP et en attendant la réponse. Si les demandes d'écho sont dépassées, les routes statiques sont supprimées de la table de routage et remplacées par une route de secours. Les tâches de surveillance SLA démarrent immédiatement après le déploiement et continuent de s'exécuter à moins que vous ne supprimiez le moniteur SLA de la configuration de l'appareil, c'est-à-dire qu'elles ne vieillissent pas. Les objets du moniteur IP SLA sont utilisés dans le champ Route Tracking d'une stratégie de route statique IPv4. Les routes IPv6 n’ont pas la possibilité d’utiliser le moniteur SLA via le suivi de route.

  Remarque

  IP SLA Monitor n’est pas pris en charge pour les non-fluxDéfense contre les menaces.

• Recherche groupée d’objets

  L’activation de la recherche de groupe d’objets réduit les besoins en mémoire pour les stratégies de contrôle d’accès qui incluent des objets réseau. Nous vous recommandons d'activer la recherche par groupe d'objets qui permet d'optimiser l'utilisation de la mémoire par la politique d'accès sur Défense contre les menaces.

  Remarque

  La recherche de groupe d’objets n’est pas disponible pour la version antérieure à 6.6.centre de gestionDéfense contre les menaces La recherche de groupe d’objets ne sera pas prise en charge pour les non-flux et sera désactivée.Défense contre les menaces

• Objets temporels

  Lorsque l'outil de migration Secure Firewall détecte des objets temporels référencés par des règles d'accès, il migre les objets temporels et les associe aux règles d'accès correspondantes. Vérifier les objets par rapport aux règles dans la page Examiner et valider la configuration.

  Les objets temporels sont des types de listes d'accès qui autorisent l'accès au réseau sur la base d'une période de temps. Il est utile lorsque vous devez imposer des restrictions au trafic sortant ou entrant en fonction d'une heure particulière de la journée ou de certains jours de la semaine.

  Remarque

  Vous devez migrer manuellement la configuration du fuseau horaire du vers le FTD cible L’objet temporel n’est pas pris en charge pour les non-flux et sera désactivé.Défense contre les menaces Les objets temporels sont pris en charge sur les versions 6.6 et ultérieures.centre de gestion

• Tunnels de réseau privé virtuel (VPN) de site à site

  • VPN site à site - Lorsque l'outil de migration Secure Firewall détecte une configuration de carte cryptographique dans le source, l'outil de migration Secure Firewall migre la carte cryptographique vers le VPN centre de gestion en tant que topologie point à point.

  • VPN basé sur une carte cryptographique (statique/dynamique) à partir de l'ASA

  • VPN ASA basé sur les routes (VTI)

  • Migration vers un VPN basé sur des certificats à partir d'ASA

  • La migration des points de confiance ou des certificats ASA vers le centre de gestiondoit être effectuée manuellement et fait partie de l'activité de pré-migration.

• Objets de routage dynamique, BGP et EIGRP

  • Liste de politiques

  • Liste des préfixes

  • Liste de communautés

  • Chemin du système autonome (AS)

• VPN d’accès à distance

  • Protocoles SSL et IKEv2

  • Méthodes d’authentification : AAA uniquement, certificat client uniquement, SAML, AAA et certificat client

  • AAA - Radius, Local, LDAP et AD.

  • Profils de connexion, stratégies de groupe, Dynamic Access Policy, mappage des attributs LDAP et mappage des certificats

  • ACL standard et élargi

  • Attributs personnalisés de RA VPN et équilibrage de charge VPN

  • Dans le cadre des activités préalables à la migration, effectuez les opérations suivantes:

    • Migrez manuellement les points de confiance ASA verscentre de gestion les objets PKI.

    • Récupérez les paquets AnyConnect, les fichiers Hostscan (Dap.xml, Data.xml, Hostscan Package), les paquets External Browser et les profils AnyConnect doivent être récupérés à partir de la source ASA.

    • Chargez tous les packages AnyConnect sur lecentre de gestion.

    • Chargez les profils AnyConnect directement vers centre de gestion ou à partir de l’outil de migration Cisco Secure Firewall.

    • Activez la commande ssh scopy enable sur l’ASA pour permettre la récupération des profils à partir de l’ASA Live Connect.

Configurations partiellement prises en charge

L'outil de migration Secure Firewall prend partiellement en charge les configurations suivantes pour migration : Certaines de ces configurations comprennent des règles avec des options avancées qui sont migrées sans ces options. Si le centre de gestion prend en charge ces options avancées, vous pouvez les configurer manuellement lorsque la migration sera terminée.

• Règles de politique de contrôle d'accès configurées avec des paramètres de journalisation avancés, tels que la gravité et l'intervalle de temps.

• Routes statiques qui sont configurées avec l'option de suivi.

• Migration vers un VPN basé sur des certificats.

• Objets de routage dynamique, EIGRP et BGP

  • Route-Carte

Configurations non prises en charge

L'outil de migration Secure Firewall ne prend pas en charge les configurations suivantes pour la migration : Si ces configurations sont prises en charge dans le centre de gestion, vous pouvez les configurer manuellement lorsque la migration sera complétée.

• Règles de politique de contrôle d’accès basées sur SGT

• Objets basés sur SGT

• Règles de politique de contrôle d’accès basées sur l’utilisateur

• Règles NAT configurées avec l’option d’allocation de bloc

• Objets dont le type et le code ICMP ne sont pas pris en charge

• Règles de contrôle d'accès basées sur le protocole de tunnellisation

  Remarque

  Prise en charge d'un préfiltre sur l'outil de migration Secure Firewall et centre de gestion 6.5.

• Règles NAT configurées avec SCTP

• Règles NAT configurées avec l’hôte « 0.0.0.0 »

• Route par défaut obtenue par DHCP ou PPPoE avec suivi SLA

• Calendrier du suivi SLA

• Mode de transport IPsec transform-set

• Migration du point de confiance ASA vers centre de gestion

• Mode de pare-feu transparent pour BGP

Limites de configuration

La migration de votre configuration source a les limites suivantes :

• L'outil de migration Secure Firewall prend en charge la migration des contextes de sécurité individuels à partir du en tant qu'appareils séparésDéfense contre les menaces.

• La configuration système n'est pas migrée.

• L'outil de migration Secure Firewall ne supporte pas la migration d'une seule politique ACL qui est appliqué sur plus de 50 interfaces. Faites migrer manuellement les politiques ACL étant appliquées à 50 interfaces ou plus.

• Vous ne pouvez pas migrer certaines configurations, par exemple, le routage dynamique vers Défense contre les menaces. Migrez manuellement ces configurations.

• Vous ne pouvez pas faire migrer des appareils en mode routée avec une interface virtuelle de point (BVI), une interface redondante ou une interface tunnelisée. Par contre, vous pouvez faire migrer des appareils en mode transparent avec le BVI.

• Les groupes d'objets de service imbriqués ou les groupes de ports ne sont pas pris en charge sur le centre de gestion. Dans le cadre de la conversion, l'outil de migration Secure Firewall étend le contenu du groupe objet imbriqué ou du groupe de port.

• L'outil de migration Secure Firewall divise l'objet ou les groupes de service étendus avec la source et les ports de destination qui se trouvent sur une ligne en différents objets sur plusieurs lignes. Les références à de telles règles de contrôle d'accès sont converties en centre de gestionrègles avec la même signification.

• Si la configuration source à des règles de contrôle d'accès qui ne réfèrent pas à des protocoles de tunnelage spécifique (comme GRE, IP-dans-IP et IP6-dans-IP), mais que ces règles correspondent à un trafic de tunnelage non crypté sur le , alors, en migration vers le Défense contre les menaces, les règles correspondantes ne se comporteront pas de la même manière qu'elles le font sur le . Nous vous conseillons de créer des règles de tunnelage spécifique pour celles-ci dans la politique Préfiltrage, sur le Défense contre les menaces.

• Les cartes cryptographiques supportées sont migrées comme topologie point par point.

• Si un objet AS-Path portant le même nom apparaîtcentre de gestion, la migration s'arrête avec le message d'erreur suivant :

  « Conflit de noms d'objets AS-Path détecté dans centre de gestion, veuillez résoudre le conflit dans centre de gestion pour continuer »

• La redistribution d'OSPF et du protocole d'information de routage (RIP) vers EIGRP n'est pas supportée.

• Pour PBR, la configuration de l'ASA comporte des cartes de routage alors que le centre de gestion n'utilise pas de cartes de routage. L'outil de migration Secure Firewall fait migrer la configuration dans une carte de routage appliquée à une interface.

• Pour les cartes de routage avec de multiples numéros de séquence, seul le premier numéro de séquence sera migré. Tous les autres numéros de séquence seront ignorés et montrés dans le rapport de pré-migration.

Limites pour la migration AD VPN

La migration d'accès à distance VPN est supporté avec les limites suivantes :

• La migration des paramètres SSL n'est pas prise en charge en raison des limitations de l'API.

• Le serveur LDAP est migré avec le type de chiffrement « aucun ».

• DfltGrpPolicy n'est pas migré puisque la politique n'est pas applicable pour tout le centre de gestion. Vous pouvez faire les changements nécessaires directement sur le centre de gestion.

• Pour un serveur radius, si l'autorisation dynamique est activée, la connectivité du serveur AAA doit être assurée par une interface et non par le routage dynamique. Si ASAune configuration est trouvée avec un serveur AAA dont l'autorisation dynamique est activée sans interface, l'outil de migration Secure Firewall ignore l'autorisation dynamique. Vous devez activer manuellement l'autorisation dynamique après avoir choisi une interface dans le centre de gestion.

• La configuration de ASApeut avoir une interface tout en appelant l'ensemble des adresses sous le groupe tunnel. Mais la même chose n'est pas supportée dans le centre de gestion. Si une interface est détectée dans la configuration ASA, elle est ignorée par l'outil de migration Secure Firewall et l'ensemble des adresses est migré sans l'interface.

• ASA peut avoir un mot-clé link-selection/subnet-selection pour le serveur dhcp sous le groupe de tunnels. Mais la même chose n'est pas supportée dans le centre de gestion. Si un serveur dhcp est détectée dans la configuration ASA avec ces mots-clés, cela est ignoré par l'outil de migration Secure Firewall et le serveur dhcp est transféré sans les mots-clés

• La configuration ASApeut avoir une interface tout en appelant le groupe de serveurs d'authentification, le groupe de serveurs d'authentification secondaire, le groupe de serveurs d'autorisation sous le groupe de tunnels. Mais la même chose n'est pas supportée dans le centre de gestion. Si une interface est détectée dans la configuration ASA, elle est ignorée par l'outil de migration Secure Firewall et les commandes sont transférés sans l'interface.

• La configuration ASAn'associe pas Redirect ACL à un serveur radius. Donc, il est impossible de le récupérer à partir de l'outil de migration Secure Firewall. Si rediriger l'ACL est utilisé dans ASA, cela est donc laissé vide et vous devez ajouter et l'associer manuellement dans le centre de gestion.

• ASA supporte une valeur de 0 - 720 pour le délai de réutilisation locale de vpn-addr-assign. Mais le centre de gestion supporte une valeur de 0 - 480. Si une valeur plus haute que 480 est trouvée dans la configuration de ASA, elle est réglée à la valeur supportée maximum de 480 dans le centre de gestion.

• La configuration de l'ensemble IPv4 et des paramètres DHCP useSecondaryUsernameforSession dans le profil de connexion n'est pas prise en charge en raison de problèmes d'API.

• L'option de contournement du contrôle d'accès sysopt permit-vpn n'est pas activée dans le cadre de la politique AD VPN. Par contre, si nécessaire, vous pouvez l'activer à partir du centre de gestion.

• Les valeurs du module client AnyConnect et du profil peuvent être mises à jour dans le cadre de la stratégie de groupe uniquement lorsque les profils sont téléchargés depuis l'outil de migration Secure Firewall vers le centre de gestion.

• Vous devez associer les certificats directement dans le centre de gestion.

• Les paramètres IKEv2 ne sont pas migrés par défaut. Vous devez les ajouter dans le centre de gestion.

Lignes directrices pour la migration vers l'ASA

La migration de l'option de journalisation ACL suit les meilleures pratiques pour Défense contre les menaces. L'option de journalisation pour une règle est activée ou désactivée selon la configuration de la source ASA Pour les règles dont l'action est le refus, l'outil de migration Secure Firewall configure la journalisation au début de la connexion. Si l'action est la permission, l'outil de migration Secure Firewall configure la journalisation à la fin de la connexion.

Lignes directrices pour la migration d'objets

et défense contre les menaces ont des lignes directrices de configuration différentes pour les objets. Par exemple, un ou plusieurs objets peuvent avoir le même nom dans avec un nom d'objet en minuscule et l'autre nom d'objet en majuscule, mais chaque objet doit avoir un nom unique, peu importe le scénario dans défense contre les menaces Pour accommoder de telles différences, l'outil de migration Secure Firewall analyse tous les objets et s'occupe de leur migration d'une des manières suivantes :

• Chaque objet a un nom et une configuration unique — L'outil de migration Secure Firewall migre les objets avec succès sans changements.

• Le nom d'un objet inclut un ou plusieurs caractères spéciaux qui ne sont pas supportés par le centre de gestion— L'outil de migration Secure Firewall renomme les caractères spéciaux dans le nom de l'objet avec un caractère « _ » pour rencontrer le critère de dénomination d'objets du centre de gestion.

• Un objet a le même nom et configuration qu'un objet existant dans le centre de gestion— L'outil de migration Cisco Secure Firewall Management CenterSecure Firewall réutilise l'objet pour la Cisco Secure Firewall Threat Defenseconfiguration et ne migre pas l'objet.

• Un objet a le même nom mais une configuration différente d'un objet existant Cisco Secure Firewall Management Centerdans — L'outil de migration Secure Firewall rapporte un conflit d'objet et vous permet de résoudre le conflit en ajoutant un suffixe unique au nom de l'objet pour des besoins de migration.

• De multiples objets ont le même nom mais dans des scénarios différents — L'outil de migration Secure Firewall renomme de tels objets pour rencontrer le Cisco Secure Firewall Threat Defensecritère de dénomination de l'objet

Important

L'outil de migration Secure Firewall analyse le nom et la configuration de tous les objets et groupes d'objets. Par contre, les profils XML dans les configurations VPN d'accès à distance sont analysés uniquement par le nom.

Remarque

L'outil de migration Secure Firewall prend en charge la migration d'objets de masques de réseau discontigus (masques Wildcard) si le Centre de gestion du pare-feu de destination est la version 7.1 ou une version ultérieure.

ASA example: 
object network wildcard2
subnet 2.0.0.2 255.0.0.255

Lignes directrices et limites relatives aux appareils Défense contre les menaces

Lorsque vous prévoyez de migrer votre configuration ASAvers défense contre des menaces, tenez compte des lignes directrices et des limitations suivantes :

• S'il existe des configurations spécifiques à l'appareil, telles que défense contre des menaces des routes, des interfaces, etc., lors de la migration push, l'outil de migration Secure Firewall nettoie automatiquement l'appareil et remplace la configuration ASA.

  Remarque

  Afin de prévenir toute perte indésirable de données de l'appareil (cible défense contre des menaces), nous vous recommandons de nettoyer manuellement l'appareil avant la migration.

  Durant la migration, l'outil de migration Secure Firewall réinitialise la configuration de l'interface. Si vous utilisez ces interfaces dans des politiques, l'outil de migration Secure Firewall ne peut pas les réinitialiser et ainsi donc, la migration échoue.

• L'outil de migration Secure Firewall peut créer des sous-interfaces sur l'instance native de l'appareil défense contre des menacesen fonction de la ASAconfiguration de . Créez manuellement des interfaces et de interfaces de canaux de port sur l'appareil défense contre des menacescible avant de débuter la migration Par exemple, si votre configuration ASA est affectée aux interfaces et canaux de port suivants, vous devez les créer sur le dispositif défense contre des menaces cible avant la migration :

  • Cinq interfaces physiques

  • Cinq canaux de port

  • Deux interfaces de gestion uniquement

  Remarque

  Pour les instances de conteneurs de dispositifs défense contre des menaces, les sous-interfaces ne sont pas créées par l'outil de migration Secure Firewall, seul le mappage d'interface est autorisé.

• L'outil de migration Secure Firewall peut créer des sous-interfaces et des interfaces virtuelles Bridge-Group (mode transparent) sur défense contre des menacesl'instance native du dispositif basé sur la configuration ASA. Créez manuellement des interfaces et de interfaces de canaux de port sur l'appareil défense contre des menacescible avant de débuter la migration Par exemple, si votre configuration ASA est affectée aux interfaces et canaux de port suivants, vous devez les créer sur le dispositif défense contre des menaces cible avant la migration :

  • Cinq interfaces physiques

  • Cinq canaux de port

  • Deux interfaces de gestion uniquement

  Remarque

  Pour les instances de conteneurs de dispositifs défense contre des menaces, les sous-interfaces ne sont pas créées par l'outil de migration Secure Firewall, seul le mappage d'interface est autorisé.

Centre de gestion

Le centre de gestion est un puissant gestionnaire multi-appareils basé sur le Web qui fonctionne sur son propre matériel de serveur, ou comme un appareil virtuel sur un hyperviseur. Vous pouvez utiliser le centre de gestion sur site et le centre de gestion virtuel comme centre de gestion cible pour la migration.

Le centre de gestion devrait rencontrer les critères suivants pour la migration :

• La version du logiciel du Centre de gestion qui est prise en charge pour la migration, comme décrit dans Versions logicielles prises en charge pour la migration.

• Vous avez obtenu et installé des licences intelligentes défense contre des menacesqui incluent toutes les fonctionnalités que vous prévoyez de migrer depuis l'interface ASA , comme décrit ci-dessous :

  • La section Mise en route du compte Smart de Cisco sur Cisco.com

  • Enregistrez le Centre de gestion du pare-feu avec le Cisco Smart Software Manager.

  • Octroi de licences pour le système de pare-feu

  • Vous avez activé l’API REST.centre de gestion

    Astuces

    Sur l'interface web centre de gestion, naviguez vers. Configuration du > système > Préférences Rest API > Activer Rest APIet cocher la case Activer Rest API.

  • Vous avez créé un utilisateur dédié avec des privilèges REST centre de gestionAPI pour l'outil de migration Secure Firewall, comme décrit dans Comptes d'utilisateur pour l'accès à la gestion .

Cloud-Delivered Firewall Management Center (centre de gestion de pare-feu en nuage)

Le centre de gestion de pare-feu, disponible dans le nuage, est une plateforme de gestion pour les dispositifs de défense contre les menaces et est fourni par Cisco Defense Orchestrator Le centre de gestion de pare-feu en nuage offre un grand nombre de fonctions identiques à celles d'un centre de gestion.

Vous pouvez accéder au centre de gestion des pare-feux dans le nuage à partir de CDO. Le CDO se connecte au centre de gestion des pare-feux en nuage par l'intermédiaire du Secure Device Connector (SDC). Pour plus d'informations sur le centre de gestion des pare-feux dans le nuage, voir Gestion des périphériques Cisco Secure Firewall Threat Defense avec le centre de gestion des pare-feux dans le nuage.

L'outil de migration Secure Firewall prend en charge le centre de gestion de pare-feu fourni dans le nuage en tant que centre de gestion de destination pour la migration. Pour sélectionner le centre de gestion de pare-feu fourni par le cloud comme centre de gestion de destination pour la migration, vous devez ajouter la région CDO et générer le jeton API à partir du portail CDO.