El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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:
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.
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:
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.
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:
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.
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.
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.
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.
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 |
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.
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:
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:
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:
Note: Si usted recibe un error similar al abajo, usted debe confirmar que la característica del cliente TFTP está activada.
<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>
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.
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:
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>
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.
%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.
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.
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
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:
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:
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#
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:
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:
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:
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.
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:
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.
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.
É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.
%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
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
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.
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:
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:
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.
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.
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
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.