Dépannage du téléphone VPN AnyConnect - téléphones IP, ASA et CUCM

Introduction

  

Ce document décrit comment dépanner des problèmes avec des téléphones IP qui utilisent le protocole SSL (Secure Sockets Layer) (client Cisco AnyConnect Secure Mobility) afin de se connecter à un dispositif de sécurité adaptatif Cisco (ASA) qui est utilisé comme passerelle VPN et afin de se connecter à un Cisco Unified Communications Manager (CUCM) qui est utilisé comme serveur vocal.

  

Pour obtenir des exemples de configuration d'AnyConnect avec des téléphones VPN, reportez-vous aux documents suivants :

  

• Exemple de configuration de SSLVPN avec des téléphones IP
  
  
• Exemple de configuration d'un téléphone VPN AnyConnect avec authentification par certificat

  

Informations générales

  

Avant de déployer le VPN SSL avec des téléphones IP, vérifiez que vous avez satisfait à ces exigences initiales pour les licences AnyConnect pour l'ASA et pour la version à exportation restreinte aux États-Unis du CUCM.

  

Confirmer la licence du téléphone VPN sur ASA

  

La licence de téléphone VPN active la fonctionnalité dans l'ASA. Afin de confirmer le nombre d'utilisateurs qui peuvent se connecter à AnyConnect (qu'il s'agisse ou non d'un téléphone IP), vérifiez la licence SSL AnyConnect Premium. Référez-vous à Quelle licence ASA est nécessaire pour les connexions de téléphone IP et VPN mobile ? pour plus de détails.

  

Sur l'ASA, utilisez la commande show version afin de vérifier si la fonctionnalité est activée. Le nom de la licence diffère de celui de la version ASA :

  

• ASA version 8.0.x : le nom de licence est AnyConnect pour téléphone Linksys.
  
  
• ASA version 8.2.x et ultérieure : le nom de la licence est AnyConnect pour téléphone VPN Cisco.

  

Voici un exemple pour ASA version 8.0.x :

  

ASA5505(config)# show ver

Cisco Adaptive Security Appliance Software Version 8.0(5)
Device Manager Version 7.0(2)
<snip>
Licensed features for this platform:
VPN Peers                    : 10
WebVPN Peers                 : 2
AnyConnect for Linksys phone : Disabled
<snip>
This platform has a Base license.

  

Voici un exemple pour les versions 8.2.x et ultérieures d'ASA :

  

ASA5520-C(config)# show ver

Cisco Adaptive Security Appliance Software Version 9.1(1)
Device Manager Version 7.1(1)
<snip>
Licensed features for this platform:
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
AnyConnect for Cisco VPN Phone    : Disabled       perpetual
<snip>
This platform has an ASA 5520 VPN Plus license.

  

Exportation restreinte et exportation non restreinte CUCM

  

Vous devez déployer une version de CUCM à exportation restreinte aux États-Unis pour la fonctionnalité de téléphone VPN.

  

Si vous utilisez une version non restreinte de CUCM exportée aux États-Unis, notez que :

  

• Les configurations de sécurité des téléphones IP sont modifiées afin de désactiver la signalisation et le chiffrement des supports ; cela inclut le chiffrement fourni par la fonctionnalité de téléphone VPN.
  
  
• Vous ne pouvez pas exporter les détails VPN via Import/Export.
  
  
• Les cases à cocher Profil VPN, Passerelle VPN, Groupe VPN et Configuration de fonctionnalité VPN ne sont pas affichées.

  

Remarque : une fois que vous avez effectué la mise à niveau vers la version non restreinte à l'exportation américaine de CUCM, vous ne pouvez pas effectuer une mise à niveau ultérieure vers la version restreinte à l'exportation américaine de ce logiciel ou effectuer une nouvelle installation de celle-ci.

  

Problèmes courants sur l'ASA

  

Remarque : vous pouvez utiliser Cisco CLI Analyzer (clients enregistrés uniquement) pour afficher une analyse des résultats de la commande show. Vous devez également vous reporter au document Informations importantes sur les commandes de débogage de Cisco avant d'utiliser les commandes de débogage.

  

Certificats à utiliser sur l'ASA

  

Sur l'ASA, vous pouvez utiliser des certificats SSL auto-signés, des certificats SSL tiers et des certificats génériques ; chacun de ces éléments sécurise la communication entre le téléphone IP et l'ASA.

  

Un seul certificat d'identité peut être utilisé, car un seul certificat peut être attribué à chaque interface.

  

Pour les certificats SSL tiers, installez la chaîne complète dans l'ASA et incluez tous les certificats intermédiaires et racine.

  

Trustpoint/Certificat pour l'exportation ASA et l'importation CUCM

  

Le certificat que l'ASA présente au téléphone IP pendant la négociation SSL doit être exporté à partir de l'ASA et importé dans le CUCM. Vérifiez le point de confiance attribué à l'interface à laquelle les téléphones IP se connectent afin de savoir quel certificat exporter à partir de l'ASA.

  

Utilisez la commande show run ssl afin de vérifier le point de confiance (certificat) à exporter. Référez-vous à Exemple de configuration de téléphone VPN AnyConnect avec authentification de certificat pour plus d'informations.

  

Remarque : si vous avez déployé un certificat tiers sur un ou plusieurs ASA, vous devez exporter chaque certificat d'identité de chaque ASA, puis l'importer dans le CUCM en tant que phone-vpn-trust.

  

ASA présente le certificat autosigné ECDSA au lieu du certificat RSA configuré

  

Lorsque ce problème se produit, les téléphones des modèles plus récents ne peuvent pas se connecter, tandis que les téléphones des modèles plus anciens ne rencontrent aucun problème. Voici les journaux sur le téléphone lorsque ce problème se produit :

  

VPNC: -protocol_handler: SSL dpd 30 sec from SG (enabled)
VPNC: -protocol_handler: connect: do_dtls_connect
VPNC: -do_dtls_connect: udp_connect
VPNC: -udp_connect: getsockname failed
VPNC: -udp_connect: binding sock to eth0 IP 63.85.30.39
VPNC: -udp_connect: getsockname failed
VPNC: -udp_connect: connecting to 63.85.30.34:443
VPNC: -udp_connect: connected to 63.85.30.34:443
VPNC: -do_dtls_connect: create_dtls_connection
VPNC: -create_dtls_connection: cipher list: AES256-SHA
VPNC: -create_dtls_connection: calling SSL_connect in non-block mode
VPNC: -dtls_state_cb: DTLS: SSL_connect: before/connect initialization
VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 write client hello A
VPNC: -dtls_state_cb: DTLS: SSL_connect: DTLS1 read hello verify request A
VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 write client hello A
VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 flush data
VPNC: -dtls_state_cb: DTLS: write: alert: fatal:illegal parameter
VPNC: -vpnc_set_notify_netsd : cmd: 0x5 event: 0x40000 status: 0x0 error: 0x0 
VPNC: -alert_err: DTLS write alert: code 47, illegal parameter
VPNC: -create_dtls_connection: SSL_connect ret -1, error 1
VPNC: -DTLS: SSL_connect: SSL_ERROR_SSL (error 1)
VPNC: -DTLS: SSL_connect: error:140920C5:SSL routines:SSL3_GET_SERVER_HELLO:
 old session cipher not returned
VPNC: -create_dtls_connection: DTLS setup failure, cleanup
VPNC: -do_dtls_connect: create_dtls_connection failed
VPNC: -protocol_handler: connect: do_dtls_connect failed
VPNC: -protocol_handler: connect : err: SSL success DTLS fail

  

Dans les versions 9.4.1 et ultérieures, la cryptographie à courbe elliptique est prise en charge pour SSL/TLS. Lorsqu'un client VPN SSL prenant en charge les courbes elliptiques, tel qu'un nouveau modèle de téléphone, se connecte à l'ASA, la suite de chiffrement à courbe elliptique est négociée et l'ASA présente au client VPN SSL un certificat de courbe elliptique, même lorsque l'interface qui correspond est configurée avec un point de confiance basé sur RSA. Afin d'empêcher l'ASA de présenter un certificat SSL auto-signé, l'administrateur doit supprimer les suites de chiffrement qui correspondent via la commande ssl cipher. Par exemple, pour une interface configurée avec un point de confiance RSA, l'administrateur peut exécuter cette commande afin que seuls les chiffrements basés sur RSA soient négociés :

  

ssl cipher tlsv1.2 custom "AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA"

  

Avec l'implémentation de l'ID de bogue Cisco CSCuu02848, la priorité est donnée à la configuration. Les certificats explicitement configurés sont toujours utilisés. Les certificats auto-signés ne sont utilisés qu'en l'absence d'un certificat configuré.

  

Chiffres client proposés	Certificat RSA uniquement	Cert. CE uniquement	Les deux certifications	Aucune
Chiffres RSA uniquement	Utilise le certificat RSA Utilise des chiffrements RSA	Utilise un certificat autosigné RSA Utilise des chiffrements RSA	Utilise le certificat RSA Utilise des chiffrements RSA	Utilise un certificat autosigné RSA Utilise des chiffrements RSA
Chiffres EC uniquement (rare)	Échec de connexion	Utilise le certificat EC Utilise des chiffrements EC	Utilise le certificat EC Utilise des chiffrements EC	Utilise un certificat autosigné CE Utilise des chiffrements EC
Les deux chiffrements uniquement	Utilise le certificat RSA Utilise des chiffrements RSA	Utilise le certificat EC Utilise des chiffrements EC	Utilise le certificat EC Utilise des chiffrements EC	Utilise un certificat autosigné CE Utilise des chiffrements EC

  

Base de données externe pour l'authentification des utilisateurs de téléphones IP

  

Vous pouvez utiliser une base de données externe afin d'authentifier les utilisateurs de téléphones IP. Des protocoles tels que LDAP (Lightweight Directory Access Protocol) ou RADIUS (Remote Authentication Dial In User Service) peuvent être utilisés pour l'authentification des utilisateurs de téléphones VPN.

  

Correspondances de hachage de certificat entre le certificat ASA et la liste de confiance du téléphone VPN

  

N'oubliez pas que vous devez télécharger le certificat attribué à l'interface SSL ASA et le télécharger en tant que certificat Phone-VPN-Trust dans le CUCM. Dans des circonstances différentes, le hachage de ce certificat présenté par l'ASA peut ne pas correspondre au hachage généré par le serveur CUCM et transmis au téléphone VPN via le fichier de configuration.

  

Une fois la configuration terminée, testez la connexion VPN entre le téléphone IP et l'ASA. Si la connexion continue d'échouer, vérifiez si le hachage du certificat ASA correspond au hachage attendu par le téléphone IP :

  

1. Vérifiez le hachage SHA1 (Secure Hash Algorithm 1) présenté par l'ASA.
   
   
2. Utilisez TFTP afin de télécharger le fichier de configuration du téléphone IP à partir du CUCM.
   
   
3. Décodez le hachage de la valeur hexadécimale à la base 64 ou de la base 64 à la valeur hexadécimale.

  

Vérifier le hachage SHA1

  

L'ASA présente le certificat appliqué avec la commande ssl trustpoint sur l'interface à laquelle le téléphone IP se connecte. Pour vérifier ce certificat, ouvrez le navigateur (dans cet exemple, Firefox) et entrez l'URL (group-url) à laquelle les téléphones doivent se connecter :

  

  

Télécharger le fichier de configuration du téléphone IP

  

À partir d'un PC avec accès direct au CUCM, téléchargez le fichier de configuration TFTP du téléphone présentant des problèmes de connexion. Deux méthodes de téléchargement sont disponibles :

  

1. Ouvrez une session CLI sous Windows et utilisez la commande tftp -i <TFTP Server> GET SEP<Phone Mac Address>.cnf.xml.
   

   Remarque : si vous recevez une erreur similaire à celle ci-dessous, vous devez confirmer que la fonctionnalité Client TFTP est activée.

   
   
   
   
   
2. Utilisez une application telle que Tftpd32 pour télécharger le fichier :
   
   
   
   
3. Une fois le fichier téléchargé, ouvrez le fichier XML et recherchez la configuration vpnGroup. Cet exemple montre la section et le certHash à vérifier :
   
   

   <vpnGroup>
   <mtu>1290</mtu>
   <failConnectTime>30</failConnectTime>
   <authMethod>2</authMethod>
   <pswdPersistent>0</pswdPersistent>
   <autoNetDetect>0</autoNetDetect>
   <enableHostIDCheck>0</enableHostIDCheck>
   <addresses>
   <url1>https://10.198.16.140/VPNPhone</url1>
   </addresses>
   <credentials>
   <hashAlg>0</hashAlg>
   
            
            
              5X6B6plUwUSXZnjQ4kGM33mpMXY= 
            
   </credentials>
   </vpnGroup>

  

Décoder le hachage

  

Vérifiez que les deux valeurs de hachage correspondent. Le navigateur présente le hachage au format hexadécimal, tandis que le fichier XML utilise la base 64, donc convertissez un format à l'autre afin de confirmer la correspondance. Il existe de nombreux traducteurs disponibles ; par exemple, TRANSLATOR, BINARY .

  

  

Remarque : si la valeur de hachage précédente ne correspond pas, le téléphone VPN n'approuve pas la connexion négociée avec l'ASA et la connexion échoue.

  

Équilibrage de charge VPN et téléphones IP

  

Le VPN SSL avec équilibrage de charge n'est pas pris en charge pour les téléphones VPN. Les téléphones VPN n'effectuent pas de véritable validation de certificat, mais utilisent plutôt des hachages poussés vers le bas par le CUCM pour valider les serveurs. Comme l’équilibrage de charge VPN est essentiellement une redirection HTTP, il nécessite que les téléphones valident plusieurs certificats, ce qui entraîne un échec. Les symptômes d'une panne d'équilibrage de charge VPN sont les suivants :

  

• Le téléphone alterne entre les serveurs et met un temps exceptionnellement long à se connecter, voire échoue.
  
  
• Les journaux téléphoniques contiennent des messages tels que :
  
  

  909: NOT 20:59:50.051721 VPNC: do_login: got login response
  910: NOT 20:59:50.052581 VPNC: process_login: HTTP/1.0 302 Temporary moved
  911: NOT 20:59:50.053221 VPNC: process_login: login code: 302 (redirected)
  912: NOT 20:59:50.053823 VPNC: process_login: redirection indicated
  913: NOT 20:59:50.054441 VPNC: process_login: new 'Location': 
     /+webvpn+/index.html
  914: NOT 20:59:50.055141 VPNC: set_redirect_url: new URL 
     <https://xyz1.abc.com:443/+webvpn+/index.html>

  

CSD et téléphones IP

  

Actuellement, les téléphones IP ne prennent pas en charge Cisco Secure Desktop (CSD) et ne se connectent pas lorsque CSD est activé pour le groupe de tunnels ou globalement dans l'ASA.

  

Tout d'abord, vérifiez si le CSD est activé sur l'ASA. Entrez la commande show run webvpn dans l'interface de ligne de commande ASA :

  

ASA5510-F# show run webvpn
webvpn
 enable outside
 csd image disk0:/csd_3.6.6210-k9.pkg
csd enable
 anyconnect image disk0:/anyconnect-win-3.1.00495-k9.pkg 1
 anyconnect enable
ASA5510-F#

  

Afin de vérifier les problèmes de CSD pendant une connexion de téléphone IP, vérifiez les journaux ou les débogages dans l'ASA.

  

Journaux ASA

  

%ASA-4-724002: Group <VPNPhone> User <Phone> IP <172.6.250.9> WebVPN session not 
   terminated. Cisco Secure Desktop was not running on the client's workstation.

Débogage de l’ASA

  

debug webvpn anyconnect 255
<snip>
Tunnel Group: VPNPhone, Client Cert Auth Success.
WebVPN: CSD data not sent from client
http_remove_auth_handle(): handle 24 not found!
<snip>

  

Remarque : dans un déploiement de grande envergure avec une charge élevée d'utilisateurs AnyConnect, Cisco recommande de ne pas activer la commande debug webvpn anyconnect. Sa sortie ne peut pas être filtrée par adresse IP, donc une grande quantité d'informations peut être créée.

  

Dans ASA versions 8.2 et ultérieures, vous devez appliquer la commande without-csd sous les attributs webvpn du groupe de tunnels :

  

tunnel-group VPNPhone webvpn-attributes
 authentication certificate
 group-url https://asa5520-c.cisco.com/VPNPhone enable
 without-csd

  

Dans les versions précédentes de l'ASA, cela n'était pas possible, de sorte que la seule solution de contournement était de désactiver le CSD globalement.

  

Dans Cisco Adaptive Security Device Manager (ASDM), vous pouvez désactiver CSD pour un profil de connexion spécifique, comme indiqué dans cet exemple :

  

  

Remarque : utilisez une url de groupe afin de désactiver la fonctionnalité CSD.

  

Règles DAP

  

La plupart des déploiements connectent non seulement des téléphones IP à l'ASA, mais également différents types de machines (Microsoft, Linux, Mac OS) et d'appareils mobiles (Android, iOS). Pour cette raison, il est normal de trouver une configuration existante de règles de stratégie d'accès dynamique (DAP), où, la plupart du temps, l'action par défaut sous la stratégie d'accès dynamique (DfltAccessPolicy) est la fin de la connexion.

  

Si c'est le cas, créez une règle DAP distincte pour les téléphones VPN. Utilisez un paramètre spécifique, tel que le profil de connexion, et définissez l'action sur Continuer :

  

  

Si vous ne créez pas de stratégie DAP spécifique pour les téléphones IP, l'ASA affiche une réponse positive sous la stratégie DfltAccessPolicy et une connexion défaillante :

  

%ASA-6-716038: Group <DfltGrpPolicy> User <CP-7962G-SEP8CB64F576113> IP 
   <172.16.250.9> Authentication: successful, Session Type: WebVPN.
%ASA-7-734003: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9: Session 
   Attribute aaa.cisco.grouppolicy = GroupPolicy_VPNPhone
<snip>
%ASA-6-734001: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9, 
   Connection AnyConnect: The following DAP records were selected for this 
   connection: DfltAccessPolicy
%ASA-5-734002: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9: Connection 
   terminated by the following DAP records: DfltAccessPolicy

  

Une fois que vous avez créé une stratégie DAP spécifique pour les téléphones IP avec l'action définie sur Continue, vous pouvez vous connecter :

  

%ASA-7-746012: user-identity: Add IP-User mapping 10.10.10.10 - 
   LOCAL\CP-7962G-SEP8CB64F576113 Succeeded - VPN user
%ASA-4-722051: Group <GroupPolicy_VPNPhone> User <CP-7962G-SEP8CB64F576113> IP 
   <172.16.250.9> Address <10.10.10.10> assigned to session
%ASA-6-734001: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9, Connection 
   AnyConnect: The following DAP records were selected for this connection: VPNPhone

  

Valeurs héritées de DfltGrpPolicy ou d'autres groupes

  

Dans de nombreux cas, DfltGrpPolicy est configuré avec plusieurs options. Par défaut, ces paramètres sont hérités pour la session de téléphone IP, sauf s'ils sont spécifiés manuellement dans la stratégie de groupe que le téléphone IP doit utiliser.

  

Certains paramètres qui peuvent affecter la connexion s'ils sont hérités de DfltGrpPolicy sont :

  

• verrouillage de groupe
  
  
• vpn-tunnel-protocol
  
  
• vpn-simultanément-logins
  
  
• vpn-filter

  

Supposez que vous avez cet exemple de configuration dans DfltGrpPolicy et GroupPolicy_VPNPhone :

  

group-policy DfltGrpPolicy attributes
 vpn-simultaneous-logins 0
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-clientless
 group-lock value DefaultWEBVPNGroup
 vpn-filter value NO-TRAFFIC

group-policy GroupPolicy_VPNPhone attributes
 wins-server none
 dns-server value 10.198.29.20
 default-domain value cisco.com

  

La connexion hérite des paramètres de DfltGrpPolicy qui n'ont pas été explicitement spécifiés sous GroupPolicy_VPNPhone et transmet toutes les informations au téléphone IP pendant la connexion.

  

Afin d'éviter cela, spécifiez manuellement la ou les valeurs dont vous avez besoin directement dans le groupe :

  

group-policy GroupPolicy_VPNPhone internal
group-policy GroupPolicy_VPNPhone attributes
 wins-server none
 dns-server value 10.198.29.20
 vpn-simultaneous-logins 3
 vpn-tunnel-protocol ssl-client
 group-lock value VPNPhone
 vpn-filter none
 default-domain value cisco.com

  

Afin de vérifier les valeurs par défaut de DfltGrpPolicy, utilisez la commande show run all group-policy ; cet exemple clarifie la différence entre les sorties :

  

ASA5510-F# show run group-policy DfltGrpPolicy
group-policy DfltGrpPolicy attributes
 dns-server value 10.198.29.20 10.198.29.21
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless
 default-domain value cisco.com
ASA5510-F#


ASA5510-F# sh run all group-policy DfltGrpPolicy
group-policy DfltGrpPolicy internal
group-policy DfltGrpPolicy attributes
 banner none
 wins-server none
 dns-server value 10.198.29.20 10.198.29.21
 dhcp-network-scope none
 vpn-access-hours none
 vpn-simultaneous-logins 3
 vpn-idle-timeout 30
 vpn-idle-timeout alert-interval 1
 vpn-session-timeout none
 vpn-session-timeout alert-interval 1
 vpn-filter none
 ipv6-vpn-filter none
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless

  

Voici le résultat des attributs d'héritage de stratégie de groupe via l'ASDM :

  

  

Chiffres de chiffrement pris en charge

  

Un téléphone VPN AnyConnect testé avec le téléphone IP 7962G et le microprogramme version 9.1.1 ne prend en charge que deux algorithmes de chiffrement, qui sont tous deux des normes de chiffrement avancées (AES) : AES256-SHA et AES128-SHA. Si les chiffres corrects ne sont pas spécifiés dans l'ASA, la connexion est rejetée, comme indiqué dans le journal ASA :

  

%ASA-7-725010: Device supports the following 2 cipher(s).
%ASA-7-725011: Cipher[1] : RC4-SHA
%ASA-7-725011: Cipher[2] : DES-CBC3-SHA
%ASA-7-725008: SSL client outside:172.16.250.9/52684 proposes the following 
   2 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA
%ASA-7-725011: Cipher[2] : AES128-SHA
%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no 
   shared cipher

  

Afin de confirmer si l'ASA a les bons chiffrements activés, entrez les commandes show run all ssl et show ssl :

  

ASA5510-F# show run all ssl
ssl server-version any
ssl client-version any
ssl encryption rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
ssl trust-point SSL outside
ASA5510-F#

ASA5510-F# show ssl
Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1
Start connections using SSLv3 and negotiate to SSLv3 or TLSv1
Enabled cipher order: rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
Disabled ciphers: des-sha1 rc4-md5 dhe-aes128-sha1 dhe-aes256-sha1 null-sha1
SSL trust-points:
  outside interface: SSL
Certificate authentication is not enabled
ASA5510-F#

  

Problèmes communs au CUCM

  

Paramètres VPN non appliqués au téléphone IP

  

Une fois la configuration sur CUCM créée (passerelle, groupe et profil), appliquez les paramètres VPN dans le profil téléphonique commun :

  

1. Accédez à Device > Device Settings > Common Phone Profile.
   
   
   
   
2. Saisissez les informations VPN :
   
   
   
   
3. Accédez à Device > Phone et vérifiez que ce profil est affecté à la configuration du téléphone :
   
   

  

Méthode d'authentification du certificat

  

Il existe deux façons de configurer l'authentification de certificat pour les téléphones IP : le certificat installé par le fabricant (MIC) et le certificat significatif localement (LSC). Référez-vous à Exemple de configuration de téléphone VPN AnyConnect avec authentification de certificat afin de choisir la meilleure option pour votre situation.

  

Lorsque vous configurez l'authentification de certificat, exportez le ou les certificats (autorité de certification racine) à partir du serveur CUCM et importez-les vers l'ASA :

  

1. Connectez-vous au CUCM.
   
   
2. Accédez à Unified OS Administration > Security > Certificate Management.
   
   
3. Recherchez la fonction Proxy de l'autorité de certification (CAPF) ou Cisco_Manufacturing_CA ; le type de certificat dépend de l'utilisation de l'authentification de certificat MIC ou LSC.
   
   
4. Téléchargez le fichier sur l'ordinateur local.

  

Une fois les fichiers téléchargés, connectez-vous à l'ASA via l'interface de ligne de commande ou l'ASDM et importez le certificat en tant que certificat CA.

  

  

Par défaut, tous les téléphones prenant en charge le VPN sont préchargés avec des MIC. Les modèles de téléphones 7960 et 7940 ne sont pas livrés avec un MIC et nécessitent une procédure d'installation spéciale afin que le LSC s'enregistre en toute sécurité.

  

Les derniers téléphones IP Cisco (8811, 8841, 8851 et 8861) incluent des certificats MIC signés par la nouvelle autorité de certification SHA2 de fabrication :

  

• La version 10.5(1) de CUCM inclut et approuve les nouveaux certificats SHA2.
  
  
• Si vous exécutez une version antérieure de CUCM, vous devrez peut-être télécharger le nouveau certificat d'autorité de certification de fabrication et :
  
  
  • Téléchargez-le sur CAPF-trust afin que les téléphones puissent s'authentifier auprès de CAPF afin d'obtenir un LSC.
    
    
  • Téléchargez-le sur CallManager-trust si vous souhaitez autoriser les téléphones à s'authentifier avec un MIC pour SIP 5061.
    
    

Conseil : cliquez sur ce lien afin d'obtenir l'autorité de certification SHA2 si CUCM exécute actuellement une version antérieure.

  

Attention : Cisco recommande d'utiliser les cartes MIC pour l'installation LSC uniquement. Cisco prend en charge les LSC pour l'authentification de la connexion TLS avec le CUCM. Comme les certificats racine MIC peuvent être compromis, les clients qui configurent des téléphones pour utiliser des MIC pour l'authentification TLS ou à toute autre fin le font à leurs propres risques. Cisco décline toute responsabilité en cas de compromission des MIC.

  

Par défaut, si un LSC existe dans le téléphone, l'authentification utilise le LSC, qu'il existe ou non un MIC dans le téléphone. Si un MIC et un LSC existent dans le téléphone, l'authentification utilise le LSC. Si un LSC n'existe pas dans le téléphone, mais qu'un MIC existe, l'authentification utilise le MIC.

  

Remarque : n'oubliez pas que, pour l'authentification de certificat, vous devez exporter le certificat SSL de l'ASA et l'importer dans le CUCM.

  

Vérification de l'ID hôte

  

Si le nom commun (CN) dans l'objet du certificat ne correspond pas à l'URL (group-url) que les téléphones utilisent pour se connecter à l'ASA via le VPN, désactivez la vérification de l'ID d'hôte sur le CUCM ou utilisez un certificat dans l'ASA qui correspond à cette URL sur l'ASA.

  

Cela est nécessaire lorsque le certificat SSL de l'ASA est un certificat générique, que le certificat SSL contient un autre SAN (Subject Alternative Name) ou que l'URL a été créée avec l'adresse IP au lieu du nom de domaine complet (FQDN).

  

Il s'agit d'un exemple de journal de téléphone IP lorsque le CN du certificat ne correspond pas à l'URL que le téléphone tente d'atteindre.

  

1231: NOT 07:07:32.445560 VPNC: DNS has wildcard, starting checks...
1232: ERR 07:07:32.446239 VPNC: Generic third level wildcards are not allowed, 
   stopping checks on host=(test.vpn.com) and dns=(*.vpn.com)
1233: NOT 07:07:32.446993 VPNC: hostID not found in subjectAltNames
1234: NOT 07:07:32.447703 VPNC: hostID not found in subject name
1235: ERR 07:07:32.448306 VPNC: hostIDCheck failed!!

  

Afin de désactiver la vérification de l'ID d'hôte dans CUCM, naviguez vers Advanced Features > VPN > VPN Profile :

  

  

Dépannage supplémentaire

  

Journaux et débogages à utiliser dans l'ASA

  

Sur l'ASA, vous pouvez activer ces débogages et journaux pour le dépannage :

  

logging enable
logging buffer-size 1048576
logging buffered debugging

debug webvpn anyconnect 255

  

Remarque : dans un déploiement de grande envergure avec une charge élevée d'utilisateurs AnyConnect, Cisco recommande de ne pas activer le débogage webvpnh anyconnect. Sa sortie ne peut pas être filtrée par adresse IP, donc une grande quantité d'informations peut être créée.

  

Journaux du téléphone IP

  

Pour accéder aux journaux téléphoniques, activez la fonctionnalité d'accès Web. Connectez-vous à CUCM et accédez à Device > Phone > Phone Configuration. Recherchez le téléphone IP sur lequel vous souhaitez activer cette fonctionnalité et recherchez la section relative à l'accès Web. Appliquez les modifications de configuration au téléphone IP :

  

  

Une fois que vous avez activé le service et réinitialisé le téléphone afin d'injecter cette nouvelle fonctionnalité, vous pouvez accéder aux journaux du téléphone IP dans le navigateur ; utilisez l'adresse IP du téléphone à partir d'un ordinateur ayant accès à ce sous-réseau. Accédez aux journaux de la console et vérifiez les cinq fichiers journaux. Comme le téléphone remplace les cinq fichiers, vous devez vérifier tous ces fichiers afin de trouver les informations que vous recherchez.

  

  

Problèmes corrélés entre les journaux ASA et les journaux de téléphone IP

  

Voici un exemple de corrélation des journaux de l'ASA et du téléphone IP. Dans cet exemple, le hachage du certificat sur l'ASA ne correspond pas au hachage du certificat sur le fichier de configuration du téléphone, car le certificat sur l'ASA a été remplacé par un autre certificat.

  

Journaux ASA

  

%ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with 
   client outside:172.16.250.9/50091
%ASA-7-725014: SSL lib error. Function: SSL3_READ_BYTES Reason: tlsv1 alert 
   unknown ca
%ASA-6-725006: Device failed SSL handshake with client outside:172.16.250.9/50091

  

Journaux téléphoniques

  

 902: NOT 10:19:27.155936 VPNC: ssl_state_cb: TLSv1: SSL_connect: before/connect 
   initialization
 903: NOT 10:19:27.162212 VPNC: ssl_state_cb: TLSv1: SSL_connect: unknown state
 904: NOT 10:19:27.361610 VPNC: ssl_state_cb: TLSv1: SSL_connect: SSLv3 read 
   server hello A
 905: NOT 10:19:27.364687 VPNC: cert_vfy_cb: depth:1 of 1, subject:
    </CN=10.198.16.140/unstructuredName=10.198.16.140>
 906: NOT 10:19:27.365344 VPNC: cert_vfy_cb: depth:1 of 1, pre_err: 18 (self 
   signed certificate)
 907: NOT 10:19:27.368304 VPNC: cert_vfy_cb: peer cert saved: /tmp/leaf.crt
 908: NOT 10:19:27.375718 SECD: Leaf cert hash = 
   1289B8A7AA9FFD84865E38939F3466A61B5608FC
 909: ERR 10:19:27.376752 SECD: EROR:secLoadFile: file not found </tmp/issuer.crt>
 910: ERR 10:19:27.377361 SECD: Unable to open file /tmp/issuer.crt
 911: ERR 10:19:27.420205 VPNC: VPN cert chain verification failed, issuer 
   certificate not found and leaf not trusted
 912: ERR 10:19:27.421467 VPNC: ssl_state_cb: TLSv1: write: alert: fatal:
   unknown CA
 913: ERR 10:19:27.422295 VPNC: alert_err: SSL write alert: code 48, unknown CA
 914: ERR 10:19:27.423201 VPNC: create_ssl_connection: SSL_connect ret -1 error 1
 915: ERR 10:19:27.423820 VPNC: SSL: SSL_connect: SSL_ERROR_SSL (error 1)
 916: ERR 10:19:27.424541 VPNC: SSL: SSL_connect: error:14090086:SSL 
    routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
 917: ERR 10:19:27.425156 VPNC: create_ssl_connection: SSL setup failure
 918: ERR 10:19:27.426473 VPNC: do_login: create_ssl_connection failed
 919: NOT 10:19:27.427334 VPNC: vpn_stop: de-activating vpn
 920: NOT 10:19:27.428156 VPNC: vpn_set_auto: auto -> auto
 921: NOT 10:19:27.428653 VPNC: vpn_set_active: activated -> de-activated
 922: NOT 10:19:27.429187 VPNC: set_login_state: LOGIN: 1 (TRYING) --> 3 (FAILED)
 923: NOT 10:19:27.429716 VPNC: set_login_state: VPNC : 1 (LoggingIn) --> 3 
   (LoginFailed)
 924: NOT 10:19:27.430297 VPNC: vpnc_send_notify: notify type: 1 [LoginFailed]
 925: NOT 10:19:27.430812 VPNC: vpnc_send_notify: notify code: 37 
   [SslAlertSrvrCert]
 926: NOT 10:19:27.431331 VPNC: vpnc_send_notify: notify desc: [alert: Unknown 
   CA (server cert)]
 927: NOT 10:19:27.431841 VPNC: vpnc_send_notify: sending signal 28 w/ value 13 to 
   pid 14
 928: ERR 10:19:27.432467 VPNC: protocol_handler: login failed

  

Fonctionnalité Span to PC Port

  

Vous pouvez connecter un ordinateur directement à un téléphone. Le téléphone dispose d'un port de commutateur dans le fond de panier.

  

Configurez le téléphone comme vous l'avez fait précédemment, activez le port Span to PC sur le CUCM et appliquez la configuration. Le téléphone commence à envoyer une copie de chaque trame au PC. Utilisez Wireshark en mode proche afin de capturer le trafic pour l'analyse.

  

  

Modification de la configuration du téléphone IP connecté par VPN

  

Une question courante est de savoir si vous pouvez modifier la configuration VPN lorsque le téléphone IP est connecté hors du réseau par AnyConnect. La réponse est oui, mais vous devez confirmer certains paramètres de configuration.

  

Effectuez les modifications nécessaires dans le CUCM, puis appliquez les modifications au téléphone. Il existe trois options (Apply Config, Reset, Restart) pour transmettre la nouvelle configuration au téléphone. Bien que les trois options déconnectent le VPN du téléphone et de l'ASA, vous pouvez vous reconnecter automatiquement si vous utilisez l'authentification par certificat ; si vous utilisez l'authentification, l'autorisation et la comptabilité (AAA), vous êtes invité à fournir à nouveau vos informations d'identification.

  

  

Remarque : lorsque le téléphone IP se trouve sur le côté distant, il reçoit normalement une adresse IP d'un serveur DHCP externe. Pour que le téléphone IP reçoive la nouvelle configuration du CUCM, il doit contacter le serveur TFTP du bureau central. Normalement, CUCM est le même serveur TFTP.

  

Afin de recevoir les fichiers de configuration avec les modifications, vérifiez que l'adresse IP du serveur TFTP est correctement configurée dans les paramètres réseau du téléphone ; pour confirmation, utilisez l'option 150 du serveur DHCP ou définissez manuellement le serveur TFTP sur le téléphone. Ce serveur TFTP est accessible via une session AnyConnect.

  

Si le téléphone IP reçoit le serveur TFTP d'un serveur DHCP local mais que cette adresse est incorrecte, vous pouvez utiliser l'option de serveur TFTP alternatif afin de remplacer l'adresse IP du serveur TFTP fournie par le serveur DHCP. Cette procédure décrit comment appliquer le serveur TFTP secondaire :

  

1. Accédez à Settings > Network Configuration > IPv4 Configuration.
   
   
2. Faites défiler jusqu’à l’option Autre TFTP.
   
   
3. Appuyez sur la touche de fonction Yes du téléphone pour utiliser un autre serveur TFTP ; sinon, appuyez sur la touche de fonction No. Si l'option est verrouillée, appuyez sur * * # afin de la déverrouiller.
   
   
4. Appuyez sur la touche Save.
   
   
5. Appliquez le serveur TFTP secondaire sous l'option Serveur TFTP 1.

  

Consultez directement les messages d'état dans le navigateur Web ou dans les menus du téléphone afin de confirmer que le téléphone reçoit les informations correctes. Si la communication est correctement configurée, des messages tels que :

  

  

Si le téléphone ne parvient pas à récupérer les informations du serveur TFTP, vous recevez des messages d'erreur TFTP :

  

  

Renouvellement du certificat SSL ASA

  

Si vous disposez d'une configuration de téléphone VPN AnyConnect fonctionnelle mais que votre certificat SSL ASA est sur le point d'expirer, vous n'avez pas besoin d'amener tous les téléphones IP sur le site principal pour injecter les nouveaux certificats SSL sur le téléphone ; vous pouvez ajouter les nouveaux certificats pendant que le VPN est connecté.

  

Si vous avez exporté ou importé le certificat d'autorité de certification racine de l'ASA au lieu du certificat d'identité et si vous voulez continuer à utiliser le même fournisseur (CA) pendant ce renouvellement, il n'est pas nécessaire de modifier le certificat dans le CUCM car il reste le même. Mais, si vous avez utilisé le certificat d'identité, cette procédure est nécessaire ; sinon, la valeur de hachage entre l'ASA et le téléphone IP ne correspondent pas, et la connexion n'est pas approuvée par le téléphone.

  

1. Renouvelez le certificat sur l'ASA.
   

   Remarque : pour plus d'informations, reportez-vous à ASA 8.x : Renew and Install the SSL Certificate with ASDM. Créez un point de confiance distinct et n'appliquez pas ce nouveau certificat avec la commande ssl trustpoint <name> outside tant que vous n'avez pas appliqué le certificat à tous les téléphones IP VPN.

2. Exportez le nouveau certificat.
   
   
3. Importez le nouveau certificat dans le CUCM en tant que certificat Phone-VPN-Trust.
   

   Remarque : sachez que CSCuh19734 Le téléchargement de certificats avec le même CN écrasera l'ancien certificat dans Phone-VPN-trust

4. Accédez à la configuration de passerelle VPN dans le CUCM et appliquez le nouveau certificat. Vous avez maintenant les deux certificats : le certificat qui est sur le point d'expirer et le nouveau certificat qui n'a pas encore été appliqué à l'ASA.
   
   
5. Appliquez cette nouvelle configuration au téléphone IP. Naviguez jusqu'à Apply Config > Reset > Restart afin d'injecter les nouvelles modifications de configuration au téléphone IP par le tunnel VPN. Assurez-vous que tous les téléphones IP sont connectés via le VPN et qu'ils peuvent atteindre le serveur TFTP via le tunnel.
   
   
6. Utilisez TFTP pour vérifier les messages d'état et le fichier de configuration afin de confirmer que le téléphone IP a reçu le fichier de configuration avec les modifications.
   
   
7. Appliquez le nouveau point de confiance SSL dans l'ASA et remplacez l'ancien certificat.

  

Remarque : si le certificat SSL ASA a déjà expiré et si les téléphones IP ne peuvent pas se connecter via AnyConnect, vous pouvez répercuter les modifications (telles que le nouveau hachage du certificat ASA) sur le téléphone IP. Définissez manuellement le protocole TFTP du téléphone IP sur une adresse IP publique afin que le téléphone IP puisse récupérer les informations à partir de cette adresse. Utilisez un serveur TFTP public pour héberger le fichier de configuration ; par exemple, créez un transfert de port sur l'ASA et redirigez le trafic vers le serveur TFTP interne.