Teléfono de AnyConnect VPN del Troubleshooting - Teléfonos IP, ASA, y CUCM

Introducción

  

Este documento describe cómo resolver problemas los problemas con los Teléfonos IP que utiliza el protocolo de Secure Sockets Layer (SSL) (Cliente de movilidad Cisco AnyConnect Secure) para conectar con Cisco un dispositivo de seguridad adaptante (ASA) se utilice que como un gateway de VPN y para conectar con las Comunicaciones unificadas de Cisco a un encargado (CUCM) que está utilizado como servidor de la Voz.

  

Por los ejemplos de la configuración de AnyConnect con los teléfonos VPN, refiera a estos documentos:

  

• SSLVPN con el ejemplo de la configuración de los Teléfonos IP
  
  
• Teléfono de AnyConnect VPN con el ejemplo de la configuración de autenticación del certificado

  

Antecedentes

  

Antes de que usted despliegue SSL VPN con los Teléfonos IP, confirme que usted ha cumplido estos requisitos iniciales para las licencias de AnyConnect para el ASA y para la versión restringida exportación E.E.U.U. del CUCM.

  

Confirme la licencia del teléfono VPN en el ASA

  

La licencia del teléfono VPN activa la característica en el ASA. Para confirmar el número de usuarios que puedan conectar con el AnyConnect (independientemente de si es un teléfono IP), controle la licencia superior de AnyConnect SSL. ¿Refiérase a qué licencia ASA es necesaria para el teléfono IP y las conexiones VPN móviles? para conocer más detalles.

  

En el ASA, utilice el comando show version para controlar si se activa la característica. El nombre de la licencia diferencia con la versión ASA:

  

• Versión 8.0.x ASA: el nombre de la licencia es AnyConnect para el teléfono de Linksys.
  
  
• El ASA release/versión 8.2.x y más adelante: el nombre de la licencia es AnyConnect para el teléfono de Cisco VPN.

  

Aquí está un ejemplo para la versión 8.0.x ASA:

  

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.

  

Aquí está un ejemplo para las versiones 8.2.x ASA y más adelante:

  

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.

  

Exportación restringida y exportación CUCM sin restricción

  

Usted debe desplegar una versión restringida exportación E.E.U.U. de CUCM para la función del teléfono VPN.

  

Si usted utiliza una versión sin restricción de la exportación E.E.U.U. de CUCM, observe eso:

  

• Las configuraciones de Seguridad del teléfono IP se modifican para inhabilitar el cifrado de la señalización y de los media; esto incluye el cifrado proporcionado por la función del teléfono VPN.
  
  
• Usted no puede exportar los detalles VPN a través de la importación/de la exportación.
  
  
• Las casillas de verificación para el perfil VPN, el gateway de VPN, el grupo VPN, y configuración de la característica VPN no se visualizan.

  

Note: Una vez que usted actualiza a la versión sin restricción de la exportación E.E.U.U. de CUCM, usted no puede actualizar más adelante a, o realice un fresco instalan de, la versión restringida exportación E.E.U.U. de este software.

  

Problemas frecuentes en el ASA

  

Note: Usted puede utilizar el analizador del CLI de Cisco (clientes registrados solamente) para ver un análisis de las salidas del comando show. Usted debe también referir a la información importante en el documento de Cisco de los comandos Debug antes de que usted utilice los comandos debug.

  

Certificados para el uso en el ASA

  

En el ASA, usted puede utilizar los Certificados uno mismo-firmados SSL, los Certificados de tercera persona SSL, y los Certificados del comodín; ninguno de estos seguro la comunicación entre el teléfono IP y el ASA.

  

Solamente un certificado de identidad puede ser utilizado porque solamente un certificado se puede asignar a cada interfaz.

  

Para los Certificados de tercera persona SSL, instale el encadenamiento completo en el ASA, e incluya cualquier intermedio y certificado raíz.

  

Trustpoint/certificado para la exportación ASA y la importación CUCM

  

El certificado que el ASA presenta al teléfono IP durante la negociación SSL se debe exportar del ASA e importar en el CUCM. Controle el trustpoint asignado al interfaz al cual los Teléfonos IP conectan para saber qué certificado a exportar del ASA.

  

Utilice el comando SSL del funcionamiento de la demostración para verificar el trustpoint (certificado) que se exportará. Refiera al teléfono de AnyConnect VPN con el ejemplo de la configuración de autenticación del certificado para más información.

  

Note: Si usted ha desplegado un certificado de tercera persona a uno o más ASAs, usted necesita exportar cada certificado de identidad de cada ASA y después importarlo al CUCM como teléfono-VPN-confianza.

  

El ASA presenta el certificado autofirmado ECDSA en vez del certificado configurado RSA

  

Cuando ocurre este problema, los teléfonos de un más nuevo modelo no pueden conectar, mientras que los teléfonos modelo más viejos no experimentan ninguna problemas. Aquí sea abre una sesión el teléfono cuando ocurre este problema:

  

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

  

En las versiones 9.4.1 y más adelante, la criptografía elíptica de la curva se utiliza para el SSL/TLS. Cuando un cliente curva-capaz elíptico SSL VPN tal como un nuevo modelo del teléfono conecta con el ASA, se negocia la habitación elíptica de la cifra de la curva, y el ASA presenta al cliente SSL VPN con un certificado elíptico de la curva, incluso cuando el interfaz que corresponde se configura con un trustpoint RSA-basado. Para evitar que el ASA presente un certificado uno mismo-firmado SSL, el administrador debe quitar las habitaciones de la cifra que corresponden vía el comando de la cifra SSL. Por ejemplo, para un interfaz que se configure con un trustpoint RSA, el administrador puede ejecutar este comando para solamente negociar las cifras RSA-basadas:

  

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

  

Con la puesta en práctica del ID de bug CSCuu02848 de Cisco, la prioridad se da a la configuración. los Certificados Explícito-configurados se utilizan siempre. Los certificados autofirmados se utilizan solamente en ausencia de un certificado configurado.

  

Cifras propuestas del cliente	CERT RSA solamente	CERT EC solamente	Ambo Certs	Ninguno
El RSA cifra solamente	CERT de las aplicaciones RSA Cifras de las aplicaciones RSA	CERT uno mismo-firmado RSA de las aplicaciones Cifras de las aplicaciones RSA	CERT de las aplicaciones RSA Cifras de las aplicaciones RSA	CERT uno mismo-firmado RSA de las aplicaciones Cifras de las aplicaciones RSA
La EC cifra solamente (raro)	La conexión falla	CERT EC de las aplicaciones Cifras EC de las aplicaciones	CERT EC de las aplicaciones Cifras EC de las aplicaciones	CERT uno mismo-firmado EC de las aplicaciones Cifras EC de las aplicaciones
Ambas cifras solamente	CERT de las aplicaciones RSA Cifras de las aplicaciones RSA	CERT EC de las aplicaciones Cifras EC de las aplicaciones	CERT EC de las aplicaciones Cifras EC de las aplicaciones	CERT uno mismo-firmado EC de las aplicaciones Cifras EC de las aplicaciones

  

Base de datos externa para la autenticación de los usuarios del teléfono IP

  

Usted puede utilizar una base de datos externa para autenticar a los usuarios del teléfono IP. Los protocolos tales como el Lightweight Directory Access Protocol (LDAP) o el dial de la autenticación remota en el servicio de usuario (RADIUS) se pueden utilizar para la autenticación de los usuarios del teléfono VPN.

  

Coincidencias del hash del certificado entre la lista de la confianza del certificado ASA y del teléfono VPN

  

Recuerde que usted debe descargar el certificado que se asigna al interfaz ASA SSL y cargarlo por teletratamiento como certificado de la Teléfono-VPN-confianza en el CUCM. Diversas circunstancias pudieron causar el hash para este certificado presentado por el ASA para no hacer juego el hash que el servidor CUCM genera y empuja al teléfono VPN a través del archivo de configuración.

  

Una vez que la configuración es completa, pruebe la conexión VPN entre el teléfono IP y el ASA. Si la conexión continúa fallando, controlar si el hash del certificado ASA hace juego el hash el teléfono IP está esperando:

  

1. Controle el hash del algoritmo de troceo seguro 1 (SHA1) presentado por el ASA.
   
   
2. Utilice el TFTP para descargar Configuración del teléfono IP el fichero del CUCM.
   
   
3. Decodifique el hash del hexadecimal al base 64 o del base 64 al hexadecimal.

  

Controle el hash SHA1

  

El ASA presenta el certificado aplicado con el comando del trustpoint SSL en el interfaz con el cual el teléfono IP conecta. Para controlar este certificado, abra el hojeador (en este ejemplo, Firefox), y ingrese el URL (el grupo-URL) con el cual los teléfonos deben conectar:

  

  

Descargue Configuración del teléfono IP el fichero

  

De una PC con el acceso directo al CUCM, descargue el fichero de los config TFTP para el teléfono con los problemas de conexión. Dos métodos de la transferencia directa son:

  

1. Abra a una sesión CLI en Windows, y utilice tftp - i <TFTP Server> CONSIGUE el comando del MAC address >.cnf.xml del <Phone de SEPT.
   

   Note: Si usted recibe un error similar al abajo, usted debe confirmar que la característica del cliente TFTP está activada.

   
   
   
   
   
2. Utilice una aplicación tal como Tftpd32 para descargar el fichero:
   
   
   
   
3. Una vez que se descarga el fichero, abra el XML y encuentre la configuración del vpnGroup. Este ejemplo muestra la sección y el certHash que se verificarán:
   
   

   <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>
   <certHash1>5X6B6plUwUSXZnjQ4kGM33mpMXY=</certHash1>
   </credentials>
   </vpnGroup>

  

Decodifique el hash

  

Confirme que ambos valores de troceo hacen juego. El navegador presenta el hash en el formato hexadecimal, mientras que el archivo XML utiliza el base 64, así que convierte un formato al otro para confirmar la coincidencia. Hay muchos traductores disponibles; un ejemplo es el TRADUCTOR, BINARIO.

  

  

Note: Si el valor de troceo anterior no hace juego, el teléfono VPN no confía en la conexión que se negocia con el ASA, y la conexión falla.

  

Equilibrio de carga y Teléfonos IP VPN

  

el SSL Carga-equilibrado VPN no se utiliza para los teléfonos VPN. Los teléfonos VPN no realizan la validación de certificado real sino que por el contrario utilizar desmenuza empujado hacia abajo por el CUCM para validar los servidores. Porque el Equilibrio de carga VPN es básicamente un cambio de dirección HTTP, requiere los teléfonos validar los certificados múltiples, que lleva al error. Los síntomas del error del Equilibrio de carga VPN incluyen:

  

• El teléfono alterna entre los servidores y tarda excepcionalmente un tiempo prolongado para conectar o falla eventual.
  
  
• Los registros del teléfono contienen los mensajes tales como éstos:
  
  

  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 y Teléfonos IP

  

Actualmente, los Teléfonos IP no utilizan el Cisco Secure Desktop (CSD) y no conectan cuando el CSD se activa para el grupo de túnel o global en el ASA.

  

Primero, confirme si el ASA tiene CSD activado. Ingrese el comando webvpn del funcionamiento de la demostración en el ASA CLI:

  

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#

  

Para controlar los problemas CSD durante una conexión telefónica IP, controle los registros o las depuraciones en el ASA.

  

Registros 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.

Depuraciones 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>

  

Note: En un despliegue grande con una mucha carga de los usuarios de AnyConnect, Cisco recomienda que usted no activa el anyconnect del webvpn de la depuración. Su salida no se puede filtrar por la dirección IP, así que una gran cantidad de información pudo ser creada.

  

En las versiones 8.2 ASA y más adelante, usted debe aplicar el comando sin-CSD bajo webvpn-atributos del grupo de túnel:

  

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

  

En las versiones anteriores del ASA, esto no era posible, así que la única solución alternativa era inhabilitar el CSD global.

  

En el Cisco Adaptive Security Device Manager (ASDM), usted puede inhabilitar el CSD para un perfil de la conexión específico tal y como se muestra en de este ejemplo:

  

  

Note: Utilice un grupo-URL para apagar la característica CSD.

  

Reglas DAP

  

La mayoría de las implementaciones no sólo conectan los Teléfonos IP con el ASA pero también conectan diversos tipos de máquinas (Microsoft, Linux, Mac OS) y de dispositivos móviles (Android, IOS). Por este motivo, es normal encontrar una configuración existente de las reglas de la directiva del acceso dinámico (DAP), donde, la mayor parte del tiempo, está terminación la acción predeterminada bajo el DfltAccessPolicy de la conexión.

  

Si éste es el caso, cree una regla separada DAP para los teléfonos VPN. Utilice un parámetro específico, tal como el perfil de la conexión, y fije la acción para continuar:

  

  

Si usted no crea una directiva específica DAP para los Teléfonos IP, el ASA muestra un golpe bajo el DfltAccessPolicy y falla de conexión:

  

%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

  

Una vez que usted crea una directiva específica DAP para los Teléfonos IP con el conjunto de la acción para continuar, usted puede conectar:

  

%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

  

Valores heredados de DfltGrpPolicy o de otros grupos

  

En muchos casos, el DfltGrpPolicy se pone con varias opciones. Por abandono, estas configuraciones se heredan para la sesión del teléfono IP a menos que se especifiquen manualmente en la grupo-directiva que el teléfono IP debe utilizar.

  

Algunos parámetros que pudieron afectar a la conexión si se heredan del DfltGrpPolicy son:

  

• grupo-bloqueo
  
  
• VPN-túnel-protocolo
  
  
• VPN-simultáneo-claves
  
  
• VPN-filtro

  

Asuma que usted tiene este ejemplo de configuración en el DfltGrpPolicy y el 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 conexión hereda los parámetros del DfltGrpPolicy que no fueron especificados explícitamente bajo el GroupPolicy_VPNPhone y empuja toda la información al teléfono IP durante la conexión.

  

Para evitar esto, especifique manualmente los valores que usted necesita directamente en el grupo:

  

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

  

Para controlar los valores predeterminados del DfltGrpPolicy, utilice la demostración funcionan con todo el comando de la grupo-directiva; este ejemplo aclara la diferencia entre las salidas:

  

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

  

Aquí está la salida de la grupo-directiva hereda los atributos con el ASDM:

  

  

Cifras utilizadas del cifrado

  

Un teléfono de AnyConnect VPN probado con las ayudas del teléfono y de la versión de firmware 9.1.1 IP 7962G solamente dos cifras, que son ambo Advanced Encryption Standard (AES): AES256-SHA y AES128-SHA. Si las cifras correctas no se especifican en el ASA, la conexión se rechaza, tal y como se muestra en del registro 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

  

Para confirmar si el ASA tiene las cifras correctas activadas, ingrese la demostración ejecutan todo el SSL y muestran los comandos 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#

  

Problemas frecuentes en el CUCM

  

Configuraciones VPN no aplicadas al teléfono IP

  

La configuración en el CUCM se crea una vez (gateway, grupo, y perfil), aplica las configuraciones VPN en el perfil común del teléfono:

  

1. Navegue al dispositivo > a las configuraciones del dispositivo > perfil común del teléfono.
   
   
   
   
2. Ingrese la información de VPN:
   
   
   
   
3. Navegue al Device (Dispositivo) > Phone (Teléfono) y confirme este perfil se asigna a la Configuración del teléfono:
   
   

  

Certifique el método de autenticación

  

Hay dos maneras de configurar la autenticación del certificado para los Teléfonos IP: El fabricante instaló el certificado (MIC) y localmente - el certificado significativo (LSC). Refiera al teléfono de AnyConnect VPN con el ejemplo de la configuración de autenticación del certificado para elegir la mejor opción para su situación.

  

Cuando usted configura la autenticación del certificado, exporte los certificados (raíz CA) del servidor CUCM e impórtelos al ASA:

  

1. Ábrase una sesión al CUCM.
   
   
2. Navegue el Certificate Management (Administración de certificados) unificado del > Security (Seguridad) de la administración OS.
   
   
3. Encuentre la función del proxy de la autoridad de certificación (CAPF) o Cisco_Manufacturing_CA; el tipo de certificado depende sobre si usted utilizó autenticación del certificado MIC o LSC.
   
   
4. Descargue el fichero a la computadora local.

  

Una vez que se descargan los ficheros, ábrase una sesión al ASA con el CLI o el ASDM e importe el certificado como certificado CA.

  

  

Por abandono, todos los teléfonos que utilizan el VPN se cargan con MICs. Los 7960 y 7940 teléfonos modelo no vienen con un MIC y requieren un procedimiento de la instalación especial de modo que el LSC se registre con seguridad.

  

Los Teléfonos IP más nuevos de Cisco (8811, 8841, 8851, y 8861) incluyen los Certificados MIC que son firmados por el nuevo SHA2 de fabricación CA:

  

• La versión 10.5(1) CUCM incluye y confía en los nuevos Certificados SHA2.
  
  
• Si usted funciona con una versión anterior CUCM, usted puede ser que sea requerido descargar el nuevo certificado CA de fabricación y:
  
  
  • Cargúelo por teletratamiento a la CAPF-confianza de modo que los teléfonos puedan autenticar con CAPF para obtener un LSC.
    
    
  • Cargúelo por teletratamiento a la CallManager-confianza si usted quiere permitir que los teléfonos autentiquen con un MIC para el SORBO 5061.
    
    

Consejo: Haga clic este link para obtener el SHA2 CA si el CUCM funciona con actualmente una versión anterior.

  

Precaución: Cisco recomienda que usted utiliza MICs para la instalación LSC solamente. Cisco utiliza los LSC para la autenticación de la conexión TLS con el CUCM. Porque los certificados raíz MIC pueden ser comprometidos, los clientes que configuran los teléfonos para utilizar MICs para la autenticación de TLS o para cualquier otro propósito hacen tan por su cuenta y riesgo. Cisco no asume ningún defecto si se compromete el MICs.

  

Por abandono, si un LSC existe en el teléfono, la autenticación utiliza el LSC, sin importar si un MIC existe en el teléfono. Si un MIC y un LSC existen en el teléfono, la autenticación utiliza el LSC. Si un LSC no existe en el teléfono, pero existe un MIC, la autenticación utiliza el MIC.

  

Note: Recuerde que, para la autenticación del certificado, usted debe exportar el certificado SSL del ASA e importarlo al CUCM.

  

Control del ID del host

  

Si el nombre común (NC) en el tema del certificado no hace juego el URL (grupo-URL) que los teléfonos utilizan para conectar con el ASA con el VPN, que inhabilitan el control del ID del host en el CUCM o utilice un certificado en el ASA que hace juego ese URL en el ASA.

  

Esto es necesario cuando el certificado SSL del ASA es un certificado del comodín, el certificado SSL contiene un diverso SAN (nombre alternativo sujeto), o el URL fue creado con la dirección IP en vez del nombre de dominio completo (FQDN).

  

Éste es un ejemplo de un registro del teléfono IP cuando el NC del certificado no hace juego el URL que el teléfono está intentando alcanzar.

  

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!!

  

Para inhabilitar el incorporar del ID del host los CUCM, navegan a las funciones avanzadas > al perfil VPN > VPN:

  

  

Resolución de otros problemas

  

Registros y depuraciones a utilizar en el ASA

  

En el ASA, usted puede activar estas depuraciones y registros para resolver problemas:

  

logging enable
logging buffer-size 1048576
logging buffered debugging

debug webvpn anyconnect 255

  

Note: En un despliegue grande con una mucha carga de los usuarios de AnyConnect, Cisco recomienda que usted no activa el anyconnect del webvpnh de la depuración. Su salida no se puede filtrar por la dirección IP, así que una gran cantidad de información pudo ser creada.

  

Registros del teléfono IP

  

Para tener acceso a los registros del teléfono, active la característica del Acceso Web. Ábrase una sesión al CUCM, y navegue al Device (Dispositivo) > Phone (Teléfono) > a la Configuración del teléfono. Encuentre el teléfono IP en el cual usted quiere activar esta característica, y encuentre la sección para el Acceso Web. Aplique los cambios de configuración al teléfono IP:

  

  

Una vez que usted activa el servicio y reajusta el teléfono para inyectar esta nueva función, usted puede tener acceso al teléfono IP abre una sesión al navegador; utilice la dirección IP del teléfono de un ordenador con el acceso a esa subred. Vaya a los registros de la consola y controle los cinco archivos del registro. Porque el teléfono sobregraba los cinco ficheros, usted debe controlar todos estos ficheros en la orden encuentra la información que usted busca.

  

  

Los problemas correlacionados entre los registros ASA y el IP llaman por teléfono a los registros

  

Éste es un ejemplo de cómo correlacionar los registros del ASA y del teléfono IP. En este ejemplo, el hash del certificado en el ASA no hace juego el hash del certificado en el archivo de configuración del teléfono porque el certificado en el ASA fue substituido por un diverso certificado.

  

Registros 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

  

Registros del teléfono

  

 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

  

Palmo a la característica del puerto de la PC

  

Usted puede conectar un ordenador directamente con un teléfono. El teléfono tiene un puerto del switch en la Placa posterior.

  

Configure el teléfono como usted lo hizo previamente, para activar el palmo al puerto de la PC en el CUCM, y para aplicar la configuración. El teléfono comienza a enviar una copia de cada bastidor a la PC. Utilice Wireshark en el modo promiscuo para capturar el tráfico para el análisis.

  

  

Configuración del teléfono IP cambios mientras que es conectado por el VPN

  

Una pregunta común es si usted puede modificar la configuración VPN mientras que el teléfono IP es conectado fuera de la red por AnyConnect. La respuesta está sí, pero usted debe confirmar algunas configuraciones.

  

Realice los cambios necesarios en el CUCM, después aplique los cambios al teléfono. Hay tres opciones (aplique los Config, reajustan, reinicio) para empujar la nueva configuración al teléfono. Aunque las tres opciones desconecten el VPN del teléfono y del ASA, usted puede volver a conectar automáticamente si usted está utilizando la autenticación del certificado; si usted está utilizando el Authentication, Authorization, and Accounting (AAA), le incitan para sus credenciales otra vez.

  

  

Note: Cuando el teléfono IP está en el lado remoto, recibe normalmente una dirección IP de un servidor externo del DHCP. Para que el teléfono IP reciba la nueva configuración del CUCM, debe entrar en contacto con el servidor TFTP en la oficina principal. El CUCM es normalmente el mismo servidor TFTP.

  

Para recibir los archivos de configuración con los cambios, confirme que la dirección IP para el servidor TFTP está puesta correctamente en las configuraciones de red en el teléfono; para la confirmación, utilice la opción 150 del servidor del DHCP o fije manualmente el TFTP en el teléfono. Este servidor TFTP es accesible con una sesión de AnyConnect.

  

Si el teléfono IP está recibiendo el servidor TFTP de un servidor local del DHCP pero ese direccionamiento es incorrecto, usted puede utilizar la opción del servidor alterna TFTP para reemplazar la dirección IP del servidor TFTP proporcionada por el servidor del DHCP. Este procedimiento describe cómo aplicar el servidor alterno TFTP:

  

1. Navegue a las configuraciones > a la configuración de la Configuración de la red IPv4.
   
   
2. Desplazamiento a la opción alterna TFTP.
   
   
3. Pulse la tecla suave del sí para que el teléfono utilice un servidor de la alternativa TFTP; si no, no pulse la ninguna tecla suave. Si la opción es bloqueada, prensa * * # para desbloquearla.
   
   
4. Presione la tecla programable Save.
   
   
5. Aplique el servidor alterno TFTP bajo opción del servidor 1 TFTP.

  

Revise los mensajes de estado en el buscador Web o en los menús del teléfono directamente para confirmar que el teléfono está recibiendo la información correcta. Si la comunicación se pone correctamente, usted ve los mensajes tales como éstos:

  

  

Si el teléfono no puede extraer la información del servidor TFTP, usted recibe los mensajes de error TFTP:

  

  

Renovación del certificado ASA SSL

  

Si usted hace un teléfono funcional de AnyConnect VPN poner pero su certificado ASA SSL está a punto de expirar, usted no necesita traer todos los Teléfonos IP al sitio principal para inyectar los nuevos Certificados SSL al teléfono; usted puede agregar los nuevos Certificados mientras que el VPN está conectado.

  

Si usted ha exportado o importado certificado raíz CA del ASA en vez del certificado de identidad y si usted quiere continuar utilizando al mismo vendedor (CA) durante esta renovación, no es necesario cambiar el certificado en el CUCM porque sigue siendo lo mismo. Pero, si usted utilizó el certificado de identidad, este procedimiento es necesario; si no, el valor de troceo entre el teléfono ASA y IP no hace juego, y la conexión no es confiada en por el teléfono.

  

1. Renueve el certificado en el ASA.
   

   Note: Para los detalles, refiera a ASA 8.x: Renueve y instale el certificado SSL con ASDM. Cree un trustpoint separado y no aplique este nuevo certificado con el <name> del trustpoint SSL fuera del comando hasta que usted haya aplicado el certificado a todos los Teléfonos IP VPN.

2. Exporte el nuevo certificado.
   
   
3. Importe el nuevo certificado al CUCM como certificado de la Teléfono-VPN-confianza.
   

   Note: Sea consciente de los certs que cargan por teletratamiento CSCuh19734 con el mismo NC sobregrabará el CERT viejo en la Teléfono-VPN-confianza

4. Navegue a la configuración de gateway de VPN en el CUCM, y aplique el nuevo certificado. Usted ahora tiene ambos Certificados: el certificado que está a punto de expirar y el nuevo certificado que no se ha aplicado al ASA todavía.
   
   
5. Aplique esta nueva configuración al teléfono IP. Navegue para aplicar los Config > reajustado > reinicio para inyectar los nuevos cambios de configuración al teléfono IP a través del túnel VPN. Asegúrese de que todos los Teléfonos IP estén conectados con el VPN y de que pueden alcanzar el servidor TFTP a través del túnel.
   
   
6. Utilice el TFTP para controlar los mensajes de estado y el archivo de configuración para confirmar que el teléfono IP recibió el archivo de configuración con los cambios.
   
   
7. Aplique el nuevo SSL Trustpoint en el ASA, y substituya el certificado viejo.

  

Note: Si se expira el certificado ASA SSL ya y si los Teléfonos IP no pueden conectar con AnyConnect; usted puede empujar los cambios (tales como el nuevo hash del certificado ASA) al teléfono IP. Fije manualmente el TFTP en el teléfono IP a una dirección IP pública así que el teléfono IP puede extraer la información de allí. Utilice un servidor del público TFTP para recibir el archivo de configuración; un ejemplo es crear una expedición del puerto en el ASA y reorientar el tráfico al servidor interno TFTP.