Problème
Un tunnel VTI (Virtual Tunnel Interface) configuré pour un accès sécurisé sur un routeur CAT8500 affiche IPsec SA comme établi lors de la vérification avec show crypto ipsec sa, mais l'état de l'AS IKEv2 reste en négociation lorsqu'il est visualisé avec show crypto ikev2 sa. Le protocole de ligne d'interface du tunnel est désactivé et le côté d'accès sécurisé indique que la connexion est déconnectée, ce qui empêche l'établissement correct du tunnel.
Environnement
- Gamme de produits : CAT8500
- Version du logiciel: 17.15.4c
- Technologie : Tunnels réseau d'accès sécurisé (IPsec, site à site)
- Type de tunnel : VTI (Virtual Tunnel Interface)
- Version IKE : IKEv2
Résolution
Selon nos paramètres ipsec pris en charge -
Les valeurs recommandées sont 19,20 pour le groupe DH.
crypto ikev2 proposition csse-G256
cryptage aes-gcm-256
prf sha256
groupe 19 21. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Ceci nécessite un changement à 19,20
Porte-clés -
crypto ikev2 porte-clés csse_useast
homologue csse_virginia1
address x.x.x.x <<<<<<<<<<<<<<<<< Secure Access DC
pre-shared-key local <supprimé>
pre-shared-key remote <supprimé>
!
Profil - identité locale de correspondance manquante qui serait l'ID de tunnel de l'interface utilisateur CSA lorsque nous créons un groupe de tunnels réseau.
crypto ikev2 profile csse_virginia1
match identity remote address x.x.x.x 255.255.255.255
authentication remote pre-share
authentication local pre-share
porte-clés local csse_useast
!
Une fois que vous avez modifié le groupe DH, le problème d’identité locale de correspondance ajouté est résolu.
Motif
La cause principale de ce problème est généralement une configuration d'identité locale manquante ou incorrecte dans le profil IKEv2. Secure Access nécessite des paramètres d'identité spécifiques pour établir correctement la négociation IKEv2. En outre, l'utilisation de groupes Diffie-Hellman non pris en charge (autres que 19 et 20) peut empêcher la négociation IKEv2 avec Secure Access.
Autres informations utiles
Commentaires