Dépannage des problèmes courants de VPN IPsec L2L et d'accès distant
Contenu
Introduction
Ce document contient les solutions les plus courantes aux problèmes de VPN IPsec. Ces solutions viennent directement de demandes de service que l'assistance technique Cisco a résolu. Beaucoup de ces solutions peuvent être mises en application avant le dépannage approfondi d'une connexion VPN IPsec. En conséquence, ce document fournit une liste de contrôle des procédures courantes à essayer avant de commencer le dépannage d'une connexion et d'appeler l'assistance technique Cisco.
Si vous avez besoin de documents donnant des exemples de configuration pour le VPN de site-à-site et le VPN d'accès à distance, référez-vous aux sections VPN d'accès à distance, VPN de site à site (L2L) avec PIX, VPN de site à site (L2L) avec IOS, et VPN de site à site (L2L) avec VPN3000 de Exemples de configuration et Notes techniques.
Remarque : Même si les exemples de configuration de ce document sont destinés aux routeurs et aux appliances de sécurité, presque tous ces concepts sont également applicables au concentrateur VPN 3000.
Remarque : reportez-vous à Dépannage de la sécurité IP - Compréhension et utilisation des commandes de débogage pour fournir une explication des commandes de débogage courantes utilisées pour résoudre les problèmes IPsec sur le logiciel Cisco IOS® et PIX.
Remarque : ASA/PIX ne transmettra pas le trafic de multidiffusion sur les tunnels VPN IPsec.
Remarque : Vous pouvez rechercher n'importe quelle commande utilisée dans ce document à l'aide de l'outil de recherche de commandes (clients enregistrés uniquement).
Avertissement : La plupart des solutions présentées dans ce document peuvent entraîner une perte temporaire de toute la connectivité VPN IPsec sur un périphérique. Il est recommandé de mettre en application ces solutions avec prudence et selon votre politique de contrôle de modification.
Conditions préalables
Conditions requises
Cisco recommande que vous connaissiez la configuration de VPN IPsec sur ces périphériques Cisco :
-
Dispositif de sécurité de la gamme Cisco PIX 500
-
Dispositif de sécurité de la gamme Cisco ASA 5500
-
Routeurs Cisco IOS
-
Concentrateurs de la gamme Cisco VPN 3000 (facultatif)
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
-
Dispositif de sécurité de la gamme Cisco ASA 5500
-
Dispositif de sécurité de la gamme Cisco PIX 500
-
Cisco IOS
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
La configuration de VPN IPsec ne fonctionne pas
Problème
Une solution VPN IPsec récemment configurée ou modifiée ne fonctionne pas.
Une configuration actuelle de VPN IPsec ne fonctionne plus.
Solutions
Cette section contient des solutions pour les problèmes de VPN IPsec les plus courants. Bien qu'elles ne soient mentionnées dans aucun ordre particulier, ces solutions peuvent être utilisées comme une liste de contrôle des éléments à vérifier ou à essayer avant que vous engagiez un dépannage approfondi et appeliez le TAC. Toute ces solutions viennent directement de demandes de service au TAC et ont résolu de nombreux problèmes clients.
-
Effacer des associations de sécurité anciennes ou existantes (tunnels)
-
Vérifier que les commandes sysopt sont présentes (PIX/ASA seulement)
-
Vérifiez si les ACL sont exacts et liés à la carte de chiffrement.
-
Vérifier les numéros et le nom de la séquence de la carte de chiffrement
Remarque : certaines des commandes de ces sections ont été déplacées vers une deuxième ligne en raison de considérations d'espace.
Activer NAT-Traversal (problème #1 de VPN RA)
Nat-Traversal ou NAT-T permet au trafic VPN de passer par des périphériques NAT ou PAT, tels qu'un routeur Linksys SOHO. Si NAT-T n'est pas activé, les utilisateurs de client VPN semblent souvent se connecter au PIX ou à l'ASA sans problème, mais ils ne peuvent pas accéder au réseau interne derrière le dispositif de sécurité.
Si vous n'activez pas NAT-T dans le périphérique NAT/PAT, vous pouvez recevoir le message d'erreur regular translation creation failed for protocol 50 src inside:10.0.1.26 dst outside:10.9.69.4 dans le PIX/ASA.
De même, si vous ne pouvez pas ouvrir plusieurs sessions simultanées depuis la même adresse IP, le message d'erreur Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding. apparaît. Activez NAT-T dans le périphérique VPN de tête de réseau afin de résoudre cette erreur.
Remarque : avec le logiciel Cisco IOS version 12.2(13)T et ultérieure, NAT-T est activé par défaut dans Cisco IOS.
Voici la commande pour activer NAT-T sur un dispositif de sécurité Cisco. Le 20 dans cet exemple est la durée de keepalive (par défaut).
PIX/ASA 7.1 et antérieur
pix(config)#isakmp nat-traversal 20
PIX/ASA 7.2(1) et ultérieur
securityappliance(config)#crypto isakmp nat-traversal 20
Les clients ont aussi besoin d'être modifiés afin que cela fonctionne.
Dans le Client VPN Cisco, choisissez Connection entries et cliquez sur Modify. Une nouvelle fenêtre s'ouvre dans laquelle vous devez choisir l'onglet Transport. Sous cet onglet, choisissez Enable Transparent Tunneling et la case d'option IPSec over UDP (NAT/PAT). Cliquez alors sur Save et testez la connexion.
Remarque : cette commande est identique pour PIX 6.x et PIX/ASA 7.x.
Remarque : Il est important d'autoriser l'UDP 4500 pour les ports NAT-T, UDP 500 et ESP par la configuration d'une liste de contrôle d'accès car PIX/ASA agit en tant que périphérique NAT. Référez-vous à Configuration d'un tunnel IPsec par un pare-feu avec NAT pour plus d'informations afin d'en savoir plus sur la configuration d'un ACL dans PIX/ASA.
Concentrateur VPN
Choisissez Configuration > Tunneling and Security > IPSEC > NAT Transparency > Enable : IPsec supérieur à NAT-T afin d'activer NAT-T sur le concentrateur VPN.
Remarque : NAT-T permet également à plusieurs clients VPN de se connecter simultanément via un périphérique PAT à n'importe quelle tête de réseau, qu'il s'agisse de PIX, de routeur ou de concentrateur.
Tester correctement la connectivité
Dans l'idéal, la connectivité VPN est testée à partir de périphériques derrière les périphériques qui font le cryptage, pourtant de nombreux utilisateurs testent la connectivité de VPN avec la commande ping sur les périphériques qui font le cryptage. Alors que le ping fonctionne généralement à cet effet, il est important que la source de votre ping vienne de la bonne interface. Si l'origine du ping est mal déterminée, il peut apparaître un échec de la connexion VPN alors qu'en fait cela fonctionne. Prenez ce scénario comme exemple :
ACL de chiffrement routeur A
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
ACL de chiffrement routeur B
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Dans cette situation, l'origine d'un ping doit être déterminée à l'« intérieur » du réseau derrière l'un ou l'autre routeur. Cela est nécessaire, parce que les ACL de chiffrement sont seulement configurés pour crypter le trafic avec ces adresses sources. Un ping dont la source vient d'interfaces Internet de l'un ou l'autre routeur n'est pas crypté. Utilisez les options étendues de la commande ping dans le mode EXEC privilégié pour déterminer la source d'un ping depuis l'interface « interne » d'un routeur :
routerA#ping Protocol [ip]: Target IP address: 192.168.200.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.100.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds: Packet sent with a source address of 192.168.100.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = ½/4 ms
Imaginez que les routeurs dans ce diagramme ont été remplacés par des dispositifs de sécurité PIX ou ASA. Le ping utilisé pour tester la connectivité peut également provenir de l'interface interne avec le mot clé inside :
securityappliance#ping inside 192.168.200.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Remarque : Il n'est pas recommandé de cibler l'interface interne d'un dispositif de sécurité avec votre requête ping. Si vous devez cibler l'interface interne avec votre ping, vous devez activer management-access sur cette interface ou bien le dispositif ne répond pas.
securityappliance(config)#management-access inside
Remarque : lorsqu'il existe un problème de connectivité, même la phase 1 du VPN ne s'active pas. Sur l'ASA, si la connectivité échoue, la sortie SA est semblable à cet exemple, ce qui indique probablement une configuration de l'homologue de chiffrement incorrecte et/ou une configuration de proposition ISAKMP incorrecte :
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2
Note : L'état peut être de MM_WAIT_MSG2 à MM_WAIT_MSG5, ce qui indique un échec de l'échange d'état concerné en mode principal (MM).
Remarque : La sortie de l'association de sécurité Crypto lorsque la phase 1 est terminée est similaire à cet exemple :
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Activer ISAKMP
S'il n'y a aucune indication qu'un tunnel VPN IPsec monte tunnel s'établit, c'est probablement dû au fait qu'ISAKMP n'a pas été activé. Soyez sûr que vous avez activé ISAKMP sur vos périphériques. Utilisez l'une de ces commandes pour activer ISAKMP sur vos périphériques :
-
Cisco IOS
router(config)#crypto isakmp enable
-
Cisco PIX 7.1 et antérieur (remplacez outside par votre interface désirée)
pix(config)#isakmp enable outside
-
Cisco PIX/ASA 7.2(1) et antérieur (remplacez outside par votre interface désirée)
securityappliance(config)#crypto isakmp enable outside
Vous pouvez également obtenir cette erreur quand vous activez ISAKMP sur l'interface externe :
UDP: ERROR - socket <unknown> 62465 in used ERROR: IkeReceiverInit, unable to bind to port
La cause de l'erreur peut venir du fait que le client derrière l'ASA/PIS est soumis à un PAT au port UDP 500 avant qu'isakmp ne puisse être activé sur l'interface. Une fois que cette traduction PAT retirée (clear xlate), isakmp peut être activé.
Remarque : assurez-vous toujours que les numéros de port UDP 500 et 4500 sont réservés à la négociation des connexions ISAKMP avec l'homologue.
Remarque : lorsque ISAKMP n'est pas activé sur l'interface, le client VPN affiche un message d'erreur similaire à ce message :
Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding
Remarque : afin de résoudre cette erreur, activez le protocole ISAKMP sur l'interface de chiffrement de la passerelle VPN.
Activer/Désactiver PFS
Dans des négociations IPsec, le Perfect Forward Secrecy (PFS) assure que chacune nouvelle clé cryptographique est indépendante de toute clé précédente. Activez ou désactivez PFS sur les deux homologues du tunnel ; sinon, le tunnel IPsec LAN-à-LAN (L2L) n'est pas établi dans le routeur PIX/ASA/IOS.
PIX/ASA :
PFS est désactivé par défaut. Afin d'activer PFS, utilisez la commande pfs avec le mot clé enable en mode de configuration de stratégie de groupe. Afin de désactiver PFS, saisissez le mot clé disable.
hostname(config-group-policy)#pfs {enable | disable}
Afin de retirer l'attribut PFS de la configuration en cours, saisissez la forme no de cette commande. Une stratégie de groupe peut hériter d'une valeur pour PFS d'une autre stratégie de groupe. Saisissez la forme no de cette commande afin d'éviter d'hériter d'une valeur.
hostname(config-group-policy)#no pfs
Routeur IOS :
Afin de spécifier qu'IPsec doit demander le PFS quand de nouvelles associations de sécurité sont demandées pour cette entrée de la carte de chiffrement ou qu'IPsec requiert le PFS quand il reçoit des demandes de nouvelles associations de sécurité, utilisez la commande set pfs en mode configuration de carte de chiffrement. Afin de spécifier qu'IPsec ne doit pas demander le PFS, utilisez la forme no de cette commande. Par défaut, PFS n'est pas demandé. Si aucun groupe n'est spécifié avec cette commande, group1 est utilisé par défaut.
set pfs [group1 | group2] no set pfs
Pour la commande set pfs :
-
group1 — Spécifie qu'IPsec doit utiliser le groupe modulaire de nombres premiers 768 bits Diffie-Hellman quand le nouvel échange Diffie-Hellman est exécuté.
-
group2 : indique qu'IPsec doit utiliser le groupe de modules principaux Diffie-Hellman 1 024 bits lorsque le nouvel échange Diffie-Hellman est effectué.
Exemple :
Router(config)#crypto map map 10 ipsec-isakmp Router(config-crypto-map)#set pfs group2
Remarque : Perfect Forward Secrecy (PFS) est une propriété de Cisco et n'est pas pris en charge sur les périphériques tiers.
Effacer des associations de sécurité anciennes ou existantes (tunnels)
Si ce message d'erreur se produit dans le routeur IOS, le problème est que la SA a expiré ou a été effacée. Le périphérique de tunnel distant ne sait pas qu'il utilise la SA qui a expirée pour envoyer un paquet (pas un paquet d'établissement de SA). Quand une nouvelle SA a été établie, la communication reprend, initiant ainsi le trafic intéressant à travers le tunnel pour créer une nouvelle SA et rétablir le tunnel.
%CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x has no SA
Si vous effacez les associations de sécurité (SA) ISAKMP (phase I) et IPsec (phase II), la meilleure solution et la plus simple est de résoudre les problèmes IPsec des VPN.
Si vous effacez des SA, vous pouvez fréquemment résoudre une grande variété de messages d'erreur et de comportements étranges sans nécessité de dépanner. Tandis que cette technique peut facilement être utilisée dans n'importe quelle situation, c'est presque toujours une condition d'effacer des SA après avoir fait des changements ou des ajouts dans la configuration VPN IPsec actuelle. De plus, alors qu'il est possible d'effacer uniquement des associations de sécurité spécifiques, le plus grand avantage peut venir du moment où vous effacer l'ensemble des SA sur le périphérique.
Remarque : Une fois que les associations de sécurité ont été effacées, il peut être nécessaire d'envoyer du trafic à travers le tunnel pour les rétablir.
Avertissement : sauf si vous spécifiez les associations de sécurité à effacer, les commandes répertoriées ici peuvent effacer toutes les associations de sécurité sur le périphérique. Procédez avec prudence si d'autres tunnels VPN IPsec sont en service.
-
Afficher les associations de sécurité avant de les effacer
-
Cisco IOS
router#show crypto isakmp sa router#show crypto ipsec sa
-
Dispositifs de sécurité Cisco PIX/ASA
securityappliance#show crypto isakmp sa securityappliance#show crypto ipsec sa
Remarque : ces commandes sont identiques pour Cisco PIX 6.x et PIX/ASA 7.x
-
-
Effacez les associations de sécurité. Chaque commande peut être saisie comme indiqué en gras ou avec les options montrées avec elles.
-
Cisco IOS
-
ISAKMP (phase I)
router#clear crypto isakmp ? <0 - 32766> connection id of SA <cr>
-
IPsec (phase II)
router#clear crypto sa ? counters Reset the SA counters map Clear all SAs for a given crypto map peer Clear all SAs for a given crypto peer spi Clear SA by SPI <cr>
-
-
Dispositifs de sécurité Cisco PIX/ASA
-
ISAKMP (phase I)
securityappliance#clear crypto isakmp sa
-
IPsec (phase II)
security appliance#clear crypto ipsec sa ? counters Clear IPsec SA counters entry Clear IPsec SAs by entry map Clear IPsec SAs by map peer Clear IPsec SA by peer <cr>
-
-
Vérifier la durée de vie d'ISAKMP
Si les utilisateurs sont fréquemment déconnectés à travers le tunnel L2L, le problème peut être la durée de vie moindre configurée dans la SA ISAKMP. Si une divergence quelconque se produit dans la durée de vie d'ISAKMP, vous pouvez recevoir le message d'erreur %PIX|ASA-5-713092: Group = x.x.x.x, IP = x.x.x.x, Failure during phase 1 rekeying attempt due to collision dans PIX/ASA. Pour FWSM, vous pouvez recevoir le message d'erreur %FWSM-5-713092: Group = x.x.x.x, IP = x.x.x.x, Failure during phase 1 rekeying attempt due to collision. Configurez la même valeur dans les deux homologues afin de résoudre le problème.
La valeur par défaut est 86 400 secondes ou 24 heures. En règle générale, une durée de vie plus courte fournit des négociations ISAKMP plus sécurisées (jusqu'à un point), mais, avec des durées de vie plus courtes, le dispositif de sécurité installe plus rapidement les futures SA IPsec.
Une correspondance est établie quand les stratégies des deux homologues contiennent des valeurs identiques de cryptage, de hachage, d'authentification et de paramètre Diffie-Hellman, et quand la stratégie de l'homologue distant spécifie une durée de vie inférieure ou égale à la durée de vie dans la stratégie comparée. Si les durées de vie ne sont pas identiques, la durée de vie plus courte — provenant de la stratégie de l'homologue distant — est utilisée. Si aucune correspondance acceptable n'est trouvée, l'IKE refuse la négociation et la SA IKE n'est pas établie.
Spécifiez la durée de vie de la SA. Cet exemple définit une durée de vie de 4 heures (14 400 secondes). La valeur par défaut est 86 400 secondes (24 heures).
PIX/ASA
hostname(config)#isakmp policy 2 lifetime 14400
Routeur IOS
R2(config)#crypto isakmp policy 10 R2(config-isakmp)#lifetime 86400
Si la durée de vie maximale configurée est dépassée, vous recevez ce message d'erreur quand la connexion VPN est terminée :
Secure VPN Connection terminated locally by the Client. Reason 426: Maximum Configured Lifetime Exceeded.
Afin de résoudre ce message d'erreur, définissez la valeur lifetime à 0 afin de définir la durée de vie d'une association de sécurité IKE à l'infini. Le VPN sera toujours connecté et ne s'arrêtera pas.
hostname(config)#isakmp policy 2 lifetime 0
Vous pouvez également désactiver re-xauth dans la stratégie de groupe afin de résoudre le problème.
Activer ou désactiver les Keepalives d'ISAKMP
Si vous configurez les keepalives d'ISAKMP, cela aide à éviter des VPN LAN-à-LAN ou d'accès à distance sporadiquement abandonnés, ce qui inclut des clients VPN, des tunnels et les tunnels qui sont abandonnés après une période d'inactivité. Cette fonctionnalité laisse le périphérique du tunnel surveiller la présence continue d'un homologue distant et enregistre sa propre présence auprès de cet homologue. Si l'homologue ne répond plus, le périphérique supprime la connexion. Pour que les keepalives d'ISAKMP fonctionnent, les deux périphériques VPN doivent les prendre en charge.
-
Configurez les keepalives d'ISAKMP dans Cisco IOS avec cette commande :
router(config)#crypto isakmp keepalive 15
-
Utilisez ces commandes pour configurer les keepalives d'ISAKMP sur les dispositifs de sécurité PIX/ASA :
-
Cisco PIX 6.x
pix(config)#isakmp keepalive 15
-
Cisco PIX/ASA 7.x et ultérieur, pour le groupe de tunnels nommé 10.165.205.222
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive threshold 15 retry 10
Dans certaines situations, il est nécessaire de désactiver cette fonctionnalité afin de résoudre le problème, par exemple, si le client VPN est derrière un pare-feu qui bloque les paquets DPD.
Cisco PIX/ASA 7.x et ultérieur, pour le groupe de tunnels nommé 10.165.205.222
Désactive le traitement du keepalive IKE qui est activé par défaut.
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive disable
Désactiver Keepalive pour un client Cisco VPN 4.x
Choisissez %System Root% > Program Files > Cisco Systems >VPN Client > Profiles sur le PC client qui rencontre le problème afin de désactiver le keepalive IKE et modifier le fichier PCF, le cas échéant, pour la connexion.
Remplacez 'ForceKeepAlives=0' (valeur par défaut) par 'ForceKeepAlives=1'.
-
Remarque : les keepalives sont propriétaires de Cisco et ne sont pas pris en charge par des périphériques tiers.
Ressaisir ou récupérer les clés pré-partagées
Dans de nombreux cas, une simple erreur typographique peut être à blâmer quand un tunnel VPN IPsec tunnel ne fonctionne pas. Par exemple, sur le dispositif de sécurité, les clés pré-partagées deviennent masquées une fois qu'elles sont saisies. Cette obfuscation rend impossible de voir si une clé est incorrecte.Assurez-vous que vous avez entré des clés pré-partagées correctement sur chaque point d'extrémité VPN. Ressaisissez une clé pour être certain qu'elle soit correcte ; c'est une solution simple qui peut aider à éviter un dépannage approfondi.
Dans le VPN d'accès à distance, vérifiez que le nom de groupe valide et la clé pré-partagée sont saisis dans le client VPN Cisco. Vous pouvez rencontrer cette erreur si le nom de groupe/la clé pré-partagée ne correspondent pas entre le client VPN et le périphérique de tête de réseau.
1 12:41:51.900 02/18/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 2 12:41:51.900 02/18/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed 3 14:37:50.562 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 4 14:37:50.593 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202) 5 14:44:15.937 10/05/06 Sev=Warning/2 IKE/0xA3000067 Received Unexpected InitialContact Notify (PLMgrNotify:888) 6 14:44:36.578 10/05/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 7 14:44:36.593 10/05/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed... may be configured with invalid group password. 8 14:44:36.609 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 9 14:44:36.640 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202)
Vous pouvez également récupérer une clé pré-partagée sans changement dans la configuration sur le dispositif de sécurité PIX/ASA. Référez-vous à PIX/ASA 7.x : Récupération de clé pré-partagée.
Avertissement : si vous supprimez des commandes liées au chiffrement, vous risquez de supprimer un ou tous vos tunnels VPN. Utilisez ces commandes avec prudence et référez-vous à la politique de contrôle de modification de votre organisation avant de suivre ces étapes.
-
Utilisez ces commandes pour supprimer et ressaisir la clé pré-partagée secretkey pour l'homologue 10.0.0.1 ou le groupe vpngroup dans IOS :
-
VPN Cisco de LAN-à-LAN
router(config)#no crypto isakmp key secretkey address 10.0.0.1 router(config)#crypto isakmp key secretkey address 10.0.0.1
-
VPN Cisco d'accès à distance
router(config)#crypto isakmp client configuration group vpngroup router(config-isakmp-group)#no key secretkey router(config-isakmp-group)#key secretkey
-
-
Utilisez ces commandes pour supprimer et ressaisir la clé pré-partagée secretkey de pour l'homologue 10.0.0.1 sur des dispositifs de sécurité PIX/ASA :
-
Cisco PIX 6.x
pix(config)#no isakmp key secretkey address 10.0.0.1 pix(config)#isakmp key secretkey address 10.0.0.1
-
Cisco PIX/ASA 7.x et ultérieur
securityappliance(config)#tunnel-group 10.0.0.1 ipsec-attributes securityappliance(config-tunnel-ipsec)#no pre-shared-key securityappliance(config-tunnel-ipsec)#pre-shared-key secretkey
-
Clé pré-partagée non correspondante
L'initiation du tunnel VPN se déconnecte. Ce problème peut se produire en raison d'une clé pré-partagée non correspondante pendant I des négociations.
Le message MM WAIT MSG 6 dans la commande show crypto isakmp sa indique une clé prépartagée mal jumelée, comme illustré dans l'exemple suivant :
ASA#show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.7.13.20
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG_6
Afin de résoudre ce problème, ressaisissez la clé pré-partagée dans les deux dispositifs ; la clé pré-partagée doit être unique et doit correspondre. Voyez Ressaisir ou récupérer les clé pré-partagées pour plus d'informations.
Supprimer et ré-appliquer des cartes de chiffrement
Quand vous effacez les associations de sécurité et que cela ne résout pas le problème de IPsec de VPN, retirez et réappliquez la carte de chiffrement pertinente pour résoudre un large éventail de problèmes, y compris les interruptions intermittentes du tunnel VPN et l'échec d'activation de quelques sites VPN.
Avertissement : Si vous supprimez une carte de chiffrement d'une interface, elle supprime définitivement tous les tunnels IPsec associés à cette carte de chiffrement. Suivez ces étapes avec prudence et tenez compte de la politique de contrôle de modification de votre organisation avant de commencer.
-
Utilisez ces commandes pour supprimer une carte de chiffrement dans Cisco IOS :
Commencez en supprimant la carte de chiffrement de l'interface. Utilisez la forme no de la commande crypto map.
router(config-if)#no crypto map mymap
Continuez à utiliser la forme no pour supprimer une carte de chiffrement entière.
router(config)#no crypto map mymap 10
Remplacez la carte de chiffrement sur l'interface Ethernet0/0 pour l'homologue 10.0.0.1. Cet exemple montre la configuration minimale requise de la carte de chiffrement :
router(config)#crypto map mymap 10 ipsec-isakmp router(config-crypto-map)#match address 101 router(config-crypto-map)#set transform-set mySET router(config-crypto-map)#set peer 10.0.0.1 router(config-crypto-map)#exit router(config)#interface ethernet0/0 router(config-if)#crypto map mymap
-
Utilisez ces commandes pour supprimer et remplacer une carte de chiffrement sur le PIX ou l'ASA :
Commencez en supprimant la carte de chiffrement de l'interface. Utilisez la forme no de la commande crypto map.
securityappliance(config)#no crypto map mymap interface outside
Continuez à utiliser la forme no pour supprimer les autres commandes crypto map.
securityappliance(config)#no crypto map mymap 10 match address 101 securityappliance(config)#no crypto map mymap set transform-set mySET securityappliance(config)#no crypto map mymap set peer 10.0.0.1
Remplacez la carte de chiffrement pour l'homologue 10.0.0.1. Cet exemple montre la configuration minimale requise de la carte de chiffrement :
securityappliance(config)#crypto map mymap 10 ipsec-isakmp securityappliance(config)#crypto map mymap 10 match address 101 securityappliance(config)#crypto map mymap 10 set transform-set mySET securityappliance(config)#crypto map mymap 10 set peer 10.0.0.1 securityappliance(config)#crypto map mymap interface outside
Remarque : si vous supprimez et réappliquez la carte de chiffrement, cela résout également le problème de connectivité si l'adresse IP de l'extrémité principale a été modifiée.
Vérifier que les commandes sysopt sont présentes (PIX/ASA seulement)
Les commandes sysopt connection permit-ipsec et sysopt connection permit-vpn permettent à des paquets d'un tunnel IPsec et à leurs charges utiles de sauter les ACL d'interface sur le dispositif de sécurité. Les tunnels IPsec qui se terminent sur le dispositif de sécurité sont susceptibles d'échouer si l'une de ces commandes n'est pas activée.
Dans le logiciel du dispositif de sécurité version 7.0 et antérieure, la commande sysopt adéquate pour cette situation est sysopt connection permit-ipsec.
Dans le logiciel du dispositif de sécurité version 7.1(1) et ultérieure, la commande sysopt adéquate pour cette situation est sysopt connection permit-vpn.
Dans PIX 6.x, cette fonctionnalité est désactivée par Default. Avec PIX/ASA 7.0(1) et ultérieur, cette fonctionnalité est activée par défaut. Utilisez ces commandes show pour déterminer si la commande sysopt adéquate est activée sur votre périphérique :
-
Cisco PIX 6.x
pix# show sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret no sysopt uauth allow-http-cache no sysopt connection permit-ipsec !--- sysopt connection permit-ipsec is disabled no sysopt connection permit-pptp no sysopt connection permit-l2tp no sysopt ipsec pl-compatible
-
Cisco PIX/ASA 7.x
securityappliance# show running-config all sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret sysopt connection permit-vpn !--- sysopt connection permit-vpn is enabled !--- This device is running 7.2(2)
Utilisez ces commandes afin d'activer la commande sysopt correcte pour votre périphérique :
-
Cisco PIX 6.x et PIX/ASA 7.0
pix(config)#sysopt connection permit-ipsec
-
Cisco PIX/ASA 7.1(1) et ultérieur
securityappliance(config)#sysopt connection permit-vpn
Remarque : Si vous ne souhaitez pas utiliser la commande sysopt connection, vous devez explicitement autoriser le trafic requis, qui est intéressant du trafic de la source à la destination, par exemple, du LAN du périphérique distant au LAN du périphérique local et le « port UDP 500 » pour l'interface externe du périphérique distant à l'interface externe du périphérique local, dans la liste de contrôle d'accès externe.
Vérifier l'identité d'ISAKMP
Si le tunnel IPsec du VPN échoue dans le cadre de la négociation IKE, la panne peut être attribuable soit au PIX, soit à l'incapacité du pair à reconnaître l'identité du pair. Quand deux homologues utilisent IKE pour établir des associations de sécurité IPsec, chaque homologue envoie son identité ISAKMP à l'homologue distant. Ils envoient leur adresse IP ou leur nom d'hôte selon la façon dont l'identité ISAKMP de chacun est paramétrée. Par défaut, l'identité ISAKMP de l'unité du pare-feu PIX est paramétrée sur l'adresse IP. En règle générale, paramétrez le dispositif de sécurité et les identités de ses homologues de la même manière pour éviter un échec de la négociation IKE.
Afin de faire en sorte que l'IP de la phase 2 soit envoyée à l'homologue, utilisez la commande isakmp identity dans le mode de configuration globale
crypto isakmp identity address !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with pre-shared key as authentication type
OU
crypto isakmp identity auto !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with ISAKMP negotiation by connection type; IP address for !--- preshared key or cert DN for certificate authentication.
OU
crypto isakmp identity hostname !--- Uses the fully-qualified domain name of !--- the host exchanging ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
Le tunnel VPN ne s'active pas après avoir déplacé la configuration de PIX à ASA à l'aide de l'outil de migration de configuration PIX/ASA; ces messages apparaissent dans le journal :
[IKEv1] : Groupe = x.x.x.x, IP = x.x.x.x,Stale PeerTblEntry found, removing! (saisie périmée PeerTblEntry retrouvée, retrait en cours!) [IKEv1] : Groupe = le x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match! (Échec de retrait du pair de la table de corrélation, aucune correspondance!) [IKEv1] : Groupe = x.x.x.x, IP = x.x.x.x, construct_ipsec_delete() : Aucun SPI pour déterminer la SA de phase 2! [IKEv1] : Groupe = le x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match! (Échec de retrait du pair de la table de corrélation, aucune correspondance!)
Ce problème survient parce que le paramétrage de PIX par défaut est réglé pour identifier la connexion comme nom d'hôte ou ASA identifie en tant qu'IP. Afin de résoudre ce problème, utilisez la commande crypto isakmp identity en mode de configuration globale, comme affiché ci-dessous :
crypto isakmp identity hostname !--- Use the fully-qualified domain name of !--- the host exchanging ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
Quand vous recevez un message d'erreur Received an un-encrypted INVALID COOKIE (Réception d'un témoin non valide non chiffré), entrez la commande crypto isakmp identitiy address afin de résoudre le problème.
Remarque : La commande isakmp identity a été déconseillée de la version 7.2(1) du logiciel. Référez-vous à Référence de commandes des dispositifs de sécurité Cisco version 7.2 pour plus d'informations.
Vérifier le délai d'attente d'inactivité/de session
Si le délai d'attente d'inactivité est défini à 30 minutes (par défaut), cela signifie qu'il supprime le tunnel après 30 minutes sans trafic passant par celui-ci. Le client VPN est déconnecté au bout de 30 minutes indépendamment de la configuration du délai d'attente et rencontre l'erreur PEER_DELETE-IKE_DELETE_UNSPECIFIED.
Réglez le délai de mise en veille et le délai d'expiration de session à zéro afin de garder le tunnel activé en tout temps et d'assurer que celui-ci ne s'interrompt jamais, même avec l'utilisation d'appareils tiers.
PIX/ASA 7.x et ultérieur
Saisissez la commande vpn-idle-timeout dans le mode de configuration de la stratégie de groupe ou de configuration du nom d'utilisateur afin de configurer le délai d'attente de l'utilisateur :
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-idle-timeout none
Configurez une durée maximale pour des connexions de VPN avec la commande vpn-session-timeout dans le mode de configuration de la stratégie de groupe ou de configuration du nom d'utilisateur :
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-session-timeout none
Remarque : Lorsque vous avez tunnel-all configuré, vous n'avez pas besoin de configurer idle-timeout parce que, même si vous configurez VPN-idle timeout, il ne fonctionnera pas parce que tout le trafic passe par le tunnel (puisque tunnel-all est configuré). Par conséquent, le trafic pertinent (ou même le trafic généré par le PC) sera considéré comme intéressant, ce qui empêchera le passage au mode veille selon la période définie.
Routeur Cisco IOS
Utilisez la commande crypto ipsec security-association idle-time dans le mode de configuration globale ou de configuration de la carte de chiffrement afin de configurer le temporisateur d'attente de SA IPsec. Par défaut, les temporisateurs de SA IPsec sont désactivés.
crypto ipsec security-association idle-time seconds
La durée en seconds est celle qui est autorisée par le temporisateur pour qu'un homologue inactif puisse maintenir une SA. Les valeurs valides pour l'argument seconds sont comprises entre 60 et 86 400.
Vérifiez que les ACL sont exacts et liés à la carte de cryptage
Dans une configuration VPN IPsec classique, deux listes d'accès sont utilisées. L'une permet d'exempter le trafic destiné au tunnel VPN à partir du processus NAT, l'autre définit le trafic à crypter. Ceci inclut une ACL de chiffrement dans une configuration LAN-à-LAN ou une ACL transmission tunnel partagée dans une configuration d'accès à distance. Lorsque ces ACL ne sont pas correctement configurées ou qu'elles sont manquantes, le trafic risque de ne circuler que dans un seul sens dans le tunnel VPN ou de ne pas être envoyé du tout dans le tunnel.
Remarque : veillez à lier la liste de contrôle d'accès de chiffrement à la carte de chiffrement en utilisant la commande crypto map match address en mode de configuration globale.
Assurez-vous d'avoir configuré toutes les listes d'accès nécessaires pour réaliser votre configuration VPN IPsec et que ces listes d'accès définissent le trafic voulu. Cette liste contient les éléments simples à vérifier lorsque vous suspectez qu'une ACL est à l'origine des problèmes que vous rencontrez avec votre VPN IPsec.
-
Assurez-vous que votre exemption NAT et vos listes de contrôle d'accès de chiffrement spécifient le trafic voulu.
-
Si vous avez plusieurs tunnels VPN et ACL de chiffrement, assurez-vous que ces ACL ne se superposent pas.
Remarque : Sur le concentrateur VPN, vous pouvez voir un journal comme ceci :
Tunnel Rejected: IKE peer does not match remote peer as defined in L2L policy
Afin d'éviter ce message et de faire fonctionner le tunnel, assurez-vous que les ACL de chiffrement ne superposent pas et que le même trafic intéressant n'est utilisé par aucun autre tunnel VPN configuré.
-
N'utilisez pas une ACL deux fois. Même si vos listes de contrôle d'accès d'exemption NAT et de chiffrement indiquent le même trafic, utilisez deux listes d'accès différentes.
-
Pour la configuration d'accès à distance, n'utilisez pas de liste d'accès pour le trafic intéressant avec la carte de chiffrement dynamique. Ceci peut rendre le client VPN incapable de se connecter au périphérique de tête de réseau. Si vous avez configuré de manière erronée l'ACL de chiffrement pour le VPN d'accès à distance, vous pouvez obtenir le message d'erreur %ASA-3-713042: IKE Initiator unable to find policy: Intf 2.
Remarque : s'il s'agit d'un tunnel VPN site à site, assurez-vous de faire correspondre la liste d'accès à l'homologue. Ils doivent être en ordre inverse pour le pair.
-
Assurez-vous que votre périphérique est configuré pour utiliser la liste de contrôle d'accès d'exemption NAT : Sur un routeur, cela signifie que vous utilisez la commande route-map. Sur le PIX ou l'ASA, cela signifie que vous utilisez la commande nat (0). Une liste de contrôle d'accès d'exemption NAT est requise pour les configurations de LAN-à-LAN et les configurations d'accès à distance.
-
Ici, un routeur IOS est configuré pour exempter le trafic envoyé entre 192.168.100.0 /24 et 192.168.200.0 /24 ou 192.168.1.0 /24 depuis le NAT. Le trafic destiné à n'importe où ailleurs est soumis à la surcharge NAT :
access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 any route-map nonat permit 10 match ip address 110 ip nat inside source route-map nonat interface FastEthernet0/0 overload
-
Ici, un PIX est configuré pour exempter le trafic envoyé entre 192.168.100.0 /24 et 192.168.200.0 /24 ou 192.168.1.0 /24 depuis le NAT. Par exemple, tout autre trafic est soumis à la surcharge NAT :
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.255.0 nat (inside) 0 access-list noNAT nat (inside) 1 0.0.0.0 0.0.0.0 global (outside) 1 interface
Remarque : les listes de contrôle d'accès d'exemption NAT fonctionnent uniquement avec l'adresse IP ou les réseaux IP, tels que les exemples mentionnés (liste d'accès noNAT), et doivent être identiques aux listes de contrôle d'accès de crypto-carte. Les ACL d'exemption NAT ne fonctionnent pas avec les numéros de port (par exemple, 23, 25, etc.).
Remarque : dans un environnement VOIP, où les appels vocaux entre les réseaux sont transmis via le VPN, les appels vocaux ne fonctionnent pas si les listes de contrôle d'accès NAT 0 ne sont pas correctement configurées. Avant de procéder à un dépannage approfondi de la VOIP, il est suggéré de contrôler l'état de la connectivité VPN, parce que le problème pourrait être la mauvaise configuration d'ACL d'exemption NAT.
Remarque : Vous pouvez obtenir le message d'erreur comme indiqué en cas de configuration incorrecte dans les listes de contrôle d'accès d'exemption NAT (nat 0).
%PIX-3-305005: No translation group found for icmp src outside:192.168.100.41 dst inside:192.168.200.253 (type 8, code 0)
%ASA-3-305005: No translation group found for udp src Outside:x.x.x.x/p dst Inside:y.y.y.y/p
Note: Exemple incorrect :
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 eq 25
Si l'exemption NAT (nat 0) ne fonctionne pas, alors essayez de la supprimer et émettez la commande NAT 0 pour qu'elle fonctionne.
-
-
Assurez-vous que vos ACL ne sont pas vers l'arrière et sont du bon type.
-
Les ACL de chiffrement et d'exemption NAT pour des configurations de LAN-à-LAN doivent être écrites avec la perspective du périphérique sur lequel l'ACL est configurée. Ceci signifie que les ACL doivent servir de miroir les unes pour les autres. Dans cet exemple, un tunnel de LAN-à-LAN est configuré entre 192.168.100.0 /24 et 192.168.200.0 /24.
ACL de chiffrement routeur A
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
ACL de chiffrement routeur B
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Remarque : Bien qu'il ne soit pas illustré ici, ce même concept s'applique également aux appliances de sécurité PIX et ASA.
-
Dans PIX/ASA, les ACL de transmission tunnel partagée pour configurations d'accès à distance doivent être des listes d'accès standard qui autorisent le trafic vers le réseau pour lequel les clients VPN ont besoin d'accès. Les routeurs IOS peuvent utiliser une ACL étendue pour la transmission tunnel partagée.
Remarque : dans la liste de contrôle d'accès étendue, utiliser 'any' à la source dans la liste de contrôle d'accès de tunnellisation fractionnée est similaire à désactiver la transmission tunnel partagée. Utilisez seulement les réseaux sources dans l'ACL étendue pour la transmission tunnel partagée.
Note: Exemple correct :
access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255
Note: Exemple incorrect :
access-list 140 permit ip any 10.18.0.0 0.0.255.255
-
Cisco IOS
router(config)#access-list 10 permit ip 192.168.100.0 router(config)#crypto isakmp client configuration group MYGROUP router(config-isakmp-group)#acl 10
-
Cisco PIX 6.x
pix(config)#access-list 10 permit 192.168.100.0 255.255.255.0 pix(config)#vpngroup MYGROUP split-tunnel 10
-
Cisco PIX/ASA 7.x
securityappliance(config)#access-list 10 standard permit 192.168.100.0 255.255.255.0 securityappliance(config)#group-policy MYPOLICY internal securityappliance(config)#group-policy MYPOLICY attributes securityappliance(config-group-policy)#split-tunnel-policy tunnelspecified securityappliance(config-group-policy)#split-tunnel-network-list value 10
-
-
Cette erreur se produit dans ASA 8.3 si le NO NAT ACL est mal configuré ou n'est pas configuré sur ASA :
%ASA-5-305013 : Règles asymétriques NAT jumelées pour les flux en amont et en aval; Connexion pour le port udp src à l'extérieur : x.x.x.x/xxxxx dst inside:x.x.x.x/xx refusé en raison d'une défaillance du chemin inverse NAT
Afin de résoudre ce problème, vérifiez si la configuration est correcte. Si non, procédez à la reconfiguration.
Configuration d'exemption dans la version ASA 8.3 pour le tunnel VPN de site à site :
Un VPN site à site doit être établi entre HOASA et BOASA avec les deux ASA utilisant la version 8.3. La configuration NAT d'exception sur HOASA ressemble à ceci :
object network obj-local subnet 192.168.100.0 255.255.255.0 object network obj-remote subnet 192.168.200.0 255.255.255.0 nat (inside,outside) 1 source static obj-local obj-local destination static obj-remote objremote
Vérifier les stratégies ISAKMP
Si le tunnel IPsec ne FONCTIONNE pas, vérifiez que les stratégies ISAKMP correspondent avec les homologues distants. Cette stratégie ISAKMP s'applique à la fois au VPN IPsec de site-à-site (L2L) et au VPN IPsec d'accès à distance.
Si les clients VPN Cisco ou le VPN de site-à-site ne peuvent pas établir le tunnel avec le périphérique distant, vérifiez que les deux homologues contiennent les mêmes valeurs de cryptage, d'authentification et de paramètre Diffie-Hellman et quand la stratégie de l'homologue distant spécifie une durée de vie inférieure ou égale à celle de la stratégie que l'initiateur a envoyée. Si les durées de vie ne sont pas identiques, le dispositif de sécurité utilise la durée de vie plus courte. Si aucune correspondance acceptable n'existe, ISAKMP refuse la négociation et la SA n'est pas établie.
"Error: Unable to remove Peer TblEntry, Removing peer from peer table failed, no match!"
Voici le message détaillé du journal :
4|Mar 24 2010 10:21:50|713903: IP = X.X.X.X, Error: Unable to remove PeerTblEntry 3|Mar 24 2010 10:21:50|713902: IP = X.X.X.X, Removing peer from peer table failed, no match! 3|Mar 24 2010 10:21:50|713048: IP = X.X.X.X, Error processing payload: Payload ID: 1 4|Mar 24 2010 10:21:49|713903: IP = X.X.X.X, Information Exchange processing failed 5|Mar 24 2010 10:21:49|713904: IP = X.X.X.X, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping
Ce message apparaît habituellement en raison de stratégies ISAKMP non correspondantes ou d'une déclaration NAT 0 manquante.
En outre, ce message apparaît :
Error Message %PIX|ASA-6-713219: Queueing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Ce message indique que les messages de phase 2 sont mis en file d'attente après la fin de la phase 1. Ce message d'erreur peut avoir l'un des motifs suivants :
-
Non correspondance de phase sur l'un des homologues
-
L'ACL empêche les homologues de terminer la phase 1
Ce message vient habituellement après le message d'erreur Removing peer from peer table failed, no match! .
Si le client VPN Cisco ne peut pas connecter le périphérique de tête de réseau, le problème peut être la non correspondance de la stratégie ISAKMP. Le périphérique de tête de réseau doit correspondre à l'une des propositions IKE du client VPN Cisco.
Remarque : pour la stratégie ISAKMP et le jeu de transformation IPsec qui est utilisé sur PIX/ASA, le client VPN Cisco ne peut pas utiliser une stratégie avec une combinaison DES et SHA. Si vous utilisez le DES, vous devez utiliser le MD5 pour l'algorithme de hachage, ou vous pouvez utiliser les autres combinaisons, 3DES avec SHA et 3DES avec MD5.
Vérifier que le routage est correct
Le routage est une partie capitale de presque chaque déploiement VPN IPsec. Assurez-vous que vos périphériques de cryptage, tels que des routeurs et des dispositifs de sécurité PIX ou ASA, ont les informations de routage appropriées pour envoyer le trafic via votre tunnel VPN. Par ailleurs, si d'autres routeurs existent derrière votre périphérique de passerelle, assurez-vous que ces routeurs sachent comment atteindre le tunnel et quels réseaux sont de l'autre côté.
Un composant clé du routage dans un déploiement VPN est le Reverse Route Injection (RRI). Le RRI place des entrées dynamiques pour des réseaux distants ou des clients VPN dans la table de routage d'une passerelle VPN. Ces routes sont utiles au périphérique sur lequel elles sont installées, ainsi qu'à d'autres périphériques dans le réseau, parce que des routes installées par RRI peuvent être redistribuées par un protocole de routage tel qu'EIGRP ou OSPF.
-
Dans une configuration de LAN-à-LAN, il est important pour chaque périphérique d'avoir une route ou des routes pour les réseaux pour lesquels il est censé crypter le trafic. Dans cet exemple, Router A doit avoir des routes pour les réseaux derrière Router B via 10.89.129.2. Router B doit avoir une route semblable vers 192.168.100.0 /24 :
-
La première façon de s'assurer que chaque routeur connaît la route appropriée est de configurer des routes statiques pour chaque réseau de destination. Par exemple, Router A peut avoir ces instructions de route configurées :
ip route 0.0.0.0 0.0.0.0 172.22.1.1 ip route 192.168.200.0 255.255.255.0 10.89.129.2 ip route 192.168.210.0 255.255.255.0 10.89.129.2 ip route 192.168.220.0 255.255.255.0 10.89.129.2 ip route 192.168.230.0 255.255.255.0 10.89.129.2
Si Router A a été remplacé par un PIX ou ASA, la configuration peut ressembler à ceci :
route outside 0.0.0.0 0.0.0.0 172.22.1.1 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2
-
Si un grand nombre de réseaux existe derrière chaque périphérique, la configuration des routes statiques devient difficile à maintenir. Au lieu de cela, il est recommandé d'utiliser le Reverse Route Injection, comme décrit. Le RRI place dans la table de routage des routes pour tous les réseaux mentionnés dans l'ACL de chiffrement. Par exemple, l'ACL de chiffrement et la carte de chiffrement de Router A peuvent ressembler à ceci :
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.210.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.220.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.230.0 0.0.0.255 crypto map myMAP 10 ipsec-isakmp set peer 10.89.129.2 reverse-route set transform-set mySET match address 110
Si Router A a été remplacé par un PIX ou ASA, la configuration peut ressembler à ceci :
access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.210.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.220.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.230.0 255.255.255.0 crypto map myMAP 10 match address cryptoACL crypto map myMAP 10 set peer 10.89.129.2 crypto map myMAP 10 set transform-set mySET crypto map mymap 10 set reverse-route
-
-
Dans une configuration d'accès à distance, des changements de routage ne sont pas toujours nécessaires. Cependant, si d'autres routeurs existent derrière le routeur de passerelle VPN ou le dispositif de sécurité, ces routeurs doivent apprendre le chemin menant aux clients VPN d'une manière ou d'une autre. Dans cet exemple, supposez que les clients VPN obtiennent des adresses comprises dans la plage de 10.0.0.0 /24 quand ils se connectent.
Si aucun protocole de routage n'est en service entre la passerelle et l'autre routeur, des routes statiques peuvent être utilisées sur des routeurs tels que Router 2 :
ip route 10.0.0.0 255.255.255.0 192.168.100.1
Si un protocole de routage tel qu'EIGRP ou OSPF est en service entre la passerelle et d'autres routeurs, il est recommandé d'utiliser le Reverse Route Injection comme décrit. Le RRI ajoute automatiquement des routes pour le client VPN à la table de routage de la passerelle. Ces routes peuvent alors être distribuées aux autres routeurs dans le réseau.
-
Routeur Cisco IOS :
crypto dynamic-map dynMAP 10 set transform-set mySET reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
-
Dispositif de sécurité Cisco PIX ou ASA :
crypto dynamic-map dynMAP 10 set transform-set mySET crypto dynamic-map dynMAP 10 set reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
-
Remarque : Le problème de routage se produit si le pool d'adresses IP attribué aux clients VPN se chevauche avec les réseaux internes du périphérique de tête de réseau. Pour plus d'informations, référez-vous à la section Réseaux privés en superposition.
Vérifier que le jeu de transformation est correct
Assurez-vous que le cryptage IPsec et les algorithmes de hachage à utiliser par le jeu de transformation aux deux extrémités sont identiques. Référez-vous à la section Référence des commandes du guide de configuration du dispositif de sécurité Cisco pour plus d'informations.
Remarque : pour la stratégie ISAKMP et le jeu de transformation IPsec qui est utilisé sur PIX/ASA, le client VPN Cisco ne peut pas utiliser une stratégie avec une combinaison DES et SHA. Si vous utilisez le DES, vous devez utiliser le MD5 pour l'algorithme de hachage, ou vous pouvez utiliser les autres combinaisons, 3DES avec SHA et 3DES avec MD5.
Vérifier les numéros et le nom de la séquence de la carte de chiffrement, et vérifier que la carte de chiffrement est appliquée dans la bonne interface, dans laquelle le tunnel IPsec commence/s'arrête
Si des homologues statiques et dynamiques sont configurés sur la même carte de chiffrement, l'ordre des entrées dans la carte de chiffrement est très important. Le numéro de séquence de l'entrée dynamique de la carte de chiffrement doit être plus élevé que toutes les autres entrées statiques de la carte de chiffrement. Si les entrées statiques ont des numéros plus élevés que l'entrée dynamique, les connexions avec ces homologues échouent et les débogages indiqués apparaissent.
IKEv1]: Group = x.x.x.x, IP = x.x.x.x, QM FSM error (P2 struct &0x49ba5a0, mess id 0xcd600011)! [IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
Remarque : une seule crypto-carte dynamique est autorisée pour chaque interface de l'appliance de sécurité.
Voici un exemple de carte de chiffrement correctement numérotée qui contient une entrée statique et une entrée dynamique. Notez que l'entrée dynamique a le numéro de séquence le plus élevé et que de la place a été laissée pour ajouter des entrées statiques supplémentaires :
crypto dynamic-map cisco 20 set transform-set myset crypto map mymap 10 match address 100 crypto map mymap 10 set peer 172.16.77.10 crypto map mymap 10 set transform-set myset crypto map mymap interface outside crypto map mymap 60000 ipsec-isakmp dynamic cisco
Remarque : Les noms de cartes Crypto sont sensibles à la casse.
Note : Ce message d'erreur peut également être vu lorsque la séquence d'hommes de chiffrement dynamique n'est pas correcte, ce qui entraîne l'homologue à atteindre la mauvaise carte de chiffrement, et aussi par une liste d'accès de chiffrement non correspondante qui définit le trafic intéressant : %ASA-3-713042 : IKE Initiator unable to find policy:
Dans les scénarios où plusieurs tunnels VPN doivent se terminer sur la même interface, nous avons besoin de créer une carte de chiffrement avec le même nom (une seule carte de chiffrement est permise par interface), mais avec un numéro de séquence différent. Il en va de même pour le routeur, le PIX et l'ASA.
Référez-vous à Configurer IPsec entre un concentrateur et des PIX distants avec un client VPN et l'authentification étendue pour plus d'informations afin d'en savoir plus sur la configuration PIX du concentrateur pour la même carte de chiffrement avec des numéros de séquence différents sur la même interface. De même, référez-vous à PIX/ASA 7.X : Ajouter un nouveau tunnel ou accès à distance à un VPN L2L existant pour plus d'informations afin d'en savoir plus sur la configuration de la carte de chiffrement pour des scénarios VPN L2L et d'accès à distance.
Vérifier que l'adresse IP de l'homologue est correcte
Pour une configuration VPN IPsec de LAN-à-LAN (L2L) avec dispositif de sécurité PIX/ASA 7.x, vous devez spécifier le nom (<name>) du groupe de tunnels comme adresse ip de l'homologue distant (fin de tunnel distant) dans la commande tunnel-group<name> type ipsec-l2l pour la création et la gestion de la base de données des enregistrements spécifiques à la connexion pour IPsec. L'adresse IP de l'homologue doit correspondre dans les commandes tunnel group name et Crypto map set address. Lorsque que vous configurez le VPN avec l'ASDM, il a généré le nom du groupe de tunnels automatiquement avec la bonne adresse IP de l'homologue. Si l'adresse IP de l'homologue n'est pas configurée correctement, les journaux peuvent contenir ce message, ce qui peut être résolu par la configuration appropriée de l'adresse IP de l'homologue.
[IKEv1]: Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Dans une configuration VPN IPsec de LAN-à-LAN (L2L) avec PIX 6.x, l'adresse IP de l'homologue (fin de tunnel distant) doit correspondre dans les commandes isakmp key address et set peer dans la carte de chiffrement pour que la connexion VPN IPsec fonctionne.
Quand l'adresse IP du pair n'a pas été configurée correctement dans la configuration de cryptage ASA, le ASA ne peut pas établir le tunnel VPN et s'arrête à l'étape MM WAIT MSG4 seulement. Afin de résoudre ce problème, corrigez l'adresse IP du pair dans la configuration.
Voici la sortie de la commande show crypto isakmp sa quand le tunnel VPN s'arrête à l'état MM_WAIT_MSG4.
hostname#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG4
Vérifier le groupe de tunnels et les noms de groupe
%PIX|ASA-3-713206: Tunnel Rejected: Conflicting protocols specified by tunnel-group and group-policy
Ce message apparaît quand un tunnel est supprimé, parce que le tunnel autorisé spécifié dans la stratégie de groupe est différent du tunnel autorisé dans la configuration du groupe de tunnels.
group-policy hf_group_policy attributes vpn-tunnel-protocol l2tp-ipsec username hfremote attributes vpn-tunnel-protocol l2tp-ipsec Both lines should read: vpn-tunnel-protocol ipsec l2tp-ipsec
Activez IPSec dans la stratégie de groupe par défaut pour les protocoles existants déjà dans la stratégie de groupe par défaut.
group-policy DfltGrpPolicy attributes vpn-tunnel-protocol L2TP-IPSec IPSec webvpn
Désactiver XAUTH pour des homologues L2L
Si un tunnel de LAN-à-LAN et un tunnel VPN d'accès à distance sont configurés sur la même carte de chiffrement, des informations sur XAUTH sont demandées à l'homologue LAN-à-LAN et le tunnel de LAN-à-LAN échoue avec « CONF_XAUTH » dans la sortie de la commande show crypto isakmp sa.
Voici un exemple de sortie SA :
Router#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status X.X.X.X Y.Y.Y.Y CONF_XAUTH 10223 0 ACTIVE X.X.X.X Z.Z.Z.Z CONF_XAUTH 10197 0 ACTIVE
Remarque : Ce problème ne s'applique qu'à Cisco IOS et PIX 6.x. alors que PIX/ASA 7.x n'est pas affecté par ce problème puisqu'il utilise des groupes de tunnels.
Utilisez le mot clé no-xauth quand vous saisissez la clé isakmp, de sorte que le périphérique ne demande pas d'informations sur XAUTH (nom d'utilisateur et mot de passe). Ce mot clé désactive XAUTH pour les homologues IPsec statiques. Saisissez un commande semblable à celle-ci sur le périphérique pour lequel un VPN L2L et un VPN RA sont configurés sur la même carte de chiffrement :
router(config)#crypto isakmp key cisco123 address 172.22.1.164 no-xauth
Dans le scénario où PIX/ASA 7.x agit en tant que serveur VPN simplifié, le client VPN simplifié ne peut pas se connecter à la tête de réseau en raison du problème Xauth. Désactivez l'authentification des utilisateurs dans le PIX/ASA afin de résoudre le problème comme montré :
ASA(config)#tunnel-group example-group type ipsec-ra ASA(config)#tunnel-group example-group ipsec-attributes ASA(config-tunnel-ipsec)#isakmp ikev1-user-authentication none
Voyez la section Divers de ce document afin d'en savoir plus sur la commande isakmp ikev1-user-authentication.
Regroupement VPN en cours d'épuisement
Quand la plage des adresses IP attribuées à la réserve VPN n'est pas suffisante, vous pouvez étendre l'offre des adresses IP de deux manières :
-
Enlevez la plage existante et définissez la nouvelle plage. Voici un exemple :
CiscoASA(config)#no ip local pool testvpnpool 10.76.41.1-10.76.41.254 CiscoASA(config)#ip local pool testvpnpool 10.76.41.1-10.76.42.254
-
Quand des sous-réseaux non contigus doivent être ajoutés à la réserve VPN, vous pouvez définir deux groupes VPN distincts et les spécifier alors dans la commande sous le « tunnel-group attributes (attributs de groupe de tunnels) ». Voici un exemple :
CiscoASA(config)#ip local pool testvpnpoolAB 10.76.41.1-10.76.42.254 CiscoASA(config)#ip local pool testvpnpoolCD 10.76.45.1-10.76.45.254 CiscoASA(config)#tunnel-group test type remote-access CiscoASA(config)#tunnel-group test general-attributes CiscoASA(config-tunnel-general)#address-pool (inside) testvpnpoolAB testvpnpoolCD CiscoASA(config-tunnel-general)#exit
La commande dans laquelle vous spécifiez les groupes est très importante parce que ASA attribue des adresses de ces groupes dans la commande dans laquelle les groupes apparaissent dans cette commande.
Remarque : Les paramètres address-pools de la commande group-policy address-pools remplacent toujours les paramètres de pool local dans la commande tunnel-group address-pool.
Problèmes de latence pour le trafic du client VPN
Quand il y a des questions de latence au-dessus d'une connexion VPN, vérifiez le suivant afin de résoudre ceci :
-
Vérifiez si le MSS du paquet peut être réduit plus loin.
-
Si IPsec/tcp est utilisé au lieu d'IPsec/udp, alors configurez preserve-vpn-flow.
-
Réinstallez Cisco ASA .
Les clients VPN ne peuvent pas se connecter à ASA/PIX
Problème
Les clients VPN Cisco ne peuvent pas authentifier quand le X-auth est utilisé avec le serveur Radius.
Solution
Le problème peut être que le xauth expire. Augmentez la valeur d'attente pour le serveur AAA afin de résoudre ce problème.
Exemple :
Hostname(config)#aaa-server test protocol radius hostname(config-aaa-server-group)#aaa-server test host 10.2.3.4 hostname(config-aaa-server-host)#timeout 10
Problème
Les clients VPN Cisco ne peuvent pas authentifier quand le X-auth est utilisé avec le serveur Radius.
Solution
Au commencement, assurez-vous que l'authentification fonctionne correctement. Pour isoler le problème, vérifiez d'abord l'authentification avec la base de données locale sur le ASA.
tunnel-group tggroup general-attributes
authentication-server-group none
authentication-server-group LOCAL
exit
Si ceci fonctionne bien, alors le problème devrait être lié à la configuration du serveur Radius.
Vérifiez la Connectivité du serveur Radius à partir du ASA . Si le ping fonctionne sans problème, alors vérifiez la configuration liée à Radius sur le ASA et la configuration de base de données sur le serveur Radius.
Vous pourriez utiliser la commande de débogage de Radius (debug radius) pour dépanner des problèmes liés à Radius. Pour un exemple de l'affichage de la commande debug radius, référez-vous à cet échantillon d'affichage.
Remarque : Avant d'utiliser la commande debug sur l'ASA, reportez-vous à la documentation suivante : Message d'avertissement.
Le client interrompt fréquemment la connexion au premier essai, ou la connexion de sécurité VPN est terminée par le pair. Raison 433. » ou « Connexion VPN sécurisée terminée par Peer Reason 433:(Raison non spécifiée par Peer)"
Problème
Les utilisateurs du client VPN Cisco peuvent recevoir cette erreur quand ils essayent la connexion avec le périphérique VPN de tête de réseau.
« Le client VPN interrompt fréquemment la connexion à la première tentative » ou « la connexion VPN sécurisée a été interrompue par le pair ». Raison 433." ou "Connexion VPN sécurisée terminée par Peer Reason 433:(Reason Not Specified by Peer)" ou "Tentative d'attribution d'adresse IP de réseau ou de diffusion, suppression (x.x.x.x) du pool"
Solution 1
Le problème pourrait être avec l'affectation du bassin d'IP attribuée sur ASA/PIX, le serveur Radius, le serveur DHCP ou par le serveur Radius agissant en tant que serveur . Utilisez la commande debug crypto afin de vérifier que le masque de réseau et les adresses IP sont corrects. En outre, vérifiez que le pool n'inclut pas l'adresse du réseau et l'adresse de diffusion. Les serveurs Radius doivent pouvoir assigner les adresses IP propres aux clients.
Solution 2
Ce problème se produit également en raison des défaillances de l'authentification étendue. Vous devez vérifier le serveur AAA pour éliminer cette erreur. Vérifier le mot de passe d'authentification de serveur sur le serveur et le client et la réinitialisation du serveur AAA pourrait résoudre ce problème.
Solution 3
Un autre solution pour cette question est de désactiver la configuration de détection des menaces. Parfois quand il y a plusieurs retransmissions pour différentes associations de sécurité inachevées (SAs), le ASA avec la fonction activée de détection des menaces estime qu'une attaque de balayage se produit et les ports VPN sont marqués en tant que contrevenant principal. Essayez de désactiver la configuration de détection des menaces comme ceci peut créer beaucoup charger le traitement du ASA . Employez ces commandes afin de désactiver la détection des menaces :
no threat-detection basic-threat no threat-detection scanning-threat shun no threat-detection statistics no threat-detection rate
Pour plus d'informations sur cette caractéristique, référez-vous à la Détection des menaces.
Remarque : ceci peut être utilisé comme solution de contournement pour vérifier si cela corrige le problème réel. Assurez-vous que la désactivation de la détection des menaces sur Cisco ASA compromet réellement plusieurs fonctionnalités de sécurité telles que la lutte aux tentatives de balayage, les DoS avec un SPI non valide, les paquets qui échouent à l'inspection des applications et les sessions inachevées.
Solution 4
Ce problème se produit également quand un ensemble de transformations n'est pas correctement configuré. Une configuration correcte de l'ensemble de transformations résout le problème.
Les utilisateur de l'accès à distance et d'EZVPN se connectent au VPN mais ne peuvent pas accéder aux ressources externes
Problème
Les utilisateurs de l'accès à distance n'ont aucune connectivité Internet une fois qu'ils se connectent au VPN.
Les utilisateurs de l'accès à distance ne peuvent pas accéder à des ressources situées derrière d'autres VPN sur le même périphérique.
Les utilisateurs de l'accès à distance peuvent seulement accéder au réseau local.
Solutions
Essayez ces solutions afin de résoudre ce problème :
Impossible d'accéder aux serveurs dans DMZ
Une fois que le client VPN est établi, le tunnel IPsec avec le périphérique VPN de tête de réseau (routeur PIX/ASA/IOS), les utilisateurs du client VPN peuvent accéder aux ressources du réseau INTERNE (10.10.10.0/24), mais ils ne peuvent pas accéder au réseau DMZ (10.1.1.0/24).
Diagramme
Vérifiez que la configuration transmission tunnel partagée, NO NAT est ajoutée dans le périphérique de tête de réseau pour accéder aux ressources dans le réseau DMZ.
Exemple
| ASA/PIX |
|---|
ciscoasa#show running-config !--- Split tunnel for the inside network access access-list vpnusers_spitTunnelAcl permit ip 10.10.10.0 255.255.0.0 any !--- Split tunnel for the DMZ network access access-list vpnusers_spitTunnelAcl permit ip 10.1.1.0 255.255.0.0 any !--- Create a pool of addresses from which IP addresses are assigned !--- dynamically to the remote VPN Clients. ip local pool vpnclient 192.168.1.1-192.168.1.5 !--- This access list is used for a nat zero command that prevents !--- traffic which matches the access list from undergoing NAT. !--- No Nat for the DMZ network. access-list nonat-dmz permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0 !--- No Nat for the Inside network. access-list nonat-in permit ip 10.10.10.0 255.255.255.0 192.168.1.0 255.255.255.0 !--- NAT 0 prevents NAT for networks specified in the ACL nonat . nat (DMZ) 0 access-list nonat-dmz nat (inside) 0 access-list nonat-in |
Configuration de la version 8.3 deASA :
Cette configuration affiche comment configurer l' exemption NAT pour le réseau DMZ afin de permettre aux utilisateurs VPN d'accéder au réseau DMZ :
object network obj-dmz subnet 10.1.1.0 255.255.255.0 object network obj-vpnpool subnet 192.168.1.0 255.255.255.0 nat (inside,dmz) 1 source static obj-dmz obj-dmz destination static obj-vpnpool obj-vpnpool
Après avoir ajouté une nouvelle entrée pour la configuration NAT, effacez la traduction Nat.
Clear xlate Clear local
Vérifier :
Si le tunnel a été établi, allez au client VPN Cisco et choisissez Status > Route Details pour vérifier que les routes sécurisées sont affichées pour les réseaux DMZ et INTERNES.
Référez-vous à PIX/ASA 7.x : Accès au serveur de messagerie sur l'exemple de configuration DMZ pour plus d'informations sur la façon de configurer le pare-feu PIX pour l'accès à un serveur de messagerie situé sur le réseau de Zone démilitarisée (DMZ).
Référez-vous à PIX/ASA 7.x : Ajouter un nouveau tunnel ou accès à distance à un VPN L2L existant afin d'obtenir les étapes nécessaires à l'ajout d'un nouveau tunnel VPN ou d'un VPN d'accès à distance à une configuration VPN L2L qui existe déjà.
Référez-vous à PIX/ASA 7.x : Permettre la transmission tunnel partagée pour des clients VPN sur l'exemple de configuration ASA afin d'obtenir des instructions pas à pas sur la façon de permettre l'accès de clients VPN à l'Internet tandis qu'ils sont reliés par tunnel dans un dispositif de sécurité adaptatif (ASA) Cisco de la gamme 5500.
Les clients VPN sont incapables de résoudre le DNS
Une fois le tunnel établi, si les clients VPN ne peuvent pas résoudre le DNS, le problème peut être la configuration du serveur DNS dans le périphérique de tête de réseau (ASA/PIX). Contrôlez également la connectivité entre les clients VPN et le serveur DNS. La configuration du serveur DNS doit être effectuée sous la stratégie de groupe et être appliqué sous la stratégie de groupe dans les attributs généraux du groupe de tunnels ; par exemple :
!--- Create the group policy named vpn3000 and !--- specify the DNS server IP address(172.16.1.1) !--- and the domain name(cisco.com) in the group policy. group-policy vpn3000 internal group-policy vpn3000 attributes dns-server value 172.16.1.1 default-domain value cisco.com !--- Associate the group policy(vpn3000) to the tunnel group !--- using the default-group-policy. tunnel-group vpn3000 general-attributes default-group-policy vpn3000
Les clients VPN sont incapables de se connecter à des serveurs internes par le nom
Le client VPN ne peut pas soumettre une requête ping aux hôtes ou aux serveurs du réseau interne distant ou en tête de réseau par le nom. Vous devez activer l'option split-dns configure sur l'ASA afin de résoudre ce problème.
Transmission tunnel partagée — Impossible d'accéder à l'Internet ou aux réseaux exclus
La transmission tunnel partagée laisse les clients IPsec d'accès à distance diriger conditionnellement des paquets via le tunnel IPsec sous forme cryptée ou diriger des paquets vers une interface réseau sous forme de texte clair, décryptée, dans laquelle ils sont ensuite routés vers la destination finale. La transmission tunnel partagée est désactivée par défaut, c'est le trafic tunnelall.
split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
Remarque : l'option exclpected est prise en charge uniquement pour les clients VPN Cisco, et non pour les clients EZVPN.
ciscoasa(config-group-policy)#split-tunnel-policy excludespecified
Référez-vous à ces documents pour des exemples de configuration détaillés de transmission tunnel partagée :
Hairpinning
Cette fonctionnalité est utile pour le trafic VPN qui entre dans interface, mais qui est ensuite routé hors de cette même interface. Par exemple, si vous avez un réseau VPN en étoile dans lequel le dispositif de sécurité est le concentrateur et les réseaux VPN à distance sont des rayons, pour qu'un rayon communique avec un autre, le trafic doit aller dans le dispositif de sécurité, puis ressortir pour aller vers l'autre rayon.
Utilisez la configuration same-security-traffic pour laisser le trafic entrer et sortir de la même interface.
securityappliance(config)#same-security-traffic permit intra-interface
Accès au LAN local
Les utilisateurs de l'accès à distance se connectent au VPN et peuvent se connecter au réseau local seulement.
Pour un exemple de configuration plus détaillé, référez-vous à PIX/ASA 7.x : Permettre l'accès au LAN local pour des clients VPN.
Réseaux privés en superposition
Problème
Si vous ne pouvez pas accéder au réseau interne après l'établissement du tunnel, contrôlez l'adresse IP assignée au client VPN qui se superpose au réseau interne derrière le périphérique de tête de réseau.
Solution
Assurez-vous toujours que les adresses IP dans le pool à assigner pour les clients VPN, le réseau interne du périphérique de tête de réseau et le réseau interne de client VPN doivent être dans des réseaux différents. Vous pouvez assigner le même réseau principal avec différents sous-réseaux, mais parfois les problèmes de routage se produisent.
Pour d'autres exemples, voyez le diagramme et l'exemple de la section Impossible d'accéder aux serveurs dans DMZ.
Impossible de connecter plus de trois utilisateurs de client VPN
Problème
Seuls trois clients VPN peuvent se connecter à ASA/PIX ; la connexion pour le quatrième client échoue. Lors de la panne, ce message d'erreur est affiché :
Secure VPN Connection terminated locally by the client. Reason 413: User Authentication failed.
tunnel rejected; the maximum tunnel count has been reached
Solutions
Dans la plupart des cas, ce problème est lié à un paramétrage de procédures de connexion simultanées dans la stratégie de groupe et à la limite de session maximale.
Essayez ces solutions afin de résoudre ce problème :
Pour plus d'informations, référez-vous à la section Configurer des stratégies de groupe de Procédures de configuration ASDM VPN sélectionnées pour la gamme Cisco ASA 5500 version 5.2.
Configurer des procédures de connexion simultanées
Si la case à cocher Inherit dans l'ASDM est cochée, le nombre par défaut de procédures de connexion simultanées seulement est permis pour l'utilisateur. La valeur par défaut pour des procédures de connexion simultanées est trois.
Afin de résoudre ce problème, augmentez la valeur pour des procédures de connexion simultanées.
-
Lancez l'ASDM, puis allez à Configuration > VPN > Group Policy.
-
Choisissez le Group approprié et cliquez sur le bouton Edit.
-
Une fois dans l'onglet General, décochez la case à cocher Inherit pour Simultaneous Logins sous Connection Settings. Choisissez une valeur Appropriée dans le champ.
Remarque : la valeur minimale de ce champ est 0, ce qui désactive la connexion et empêche l'accès utilisateur.
Remarque : lorsque vous vous connectez à l'aide du même compte utilisateur à partir d'un autre ordinateur, la session en cours (la connexion établie à partir d'un autre ordinateur à l'aide du même compte utilisateur) est interrompue et la nouvelle session est établie. C'est le comportement par défaut et est indépendant aux procédures de connexion VPN simultanées.
Configurer ASA/PIX avec CLI
Effectuez ces étapes afin de configurer le nombre désiré de procédures de connexion simultanées. Dans cet exemple, 20 a été choisi comme valeur désirée.
ciscoasa(config)#group-policy Bryan attributes ciscoasa(config-group-policy)#vpn-simultaneous-logins 20
Afin d'en savoir plus sur cette commande, référez-vous à Référence de commande des dispositifs de sécurité Cisco version 7.2.
Utilisez la commande vpn-sessiondb max-session-limit dans le mode de configuration globale afin de limiter les sessions VPN à une valeur plus faible que celle autorisée par le dispositif de sécurité. Utilisez la version no de cette commande afin de supprimer la limite de session. Utilisez de nouveau la commande afin de remplacer la configuration actuelle.
vpn-sessiondb max-session-limit {session-limit}
Cet exemple montre comment paramétrer une limite de session VPN maximale à 450 :
hostname#vpn-sessiondb max-session-limit 450
Configurer un concentrateur
Message d'erreur
20932 10/26/2007 14:37:45.430 SEV=3 AUTH/5 RPT=1863 10.19.187.229 Authentication rejected: Reason = Simultaneous logins exceeded for user handle = 623, server = (none), user = 10.19.187.229, domain = <not specified>
Solution
Effectuez ces étapes afin de configurer le nombre désiré de procédures de connexion simultanées. Vous pouvez également essayer de paramétrer les procédures de connexion simultanées à 5 pour cette SA :
Choisissez Configuration > User Management (Gestion des utilisateurs) > Groups (Groupes)> Modify (Modifier) 10.19.187.229 > General (Général)> Simultaneous Logins (Connexions simultanées) et changent le nombre de procédures de connexion à 5.
Impossible de lancer la session ou une application et transfert lent après l'établissement du tunnel
Problème
Après l'établissement du tunnel IPsec, l'application ou la session ne se lance pas à travers le tunnel.
Solutions
Utilisez la commande ping pour vérifier le réseau ou pour trouver si le serveur d'application est accessible depuis votre réseau. Cela peut être un problème avec la taille de segment maximale (MSS) pour les paquets temporaires qui traversent un routeur ou un périphérique PIX/ASA, en particulier des segments TCP avec le bit SYN paramétré.
Routeur Cisco IOS — Changer la valeur MSS dans l'interface externe (interface d'extrémité de tunnel) du routeur
Exécutez ces commandes afin de changer la valeur MSS dans l'interface externe (interface d'extrémité de tunnel) du routeur :
Router>enable Router#configure terminal Router(config)#interface ethernet0/1 Router(config-if)#ip tcp adjust-mss 1300 Router(config-if)#end
Ces messages montrent la sortie de débogage pour la MSS de TCP :
Router#debug ip tcp transactions Sep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)] Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 1300, MSS is 1300 Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751 Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 1300 Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]
La MSS est ajustée à 1 300 sur le routeur comme configuré.
Pour plus d'informations, référez-vous à PIX/ASA 7.x et IOS : fragmentation de VPN.
PIX/ASA 7.X — Se référer à la documentation PIX/ASA
Il y a impossibilité d'accéder à l'Internet correctement ou le transfert est lent via le tunnel, parce qu'il en résulte le message d'erreur de taille du MTU et des problèmes de MSS. Référez-vous à ces documents afin de résoudre le problème :
Impossible d'initier un tunnel VPN depuis ASA/PIX
Problème
Vous ne pouvez pas initier le tunnel VPN depuis l'interface d'ASA/PIX, et après l'établissement du tunnel, l'extrémité distante/client VPN ne peut pas soumettre de requête ping à l'interface interne d'ASA/PIX sur le tunnel VPN. Par exemple, il est possible que le client pn ne puisse pas initier une connexion SSH ou HTTP vers l'interface interne de l'ASA via le tunnel VPN.
Solution
Une requête ping ne peut pas être soumise à l'interface interne du PIX depuis l'autre extrémité du tunnel à moins que la commande management-access soit configurée dans le mode de configuration globale.
PIX-02(config)#management-access inside PIX-02(config)#show management-access management-access inside
Remarque : cette commande permet également d'initier une connexion ssh ou http à l'interface interne d'ASA via un tunnel VPN.
Remarque : Ces informations s'appliquent également à l'interface DMZ. Par exemple, si vous voulez soumettre un requête ping à l'interface DMZ de PIX/ASA ou si vous voulez initier un tunnel depuis l'interface DMZ, la commande management-access DMZ est requise.
PIX-02(config)#management-access DMZ
Remarque : Si le client VPN ne peut pas se connecter, assurez-vous que les ports ESP et UDP sont ouverts. Toutefois, si ces ports ne sont pas ouverts, essayez de vous connecter sur TCP 10000 en sélectionnant ce port sous l'entrée de connexion du client VPN. Cliquez avec le bouton droit sur modify > transport tab > IPsec over TCP. Référez-vous à PIX/ASA 7.x pour prendre en charge IPsec sur TCP sur n'importe quel exemple de configuration de port pour plus d'informations sur IPsec sur TCP.
Incapable de faire circuler le trafic à travers le tunnel VPN
Problème
Vous ne pouvez pas passer le trafic à travers un tunnel VPN.
Solution
Cette question se produit en raison du problème décrit dans l'ID de bogue Cisco CSCtb53186 (clients enregistrés seulement). Afin de résoudre ce problème, réinstaller ASA. Référez-vous au bogue pour en savoir plus.
Cette question pourrait également se produire quand les paquets ESP sont bloqués. Afin de résoudre ce problème, reconfigurer le tunnel VPN.
Ce problème pourrait se produire quand des données ne sont pas chiffrées, mais seulement déchiffré au-dessus du tunnel VPN suivant les indications de ce rapport :
ASA# sh crypto ipsec sa peer x.x.x.x
peer address: y.y.y.y
Crypto map tag: IPSec_map, seq num: 37, local addr: x.x.x.x
access-list test permit ip host xx.xx.xx.xx host yy.yy.yy.yy
local ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/0/0)
current_peer: y.y.y.y
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 393, #pkts decrypt: 393, #pkts verify: 393
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
Afin de résoudre ce problème, vérifiez ce qui suit :
-
Si les listes d'accès chiffrées s'assortissent avec le site distant, et que les listes d'accès NAT 0 sont correctes.
-
Si l'acheminement est correct et que le trafic atteint l'extérieur de l'interface pour la traverser à l'intérieur. L'exemple d'affichage montre que le déchiffrement se fait, mais le cryptage ne se produit pas.
-
Si la commande d'autorisation sysopt de connexion-vpn a été configurée sur ASA. Si non configuré, configurez cette commande parce qu'elle permet à l'ASA d'exempter le trafic VPN /chiffré de la vérification de l'interface ACL.
Configurer un homologue de secours pour le tunnel vpn sur la même carte de chiffrement
Problème
Vous voulez utiliser plusieurs homologues de secours pour un seul tunnel vpn.
Solution
Configurer plusieurs homologues est équivalent à fournir une liste de secours. Pour chaque tunnel, le dispositif de sécurité essaye de négocier avec le premier homologue de la liste.
Si cet homologue ne répond pas, le dispositif de sécurité descend dans la liste jusqu'à ce qu'un homologue réponde ou qu'il n'y ait plus d'homologues dans la liste.
L'ASA devrait avoir une carte de chiffrement déjà configurée en tant qu'homologue primaire. L'homologue secondaire pourrait être ajouté après le primaire.
Cet exemple de configuration montre l'homologue primaire en tant que X.X.X.X et l'homologue de secours en tant que Y.Y.Y.Y :
ASA(config)#crypto map mymap 10 set peer X.X.X.X Y.Y.Y.Y
Pour plus d'informations, référez-vous à la section Crypto map set peer dans Référence de commande des dispositifs de sécurité Cisco version 8.0.
Désactiver/Redémarrer un tunnel VPN
Problème
Afin de désactiver temporairement le VPN tunnel et redémarrer le service, exécutez la procédure décrite dans cette section.
Solution
Utilisez la commande crypto map interface dans le mode de configuration globale pour supprimer une carte de chiffrement précédemment définie paramétrée pour une interface. Utilisez la forme no de cette commande afin de supprimer la carte de chiffrement de l'interface.
hostname(config)#no crypto map map-name interface interface-name
Cette commande supprime une carte de chiffrement paramétrée pour toute interface active du dispositif de sécurité et rend le tunnel VPN IPsec inactif dans cette interface.
Pour redémarrer le tunnel IPsec sur une interface, vous devez assigner une carte de chiffrement à une interface avant que celle-ci puisse fournir des services IPsec.
hostname(config)#crypto map map-name interface interface-name
Certains tunnels ne sont pas chiffrés.
Problème
Quand un nombre énorme de tunnels sont configurés sur la passerelle VPN, quelques tunnels ne passent pas le trafic. L'ASA ne reçoit pas les paquets chiffrés pour ces tunnels.
Solution
Cette question se produit parce que l'ASA ne passe pas les paquets chiffrés par les tunnels. Des règles en double de cryptage sont créées dans le tableau ASP . C'est un problème connu et l'ID CSC tb de bogue (clients enregistrés seulement) a été ouvert pour aborder ce problème. Afin de résoudre ce problème, réinstaller le ou mettez à niveau l'ASA à une version pour laquelle ce bogue est réglé.
Erreur : - %ASA-5-713904 : Groupe = DefaultRAGroup, IP = x.x.x.x, le client utilise une version v2 du mode de transaction non prise en charge.Tunnel terminé.
Problème
Le message d'erreur %ASA-5-713904: Groupe = DefaultRAGroup, IP = 99.246.144.186, le client utilise une version du mode de transaction v2 non prise en charge.Un message d'erreur de fin de tunnel apparaît.
Solution
La raison du message d'erreur Transaction Mode v2 est que l'ASA prend en charge seulement IKE Mode Config V6 et pas l'ancien mode V2. Utilisez IKE Mode Config V6 afin de résoudre cette erreur.
Erreur : - %ASA-6-722036 : Groupe client-groupe Utilisateur xxxx IP x.x.x.x Transmission d'un grand paquet 1220 (seuil 1206)
Problème
Le message d'erreur %ASA-6-722036: Group < client-group > User < xxxx > IP < x.x.x.x> Transmitting large packet 1220 (threshold 1206) error message apparaît dans les messages du journal de l'ASA. Que signifie ce message de journal et comment ceci peut être résolu ?
Solution
Ce message du journal déclare qu'un grand paquet a été envoyé au client. La source du paquet ne reconnaît pas le MTU du client. Ceci peut également être dû à la compression de données incompressibles. La solution de contournement est d'arrêter la compression SVC compression avec la commande svc compression none qui résout le problème.
Erreur : The authentication-server-group none command has been deprecated
Problème
Si vous transférez la configuration VPN de PIX/ASA qui exécute la version 7.0.x à un autre dispositif de sécurité qui exécute la version 7.2.x, vous recevez ce message d'erreur :
ERROR: The authentication-server-group none command has been deprecated. The "isakmp ikev1-user-authentication none" command in the ipsec-attributes should be used instead.
Solution
La commande authentication-serveur-group n'est plus prise en charge dans les versions 7.2(1) et ultérieures. Cette commande a été abandonnée et déplacée dans le mode de configuration des attributs généraux du groupe de tunnels.
Référez-vous à la section isakmp ikev1-user-authentication de la référence des commandes pour plus d'informations sur cette commande.
Message d'erreur quand QoS est activée à une extrémité du tunnel VPN
Problème
Si vous activiez QoS à l'une des extrémités du tunnel VPN, vous pourriez recevoir ce message d'erreur :
IPSEC: Received an ESP packet (SPI= 0xDB6E5A60, sequence number= 0x7F9F) from 10.18.7.11 (user= ghufhi) to 172.16.29.23 that failed anti-replay checking
Solution
Ce message apparaît normalement quand une extrémité de tunnel utilise QoS. Ceci se produit quand un paquet est détecté comme étant en panne. Vous pouvez désactiver QoS pour arrêter ceci, mais le problème peut être ignoré tant que peut le trafic peut traverser le tunnel.
AVERTISSEMENT : crypto map entry will be incomplete
Problème
Quand vous exécutez la commande crypto map mymap 20 ipsec-isakmp, vous pourriez recevoir cette erreur :
AVERTISSEMENT : crypto map entry will be incomplete
Exemple :
ciscoasa(config)#crypto map mymap 20 ipsec-isakmp WARNING: crypto map entry will be incomplete
Solution
C'est un avertissement habituel quand vous définissez une nouvelle carte de chiffrement, rappelant que les paramètres tels que access-list (match address), transform set et peer address doivent être configurés avant que cela puisse fonctionner. Il est également normal que la première ligne que vous avez saisie afin de définir la carte de chiffrement ne s'affiche pas dans la configuration.
Erreur : - %ASA-4-400024 : IDS:2151 Large ICMP packet from to on interface outside
Problème
Impossible de passer un grand paquet ping à travers le tunnel vpn. Quand nous essayons de passer de grands paquets ping, nous obtenons l'erreur %ASA-4-400024: IDS:2151 Large ICMP packet from to on interface outside
Solution
Désactivez les signatures 2150 et 2151 afin de résoudre ce problème.Une fois les signatures désactivées, la requête ping fonctionne correctement.
Utilisez ces commandes afin de désactiver les signatures :
ASA(config)#ip audit signature 2151 disable
ASA(config)#ip audit signature 2150 disable
Erreur : - %PIX|ASA-4-02119 : IPSEC : Received a protocol packet (SPI=spi, sequence number= seq_num) from remote_IP (username) to local_IP that failed anti-replay checking.
Problème
J'ai reçu cette erreur dans les messages du journal de l'ASA :
Erreur : - %PIX|ASA-4-02119 : IPSEC : Received a protocol packet (SPI=spi, sequence number= seq_num) from remote_IP (username) to local_IP that failed anti-replay checking.
Solution
Afin de résoudre cette erreur, utilisez la commande crypto ipsec security-association replay window-size afin de faire varier la taille de la fenêtre.
hostname(config)#crypto ipsec security-association replay window-size 1024
Remarque : Cisco vous recommande d'utiliser la taille de fenêtre 1024 complète pour éliminer tout problème d'anti-reprise.
Error Message - %PIX|ASA-4-407001: Refuser le trafic pour local-host interface_name:inside_address, limite de licence dépassée
Problème
Quelques hôtes ne peuvent pas se connecter à l'Internet et ce message d'erreur apparaît dans le syslog :
Error Message - %PIX|ASA-4-407001: Refuser le trafic pour local-host interface_name:inside_address, limite de licence dépassée
Solution
Ce message d'erreur est reçu quand le nombre d'utilisateurs dépasse la limite d'utilisateurs de la licence utilisée. Cette erreur peut être résolue en mettant à niveau la licence à un nombre plus élevé d'utilisateurs. La licence utilisateur peut inclure 50, 100 ou un nombre illimité d'utilisateurs si nécessaire.
Error Message - %VPN_HW-4-PACKET_ERROR:
Problème
Le message d'erreur Error Message - %VPN_HW-4-PACKET_ERROR: indique que les paquets ESP avec HMAC reçus par le routeur présentent un problème de correspondance. Cette erreur pourrait être provoquée par ces problèmes :
-
Module H/W VPN défectueux
-
Paquet ESP corrompu
Solution
Afin de résoudre ce message d'erreur :
-
Ignorez les messages d'erreur à moins qu'il y ait interruption du trafic.
-
S'il y a interruption du trafic, remplacez le module.
Message d'erreur : Command rejected: delete crypto connection between VLAN XXXX and XXXX, first.
Problème
Ce message d'erreur apparaît quand vous essayez d'ajouter un VLAN autorisé sur le port d'agrégation d'un commutateur : Command rejected: delete crypto connection between VLAN XXXX and VLAN XXXX, first..
La liaison agrégée de la périphérie WAN ne peut pas être modifiée pour autoriser des VLAN supplémentaires. C'est-à-dire que vous ne pouvez pas ajouter de VLAN dans la liaison agrégée IPSEC VPN SPA.
Cette commande est rejetée, parce que l'autoriser aura comme conséquence une interface VLAN de chiffrement connectée qui appartient à la liste des VLAN autorisés de l'interface, ce qui ouvre une brèche potentielle dans la sécurité d'IPSec. Notez que ce comportement s'applique à tous les ports d'agrégation.
Solution
Au lieu de la commande no switchport trunk allowed vlan (vlanlist), utilisez la commande switchport trunk allowed vlan none ou la commande "switchport trunk allowed vlan remove (vlanlist)".
Error Message - % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Dropping packet - Invalid Window Scale option for session x.x.x.x:27331 to x.x.x.x:23 [Initiator(flag 0,factor 0) Responder (flag 1, factor 2)]
Problème
Cette erreur se produit quand vous essayez de vous connecter au telnet à partir d'un périphérique sur l'extrémité lointaine d'un tunnel VPN ou à partir du routeur lui-même :
Error Message - % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Dropping packet - Invalid Window Scale option for session x.x.x.x:27331 to x.x.x.x:23 [Initiator(flag 0,factor 0) Responder (flag 1, factor 2)]
Solution
La licence utilisateur peut inclure 50, 100 ou un nombre illimité d'utilisateurs si nécessaire. La mise à l'échelle des fenêtres a été ajoutée pour permettre une transmission rapide des données sur des réseaux LFN (Long Fat Network). Ce sont généralement des connexions avec une très grande bande passante, mais également avec une latence élevée. Les réseaux avec des connexions satellites sont un exemple de LFN, puisque les liaisons satellites ont toujours des délais de propagation élevés, mais ont généralement une grande bande passante. Pour permettre à la mise à l'échelle des fenêtres de prendre en charge les LFN, la taille de la fenêtre TCP doit être supérieure à 65 535. Ce message d'erreur peut être résolu en augmentant la taille de la fenêtre TCP pour qu'elle soit supérieure à 65 535.
%ASA-5-305013 : Règles NAT asymétriques jumelées pour l'aval et l'amont. Mettez à jour les flux liés à ce problème
Problème
Ce message d'erreur apparaît une fois que le tunnel VPN est soulevé :
%ASA-5-305013 : Règles NAT asymétriques jumelées pour l'aval et l'amont. Mettez à jour les flux liés à ce problème
Solution
Afin de résoudre ce problème lorsque sur une interface différente que l'hôte utilisant NAT, employez l'adresse appariée au lieu de l'adresse réelle pour se connecter à l'hôte. En outre, activez la commande d'inspection si l'application inclut l'adresse IP.
%PIX|ASA-5-713068 : Message de notification inhabituel reçu : notify_type
Problème
Ce message d'erreur apparaît si le tunnel VPN n'apparaît pas :
%PIX|ASA-5-713068 : Message de notification inhabituel reçu : notify_type
Solution
Ce message se produit en raison de la mauvaise configuration (c'est-à-dire, quand les politiques ou les ACL ne sont pas configurés pour être identiques sur les pairs). Une fois que les politiques et les ACL sont appariés, le tunnel s'affiche sans problème.
%ASA-5-720012 : (VPN-secondaire) Impossible de mettre à jour les données de délai d'exécution de basculement IPSec sur l'équipement de réserve (ou) %-6- : (unité VPN) Impossible de mettre à jour les données de délai d'exécution de basculement IPsec
Problème
Un de ces messages d'erreur apparaît quand vous essayez d'améliorer le dispositif de sécurité adaptable Cisco (ASA) :
%ASA-5-720012 : (VPN-Secondaire) Impossible de mettre à jour les données de délai d'exécution de basculement IPSec sur l'équipement de réserve.
%ASA-6-720012 : (L'unité VPN) n'a pas pu mettre à jour les données de délai d'exécution de basculement IPsec sur l'équipement de réserve.
Solution
Ces messages d'erreur sont des erreurs à titre informatif. Les messages n'affectent pas la fonctionnalité de l'ASA ou du VPN .
Ces messages apparaissent quand le sous-système de basculement du VPN ne peut pas mettre à jour des données d'exécution liées à IPsec parce que le tunnel correspondant d'IPsec a été supprimé sur l'équipement de réserve. Afin de résoudre ces derniers, émettez la commande de mise en attente wr sur l'unité active.
Deux bogues ont été enregistrés pour régler les problèmes causés par ce comportement et mettre à niveau une version logicielle d'ASA où ces bogues ont été réparés. Référez-vous aux tj et tn CSC d'ID de bogues Cisco (clients enregistrés seulement) pour de plus amples renseignements.
Erreur : - %ASA-3-713063 : Adresse de pair IKE non configurée pour la destination 0.0.0.0
Problème
Le %ASA-3-713063 : L'adresse de pair IKE non configurée pour le message d'erreur de 0.0.0.0 destination apparaît et le tunnel n'apparaît pas.
Solution
Ce message apparaît quand l'adresse de pair IKE n'est pas configurée pour un tunnel L2L . Cette erreur peut être résolue en changeant le numéro de séquence de la carte crypto, puis en retirant et en réappliquant la carte crypto.
Erreur : %ASA-3-752006 : Le gestionnaire de tunnels n'a pas pu envoyer un message de SAISIE DE CLÉ KEY_ACQUIRE.
Problème
Le %ASA-3-752006 : Le gestionnaire de tunnel n'a pas pu envoyer un message KEY_ACQUIRE.Erreur probable de configuration de la carte de chiffrement ou du groupe de tunnels. » le message d'erreur est obtenu sur Cisco ASA.
Solution
Ce message d'erreur peut être causé par par une mauvaise configuration de la carte de chiffrement ou du groupe de tunnels. Assurez-vous que les deux sont configurés correctement. Pour plus d'informations sur ce message d'erreur, référez-vous à l'erreur 752006 .
Voici certaines des actions correctives :
-
Retirez l'ACL chiffré (par exemple, lié à la carte dynamique).
-
Retirez la configuration IKE liée à v2 inutilisée, le cas échéant.
-
Vérifiez que l'ACL chiffré est correctement assorti.
-
Retirez les entrées de liste d'accès en double, le cas échéant.
Erreur : %ASA-4-402116 : IPSEC : Paquet ESP reçu (SPI= 0x99554D4E, numéro d'ordre= 0x9E) de la part de XX.XX.XX.XX (utilisateur= XX.XX.XX.XX) à YY.YY.YY.YY
Dans une installation tunnel LAN à LAN VPN, cette erreur est reçue sur une extrémité ASA :
Le paquet interne désencapsulé ne correspond pas à la politique négociée dans la SA.
Le paquet spécifie sa destination à 10.32.77.67, sa source à 10.105.30.1 et son protocole à icmp.
SA spécifie son proxy local à 10.32.77.67/255.255.255.255/ip/0 et son remote_proxy (proxy distant) à 10.105.42.192/255.255.255.224/ip/0.
Solution
Vous devez vérifier les listes d'accès du trafic intéressant définies sur les deux extrémités du tunnel VPN. Chacun des deux devraient s'assortir en tant qu'images miroir exactes.
Pour lancer l'installateur 64-bit VA afin d'activer l'adaptateur virtuel dû à l'erreur 0xffffffff
Problème
Pour lancer l'installateur 64-bit VA afin d'activer l'adaptateur virtuel dû au message d'erreur de connexion 0xffffffff est reçu quand AnyConnect ne parvient pas à établir une connexion.
Solution
Procédez comme suit pour résoudre ce problème :
-
Allez aux réglages System (système) > Internet Communication Management (Gestion de la communication Internet) > Internet Communication (Communication Internet) et assurez-vous de désactiver<b>
-
S'il est désactivé, alors désactivez toute la partiedu modèle administratif du GPO attribué à l'ordinateur et retestez-le.
Référez-vous à Désactiver la mise à jour 
automatique des certificats racine pour plus d'informations.
Erreur 5 : Aucun nom d'hôte n'existe pour cette entrée de connexion. Impossible d'établir la connexion VPN.
Problème
Erreur 5 : Aucun nom d'hôte n'existe pour cette entrée de connexion. Le message d'erreur Incapable d'effectuer la connexion VPN est reçu à l'installation d'un nouveau PC.
Solution
Cette question est due à l'ID de bogue Cisco CSCso94244 (clients enregistrés seulement). Référez-vous à ce bogue pour plus d'informations.
Le Client VPN Cisco ne fonctionne pas avec la carte mécanographique sur le Windows 7
Problème
Le client VPN Cisco ne fonctionne pas avec la carte de données sur Windows 7.
Solution
Le Client VPN Cisco installé sur le Windows 7 ne fonctionne pas avec les connexions 3G puisque des cartes de données ne sont pas prises en charge sur des clients VPN installés sur un ordinateur Windows 7.
Message d'avertissement : « Cette fonctionnalité VPN pourrait ne pas du tout fonctionner »
Problème
En essayant d'activer l'ISAKMP sur l'interface extérieure de l'ASA, ce message d'avertissement est reçu :
ASA(config)# crypto isakmp enable outside WARNING, system is running low on memory. Performance may start to degrade. VPN functionality may not work at all.
En ce moment, l'accès à l'ASA se fait par ssh. HTTPS est arrêté et d'autres clients SSL sont également touchés.
Solution
Ce problème est dû aux mémoires requises par différents modules tels que le module de connexion (logger) et de chiffrement (crypto). Assurez-vous que vous n'avez pas la commande logging queue 0. Il règle le groupe de files d'attente à 8192 et l'attribution de la mémoire monte en flèche.
Dans des plateformes telles qu'ASA5505 et ASA5510, cette allocation de mémoire tend à accaparer la mémoire d'autres modules (IKE et etc.). L'ID de bogue Cisco CSCtb58989 (clients enregistrés seulement) a été enregistré pour régler ce genre de comportement. Afin de résoudre ceci, configurez la queue de connexion à valeur inférieure, telle que 512.
Erreur de remplissage d'IPSec
Problème
Ce message d'erreur est reçu :
%PIX|ASA-3-402130: CRYPTO: Received an ESP packet (SPI = 0xXXXXXXX, sequence number= 0xXXXX) from x.x.x.x (user= user) to y.y.y.y with incorrect IPsec padding
Solution
La question se produit parce que l'IPSec du VPN négocie sans algorithme de hachage. Le hachage de paquet assure le contrôle d'intégrité pour le canal de l'ESP. Par conséquent, sans hacher, des paquets mal conformés sont reçus non détectés par Cisco ASA qui tente de déchiffrer ces paquets. Cependant, parce que ces paquets comportent des malformations, l'ASA trouve des imperfections tout en déchiffrant le paquet. Ceci entraîne les messages d'erreur de remplissage qui sont observés.
La recommandation est d'inclure un algorithme de hachage dans la série de transformations pour le VPN et de s'assurer que le lien entre les pairs comporte le nombre minimal de malformations de paquet.
Temps de retard dû au temps mort sur les téléphones des sites distants
Problème
Il y a un temps mort sur les téléphones de sites distants. Comment résoudre ce problème ?
Solution
Désactivez l'inspection SCCP et SIP afin de résoudre ce problème :
asa(config)# no inspect sip asa(config)# no inspect skinny
Le tunnel VPN se déconnecte après 18 heures.
Problème
Le tunnel VPN se fait déconnecter après 18 heures même si la durée de vie est de 24 heures.
Solution
La durée de vie est le temps maximum que la SA peut être utilisée pour la réintroduction d'une clé. La valeur que vous écrivez dans la configuration, car la durée de vie est différente de la période de réintroduction d'une clé de SA. Par conséquent, il est nécessaire de négocier une nouvelle SA (ou paire de SA dans le cas d'IPsec) avant que l'actuelle expire. Le temps de réintroduction d'une clé doit toujours être plus petit que la durée de vie afin de permettre plusieurs tentatives au cas où la première tentative de réintroduction d'une clé échouerait. Les RFC ne spécifient pas comment calculer le temps de réintroduction d'une clé. Ceci est laissé à la discrétion des responsables de l'implantation. Par conséquent, le temps variera selon la plateforme utilisée, quelle version de logiciel, etc.
Quelques implantation peuvent employer un facteur aléatoire pour calculer le temporisateur de réintroduction d'une clé. Par exemple, si l'ASA lance le tunnel, puis il est normal qu'il réintroduira une clé à 64 800 secondes = 75 % de 86 400. Si les initiés de routeur, alors l'ASA peut attendre plus longtemps avant de donner au pair plus de temps pour redonner une clé. Ainsi, il est normal que la session VPN se déconnecte toutes les 18 heures pour utiliser une autre clé pour la négociation VPN. Ceci ne doit poser aucune baisse ou problème VPN.
Le flux de trafic n'est pas maintenu après la renégociation du tunnel LAN à LAN.
Problème
Le flux de trafic n'est pas maintenu après que le tunnel LAN à LAN soit renégocié.
Solution
L'ASA surveille chaque connexion qui la traverse et met à jour une entrée dans sa table d'état selon la fonction d'inspection d'applications. Les détails chiffrés du trafic qui traversent le VPN sont mis à jour sous forme de base de données de l'association de sécurité (SA). Des connexions de réseau local aux connexions de réseau privé virtuel local, deux flux de trafic différents sont mis à jour. L'une est le trafic chiffré entre les passerelles VPN. L'autre est la circulation entre la ressource de réseau derrière la passerelle VPN et l'utilisateur derrière l'autre extrémité. Quand la commexion VPN se termine, les détails d'écoulement pour cette SA particulière sont supprimés. Cependant, l'entrée du tableau d'état mis à jour par l'ASA pour cette connexion TCP devient éventée en raison de l'absence d'activité, qui entrave le téléchargement. Ceci signifie que l'ASA retiendra toujours la connexion TCP pour ce flux particulier tandis que l'application utilisateur se termine. Cependant, les connexions TCP deviendront erratiques et éventuellement s'interrompre après que le seuil du délai d'inactivité TCP est franchi.
Ce problème a été résolu en introduisant une caractéristique appelée flux IPSec en tunnel persistents. Une nouvelle commande, sysopt connection preserve-vpn-flows, a été intégrée dans l'ASA de Cisco afin de retenir les données du tableau d'état à la renégociation du tunnel VPN . Par défaut, cette commande est désactivée. En activant ceci, l'ASA de Cisco mettra à jour les données de tableau d'état de TCP quand le VPN de L2L récupère de l'interruption et rétablit le tunnel.
Le message d'erreur indique que la bande passante est atteinte pour la fonctionnalité de chiffrage.
Problème
Ce message d'erreur est reçu sur le routeur de série 2900 :
Erreur : 20 mars 10:51:29 : %CERM-4-TX_BW_LIMIT : La limite de bande passante Tx maximale de 85 000 Kbit/sec atteinte pour la fonctionnalité crypto avec la technologie de la licence securityk9.
Solution
C'est un problème connu qui se produit en raison des instructions strictes émises par le gouvernement des États-Unis. Selon ceci, la licence securityk9 peut seulement permettre un cryptage de données utiles jusqu'aux débits près de 90 Mbit/s et limiter le nombre de sessions TLS/tunnels chiffrés vers le périphérique. Pour plus d'informations sur les restrictions à l'exportation de crypto, référez-vous à à la licence Cisco ISR G2 SEC et HSEC.
Pour les périphériques Cisco, il est dérivé pour être moins que le trafic 85 Mbit/sec unidirectionnel dans ou hors du routeur ISR G2, avec un total bidirectionnel de 170 Mbit/sec. Cette condition requise s'applique aux plateformes Cisco 1900, 2900, 3900 et G2. Cette commande vous aide à visualiser ces limites :
Router#show platform cerm-information Crypto Export Restrictions Manager(CERM) Information: CERM functionality: ENABLED ---------------------------------------------------------------- Resource Maximum Limit Available ---------------------------------------------------------------- Tx Bandwidth(in kbps) 85000 85000 Rx Bandwidth(in kbps) 85000 85000 Number of tunnels 225 225 Number of TLS sessions 1000 1000 ---Output truncated----
Il y a un bogue classé pour contrer ce comportement. Référez-vous au CSC tu de l'ID de bogue Cisco pour en savoir plus (clients enregistrés seulement) pour plus de renseignements.
Afin d'éviter ce problème, vous devez acheter une licence HSECK9. Une licence de fonction « hseck9 » fournit à la fonctionnalité améliorée de cryptage des données utiles avec un plus grand nombre de tunnels VPN et les sessions de voix sécurisée. Pour plus d'informations sur la licence de routeur Cisco, référez-vous à l'activation du logiciel.
Problème : Le trafic de chiffrage sortant dans un tunnel IPsec risque d'échouer, même si le trafic de déchiffrement entrant fonctionne.
Solution
Ce problème a été observé sur une connexion d'IPsec après plusieurs recompositions, mais la condition de déclenchement n'est pas claire. La présence de ce problème peut être établie en vérifiant l'affichage de la commande show asp drop et en vérifiant que le compteur VPN de contexte expiré augmente pour chaque paquet sortant envoyé. Référez-vous au td d'ID de bogue Cisco (clients enregistrés seulement) pour en savoir plus.
Divers
Un message AG_INIT_EXCH apparaît dans la sortie des commandes « show crypto isakmp sa » et « debug »
Si le tunnel n'est pas initié, le message AG_INIT_EXCH apparaît dans la sortie des commandes show crypto isakmp sa et debug. La raison peut être la non correspondance de stratégies isakmp ou le blocage du port UDP 500.
Le message de débogage « Received an IPC message during invalid state » apparaît
Il s'agit d'un message d'information et n'est en rien lié à la déconnexion du tunnel VPN.
Informations connexes
- Problème avec PIX/ASA 7.0 : MSS dépassée - Les clients HTTP ne peuvent pas accéder à certains sites Web
- PIX/ASA 7.x et IOS : Fragmentation VPN
- Dispositifs de sécurité de la gamme Cisco ASA 5500
- Dispositifs de sécurité de la gamme Cisco PIX 500
- Négociation IPSec/Protocoles IKE
- Concentrateurs VPN de la gamme Cisco 3000
- Support et documentation techniques - Cisco Systems
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
31-Mar-2014 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)