Solución de problemas del teléfono VPN AnyConnect: teléfonos IP, ASA y CUCM

Introducción

  

Este documento describe cómo resolver problemas con teléfonos IP que utilizan el protocolo Secure Sockets Layer (SSL) (Cisco AnyConnect Secure Mobility Client) para conectarse a un Cisco Adaptive Security Appliance (ASA) que se utiliza como una puerta de enlace VPN y para conectarse a un Cisco Unified Communications Manager (CUCM) que se utiliza como servidor de voz.

  

Para ver ejemplos de configuración de AnyConnect con teléfonos VPN, consulte estos documentos:

  

• Ejemplo de Configuración de SSLVPN con Teléfonos IP
  
  
• Ejemplo de Configuración de AnyConnect VPN Phone with Certificate Authentication

  

Antecedentes

  

Antes de implementar SSL VPN con teléfonos IP, confirme que ha cumplido estos requisitos iniciales para las licencias de AnyConnect para ASA y para la versión restringida de exportación de EE. UU. de CUCM.

  

Confirmar la licencia del teléfono VPN en ASA

  

La licencia del teléfono VPN habilita la función en el ASA. Para confirmar el número de usuarios que pueden conectarse con AnyConnect (sea o no un teléfono IP), verifique la Licencia SSL Premium de AnyConnect. Consulte ¿Qué licencia ASA se necesita para las conexiones de teléfono IP y VPN móvil? para obtener más detalles.

  

En ASA, utilice el comando show version para verificar si la función está habilitada. El nombre de la licencia difiere de la versión de ASA:

  

• ASA versión 8.0.x: el nombre de la licencia es AnyConnect para el teléfono Linksys.
  
  
• ASA versión 8.2.x y posteriores: el nombre de la licencia es AnyConnect para Cisco VPN Phone.

  

Este es un ejemplo para ASA Release 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.

  

Este es un ejemplo para ASA Releases 8.2.x y versiones posteriores:

  

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.

  

Exportar CUCM restringido y exportar CUCM no restringido

  

Debe implementar una versión restringida de exportación de EE. UU. de CUCM para la función de teléfono VPN.

  

Si utiliza una versión sin restricciones de exportación de EE. UU. de CUCM, tenga en cuenta que:

  

• Las configuraciones de seguridad del teléfono IP se modifican para inhabilitar la señalización y el cifrado de medios; esto incluye el cifrado proporcionado por la función de teléfono VPN.
  
  
• No puede exportar detalles de VPN a través de Importar/Exportar.
  
  
• No se muestran las casillas de verificación VPN Profile (Perfil de VPN), VPN Gateway (Puerta de enlace VPN), VPN Group (Grupo VPN) y VPN Feature Configuration (Configuración de funciones VPN).

  

Nota: una vez que haya actualizado a la versión sin restricciones de exportación de EE. UU. de CUCM, no podrá realizar una actualización posterior a la versión restringida de exportación de EE. UU. de este software ni realizar una instalación nueva de la misma.

  

Problemas comunes en ASA

  

Nota: Puede utilizar Cisco CLI Analyzer (sólo clientes registrados) para ver un análisis de los resultados del comando show. También debe consultar el documento Información importante sobre comandos de depuración de Cisco antes de utilizar los comandos debug.

  

Certificados para su uso en ASA

  

En ASA, puede utilizar certificados SSL autofirmados, certificados SSL de terceros y certificados comodín; cualquiera de estos certificados protege la comunicación entre el teléfono IP y el ASA.

  

Sólo se puede utilizar un certificado de identidad porque sólo se puede asignar un certificado a cada interfaz.

  

Para certificados SSL de terceros, instale la cadena completa en ASA e incluya cualquier certificado intermedio y raíz.

  

Trustpoint/Certificate for ASA Export and CUCM Import

  

El certificado que ASA presenta al teléfono IP durante la negociación SSL debe exportarse desde ASA e importarse en CUCM. Verifique el punto de confianza asignado a la interfaz a la que se conectan los teléfonos IP para saber qué certificado exportar del ASA.

  

Utilice el comando show run ssl para verificar el punto de confianza (certificado) que se va a exportar. Consulte Ejemplo de Configuración de AnyConnect VPN Phone with Certificate Authentication para obtener más información.

  

Nota: si ha implementado un certificado de terceros en uno o más ASA, debe exportar cada certificado de identidad de cada ASA y, a continuación, importarlo a CUCM como phone-vpn-trust.

  

ASA presenta el certificado de firma automática ECDSA en lugar del certificado RSA configurado

  

Cuando se produce este problema, los teléfonos de modelos más nuevos no pueden conectarse, mientras que los teléfonos de modelos más antiguos no experimentan ningún problema. Estos son los registros en 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 posteriores, la criptografía de curva elíptica es compatible con SSL/TLS. Cuando un cliente SSL VPN con capacidad de curva elíptica, como un nuevo modelo de teléfono, se conecta al ASA, se negocia el conjunto de cifrado de curva elíptica y el ASA presenta al cliente SSL VPN un certificado de curva elíptica, incluso cuando la interfaz que corresponde se configura con un punto de confianza basado en RSA. Para evitar que ASA presente un certificado SSL autofirmado, el administrador debe eliminar los conjuntos de cifrado que corresponden a través del comando ssl cipher. Por ejemplo, para una interfaz que se configura con un punto de confianza RSA, el administrador puede ejecutar este comando para que sólo se negocien los cifrados basados en RSA:

  

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

  

Con la implementación del ID de bug Cisco CSCuu02848, se da prioridad a la configuración. Siempre se utilizan certificados configurados explícitamente. Los certificados autofirmados sólo se utilizan en ausencia de un certificado configurado.

  

Cifrados de cliente propuestos	Solo certificado RSA	Solo certificado EC	Ambos certificados	Ninguno
Sólo cifrados RSA	Utiliza el certificado RSA Utiliza cifrados RSA	Utiliza un certificado autofirmado RSA Utiliza cifrados RSA	Utiliza el certificado RSA Utiliza cifrados RSA	Utiliza un certificado autofirmado RSA Utiliza cifrados RSA
Cifras EC solamente (raras)	La conexión falla	Utiliza un certificado EC Utiliza cifrados EC	Utiliza un certificado EC Utiliza cifrados EC	Utiliza un certificado autofirmado de la CE Utiliza cifrados EC
Sólo ambos cifrados	Utiliza el certificado RSA Utiliza cifrados RSA	Utiliza un certificado EC Utiliza cifrados EC	Utiliza un certificado EC Utiliza cifrados EC	Utiliza un certificado autofirmado de la CE Utiliza cifrados EC

  

Base de datos externa para autenticación de usuarios de teléfonos IP

  

Puede utilizar una base de datos externa para autenticar a los usuarios de teléfonos IP. Se pueden utilizar protocolos como el protocolo ligero de acceso a directorios (LDAP) o el servicio de usuario de acceso telefónico de autenticación remota (RADIUS) para la autenticación de usuarios de teléfonos VPN.

  

Coincidencias de Hash de Certificado entre el Certificado ASA y la Lista de Confianza del Teléfono VPN

  

Recuerde que debe descargar el certificado asignado a la interfaz SSL de ASA y cargarlo como certificado de confianza de VPN de teléfono en CUCM. Diferentes circunstancias pueden hacer que el hash para este certificado presentado por ASA no coincida con el hash que el servidor de CUCM genera y envía al teléfono VPN a través del archivo de configuración.

  

Una vez finalizada la configuración, pruebe la conexión VPN entre el teléfono IP y el ASA. Si la conexión continúa fallando, verifique si el hash del certificado ASA coincide con el hash que el teléfono IP espera:

  

1. Verifique el hash del algoritmo hash seguro 1 (SHA1) presentado por el ASA.
   
   
2. Utilice TFTP para descargar el archivo de configuración del teléfono IP de CUCM.
   
   
3. Decodificar el hash de hexadecimal a base 64 o de base 64 a hexadecimal.

  

Comprobar Hash SHA1

  

El ASA presenta el certificado aplicado con el comando ssl trustpoint en la interfaz a la cual se conecta el teléfono IP. Para comprobar este certificado, abra el explorador (en este ejemplo, Firefox) e introduzca la URL (group-url) a la que se deben conectar los teléfonos:

  

  

Descargar archivo de configuración del teléfono IP

  

Desde una PC con acceso directo a CUCM, descargue el archivo de configuración TFTP para el teléfono con problemas de conexión. Dos métodos de descarga son:

  

1. Abra una sesión CLI en Windows y utilice el comando tftp -i <TFTP Server> GET SEP<Phone Mac Address>.cnf.xml.
   

   Nota: Si recibe un error similar al siguiente, debe confirmar que la función Cliente TFTP está habilitada.

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

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

  

Decodificar el hash

  

Confirme que ambos valores de hash coincidan. El navegador presenta el hash en formato hexadecimal, mientras que el archivo XML utiliza la base 64, por lo que debe convertir un formato al otro para confirmar la coincidencia. Hay muchos traductores disponibles; un ejemplo es el TRANSLATOR, BINARY .

  

  

Nota: Si el valor hash anterior no coincide, el teléfono VPN no confía en la conexión que se negocia con el ASA y la conexión falla.

  

Balanceo de Carga VPN y Teléfonos IP

  

VPN SSL con equilibrio de carga no es compatible con teléfonos VPN. Los teléfonos VPN no realizan una validación de certificado real, sino que utilizan hashes transferidos por CUCM para validar los servidores. Debido a que el balanceo de carga VPN es básicamente una redirección HTTP, requiere que los teléfonos validen múltiples certificados, lo que conduce a la falla. Los síntomas de la falla de balanceo de carga de VPN incluyen:

  

• El teléfono alterna entre servidores y tarda mucho tiempo en conectarse o, en última instancia, falla.
  
  
• Las notas telefónicas contienen mensajes como los siguientes:
  
  

  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>

  

Teléfonos IP y CSD

  

Actualmente, los teléfonos IP no admiten Cisco Secure Desktop (CSD) y no se conectan cuando CSD está habilitado para el grupo de túnel o globalmente en ASA.

  

En primer lugar, confirme si el ASA tiene CSD activado. Ingrese el comando show run webvpn en la CLI de 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#

  

Para verificar los problemas de CSD durante una conexión del teléfono IP, verifique los registros o las depuraciones en el ASA.

  

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

  

Nota: en una implementación de gran tamaño con una gran carga de usuarios de AnyConnect, Cisco recomienda que no habilite debug webvpn anyconnect. Su salida no se puede filtrar por dirección IP, por lo que se puede crear una gran cantidad de información.

  

En las versiones 8.2 y posteriores de ASA, debe aplicar el comando without-csd bajo los atributos webvpn del grupo de túnel:

  

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

  

En versiones anteriores de ASA, esto no era posible, por lo que la única solución era deshabilitar el CSD globalmente.

  

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

  

  

Nota: Use un group-url para desactivar la función CSD.

  

Reglas DAP

  

La mayoría de las implementaciones no solo conectan teléfonos IP al ASA, sino que también conectan diferentes tipos de máquinas (Microsoft, Linux, Mac OS) y dispositivos móviles (Android, iOS). Por este motivo, es normal encontrar una configuración existente de reglas de directiva de acceso dinámico (DAP), donde, la mayoría de las veces, la acción predeterminada de DfltAccessPolicy es la finalización de la conexión.

  

Si este es el caso, cree una regla DAP independiente para los teléfonos VPN. Utilice un parámetro específico, como el perfil de conexión, y establezca la acción en Continue:

  

  

Si no crea una política DAP específica para los teléfonos IP, ASA muestra un resultado en la política de acceso Dflt y una conexión fallida:

  

%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 haya creado una política DAP específica para los teléfonos IP con la acción establecida en Continue, podrá conectarse:

  

%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 u otros grupos

  

En muchos casos, DfltGrpPolicy se configura con varias opciones. De forma predeterminada, esta configuración se hereda para la sesión del teléfono IP a menos que se especifique manualmente en la directiva de grupo que debe utilizar el teléfono IP.

  

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

  

• bloqueo de grupo
  
  
• vpn-tunnel-protocol
  
  
• vpn-simultaneals-logins
  
  
• vpn-filter

  

Suponga que tiene este ejemplo de configuración en DfltGrpPolicy y 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 de DfltGrpPolicy que no se especificaron explícitamente en GroupPolicy_VPNPhone y envía toda la información al teléfono IP durante la conexión.

  

Para evitar esto, especifique manualmente los valores que 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 verificar los valores predeterminados de DfltGrpPolicy, utilice el comando show run all group-policy; este ejemplo aclara la diferencia entre los resultados:

  

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

  

A continuación se muestra el resultado de los atributos inherit de la política de grupo a través de ASDM:

  

  

Cifrados de cifrado compatibles

  

Un teléfono VPN AnyConnect probado con el teléfono IP 7962G y la versión de firmware 9.1.1 solo admite dos cifrados, que son ambos Estándar de cifrado avanzado (AES): AES256-SHA y AES128-SHA. Si no se especifican los cifrados correctos en el ASA, se rechaza la conexión, como se muestra en el registro de 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 ASA tiene los cifrados correctos habilitados, ingrese los comandos show run all ssl y 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#

  

Problemas comunes de CUCM

  

Configuración de VPN no aplicada al teléfono IP

  

Una vez creada la configuración en CUCM (puerta de enlace, grupo y perfil), aplique la configuración de VPN en Perfil de teléfono común:

  

1. Vaya a Device > Device Settings > Common Phone Profile.
   
   
   
   
2. Introduzca la información de VPN:
   
   
   
   
3. Navegue hasta Device > Phone y confirme que este perfil está asignado a la configuración del teléfono:
   
   

  

Método de autenticación de certificados

  

Hay dos formas de configurar la autenticación de certificados para los teléfonos IP: el certificado instalado por el fabricante (MIC) y el certificado de importancia local (LSC). Consulte Ejemplo de Configuración de AnyConnect VPN Phone with Certificate Authentication para elegir la mejor opción para su situación.

  

Al configurar la autenticación de certificados, exporte los certificados (CA raíz) del servidor de CUCM e impórtelos al ASA:

  

1. Inicie sesión en CUCM.
   
   
2. Vaya a Unified OS Administration > Security > Certificate Management.
   
   
3. Busque la función de proxy de autoridad certificadora (CAPF) o Cisco_Manufacturing_CA; el tipo de certificado depende de si utilizó la autenticación de certificado MIC o LSC.
   
   
4. Descargue el archivo en el equipo local.

  

Una vez descargados los archivos, inicie sesión en ASA a través de CLI o ASDM e importe el certificado como certificado de CA.

  

  

De forma predeterminada, todos los teléfonos que admiten VPN están precargados con MIC. Los teléfonos de los modelos 7960 y 7940 no vienen con un MIC y requieren un procedimiento de instalación especial para que el LSC se registre de manera segura.

  

Los teléfonos IP de Cisco más recientes (8811, 8841, 8851 y 8861) incluyen certificados MIC firmados por la nueva CA Manufacturing SHA2:

  

• La versión 10.5(1) de CUCM incluye los nuevos certificados SHA2 y confía en ellos.
  
  
• Si ejecuta una versión anterior de CUCM, es posible que deba descargar el nuevo certificado de CA de fabricación y:
  
  
  • Cargarlo en CAPF-trust para que los teléfonos puedan autenticarse con CAPF para obtener un LSC.
    
    
  • Cárguelo a CallManager-trust si desea permitir que los teléfonos se autentiquen con un MIC para SIP 5061.
    
    

Sugerencia: haga clic en este enlace para obtener la CA SHA2 si CUCM ejecuta actualmente una versión anterior.

  

Precaución: Cisco recomienda utilizar MIC sólo para la instalación de LSC. Cisco admite LSC para la autenticación de la conexión TLS con CUCM. Debido a que los certificados raíz de MIC pueden estar en riesgo, los clientes que configuran teléfonos para utilizar MIC para la autenticación TLS o para cualquier otro propósito lo hacen bajo su propio riesgo. Cisco no asume ninguna responsabilidad si los MIC están comprometidos.

  

De forma predeterminada, si existe un LSC en el teléfono, la autenticación utiliza el LSC, independientemente de si existe un MIC en el teléfono. Si existe un MIC y un LSC en el teléfono, la autenticación utiliza el LSC. Si no existe un LSC en el teléfono, pero sí existe un MIC, la autenticación utiliza el MIC.

  

Nota: recuerde que, para la autenticación de certificados, debe exportar el certificado SSL del ASA e importarlo a CUCM.

  

Comprobación de ID de host

  

Si el nombre común (CN) en el asunto del certificado no coincide con la URL (group-url) que los teléfonos utilizan para conectarse al ASA a través de la VPN, inhabilite la Verificación de ID de Host en CUCM o utilice un certificado en el ASA que coincida con esa URL en el ASA.

  

Esto es necesario cuando el certificado SSL del ASA es un certificado comodín, el certificado SSL contiene una SAN diferente (nombre alternativo del sujeto) o la URL se creó con la dirección IP en lugar del nombre de dominio completo (FQDN).

  

Este es un ejemplo de una nota telefónica IP cuando el CN del certificado no coincide con la URL que el teléfono está tratando de 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 la Verificación de ID de host en CUCM, navegue hasta Funciones avanzadas > VPN > Perfil VPN:

  

  

Resolución de otros problemas

  

Registros y depuraciones para utilizar en ASA

  

En el ASA, puede habilitar estos debugs y registros para troubleshooting:

  

logging enable
logging buffer-size 1048576
logging buffered debugging

debug webvpn anyconnect 255

  

Nota: en una implementación de gran tamaño con una gran carga de usuarios de AnyConnect, Cisco recomienda que no habilite el comando debug webvpnh anyconnect. Su salida no se puede filtrar por dirección IP, por lo que se puede crear una gran cantidad de información.

  

Registros del teléfono IP

  

Para acceder a los registros telefónicos, habilite la Función de Acceso Web. Inicie sesión en CUCM y navegue hasta Device > Phone > Phone Configuration. Busque el teléfono IP en el que desea activar esta función y busque la sección de Web Access (Acceso web). Aplique los cambios de configuración al teléfono IP:

  

  

Una vez que habilite el servicio y reinicie el teléfono para insertar esta nueva función, puede acceder a los registros del teléfono IP en el navegador; utilice la dirección IP del teléfono desde un equipo con acceso a esa subred. Vaya a los registros de la consola y compruebe los cinco archivos de registro. Debido a que el teléfono sobrescribe los cinco archivos, debe comprobar todos estos archivos para encontrar la información que busca.

  

  

Problemas correlacionados entre los registros de ASA y los registros de teléfonos IP

  

Este es un ejemplo de cómo correlacionar los registros del ASA y el teléfono IP. En este ejemplo, el hash del certificado en el ASA no coincide con el hash del certificado en el archivo de configuración del teléfono porque el certificado en el ASA fue reemplazado por un certificado diferente.

  

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

  

Función Span to PC Port

  

Puede conectar un equipo directamente a un teléfono. El teléfono tiene un puerto de switch en el plano posterior.

  

Configure el teléfono como lo hizo anteriormente, habilite Span to PC Port en CUCM y aplique la configuración. El teléfono comienza a enviar una copia de cada trama al PC. Utilice Wireshark en modo promiscuo para capturar el tráfico para su análisis.

  

  

Cambios en la configuración del teléfono IP mientras está conectado por VPN

  

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

  

Realice los cambios necesarios en CUCM y aplíquelos al teléfono. Hay tres opciones (Aplicar configuración, Restablecer y Reiniciar) para enviar la nueva configuración al teléfono. Aunque las tres opciones desconectan la VPN del teléfono y el ASA, puede volver a conectarse automáticamente si está utilizando la autenticación de certificados; si está utilizando la autenticación, autorización y contabilidad (AAA), se le solicitarán de nuevo sus credenciales.

  

  

Nota: Cuando el teléfono IP se encuentra en el lado remoto, normalmente recibe una dirección IP de un servidor DHCP externo. Para que el teléfono IP reciba la nueva configuración desde CUCM, debe comunicarse con el servidor TFTP en la Oficina Principal. Normalmente, CUCM es 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é configurada correctamente en la configuración de red en el teléfono; para la confirmación, utilice la opción 150 del servidor DHCP o establezca manualmente el TFTP en el teléfono. Se puede acceder a este servidor TFTP mediante una sesión de AnyConnect.

  

Si el teléfono IP recibe el servidor TFTP de un servidor DHCP local pero esa dirección es incorrecta, puede utilizar la opción de servidor TFTP alternativo para invalidar la dirección IP del servidor TFTP proporcionada por el servidor DHCP. Este procedimiento describe cómo aplicar el servidor TFTP alternativo:

  

1. Vaya a Settings > Network Configuration > IPv4 Configuration.
   
   
2. Desplácese hasta la opción TFTP alternativo.
   
   
3. Pulse la tecla programada Sí del teléfono para utilizar un servidor TFTP alternativo; de lo contrario, pulse la tecla programada No. Si la opción está bloqueada, presione * * # para desbloquearla.
   
   
4. Presione la tecla programable Save.
   
   
5. Aplique el servidor TFTP alternativo en la opción Servidor TFTP 1.

  

Revise los mensajes de estado en el navegador 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 está configurada correctamente, verá mensajes como estos:

  

  

Si el teléfono no puede recuperar la información del servidor TFTP, recibirá mensajes de error TFTP:

  

  

Renovación del certificado SSL de ASA

  

Si tiene una configuración de teléfono AnyConnect VPN funcional pero su certificado SSL ASA está a punto de caducar, no necesita traer todos los teléfonos IP al sitio principal para inyectar los nuevos certificados SSL en el teléfono; puede agregar los nuevos certificados mientras la VPN está conectada.

  

Si ha exportado o importado el certificado de CA raíz del ASA en lugar del certificado de identidad y desea seguir utilizando el mismo proveedor (CA) durante esta renovación, no es necesario cambiar el certificado en CUCM porque sigue siendo el mismo. Sin embargo, si utilizó el Certificado de identidad, este procedimiento es necesario; de lo contrario, el valor de hash entre el ASA y el teléfono IP no coincide y el teléfono no confía en la conexión.

  

1. Renueve el certificado en el ASA.
   

   Nota: Para obtener más información, consulte ASA 8.x: Renovación e Instalación del Certificado SSL con ASDM. Cree un punto de confianza independiente y no aplique este nuevo certificado con el comando ssl trustpoint <name>outside hasta que haya aplicado el certificado a todos los teléfonos IP VPN.

2. Exporte el nuevo certificado.
   
   
3. Importe el nuevo certificado a CUCM como certificado de confianza de VPN de teléfono.
   

   Nota: Tenga en cuenta que CSCuh19734 La carga de certificados con el mismo CN sobrescribirá el certificado antiguo en Phone-VPN-trust

4. Desplácese hasta la configuración de la puerta de enlace VPN en CUCM y aplique el nuevo certificado. Ahora tiene ambos certificados: el certificado que está a punto de caducar y el nuevo certificado que aún no se ha aplicado al ASA.
   
   
5. Aplique esta nueva configuración al teléfono IP. Vaya a Apply Config > Reset > Restart para insertar los nuevos cambios de configuración en el teléfono IP a través del túnel VPN. Asegúrese de que todos los teléfonos IP estén conectados a través de la VPN y que puedan alcanzar el servidor TFTP a través del túnel.
   
   
6. Utilice TFTP para verificar 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 sustituya el certificado antiguo.

  

Nota: Si el certificado SSL de ASA ya ha caducado y los teléfonos IP no pueden conectarse a través de AnyConnect, puede aplicar los cambios (como el nuevo hash del certificado de ASA) al teléfono IP. Establezca manualmente el TFTP en el teléfono IP en una dirección IP pública para que el teléfono IP pueda recuperar la información desde allí. Utilice un servidor TFTP público para alojar el archivo de configuración; un ejemplo es crear un reenvío de puertos en el ASA y redirigir el tráfico al servidor TFTP interno.