Solucione problemas comunes con VPN IPSec L2L y de acceso remoto
Opciones de descarga
Lenguaje no discriminatorio
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.
Acerca de esta traducción
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).
Contenido
Introducción
Este documento contiene las soluciones más comunes para los problemas de VPN de IPSec.
Antecedentes
Estas soluciones provienen directamente de las solicitudes de servicio que el soporte técnico de Cisco ha resuelto.
Muchas de estas soluciones se implementan antes de profundizar en la solución de problemas relacionados con una conexión de red privada virtual (VPN) IPSec.
En este documento se proporciona un resumen de los procedimientos comunes que se deben probar antes de comenzar a solucionar problemas de conexión.
Aunque los ejemplos de configuración en este documento son para uso en routers y dispositivos de seguridad, casi todos estos conceptos también son aplicables a VPN 3000.
Consulte Solución de problemas de seguridad de IP: comprensión y uso de comandos de depuración para obtener una explicación de los comandos de depuración comunes usados para solucionar problemas de IPSec en el software Cisco IOS® y en .
Nota: Cisco Adaptive Security Appliance (ASA) no pasa tráfico de multidifusión a través de túneles VPN IPSec.
Advertencia: Muchas de las soluciones que aparecen en este documento pueden causar una pérdida temporal de conectividad VPN IPSec en un dispositivo.
Se recomienda que estas soluciones se implementen con precaución y de acuerdo con su política del control de cambios.
Prerequisites
Requirements
Cisco recomienda conocer la configuración VPN IPSec en estos dispositivos de Cisco:
-
Cisco ASA 5500 Series Security Appliance
-
Routers Cisco IOS®
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
-
Cisco ASA 5500 Series Security Appliance
-
Las versiones del software Cisco IOS®
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Convenciones
Consulte el documento Cisco Technical Tips Conventions (Convenciones sobre consejos técnicos de Cisco) para obtener más información sobre las convenciones de los documentos.
La Configuración de VPN IPSec no Funciona
Problema
Una solución recientemente configurada o modificada de VPN IPSec no funciona.
Una configuración de VPN IPSec ya no funciona.
Soluciones
Esta sección contiene las soluciones para la mayoría de los problemas de VPN IPSec.
Aunque no siguen ningún orden, estas soluciones se pueden usar como una lista de comprobación de elementos para verificar o probar antes de iniciar una corrección exhaustiva.
Todas estas soluciones provienen directamente de solicitudes de servicio de Cisco Technical Assistance Center (TAC) y han resuelto numerosos problemas.
-
Despejar las Asociaciones de Seguridad Antiguas o Existentes (Túneles)
-
Verificar que los comandos sysopt estén presentes (solo Cisco ASA)
-
Verificar que las ACL sean Correctas y Estén Enlazadas al Mapa Crypto
-
Verifocar el Nombre y los Números de Secuencia del Mapa Crypto
-
Problemas con el Tiempo de Espera para el Tráfico del Cliente VPN
Nota: Algunos de los comandos de estas secciones se han separado en dos líneas debido a cuestiones de espacio.
Habilitar NAT-Traversal (Problema de VPN RA n.º 1)
NAT-Traversal (o NAT-T) permite que el tráfico VPN pase a través de los dispositivos NAT o PAT, como un router Linksys SOHO.
Si NAT-T no está habilitada, los usuarios de VPN Client a menudo parecen conectarse a Cisco ASA sin problemas, pero no pueden acceder a la red interna detrás del dispositivo de seguridad.
Si no habilita NAT-T en el dispositivo NAT/PAT, puede recibir el mensaje de error común en ASA translation creation failed for protocol 50 src inside:10.0.1.26 dst outside:10.9.69.4 (error de creación de traducción regular para el protocolo 50 src inside:10.0.1.26 dst outside:10.9.69.4).
Del mismo modo, si no puede iniciar sesión simultáneamente desde la misma dirección IP, aparecerá el mensaje de error Secure VPN connection terminated locally by client (conexión local cerrada por el cliente). Reason 412: El par remoto ya no responde.aparece el mensaje de error.
Habilite NAT-T en el dispositivo de VPN headend para resolver este error.
Nota: Con la versión de software Cisco IOS® 12.2(13)T y posteriores, NAT-T queda habilitada de forma predeterminada en Cisco IOS.
Este es el comando para habilitar NAT-T en un Dispositivo de Seguridad de Cisco. En este ejemplo, el valor veinte (20) es el tiempo de mantenimiento de la conexión [keepalive] (predeterminado).
ASA
securityappliance(config)#crypto isakmp nat-traversal 20
Para que funcione, los clientes también deben ser modificados.
En Cisco VPN Client, navegue hasta Connection Entries (Entradas de conexión) y haga clic en Modify (Modificar). Se abrirá una ventana nueva donde debe elegir la pestaña Transport (Transportar).
En esta pestaña, haga clic en Enable Transparent Tunneling (Habilitar tunelización transparente) y en el botón de opción IPSec over UDP (NAT / PAT) (IPSec sobre UDP [NAT/PAT]). Luego haga clic en Save (Guardar) y pruebe la conexión.
Es importante habilitar los puertos UDP 4500 para NAT-T, UDP 500 y ESP a través de la configuración de una ACL porque ASA se comporta como un dispositivo NAT.
Para más información sobre la configuración de ACL en ASA, consulte Configurar un túnel IPsec a través de un firewall con NAT
Probar la Conectividad Correctamente
Lo ideal es que la conectividad VPN se pruebe desde los dispositivos que están detrás de los dispositivos terminales que realizan la encriptación. Sin embargo, muchos usuarios prueban la conectividad VPN con el comando ping en los dispositivos que realizan la encriptación.
Aunque el comando ping normalmente funciona para este propósito, es importante que se origine desde la interfaz correcta.
Si el ping no se origina correctamente, puede parecer que la conexión VPN falla cuando en realidad funciona. Este es un ejemplo:
Crypto ACL de Router A
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Crypto ACL de Router B
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
En esta situación, se debe originar un ping desde la red interna detrás de cualquiera de los routers. Esto es así porque las ACL crypto solo están configuradas para cifrar el tráfico con esas direcciones de origen.
No secifrará un ping originado desde las interfaces externas de cualquier router Utilice las opciones ampliadas del comando ping en el modo EXEC privilegiado para originar un ping desde la interfaz interna de un router:
routerA#ping Protocol [ip]: Target IP address: 192.168.200.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.100.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds: Packet sent with a source address of 192.168.100.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = ½/4 ms
Imagine que los routers de este diagrama se reemplazaron con dispositivos de seguridad ASA. El ping usado para probar la conectividad también se puede originar desde la interfaz interna con la palabra clave inside (interna):
securityappliance#ping inside 192.168.200.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
No se recomienda dirigirse a la interfaz interna de un dispositivo de seguridad con su ping.
Si debe dirigirse a una interfaz interna con su ping, debe habilitar management-access en esa interfaz o el dispositivo no responderá.
securityappliance(config)#management-access inside
Cuando existe un problema con la conectividad, incluso la fase uno (1) de VPN no funciona.
En Cisco ASA, si falla la conectividad, el resultado de SA es similar a este ejemplo, lo que indica una posible configuración de pares criptográficos incorrecta o una configuración de la propuesta de protocolo de administración de claves y asociaciones de seguridad de Internet (ISAKMP) incorrecta:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2
El estado puede ser de MM_WAIT_MSG2 a MM_WAIT_MSG5, lo que indica la falla del intercambio de estado en cuestión en Modo principal (MM, Main Mode).
La salida SA crypto cuando la fase 1 está activa es similar a este ejemplo:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Habilitar ISAKMP
Si no hay ninguna indicación de que un túnel VPN IPSec funcione, es posible que ISAKMP no se haya habilitado. Asegúrese de haber habilitado ISAKMP en sus dispositivos.
Utilice uno de estos comandos para habilitar ISAKMP en sus dispositivos:
Las versiones del software Cisco IOS®
router(config)#crypto isakmp enable
Cisco ASA (reemplace outside [externa] con la interfaz deseada).
securityappliance(config)#crypto isakmp enable outside
También puede obtener este error cuando habilita ISAKMP en la interfaz exterior:
UDP: ERROR - socket <unknown> 62465 in used ERROR: IkeReceiverInit, unable to bind to port
La causa del error puede ser que el cliente detrás de Cisco ASA obtenga PAT al puerto UDP 500 antes de que se pueda habilitar ISAKMP en la interfaz. Una vez que se quita esa traducción de PAT (despejar xlate), isakmp puede ser habilitado.
Verifique que los números de puerto UDP 500 y 4500 estén reservados para la negociación de conexiones ISAKMP con el par.
Cuando ISAKMP no esté habilitado en la interfaz, el cliente VPN muestra un mensaje de error similar a este mensaje:
Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding
Para resolver este error, habilite ISAKMP en la interfaz crypto del gateway de VPN.
Habilitar/Inhabilitar PFS
En las negociaciones de IPSec, Perfect Forward Secrecy (PFS) garantiza que cada clave criptográfica nueva no esté relacionada a cualquier clave anterior.
Habilite o inhabilite PFS en ambos peers de túnel; de lo contrario, el túnel IPsec de LAN a LAN (L2L) no se establece en el router ASA/Cisco IOS®.
Perfect Forward Secrecy (PFS) es propiedad de Cisco y no es soportado en otros dispositivos de terceros.
ASA:
PFS se inhabilita de forma predeterminada. Para habilitar PFS, use el comando pfs con la palabra clave enable (habilitar) en el modo de configuración group-policy (políticas de grupo). Para inhabilitar PFS, ingrese la palabra clave disable (inhabilitar).
hostname(config-group-policy)#pfs {enable | disable}
Para eliminar el atributo PFS de la configuración, ingrese la forma no de este comando.
Una política de grupo puede heredar un valor para PFS de otra política de grupo. Ingrese la forma no de este comando para evitar la transferencia de un valor.
hostname(config-group-policy)#no pfs
Router Cisco IOS®:
Para especificar que IPSec debe solicitar PFS cuando se solicitan nuevas asociaciones de seguridad para esta entrada de mapa criptográfico, use el comando set pfs en el modo de configuración de mapa criptográfico.
Para especificar que IPSec requiere PFS cuando recibe solicitudes de nuevas asociaciones de seguridad, use el comando set pfs en el modo de configuración de mapa criptográfico.
Para especificar que IPSec no debe solicitar a PFS, utilice la forma no de este comando. De forma predeterminada, PFS no se solicita. Si no se especifica ningún grupo con este comando, como valor predeterminado se utiliza group1.
set pfs [group1 | group2] no set pfs
Para el comando set pfs:
-
group1: Especifica que IPSec debe utilizar el grupo de módulos primos Diffie Hellman de 768 bits cuando se ejecuta el nuevo intercambio Diffie-Hellman.
-
group2: Especifica que IPSec debe utilizar el grupo de módulos primos Diffie Hellman de 1024 bits cuando se ejecuta el nuevo intercambio Diffie-Hellman.
Ejemplo:
Router(config)#crypto map map 10 ipsec-isakmp Router(config-crypto-map)#set pfs group2
Borrar asociaciones de seguridad (túneles) antiguas o existentes
Si este mensaje de error aparece en el router Cisco IOS®, el problema es que la SA expiró o se borró.
El dispositivo de extremo de túnel remoto no sabe que utiliza una SA expirada para enviar un paquete (no un paquete de establecimiento de SA).
Cuando se ha establecido una nueva SA, la comunicación se reanuda y se inicia el tráfico interesante a través del túnel para crear una nueva SA y restablecer el túnel.
%CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x has no SA
Despejar las asociaciones de seguridad ISAKMP (Fase I) e IPSec (Fase II) (SA) es la solución más simple y, a menudo, la mejor solución para resolver los problemas de VPN IPSec.
Si usted despeja las SA, puede solucionar frecuentemente una amplia variedad de mensajes de error y de conductas extrañas sin la necesidad de tener que resolver problemas.
Si bien esta técnica se puede utilizar fácilmente en cualquier situación, casi siempre es un requisito despejar las SA después de cambiar o agregar a la configuración de IPSec VPN actual.
Por otra parte, si bien es posible despejar solo asociaciones de seguridad específicas, el mayor beneficio se obtiene cuando despeja las SA en forma global en el dispositivo.
Una vez que las asociaciones de seguridad han sido despejadas, puede ser necesario enviar el tráfico a través del túnel para restablecerlas.
Advertencia: A menos que especifique qué asociaciones de seguridad quiere borrar, los comandos que se enumeran a continuación pueden borrar todas las asociaciones de seguridad del dispositivo. Proceda con cautela si otros túneles de VPN IPSec están en uso.
-
Vea las asociaciones de seguridad antes de despejarlas.
-
Cisco IOS®
router#show crypto isakmp sa router#show crypto ipsec sa
-
Dispositivos de seguridad Cisco ASA
securityappliance#show crypto isakmp sa securityappliance#show crypto ipsec sa
-
-
Despeje las asociaciones de seguridad. Cada comando se puede ingresar como se muestra en negrita o con las opciones que aparecen con ellos.
-
Las versiones del software Cisco IOS®
-
ISAKMP (Fase I)
router#clear crypto isakmp ? <0 - 32766> connection id of SA <cr>
-
IPSec (Fase II)
router#clear crypto sa ? counters Reset the SA counters map Clear all SAs for a given crypto map peer Clear all SAs for a given crypto peer spi Clear SA by SPI <cr>
-
-
Dispositivos de seguridad Cisco ASA
-
ISAKMP (Fase I)
securityappliance#clear crypto isakmp sa
-
IPSec (Fase II)
security appliance#clear crypto ipsec sa ? counters Clear IPsec SA counters entry Clear IPsec SAs by entry map Clear IPsec SAs by map peer Clear IPsec SA by peer <cr>
-
-
Verificar la duración de ISAKMP
Si frecuentemente los usuarios se desconectan a través del túnel L2L, el problema puede ser la menor duración configurada en SA ISAKMP.
Si se produce alguna discrepancia en la duración de ISAKMP, puede recibir el mensaje de error%ASA-5-713092: Grupo = x.x.x.x, IP = x.x.x.x, Falla durante la fase 1 del intento de regeneración de claves debido al mensaje de error de colisión en /ASA.
El valor predeterminado es 86.400 segundos o 24 horas. Como regla general, una duración más corta proporciona negociaciones de ISAKMP más seguras (hasta un punto); sin embargo, con duraciones más cortas, el dispositivo de seguridad configura las SA IPsec futuras más rápido.
Se logra una coincidencia cuando ambas políticas de los dos peers contienen los mismos valores de parámetro de cifrado, hash, autenticación y Diffie-Hellman, y cuando la política del peer remoto especifica una duración inferior o igual a la duración de la política comparada.
Si las duraciones no son idénticas, se utiliza la duración más corta (de la política del peer remoto). Si no se encuentra una coincidencia aceptable, IKE rechaza la negociación y la SA IKE no se establece.
Especifique la duración de SA. En este ejemplo, se establece una duración de 4 horas (14.400 segundos). El valor predeterminado es 86.400 segundos (24 horas).
ASA
hostname(config)#isakmp policy 2 lifetime 14400
Router Cisco IOS®
R2(config)#crypto isakmp policy 10 R2(config-isakmp)#lifetime 86400
Si se supera la duración máxima configurada, usted recibe el siguiente mensaje de error cuando la conexión VPN se termina:
Secure VPN Connection terminated locally by the Client. Reason 426: Maximum Configured Lifetime Exceeded.
Para resolver este mensaje de error, configure el valor de lifetime (duración) en cero (0) para establecer la duración de una asociación de seguridad IKE en infinito. La VPN siempre está conectada y no termina.
hostname(config)#isakmp policy 2 lifetime 0
También puede deshabilitar re-xauth en políticas de grupo para resolver el problema.
Habilitar o Inhabilitar los Keepalives de ISAKMP
Si configura los keepalives de ISAKMP, esto ayuda a prevenir las caídas esporádicas de las VPN de Acceso Remoto o de LAN a LAN, que incluyen los clientes VPN, los túneles y los túneles que se caen después de un período de inactividad.
Esta función permite que el extremo del túnel monitoree la presencia continua de un peer remoto e informa su propia presencia a ese par.
Si el peer deja de responder, el extremo quita la conexión.
Para que los keepalives de ISAKMP funcionen, ambos extremos de VPN deben soportarlos.
Configure los tiempos de mantenimiento de la conexión [keepalives] de ISAKMP en Cisco ISO® con este comando:
router(config)#crypto isakmp keepalive 15
Use estos comandos para configurar los tiempos de mantenimiento de la conexión [keepalives] de ISAKMP en los dispositivos de seguridad Cisco ASA:
Cisco ASA para el grupo de túnel denominado 10.165.205.222
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive threshold 15 retry 10
En algunas situaciones, es necesario inhabilitar esta función para solucionar el problema, por ejemplo, si el cliente VPN está detrás de un Firewall que evita los paquetes DPD.
Cisco ASA para el grupo de túnel denominado10.165.205.222
Deshabilite el procesamiento de mantenimiento de la conexión [keepalive] de IKE, que está habilitado de forma predeterminada.
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive disable
Inhabilite Keepalive para Cisco VPN Client 4.x.
Navegue hasta % System Root% > Program Files (Archivos de programa) > Cisco Systems > VPN Client (Cliente VPN) > Profiles (Perfiles) en la PC cliente que tiene el problema para deshabilitar el mantenimiento de la conexión [keepalive] de IKE y edite el archivo PCF, donde corresponda, para la conexión.
Cambie ForceKeepAlives=0 (predeterminado) a ForceKeepAlives=1.
Los keepalives son propiedad de Cisco y no son soportados por dispositivos de terceros.
Volver a Ingrese o Recuperar Claves Previamente Compartidas
En muchos casos, un simple error tipográfico puede ser la causa de que un túnel VPN IPSec no funcione. Por ejemplo, en el dispositivo de seguridad, las claves previamente compartidas se ocultan una vez que se ingresan.
Esta ofuscación hace imposible ver si una clave es incorrecta. Asegúrese de que ha ingresado las claves previamente compartidas correctamente en cada extremo de VPN.
Vuelva a ingresar una clave de nuevo para estar seguro de que es correcta; esta es una solución simple que puede ayudar a evitar el troubleshooting detallado.
In Remote Access VPN, verifique se que hayan ingresado la clave previamente compartida y el nombre de grupo válidos en Cisco VPN Client.
Puede abordar este error si el nombre de grupo o la clave previamente compartida no coinciden entre el cliente VPN y el dispositivo de cabecera.
1 12:41:51.900 02/18/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 2 12:41:51.900 02/18/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed 3 14:37:50.562 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 4 14:37:50.593 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202) 5 14:44:15.937 10/05/06 Sev=Warning/2 IKE/0xA3000067 Received Unexpected InitialContact Notify (PLMgrNotify:888) 6 14:44:36.578 10/05/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 7 14:44:36.593 10/05/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed... possibly be configured with invalid group password. 8 14:44:36.609 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 9 14:44:36.640 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202)
Advertencia: Si elimina comandos relacionados con la encriptación, es probable que desactive uno o todos los túneles VPN. Use estos comandos con precaución y consulte la política de control de cambios de su organización antes de eliminar comandos relacionados con la encriptación.
Use estos comandos para quitar y volver a introducir la clave previamente compartida secretkey para el par 10.0.0.1 o el grupo vpngroup en Cisco IOS®:
VPN de LAN a LAN de Cisco
router(config)#no crypto isakmp key secretkey address 10.0.0.1 router(config)#crypto isakmp key secretkey address 10.0.0.1
VPN de Acceso Remoto de Cisco
router(config)#crypto isakmp client configuration group vpngroup router(config-isakmp-group)#no key secretkey router(config-isakmp-group)#key secretkey
Use estos comandos para quitar y volver a ingresar la clave previamente compartida secretkey para el par 10.0.0.1 en los dispositivos de seguridad /Cisco ASA:
Cisco 6.x
(config)#no isakmp key secretkey address 10.0.0.1 (config)#isakmp key secretkey address 10.0.0.1
Cisco /Cisco ASA 7.x y versiones posteriores
securityappliance(config)#tunnel-group 10.0.0.1 ipsec-attributes securityappliance(config-tunnel-ipsec)#no ikev1 pre-shared-key securityappliance(config-tunnel-ipsec)# ikev1 pre-shared-key secretkey
Clave Previamente Compartida No Coincidente
La iniciación del Túnel VPN se desconecta. Este problema ocurre debido a una clave previamente compartida no coincidente durante las negociaciones de la fase I.
El mensaje MM_WAIT_MSG_6 en el comando show crypto isakmp sa indica una clave previamente compartida no coincidente, como se muestra en este ejemplo:
ASA#show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel reports 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.7.13.20
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG_6
Para resolver este problema, vuelva a ingresar la clave previamente compartida en ambos dispositivos; la clave previamente compartida debe ser única y coincidente. Consulte Volver a introducir o recuperar claves previamente compartidas para más información.
Quitar y Volver a Aplicar Mapas Crypto
Si borra asociaciones de seguridad, pero no se resuelve un problema de VPN IPSec, quite y vuelva a aplicar el mapa criptográfico relevante para resolver una amplia variedad de problemas que incluyen caídas intermitentes del túnel VPN y errores de activación de algunos sitios VPN.
Advertencia: Si quita un mapa criptográfico de una interfaz, esto desactiva definitivamente cualquier túnel IPSec asociado con ese mapa criptográfico. Realice estos pasos con precaución y tenga en cuenta la política de control de cambios de su organización antes de proceder.
Use estos comandos para quitar y reemplazar un mapa criptográfico en Cisco IOS®:
Comience por quitar el mapa crypto de la interfaz. Use la forma "no" del comando crypto map.
router(config-if)#no crypto map mymap
Continúe usando la forma no para quitar un mapa criptográfico completo.
router(config)#no crypto map mymap 10
Reemplace el mapa crypto en la interfaz Ethernet0/0 para el peer10.0.0.1. Este ejemplo muestra la configuración mínima requerida del mapa crypto:
router(config)#crypto map mymap 10 ipsec-isakmp router(config-crypto-map)#match address 101 router(config-crypto-map)#set transform-set mySET router(config-crypto-map)#set peer 10.0.0.1 router(config-crypto-map)#exit router(config)#interface ethernet0/0 router(config-if)#crypto map mymap
Use estos comandos para quitar y reemplazar un mapa criptográfico en Cisco ASA:
Comience por quitar el mapa crypto de la interfaz. Use la forma "no" del comando crypto map.
securityappliance(config)#no crypto map mymap interface outside
Continúe usando la forma no para quitar los otros comandos de mapa criptográfico.
securityappliance(config)#no crypto map mymap 10 match address 101 securityappliance(config)#no crypto map mymap set transform-set mySET securityappliance(config)#no crypto map mymap set peer 10.0.0.1
Reemplace el mapa crypto para el peer10.0.0.1. Este ejemplo muestra la configuración mínima requerida del mapa crypto:
securityappliance(config)#crypto map mymap 10 ipsec-isakmp securityappliance(config)#crypto map mymap 10 match address 101 securityappliance(config)#crypto map mymap 10 set transform-set mySET securityappliance(config)#crypto map mymap 10 set peer 10.0.0.1 securityappliance(config)#crypto map mymap interface outside
Si usted quita y vuelva a aplicar un mapa crypto, esto también resuelve el problema de conectividad si la dirección IP de headend se ha cambiado.
Verificar que los comandos sysopt estén presentes (solo Cisco ASA)
Los comandos sysopt connection permit-ipsec y sysopt connection permit-vpn permiten que los paquetes de un túnel IPSec y sus cargas útiles eludan las ACL de interfaz del dispositivo de seguridad.
Es probable que los túneles IPsec que se terminan en el dispositivo de seguridad fallen si uno de estos comandos no se habilita.
En las versiones 7.0 y anteriores del software de dispositivos de seguridad, el comando sysopt pertinente para esta situación es sysopt connection permit-ipsec.
En las versiones 7.1(1) y posteriores del software de dispositivos de seguridad, el comando sysopt pertinente para esta situación es sysopt connection permit-vpn.
En 6.x, esta funcionalidad está deshabilitada de forma predeterminada. En /Cisco ASA 7.0(1) y versiones posteriores, esta funcionalidad está habilitada de forma predeterminada. Use estos comandos show para determinar si el comando sysopt pertinente está habilitado en su dispositivo:
Cisco ASA
securityappliance# show running-config all sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret sysopt connection permit-vpn !--- sysopt connection permit-vpn is enabled !--- This device is running 7.2(2)
Use estos comandos para habilitar el comando sysopt correcto para su dispositivo:
Cisco ASA
securityappliance(config)#sysopt connection permit-vpn
Si no quiere usar el comando sysopt connection, permita explícitamente el tráfico de interés requerido desde el origen hasta el destino.
Por ejemplo, de la LAN remota a la LAN local del dispositivo remoto y el "puerto UDP 500" para la interfaz externa del dispositivo remoto a la interfaz externa del dispositivo local, en la ACL externa.
Verificar la identidad ISAKMP
Si el túnel VPN IPSec no funcionó dentro de la negociación IKE, el error puede deberse a la incapacidad del par para reconocer la identidad de su par.
Cuando dos peers utilizan IKE para establecer asociaciones de seguridad IPSec, cada peer envía su identidad ISAKMP al peer remoto.
Envía su dirección IP o su nombre de host según cómo cada uno tenga configurada su identidad ISAKMP.
De forma predeterminada, la identidad ISAKMP de la unidad de firewall se establece en la dirección IP.
Como regla general, configure el dispositivo de seguridad y las identidades de sus peers de la misma manera para evitar una falla de negociación IKE.
Para configurar el ID de fase 2 que se enviará al par, use el comando isakmp identity en el modo de configuración global.
crypto isakmp identity address !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with pre-shared key as authentication type
O
crypto isakmp identity auto !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with ISAKMP negotiation by connection type; IP address for !--- preshared key or cert DN for certificate authentication.
O
crypto isakmp identity hostname !--- Uses the fully-qualified domain name of !--- the host exchange ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
El túnel VPN no se activa después de un cambio de configuración de ASA a ASA con la herramienta de migración de configuración de ASA; en el log, aparecen estos mensajes:
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Stale PeerTblEntry found, removing!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, construct_ipsec_delete(): No SPI to identify Phase 2 SA!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
Verificar el Tiempo de Espera de la Sesión/Inactividad
Si el tiempo de espera de inactividad se establece en 30 minutos (valor predeterminado), significa que el túnel se desactiva después de 30 minutos sin tráfico a través de él.
El cliente VPN se desconecta después de 30 minutos, independientemente del parámetro de tiempo de espera inactivo, y encuentra el error PEER_DELETE-IKE_DELETE_UNSPECIFIED.
Configure idle timeout (tiempo de espera inactivo) y session timeout (tiempo de espera de la sesión) como none (ninguno) para que el túnel esté siempre activo y nunca se descarte, incluso cuando se usan dispositivos de terceros.
ASA
Ingrese el comando vpn-idle-timeout en el modo de configuración de políticas de grupo o en el modo de configuración de nombre de usuario para configurar el período de tiempo de espera del usuario:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-idle-timeout none
Configure una cantidad máxima de tiempo para las conexiones VPN con el comando vpn-session-timeout en el modo de configuración de políticas de grupo o en el modo de configuración de nombre de usuario:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-session-timeout none
Cuando tiene configurada la opción tunnel-all, no necesita configurar idle-timeout porque, incluso si configura el tiempo de espera inactivo de VPN, no funcionará porque todo el tráfico pasa por el túnel (dado que está configurada la opción "tunnel-all").
Por lo tanto, el tráfico de interés (o incluso el tráfico generado por la PC) es interesante y no permite que se active el tiempo de espera inactivo.
Router Cisco IOS®
Use el comando crypto ipsec security-association idle-time en el modo de configuración global o el modo de configuración de mapa criptográfico para configurar el temporizador de inactividad de SA IPSec.
De forma predeterminada, los temporizadores de inactividad de SA IPSec están inhabilitados.
crypto ipsec security-association idle-time seconds
El tiempo se mide en segundos, los que el temporizador de inactividad permite que un par inactivo mantenga una SA. Los valores válidos para el argumento de segundos varía de 60 a 86.400.
Verifcar que las ACL sean Correctas y estén Enlazadas al Mapa Crypto
Hay dos listas de acceso que se utilizan en una configuración típica de VPN IPSec. Una lista de acceso se utiliza para eximir el tráfico destinado al túnel VPN del proceso NAT.
La otra lista de acceso define el tráfico para cifrar; esto incluye una ACL crypto en una configuración de LAN a LAN o una ACL de túnel dividido en una configuración de acceso remoto.
Cuando estas ACL se configuran incorrectamente o se pierden, el tráfico quizás fluye en una dirección a través del túnel VPN o directamente no se envía a través del túnel.
Asegúrese de vincular la ACL criptográfica con el mapa criptográfico mediante el comando crypto map match address en el modo de configuración global.
Asegúrese de haber configurado todas las listas de acceso necesarias para completar su configuración de VPN IPSec y de que esas listas de acceso definan el tráfico correcto.
Esta lista contiene las cosas simples para verificar cuando usted sospecha que una ACL es la causa de los problemas con su VPN IPSec.
Asegúrese de que sus ACL crypto y de exención de NAT especifiquen el tráfico correcto.
Si usted tiene varios túneles VPN y varias ACL crypto, asegúrese de que esas ACL no se superpongan.
Asegúrese de que su dispositivo esté configurado para utilizar la ACL de exención de NAT. En un router, esto significa que debe usar el comando route-map.
En Cisco ASA, esto significa que debe usar el comando nat (0). Se requiere una ACL de exención de NAT para las configuraciones tanto de LAN a LAN como de acceso remoto.
En este ejemplo, un router Cisco IOS® está configurado para eximir tráfico que se envía entre 192.168.100.0 /24 y 192.168.200.0 /24 o 192.168.1.0 /24 desde NAT. El tráfico destinado a cualquier otra parte está sujeto a la sobrecarga NAT:
access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 any route-map nonat permit 10 match ip address 110 ip nat inside source route-map nonat interface FastEthernet0/0 overload
Las ACL de exención de NAT solo funcionan con la dirección IP o las redes IP, como esos ejemplos mencionados (access-list noNAT), y deben ser idénticas a las ACL de mapa crypto.
Las ACL de exención de NAT no funcionan con los números de puerto (por ejemplo, 23, 25, etc.).
En un entorno VOIP, donde las llamadas de voz entre redes se comunican a través de la VPN, las llamadas de voz no funcionan si las ACL NAT 0 no están configuradas correctamente.
Antes de abordar la solución de problemas, se recomienda verificar el estado de la conectividad VPN porque el problema podría ser la configuración incorrecta de ACL exentas de NAT.
Usted puede recibir el mensaje de error que se muestra si hay una configuración incorrecta de las ACL de exención de NAT (nat 0).
%ASA-3-305005: No translation group found for udp src Outside:x.x.x.x/p dst Inside:y.y.y.y/p
Ejemplo Incorrecto:
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 eq 25
Si la exención de NAT (nat 0) no funciona, intente quitarla y emita el comando NAT 0 para que funcione.
Asegúrese de que sus ACL no están al revés y de que sean del tipo adecuado.
Las ACL de exención de NAT y crypto para las configuraciones de LAN a LAN deben escribirse desde la perspectiva del dispositivo en el cual se configura la ACL.
Esto significa que las ACL deben reflejarse entre sí. En este ejemplo se establece un túnel de LAN a LAN entre 192.168.100.0 /24 y 192.168.200.0 /24.
Crypto ACL de Router A
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Crypto ACL de Router B
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Aunque no se incluye aquí, se puede aplicar el mismo concepto a los dispositivos de seguridad Cisco ASA.
En Cisco ASA, las ACL de túnel dividido para configuraciones de acceso remoto deben ser listas de acceso estándar que permitan tráfico hacia la red a la que los clientes VPN necesitan acceso.
Los routers Cisco IOS® pueden usar una ACL ampliada para el túnel dividido. En la lista de acceso ampliado, usar 'any' (cualquiera) en el origen en la ACL de túnel dividido es similar a deshabilitar el túnel dividido.
Use solo las redes de origen en la ACL ampliada para el túnel dividido.
Ejemplo Correcto:
access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255
Ejemplo Incorrecto:
access-list 140 permit ip any 10.18.0.0 0.0.255.255
Las versiones del software Cisco IOS®
router(config)#access-list 10 permit ip 192.168.100.0 router(config)#crypto isakmp client configuration group MYGROUP router(config-isakmp-group)#acl 10
Cisco ASA
securityappliance(config)#access-list 10 standard permit 192.168.100.0 255.255.255.0 securityappliance(config)#group-policy MYPOLICY internal securityappliance(config)#group-policy MYPOLICY attributes securityappliance(config-group-policy)#split-tunnel-policy tunnelspecified securityappliance(config-group-policy)#split-tunnel-network-list value 10
Configuración de la exención de NAT en la versión 8.3 de ASA para un túnel de VPN de sitio a sitio:
Debe establecerse una VPN de sitio a sitio entre HOASA y BOASA con ambos ASA con la versión 8.3. La configuración de exención de NAT en HOASA es similar a esta:
object network obj-local subnet 192.168.100.0 255.255.255.0 object network obj-remote subnet 192.168.200.0 255.255.255.0 nat (inside,outside) 1 source static obj-local obj-local destination static obj-remote objremote
Verificar las Políticas ISAKMP
Si el túnel IPsec no está ACTIVADO, verifique que las políticas ISAKMP se correspondan con con los peers remotos. Esta política ISAKMP es aplicable a las VPN IPsec de Sitio a Sitio (L2L) y de Acceso Remoto.
Si Cisco VPN Client o la VPN de sitio a sitio no pueden establecer el túnel con el dispositivo de extremo remoto, verifique que los dos pares contengan los mismos valores de parámetros de encriptación, hash, autenticación y Diffie-Hellman.
Verifique cuando la política de pares remotos especifica una duración menor o igual a la duración de la política que envió el iniciador.
Si las duraciones no son idénticas, el dispositivo de seguridad utiliza la duración más corta. Si no existe una coincidencia aceptable, ISAKMP rechaza la negociación y la SA no se establece.
"Error: Unable to remove Peer TblEntry, Removing peer from peer table failed, no match!"
A continuación, se proporciona el mensaje del log detallado:
4|Mar 24 2010 10:21:50|713903: IP = X.X.X.X, Error: Unable to remove PeerTblEntry 3|Mar 24 2010 10:21:50|713902: IP = X.X.X.X, Removing peer from peer table failed, no match! 3|Mar 24 2010 10:21:50|713048: IP = X.X.X.X, Error processing payload: Payload ID: 1 4|Mar 24 2010 10:21:49|713903: IP = X.X.X.X, Information Exchange processing failed 5|Mar 24 2010 10:21:49|713904: IP = X.X.X.X, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, drop
Este mensaje suele aparecer debido a políticas ISAKMP no coincidentes o una instrucción NAT 0 perdida.
Además, aparece este mensaje:
Error Message %ASA-6-713219: Queueing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Este mensaje indica que los mensajes de fase 2 están en la cola una vez que finaliza la fase 1. Este mensaje de error se debe a uno de estos motivos:
-
Discordancia en la fase de cualquiera de los peers
-
La ACL impide que los pares completen la fase 1.
Este mensaje suele aparecer después del mensaje de error Removing peer from peer table failed, no match! (no se pudo quitar el par de la tabla de pares, no hay coincidencia).
Si el Cisco VPN Client no puede conectar el dispositivo headend, el problema puede ser la discordancia de la política ISAKMP. El dispositivo de cabecera debe coincidir con una de las propuestas IKE de Cisco VPN Client.
Para la política ISAKMP y el conjunto de transformación IPSec que se utiliza en Cisco ASA, Cisco VPN Client no puede utilizar una política con una combinación de estándar de cifrado de datos (DES) y algoritmo Secure Hash (SHA).
Si utiliza DES, debe utilizar MD5 para el algoritmo de hash o puede utilizar las otras combinaciones, 3DES con SHA y 3DES con MD5.
Verificar que el Ruteo sea Correcto
Asegúrese de que todos los dispositivos de encriptación, como routers y dispositivos de seguridad Cisco ASA, cuentan con la información de routing adecuada para enviar tráfico a través del túnel VPN.
Si existen otros routers detrás del dispositivo de puerta de enlace, asegúrese de que esos routers sepan cómo llegar al túnel y qué redes están del otro lado.
Un componente crucial de ruteo en una implementación de VPN es Reverse Route Injection (RRI).
RRI coloca entradas dinámicas para las redes remotas o los clientes VPN en la tabla de ruteo de un gateway de VPN.
Estas rutas son útiles para el dispositivo en el cual están instaladas, así como para los otros dispositivos de la red, porque las rutas instaladas mediante RRI se pueden redistribuir a través de un protocolo de ruteo como EIGRP o OSPF.
En una configuración de LAN a LAN, es importante que cada extremo tenga una o más ruta a las redes para las que se supone se cifra el tráfico.
En este ejemplo, el Router A debe tener rutas a las redes detrás del Router B a través de10.89.129.2. El Router B debe tener una ruta similar a192.168.100.0 /24:
La primera manera de asegurarse de que cada router conozca la ruta apropiada es configurar las rutas estáticas para cada red de destino. Por ejemplo, el Router A puede tener estas declaraciones de ruta configuradas:
ip route 0.0.0.0 0.0.0.0 172.22.1.1 ip route 192.168.200.0 255.255.255.0 10.89.129.2 ip route 192.168.210.0 255.255.255.0 10.89.129.2 ip route 192.168.220.0 255.255.255.0 10.89.129.2 ip route 192.168.230.0 255.255.255.0 10.89.129.2
Si el router A se reemplazó con un Cisco ASA, la configuración puede ser así:
route outside 0.0.0.0 0.0.0.0 172.22.1.1 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2
Si existe un gran número de redes detrás de cada extremo, la configuración de las rutas estáticas se torna difícil de mantener.
En cambio, se recomienda que utilice Reverse Route Injection, según lo descrito. RRI se coloca en las rutas de la tabla de ruteo para todas las redes remotas enumeradas en la ACL crypto.
Por ejemplo, la ACL crypto y el mapa crypto del Router A son similares a lo siguiente:
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.210.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.220.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.230.0 0.0.0.255 crypto map myMAP 10 ipsec-isakmp set peer 10.89.129.2 reverse-route set transform-set mySET match address 110
Si el router A se reemplazó con un Cisco ASA, la configuración puede ser así:
access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.210.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.220.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.230.0 255.255.255.0 crypto map myMAP 10 match address cryptoACL crypto map myMAP 10 set peer 10.89.129.2 crypto map myMAP 10 set transform-set mySET crypto map mymap 10 set reverse-route
En una configuración de Acceso Remoto, los cambios de ruteo no siempre son necesarios.
Sin embargo, si existen otros routers detrás del Dispositivo de Seguridad o del router de gateway VPN, esos routers necesitan conocer la trayectoria a los clientes VPN de alguna manera.
En este ejemplo se supone que a los clientes VPN se les asignan direcciones en el intervalo de 10.0.0.0 /24 cuando se conectan.
Si no hay un protocol de ruteo funcionando entre el gateway y el otro router, las rutas estáticas se pueden utilizar en los routers como Router 2:
ip route 10.0.0.0 255.255.255.0 192.168.100.1
Si entre el gateway y otros routers se utiliza un protocolo de ruteo como EIGRP o OSPF, se recomienda que se utilice Reverse Route Injection según lo descrito.
RRI agrega automáticamente rutas para el cliente VPN a la tabla de ruteo del gateway. Estas rutas se pueden distribuir a los otros routers en la red.
Router Cisco IOS®:
crypto dynamic-map dynMAP 10 set transform-set mySET reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
Dispositivo de seguridad Cisco ASA:
crypto dynamic-map dynMAP 10 set transform-set mySET crypto dynamic-map dynMAP 10 set reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
El problema de ruteo ocurre si el conjunto de direcciones IP asignadas para los clientes VPN son superposiciones con las redes internas del dispositivo headend. Para más información, consulte la sección Redes privadas superpuestas.
Verificar que Transform-Set sea Correcto
Asegúrese de que los algoritmos de hash y cifrado de IPSec que usará transform set en ambos extremos sean los mismos.
Para más información, consulte la sección Referencia de comandos de la guía de configuración de Cisco Security Appliance.
Para la política ISAKMP y el conjunto de transformación IPSec que se utiliza en Cisco ASA, Cisco VPN Client no puede utilizar una política con una combinación de estándar de cifrado de datos (DES) y algoritmo Secure Hash (SHA).
Si utiliza DES, debe utilizar MD5 para el algoritmo de hash o puede utilizar las otras combinaciones, 3DES con SHA y 3DES con MD5.
Verifique el Nombre y los Números de Secuencia de Mapa Crypto, y que el mapa Crypto esté aplicado en la interfaz correcta en la que comienza/termina el túnel IPsec
Si los peers estáticos y dinámicos están configurados en el mismo mapa crypto, el orden de las entradas de mapa crypto es muy importante.
El número de secuencia de la entrada del mapa criptográfico dinámico debe ser mayor que todas las demás entradas de mapa criptográfico estático.
Si las entradas estáticas tienen una numeración mayor que la entrada dinámica, las conexiones con dichos peers fallan y aparecen los debugs como se muestran.
IKEv1]: Group = x.x.x.x, IP = x.x.x.x, QM FSM error (P2 struct &0x49ba5a0, mess id 0xcd600011)! [IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
En el Dispositivo de Seguridad, solo se permite un mapa Crypto Dinámico para cada interfaz.
A continuación, se proporciona un ejemplo de un mapa crypto numerado correctamente que contiene una entrada estática y una entrada dinámica. Observe que la entrada dinámica tiene el número de secuencia más alto y que se ha dejado espacio para agregar entradas estáticas adicionales:
crypto dynamic-map cisco 20 set transform-set myset crypto map mymap 10 match address 100 crypto map mymap 10 set peer 172.16.77.10 crypto map mymap 10 set transform-set myset crypto map mymap interface outside crypto map mymap 60000 ipsec-isakmp dynamic ciscothe
Los nombres de mapa crypto distinguen entre mayúsculas y minúsculas.
Este mensaje de error también se puede ver cuando la secuencia de comando de mapa criptográfico dinámico no es correcta, lo que hace que el par llegue al mapa criptográfico incorrecto.
Esto también se debe a una lista de acceso criptográfico no coincidente que define el tráfico interesante:%ASA-3-713042: IKE Initiator unable to find policy:
En una situación en la que varios túneles VPN terminan en la misma interfaz, cree un mapa criptográfico con el mismo nombre (solo se permite un mapa criptográfico por interfaz) pero con un número de secuencia diferente.
Esto es válido para el router y Cisco ASA.
De manera similar, consulte ASA: Add a New Tunnel or Remote Access to an Existing L2L VPN - Cisco para obtener más información sobre la configuración de mapa criptográfico para el escenario L2L y Remote Access VPN.
Verificar que la Dirección IP sea Correcta
Cree y administre la base de datos de los registros específicos de conexión para IPSec.
Para una configuración de VPN IPSec de LAN a LAN (L2L) de Cisco Adaptative Security Appliance (ASA), especifique el <name> del grupo de túnel como la dirección IP del par remoto (extremo de túnel remoto) en el comando tunnel-group <name> type ipsec-l2l.
La dirección IP del par debe coincidir en los comandos tunnel group name y Crypto map set address.
Si bien usted configura la VPN con ASDM, se generó el nombre de grupo de túnel automáticamente con la dirección IP de peer correcta.
Si la dirección IP del par no está configurada correctamente, los registros pueden contener este mensaje, que se puede resolver mediante la configuración adecuada de la dirección IP del par.
[IKEv1]: Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Cuando la dirección IP del par no se ha establecido correctamente en la configuración criptográfica de Cisco ASA, Cisco ASA no puede establecer el túnel VPN y se bloquea en la etapa MM_WAIT_MSG4 solamente.
Para resolver este problema, corrija la dirección IP de peer en la configuración.
Este es el resultado del comando show crypto isakmp sa cuando el túnel VPN se bloquea en el estado MM_WAIT_MSG4.
hostname#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG4
Verificar el Grupo de Túnel y los Nombres de Grupo
%ASA-3-713206: Tunnel Rejected: Conflicting protocols specified by tunnel-group and group-policy
El mensaje aparece cuando se cae un túnel porque el túnel permitido especificado en la política de grupo difiere del túnel permitido en la configuración del grupo de túnel.
group-policy hf_group_policy attributes vpn-tunnel-protocol l2tp-ipsec username hfremote attributes vpn-tunnel-protocol l2tp-ipsec Both lines read: vpn-tunnel-protocol ipsec l2tp-ipsec
Habilite la política de IPSec en Grupo Predeterminado en la política de Protocolos Existentes de Grupo Predeterminado.
group-policy DfltGrpPolicy attributes vpn-tunnel-protocol L2TP-IPSec IPSec webvpn
Inhabilitar XAUTH para los Peers L2L
Si se configuran un túnel de LAN a LAN y un túnel VPN de acceso remoto en el mismo mapa criptográfico, se le solicitará información XAUTH al par de LAN a LAN y se generará un error en el túnel de LAN a LAN con "CONF_XAUTH en el resultado del comando show crypto isakmp sa.
A continuación, se proporciona un ejemplo del resultado de SA:
Router#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status X.X.X.X Y.Y.Y.Y CONF_XAUTH 10223 0 ACTIVE X.X.X.X Z.Z.Z.Z CONF_XAUTH 10197 0 ACTIVE
Este problema solo se aplica a Cisco IOS®, mientras que Cisco ASA no se ve afectado por este problema, ya que usa grupos de túneles.
Cuando ingrese la clave isakmp, use la palabra clave no-xauth (sin autenticación extendida), de manera que el dispositivo no le solicite al par información XAUTH (nombre de usuario y contraseña).
Esta palabra clave inhabilita XAUTH para los peers IPSec estáticos. Ingrese un comando similar a este en el dispositivo que tiene la configuración VPN L2L y RA en el mismo mapa de crypto:
router(config)#crypto isakmp key cisco123 address 172.22.1.164 no-xauth
En la situación en la que Cisco ASA actúa como servidor Easy VPN, el cliente Easy VPN no puede conectarse a la cabecera debido al problema de Xauth.
Deshabilite la autenticación de usuario en Cisco ASA para resolver el problema como se muestra a continuación:
ASA(config)#tunnel-group example-group type ipsec-ra ASA(config)#tunnel-group example-group ipsec-attributes ASA(config-tunnel-ipsec)#isakmp ikev1-user-authentication none
Consulte la sección Varios de este documento para más información sobre el comando isakmp ikev1-user-autenticación.
Agotamiento Progresivo del Conjunto VPN
Cuando el rango de las direcciones IP asignadas al conjunto VPN no es suficiente, usted puede extender la disponibilidad de las direcciones IP de dos maneras:
-
Quite el rango existente y defina el nuevo rango. Aquí tiene un ejemplo:
CiscoASA(config)#no ip local pool testvpnpool 10.76.41.1-10.76.41.254 CiscoASA(config)#ip local pool testvpnpool 10.76.41.1-10.76.42.254
-
Cuando las subredes discontinuas deben ser agregadas al conjunto VPN, usted puede definir dos conjuntos VPN separados y luego especificarlos en orden en “túnel-group attributes”. Aquí tiene un ejemplo:
CiscoASA(config)#ip local pool testvpnpoolAB 10.76.41.1-10.76.42.254 CiscoASA(config)#ip local pool testvpnpoolCD 10.76.45.1-10.76.45.254 CiscoASA(config)#tunnel-group test type remote-access CiscoASA(config)#tunnel-group test general-attributes CiscoASA(config-tunnel-general)#address-pool (inside) testvpnpoolAB testvpnpoolCD CiscoASA(config-tunnel-general)#exit
El orden en el cual usted especifica los conjuntos es muy importante porque ASA asigna direcciones de estos conjuntos en el orden en el cual los conjuntos aparecen en este comando.
La configurción address-pools en el comando group-policy address-pools command siempre invalida la configuración de grupo local en el comando tunnel-group address-pool.
Problemas con el Tiempo de Espera para el Tráfico del Cliente VPN
Cuando haya problemas de latencia en una conexión VPN, verifique estas condiciones para resolverlos:
-
Verifique si el MSS del paquete se puede reducir más.
-
Si se utiliza IPSec/tcp en lugar de IPSec/udp, configure preserve-vpn-flow.
-
Reconecte el Cisco ASA.
Los clientes VPN no pueden conectarse con Cisco ASA
Problema
Los Cisco VPN Clients no pueden autenticar cuando X-auth se utiliza con el servidor Radius.
Solución
El problema puede ser que xauth se ha desconectado. Aumente el valor del tiempo de espera para el servidor AAA a fin de resolver este problema.
Por ejemplo:
Hostname(config)#aaa-server test protocol radius hostname(config-aaa-server-group)#aaa-server test host 10.2.3.4 hostname(config-aaa-server-host)#timeout 10
Problema
Los Cisco VPN Clients no pueden autenticar cuando X-auth se utiliza con el servidor Radius.
Solución
Inicialmente, asegúrese de que la autenticación funcione correctamente. Para restringir el problema, primero verifique la autenticación con la base de datos local de ASA.
tunnel-group tggroup general-attributes
authentication-server-group none
authentication-server-group LOCAL
exit
Si esto funciona correctamente, el problema está relacionado con la configuración del servidor Radius.
Verifique la conectividad del servidor Radius desde ASA. Si el ping funciona sin ningún problema, verifique la configuración relacionada con Radius en ASA y la configuración de la base de datos en el servidor Radius.
Podría usar el comando debug radius para solucionar problemas relacionados con Radius. Para ver un ejemplo de resultado de debug radius, consulte este Ejemplo de resultado.
Antes de usar el comando debug en Cisco ASA, consulte esta documentación: Mensaje de advertencia.
La conexión del cliente VPN se corta con frecuencia en el primer intento o "Security Connection terminated by peer. Razón 433". o "Conexión VPN segura finalizada por el Peer Reason 433:(Reason Not Specified by Peer)"
Problema
Los usuarios de Cisco VPN Client reciben este error cuando intentan conectarse con el dispositivo VPN de cabecera.
VPN client drops connection frequently on first attempt.
Security VPN Connection terminated by peer. Reason 433.
Secure VPN Connection terminated by Peer Reason 433:(Reason Not Specified by Peer)
Attempted to assign network or broadcast IP address, removing (x.x.x.x) from pool. (El cliente VPN interrumpe la conexión con frecuencia en el primer intento. Conexión VPN de seguridad finalizada por el par. Conexión VPN segura finalizada por el par. Motivo 433: [motivo no especificado por el par]. Se intentó asignar una dirección IP de red o difusión, se quita (x.x.x.x) del grupo)
Solución 1
El problema puede estar relacionado con la asignación del grupo de IP, ya sea a través de Cisco ASA, el servidor Radius, el servidor DHCP o a través del servidor Radius que actúa como servidor DHCP.
Use el comando debug crypto para verificar que la máscara de red y las direcciones IP sean correctas. Además, verificar que el conjunto no incluya la dirección de red y a la dirección de broadcast.
Los servidores de RADIUS deben poder asignar las direcciones IPapropiados a los clientes.
Solución 2
Este problema también ocurre debido al incidente de la autenticación ampliada. Usted debe marcar el servidor de AAA para resolver problemas este error.
Verifique la contraseña de autenticación del servidor en el servidor y el cliente. Volver a cargar el servidor AAA puede resolver este problema.
Solución 3
Otra solución alternativa para este problema es inhabilitar la característica de la detección de la amenaza.
Cuando hay varias retransmisiones para diferentes asociaciones de seguridad (SA) incompletas, el Cisco ASA con la función de detección de amenazas habilitada cree que se produjo un ataque de escaneo y los puertos VPN se identifican como el infractor principal.
Intentar inhabilitar la característica de la amenaza-detección como esto puede causar mucho incremento en el proceso del ASA. Utilice estos comandos para inhabilitar la detección de la amenaza:
no threat-detection basic-threat no threat-detection scanning-threat shun no threat-detection statistics no threat-detection rate
Esto se puede utilizar como solución alternativa para verificar si este repara el verdadero problema.
Tenga en cuenta que deshabilitar la detección de amenazas en Cisco ASA realmente compromete varias funciones de seguridad, como la mitigación de los intentos de análisis, DoS con inspección activa de paquetes (SPI) no válida, paquetes que no pasan la inspección de aplicaciones y sesiones incompletas.
Solución 4
Este problema también ocurre cuando un conjunto de la transformación no se configura correctamente. Una configuración adecuada del conjunto de la transformación resuelve el problema.
El acceso remoto y los usuarios del EZVPN conectan con el VPN pero no pueden acceder a los recursos externos
Problema
Los usuarios de acceso remotos no tienen ninguna conectividad a Internet una vez que conectan con el VPN.
Los usuarios de acceso remotos no pueden acceder los recursos situados detrás de otros VPN en el mismo dispositivo.
Los usuarios de acceso remotos pueden acceder solamente la red local.
Soluciones
Intentar estas soluciones para resolver este problema:
Incapaz de acceder los servidores en el DMZ
Una vez que el cliente VPN se ha establecido en el túnel IPSec con el dispositivo de cabecera VPN (router Cisco IOS®/Cisco ASA), los usuarios del cliente VPN pueden acceder a los recursos de la red INTERNA (10.10.10.0/24), pero no pueden acceder a la red de zona perimetral (DMZ) (10.1.1.0/24).
Diagrama
Marcar que el túnel dividido, NINGUNA configuración de NAT está agregado en el dispositivo de centro de distribuidor para acceder los recursos en la red DMZ.
Ejemplo:
Configuración de Cisco ASA:
Esta configuración muestra cómo configurar la exención de NAT para la red DMZ para habilitar a los usuarios de VPN para acceder la red DMZ:
object network obj-dmz subnet 10.1.1.0 255.255.255.0 object network obj-vpnpool subnet 192.168.1.0 255.255.255.0 nat (inside,dmz) 1 source static obj-dmz obj-dmz destination static obj-vpnpool obj-vpnpool
Después de que usted agregue una nueva entrada para la configuración de NAT, borrar la traducción NAT.
Clear xlate Clear local
Controle lo siguiente:
Si se estableció el túnel, vaya a Cisco VPN Client y elija Status (Estado) > Route Details (Detalles de ruta) para verificar que se muestren las rutas seguras para las redes INTERNA y DMZ.
Consulte ASA: Add a New Tunnel or Remote Access to an Existing L2L VPN - Cisco para conocer los pasos necesarios para agregar un nuevo túnel VPN o una VPN de acceso remoto a una configuración VPN L2L que ya existe.
Consulte ASA: Allow Split Tunneling for VPN Clients on the ASA Configuration Example para obtener instrucciones paso a paso sobre cómo permitir el acceso de clientes VPN a Internet mientras se tunelizan en un Cisco 5500 Series Adaptive Security Appliance (ASA).
Clientes de VPN incapaces de resolver los DN
Una vez establecido el túnel, si los clientes VPN no pueden resolver el DNS, el problema puede ser la configuración del servidor DNS en el dispositivo de cabecera (Cisco ASA).
También marcar la conectividad entre los clientes de VPN y el servidor DNS. La configuración del servidor DNS se debe configurar bajo política del grupo y aplicar bajo política del grupo en los atributos del general del túnel-grupo; por ejemplo:
!--- Create the group policy named vpn3000 and !--- specify the DNS server IP address(172.16.1.1) !--- and the domain name(cisco.com) in the group policy. group-policy vpn3000 internal group-policy vpn3000 attributes dns-server value 172.16.1.1 default-domain value cisco.com !--- Associate the group policy(vpn3000) to the tunnel group !--- with the default-group-policy. tunnel-group vpn3000 general-attributes default-group-policy vpn3000
Clientes VPN incapaces de conectar los servidores internos por nombre
El cliente VPN no puede pingear los hosts o los servidores del telecontrol o de la red interna del centro distribuidor por nombre. Usted necesita habilitar la configuración del fractura-DN en el ASA para resolver este problema.
Fractura-Túnel - Incapaz de acceder Internet o las redes excluidas
El túnel dividido permite a los usuarios IPSec de acceso remoto dirigir condicionalmente paquetes a través del túnel IPSec de forma cifrada o a una interfaz de red en forma de texto no cifrado, donde se enrutan a un destino final.
El túnel dividido está deshabilitado de forma predeterminada, lo que se refleja en la opción tunnelall de tráfico.
split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
La opción excludespecified se soporta solamente para los clientes del Cisco VPN, no los clientes EzVPN.
ciscoasa(config-group-policy)#split-tunnel-policy excludespecified
Para obtener ejemplos detallados acerca de la configuración del túnel dividido, consulte estos documentos:
Solución de devolución de llamadas
Esta característica es útil para el tráfico VPN que ingrese una interfaz pero después se rutea fuera de esa misma interfaz.
Por ejemplo, en una red VPN de tipo radial, donde el dispositivo de seguridad es la estrella y las redes VPN remotas son los radios, el tráfico de comunicación de radio a radio debe ingresar al dispositivo de seguridad y luego volver a salir hacia el otro radio.
Utilice la configuración same-security-traffic para permitir que el tráfico entre y salga de la misma interfaz.
securityappliance(config)#same-security-traffic permit intra-interface
Accesso del LAN local
Los usuarios de acceso remotos conectan con el VPN y pueden conectar con la red local solamente.
Para ver un ejemplo de configuración más detallado, consulte ASA: Permitir el accesso del LAN local para los clientes VPN.
Redes privadas superpuestas
Problema
Si usted no puede acceder la red interna después del establecimiento del túnel, marcar la dirección IP asignado al cliente VPN que solapa con la red interna detrás del dispositivo de centro de distribuidor.
Solución
Verifique que las direcciones IP del grupo que se asignará para los clientes VPN, la red interna del dispositivo de cabecera y la red interna del cliente VPN estén en redes diferentes.
Usted puede asignar la misma red principal con diversas subredes, pero los problemas de ruteo ocurren a veces.
Para obtener más ejemplos, consulte el Diagrama y ejemplo de la sección No se puede acceder a los servidores en DMZ.
Incapaz de conectar a más de tres usuarios del cliente de VPN
Problema
Solo tres clientes VPN pueden conectarse a ASA/; la conexión para el cuarto cliente falla. Sobre el incidente, se visualiza este mensaje de error:
Secure VPN Connection terminated locally by the client. Reason 413: User Authentication failed.
tunnel rejected; the maximum tunnel count has been reached
Soluciones
En la mayoría de los casos, este problema se relaciona con una configuración simultánea del login dentro de la política del grupo y del sesión-límite máximo.
Intentar estas soluciones para resolver este problema:
Configurar los Logins Simultáneos
Si la casilla de verificación Inherit (Heredar) está marcada en Cisco Adaptive Security Device Manager (ASDM), solo se permite el número predeterminado de inicios de sesión simultáneos para el usuario. El valor predeterminado para inicios de sesión simultáneos es tres (3).
Para resolver este problema, aumentar el valor para los logins simultáneos.
-
Inicie Cisco Adaptive Security Device Manager (ASDM) y luego vaya a Configuration (Configuración) > VPN > Group Policy (Políticas de grupo).
-
Elija el Grupo adecuado y haga clic en el botón Edit (Editar).
-
En la pestaña General, anule la selección en la casilla de verificación Inherit (Heredar) para Simultaneous Logins (Inicios de sesión simultáneos) en Connection Settings (Configuración de conexión). Elija un valor apropiado en el campo.
El valor mínimo para este campo es cero (0), lo que deshabilita el inicio de sesión e impide el acceso de los usuarios.
Cuando inicia sesión con la misma cuenta de usuario desde una PC diferente, la sesión actual (la conexión establecida desde otra PC con la misma cuenta de usuario) finaliza y se establece la nueva sesión.
Este es el comportamiento predeterminado y es independiente a los logins simultáneos VPN.
Configurar Cisco ASA con CLI
Realice estos pasos para configurar el número de inicios de sesión simultáneos que quiera. En este ejemplo, se eligió veinte (20) como valor deseado.
ciscoasa(config)#group-policy Bryan attributes ciscoasa(config-group-policy)#vpn-simultaneous-logins 20
Para más información sobre este comando, consulte la Referencia de comandos de Cisco Security Appliance.
Use el comando vpn-sessiondb max-session-limit en el modo de configuración global para limitar las sesiones VPN a un valor inferior al que permite el dispositivo de seguridad.
Use la versión no de este comando para eliminar el límite de sesiones. Utilice el comando para sobrescribir otra vez la configuración actual.
vpn-sessiondb max-session-limit {session-limit}
Este ejemplo muestra cómo establecer un límite máximo de la sesión de VPN de 450:
hostname#vpn-sessiondb max-session-limit 450
Configurar
Mensaje de error
20932 10/26/2007 14:37:45.430 SEV=3 AUTH/5 RPT=1863 10.19.187.229 Authentication rejected: Reason = Simultaneous logins exceeded for user handle = 623, server = (none), user = 10.19.187.229, domain = <not specified>
Solución
Complete estos pasos para configurar el número deseado de logins simultáneos. Usted puede también intentar establcer los Logins simultáneos a 5 para este SA:
Elija Configuration (Configuración) > User Management (Administración de usuarios) > Groups (Grupos) > Modify 10.19.187.229 > (Modificar 10.19.187.229) > General > Simultaneous Logins (Inicios de sesión simultáneos) y cambie el número de inicios de sesión a 5.
Incapaz de iniciar la sesión o una aplicación y de reducir la transferencia después del establecimiento del túnel
Problema
Después del establecimiento del túnel IPsec, la aplicación o la sesión no inicia a través del túnel.
Soluciones
Use el comando ping para comprobar la red o buscar si se puede tener acceso al servidor de aplicaciones desde su red.
Puede ser un problema relacionado con el tamaño máximo del segmento (MSS) para paquetes transitorios que atraviesan un router o dispositivo /Cisco ASA, específicamente segmentos TCP con el bit SYN configurado.
Router Cisco IOS®: cambie el valor de MSS en la interfaz externa (interfaz de extremo del túnel) del router.
Funcionar con estos comandos para cambiar el valor MSS en la interfaz exterior (interfaz del extremo del túnel) del router:
Router>enable Router#configure terminal Router(config)#interface ethernet0/1 Router(config-if)#ip tcp adjust-mss 1300 Router(config-if)#end
Estos mensajes muestran la salida de los debugs para TCP MSS:
Router#debug ip tcp transactions Sep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)] Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 1300, MSS is 1300 Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751 Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 1300 Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]
El MSS consigue ajustado a 1300 en el router según lo configurado.
Para obtener más información, consulte ASA y Cisco IOS®: Fragmentación VPN.
Cisco ASA: consulte la documentación de /Cisco ASA.
Hay una incapacidad para acceder Internet correctamente o para reducir la transferencia a través del túnel porque da el mensaje de error de la talla del MTU y los problemas MSS.
Consulte este documento para resolver el problema:
No se puede iniciar el túnel VPN desde Cisco ASA
Problema
No puede iniciar el túnel VPN desde la interfaz de Cisco ASA y, después del establecimiento del túnel, el cliente VPN o de extremo remoto no puede hacer ping a la interfaz interna de Cisco ASA en el túnel VPN.
Por ejemplo, es posible que el cliente pn no pueda iniciar una conexión SSH o HTTP a la interfaz interna de los Cisco ASA a través del túnel VPN.
Solución
No se puede hacer ping a la interfaz interna desde el otro extremo del túnel, salvo que el comando management-access esté configurado en el modo de configuración global.
ASA-02(config)#management-access inside ASA-02(config)#show management-access management-access inside
Este comando también facilita la iniciación de SSH o la conexión HTTP a la interfaz interna de Cisco ASA a través de un túnel VPN.
Esta información es verdad para la interfaz DMZ también. Por ejemplo, si quiere hacer ping a la interfaz DMZ de /Cisco ASA o quiere iniciar un túnel desde la interfaz DMZ, se necesita el comando management-access DMZ.
ASA-02(config)#management-access DMZ
Si el cliente VPN no puede conectarse, asegúrese de que los puertos ESP y UDP estén abiertos.
Sin embargo, si esos puertos no están abiertos, intente conectarse en TCP 10000 con la selección de este puerto en la entrada de conexión del cliente VPN.
Haga clic con el botón derecho en Modify (Modificar) > pestaña Transport (Transportar) > IPSec over TCP (IPSec sobre TCP).
Incapaz de pasar el tráfico a través del túnel VPN
Problema
Usted no puede pasar el tráfico a través de un túnel VPN.
Solución
Este problema también puede ocurrir cuando se bloquean los paquetes ESP. Para resolver este problema, vuelva a configurar el túnel VPN.
Este problema puede ocurrir cuando los datos no se cifran, sino que solo se descifran a través del túnel VPN, como se muestra en este resultado:
ASA# sh crypto ipsec sa peer x.x.x.x
peer address: y.y.y.y
Crypto map tag: IPSec_map, seq num: 37, local addr: x.x.x.x
access-list test permit ip host xx.xx.xx.xx host yy.yy.yy.yy
local ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/0/0)
current_peer: y.y.y.y
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 393, #pkts decrypt: 393, #pkts verify: 393
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
Para resolver este problema, verifique estas condiciones:
-
Si las listas de acceso crypto corresponden con con el sitio remoto, y ese las listas de acceso NAT 0 están correctas.
-
Si el routing es correcto y el tráfico llega a la interfaz externa que pasa por el interior. La salida de muestra muestra que el desciframiento está hecho, pero el cifrado no ocurre.
-
Si el comando sysopt permit connection-vpn se configuró en Cisco ASA. Si este comando no está configurado, configúrelo porque permite que Cisco ASA exima el tráfico VPN o cifrado de la verificación ACL de la interfaz.
Configurar el par de respaldo para el túnel VPN en el mismo mapa criptográfico
Problema
Usted quiere utilizar a los pares del backup múltiple para un solo túnel del vpn.
Solución
La configuración de varios pares es equivalente a la provisión de una lista de reserva. Para cada túnel, el dispositivo de seguridad intenta negociar con el primer par en la lista.
Si no responde ese par, el dispositivo de seguridad funciona su manera abajo de la lista hasta que o responda un par o no hay pares en la lista.
Cisco ASA ya tiene un mapa criptográfico configurado como par principal. El par secundario podría ser agregado después el primario.
Este ejemplo de configuración muestra el peer primario como X.X.X.X y al backup peer como Y.Y.Y.Y:
ASA(config)#crypto map mymap 10 set peer X.X.X.X Y.Y.Y.Y
Inhabilitar/túnel del reinicio VPN
Problema
Para inhabilitar temporalmente el VPN hacer un túnel y reiniciar el servicio, completan el procedimiento descrito en esta sección.
Solución
Use el comando crypto map interface en el modo de configuración global para eliminar un mapa criptográfico definido previamente en una interfaz.
Use la forma no de este comando para eliminar el conjunto de mapas criptográficos de la interfaz.
hostname(config)#no crypto map map-name interface interface-name
Este comando quita un mapa crypto configurado en cualquier interfaz de dispositivo de seguridad activo y cambia el túnel VPN IPSec a inactivo en esa interfaz.
Para reiniciar el túnel IPsec en una interfaz, usted debe asignar un conjunto de la correspondencia de criptografía a una interfaz antes que la interfaz pueda proporcionar los servicios IPSec.
hostname(config)#crypto map map-name interface interface-name
Algunos túneles no cifrados
Problema
Cuando una gran cantidad de túneles se configura en el gateway de VPN, algunos túneles no pasan el tráfico. El ASA no recibe los paquetes encriptados para esos túneles.
Solución
Este problema ocurre porque el ASA no puede pasar los paquetes encriptados a través de los túneles. Las reglas de cifrado duplicados se crean en la tabla ASP.
Error:- %ASA-5-713904: Grupo = DefaultRAGroup, IP = x.x.x.x, ... versión v2 del modo de transacción no compatible.Túnel finalizado.
Problema
El %ASA-5-713904: Grupo = DefaultRAGroup, IP = 192.0.2.0,... versión v2 del modo de transacción no compatible.Aparece el mensaje de error Tunnel Terminatederror.
Solución
El motivo del mensaje de error Transaction Mode v2 (modo de transacción v2) es que Cisco ASA solo admite el modo IKE Mode Config V6 y no la versión antigua del modo V2.
Utilice la versión de la configuración de modo V6 IKE para resolver este error.
Error:- %ASA-6-722036: IP x.x.x.x del xxxx del usuario del cliente-grupo del grupo que transmite el paquete grande 1220 (umbral 1206)
Problema
El %ASA-6-722036: El IP del < xxxx > del usuario del < cliente-grupo > del grupo < x.x.x.x> que transmite el mensaje de error grande del paquete 1220 (umbral 1206) aparece en los registros del ASA.
¿Qué hace este registro significa y cómo esto pueden ser resueltos?
Solución
Estados de este mensaje del registro que un paquete grande fue enviado al cliente. La fuente del paquete no es consciente del MTU del cliente.
Esto puede también ser debido a la compresión de los datos incompresibles. La solución alternativa es desactivar la compresión SVC con el comando svc compression none, que resuelve el problema.
Mensaje de error cuando QoS se habilita en un extremo del túnel VPN
Problema
Si habilitó QoS en un extremo del túnel VPN, puede recibir este mensaje de error:
IPSEC: Received an ESP packet (SPI= 0xDB6E5A60, sequence number= 0x7F9F) from 10.18.7.11 (user= ghufhi) to 172.16.29.23 that failed anti-replay check
Solución
Este mensaje normalmente se produce cuando un extremo del túnel realiza QoS. Esto sucede cuando se detecta un paquete fuera de servicio.
Usted puede inhabilitar QoS para parar esto pero puede ser ignorada mientras el tráfico pueda atravesar el túnel.
ADVERTENCIA: entrada de mapa criptográfico incompleta
Problema
Cuando ejecuta el comando crypto map mymap 20 ipsec-isakmp, puede recibir este error:
ADVERTENCIA: entrada de mapa criptográfico incompleta
Por ejemplo:
ciscoasa(config)#crypto map mymap 20 ipsec-isakmp WARNING: crypto map entry incomplete
Solución
Esta es una alerta habitual cuando se define un nuevo mapa criptográfico; un recordatorio de que los parámetros tales como access-list (match address), transform set y peer address deben configurarse antes de que puedan funcionar.
Es también normal que la primera línea que usted teclea para definir la correspondencia de criptografía no muestra en la configuración.
Error:- %ASA-4-400024: Paquetes icmp grandes IDS:2151 en a la interfaz afuera
Problema
Incapaz de pasar el paquete ping grande a través del túnel del vpn. Cuando intentamos pasar los paquetes ping grandes conseguimos el error %ASA-4-400024: Paquetes icmp grandes IDS:2151 en a la interfaz afuera.
Solución
Deshabilite las firmas 2150 y 2151 para resolver este problema. Una vez deshabilitadas las firmas, el ping funciona bien.
Utilice estos comandos para inhabilitar las firmas:
Neutralización de la firma 2151 de la auditoría de ASA(config)#ip
Neutralización de la firma 2150 de la auditoría de ASA(config)#ip
Error:- %ASA-4-402119: : Recibió un paquete de protocolo (SPI=spi, número de secuencia= núm_seq) de IP_remota (nombre de usuario) a IP_local que no superó la comprobación de bloqueo de reproducción.
Problema
Recibí este error en los mensajes del registro del ASA:
Error:- %|ASA-4-402119: : Recibió un paquete de protocolo (SPI=spi, número de secuencia= núm_seq) de IP_remota (nombre de usuario) a IP_local que no superó la comprobación de bloqueo de reproducción.
Solución
Para resolver este error, use el comando crypto ipsec security-association replay window-size para variar el tamaño de la ventana.
hostname(config)#crypto ipsec security-association replay window-size 1024
Cisco recomienda que usted utiliza los tamaños de la ventana completos 1024 para eliminar cualquier problema de la anti-respuesta.
Mensaje de error - %ASA-4-407001: Denegar el tráfico para el nombre_de_interfaz_host local:dirección_interna, se ha superado el límite de número de licencia
Problema
Pocos hosts no pueden conectar con Internet, y este mensaje de error aparece en el syslog:
Mensaje de error - %ASA-4-407001: Denegar el tráfico para el nombre_de_interfaz_host local:dirección_interna, se ha superado el límite de número de licencia
Solución
Se recibe este mensaje de error cuando el número de usuarios excede el límite del usuario de la licencia usada. Este error se puede resolver a través de la actualización de la licencia para que incluya un mayor número de usuarios.
La licencia de usuario puede incluir 50, 100, o a los usuarios ilimitados como sea necesario.
Mensaje de error - %VPN_HW-4-PACKET_ERROR:
Problema
El mensaje de error Error Message - % VPN_HW-4-PACKET_ERROR: indica que el paquete ESP con el HMAC recibido por el router no coinciden. Este error puede deberse a uno de estos problemas:
-
Módulo defectuoso VPN H/W
-
Paquete ESP corrupto
Solución
Para resolver este mensaje de error:
-
Ignorar los mensajes de error a menos que haya interrupción del tráfico.
-
Si hay interrupción del tráfico, Reemplazar el módulo.
Mensaje de error: Comando rechazado: conexión crypto del borrar entre el VLAN y el, primero.
Problema
Este mensaje de error aparece cuando intenta agregar una VLAN permitida en el puerto trunk en un switch:Comando rechazado: conexión crypto del borrar entre el VLAN y el VLAN, primero.
El troncal PÁLIDO del borde no se puede modificar para permitir los VLAN adicionales. Es decir, no puede agregar redes VLAN en el enlace troncal IPSEC VPN SPA.
Este comando se rechaza porque da como resultado una interfaz VLAN conectada criptográfica que pertenece a la lista de VLAN permitida, que plantea una brecha de seguridad IPSec potencial.
Observar que este comportamiento se aplica a todos los puertos troncales.
Solución
En lugar del comando no switchport trunk allowed vlan (vlanlist), use el comando switchport trunk allowed vlan none o el comando "switchport trunk allowed vlan remove (vlanlist)".
Mensaje de error - % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Paquete descartado: opción de ampliación de ventana no válida para la sesión x.x.x.x:27331 a x.x.x.x:23 [Initiator(flag 0,factor 0) Responder (flag 1, factor 2)]
Problema
Este error ocurre cuando usted intenta al telnet de un dispositivo en el otro extremo de un túnel VPN o cuando usted intenta a telnet del router sí mismo:
Mensaje de error - % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Paquete descartado: opción de ampliación de ventana no válida para la sesión x.x.x.x:27331 a x.x.x.x:23 [Initiator(flag 0,factor 0) Responder (flag 1, factor 2)]
Solución
La licencia de usuario puede incluir 50, 100, o a los usuarios ilimitados como sea necesario. Se añadió la función de escala de ventana para permitir una rápida transmisión de datos en redes de gran tamaño (LFN).
Estos son típicamente conexiones con mismo el ancho de banda alto, pero también Latencia alta.
Las redes con las conexiones satelitales son un ejemplo de un LFN, puesto que los links satelitales tienen siempre altos retrasos de propagación pero tienen típicamente ancho de banda alto.
Para habilitar la función de escala de ventana para admitir LFN, el tamaño de la ventana TCP debe ser superior a 65.535. Este mensaje de error se puede resolver si aumenta el tamaño de la ventana TCP para que sea superior a 65.535.
%ASA-5-305013: Reglas asimétricas NAT correspondidas con para delantero y reverso. Poner al día por favor los flujos de este problema
Problema
Este mensaje de error aparece una vez que sube el túnel VPN:
%ASA-5-305013: Reglas asimétricas NAT correspondidas con para delantero y reverso. Poner al día por favor los flujos de este problema
Solución
Para resolver este problema cuando no esté en la misma interfaz que el host con NAT, use la dirección asignada en lugar de la dirección real para conectarse al host.
Además, habilite el comando inspect si la aplicación incrusta la dirección IP.
%ASA-5-713068: No rutinarios recibida notifican el mensaje: notify_type
Problema
Este mensaje de error aparece si el túnel VPN no puede subir:
%ASA-5-713068: No rutinarios recibida notifican el mensaje: notify_type
Solución
Este mensaje ocurre debido al misconfiguration (es decir, cuando las políticas o los ACL no se configuran para ser lo mismo en los pares).
Una vez que se corresponden con las políticas y los ACL el túnel sube sin ningún problema.
%ASA-5-720012: ((VPN-Secundario) no podido poner al día los datos del tiempo de ejecución de failover del IPSec sobre la unidad standby (o) %ASA-6-720012: ((VPN-unidad) no podido poner al día los datos del tiempo de ejecución de failover del IPSec sobre la unidad standby
Problema
Uno de estos mensajes de error aparece cuando usted intenta actualizar el dispositivo de seguridad adaptante de Cisco (ASA):
%ASA-5-720012: (VPN-Secundario) no podido poner al día los datos del tiempo de ejecución de failover del IPSec sobre la unidad standby.
%ASA-6-720012: (VPN-unidad) no podido poner al día los datos del tiempo de ejecución de failover del IPSec sobre la unidad standby.
Solución
Estos mensajes de error son errores informativos. Los mensajes no afectan las funciones del ASA o del VPN.
Estos mensajes aparecen cuando el subsistema de conmutación por falla de VPN no puede actualizar los datos de tiempo de ejecución relacionados con IPSec porque el túnel IPSec relacionado se ha eliminado en la unidad en espera.
Para resolverlos, emita el comando wr standby en la unidad activa.
Error:- %ASA-3-713063: Dirección de peer IKE no configurada para el destino 0.0.0.0
Problema
El %ASA-3-713063: Aparece el mensaje de error IKE Peer address not configured for destination 0.0.0.0.0 y el túnel no se activa.
Solución
Este mensaje aparece cuando no configuran a la dirección de peer IKE para un túnel L2L.
Este error se puede resolver si cambia el número de secuencia del mapa criptográfico, y luego elimina y vuelve a aplicar el mapa criptográfico.
Error: %ASA-3-752006: Tunnel Manager failed to dispatch a KEY_ACQUIRE message.
Problema
El %ASA-3-752006: El Administrador de Túnel no pudo enviar un mensaje KEY_ACQUIRE.Configuración incorrecta probable del mapa criptográfico o grupo de túnel."mensaje de error se registra en Cisco ASA.
Solución
Este mensaje de error puede ser causado poruna configuración errónea del mapa Crypto o del grupo de túnel. Asegúrese de que ambos estén configurados correctamente. Para más información sobre este mensaje de error, consulte Error 752006.
A continuación se detallan algunas de las acciones correctivas posibles:
-
Elimine el ACL Crypto (por ejemplo, asociado al mapa dinámico).
-
Elimine la configuración IKEv2 no utilizada, si la hay.
-
Verifique que el Crypto coincida.
-
Elimine las entradas de lista de acceso duplicadas, si las hay.
Error: %ASA-4-402116: : Received an ESP packet (SPI= 0x99554D4E, sequence number=0x9E) from XX.XX.XX.XX (user=XX.XX.XX.XX) to YY.YY.YY.YY
En una configuración de túnel VPN LAN-LAN, este error se recibe en un extremo ASA:
El paquete interno desencapsulado no coincide con la política negociada en la SA.
El paquete especifica su destino como 10.32.77.67, su fuente como 10.30.1, y su protocolo como icmp.
El SA especifica su proxy local como 10.32.77.67/255.255.255.255/ip/0 y su remote_proxy como 10.105.42.192/255.255.255.224/ip/0.
Solución
Compruebe las listas de acceso de tráfico interesante definidas en ambos extremos del túnel VPN. Ambos deben coincidir como imágenes reflejadas exactas.
No podido iniciar el instalador 64-bit VA para habilitar el adaptador virtual debido al error 0xffffffff
Problema
El mensaje de registro Failed to launch 64-bit VA installer to enable the virtual adapter due to error 0xffffffff (error al iniciar el instalador de VA de 64 bits para habilitar el adaptador virtual debido al error 0xffffffff) se recibe cuando AnyConnect no se puede conectar.
Solución
Complete estos pasos para resolver este problema:
-
Vaya a System (Sistema) > Internet Communication Management (Administración de las comunicaciones de Internet) > Internet Communication settings (Configuración de comunicaciones de Internet) y asegúrese de que Turn Off Automatic Root Certificates Update (Desactivar actualización automática de certificados raíz) esté deshabilitada.
-
Si está deshabilitada, deshabilite la parte entera de Plantilla administrativa del GPO asignado al equipo afectado y vuelva a realizar la prueba.
Consulte Desactivar la actualización automática de certificados raíz para más información.
El Cisco VPN Client no trabaja con el indicador luminoso LED amarillo de la placa muestra gravedad menor de datos en Windows 7
Problema
El Cisco VPN Client no trabaja con el indicador luminoso LED amarillo de la placa muestra gravedad menor de datos en Windows 7.
Solución
El Cisco VPN Client instalado en Windows 7 no trabaja con las conexiones 3G puesto que los indicadores luminosos LED amarillo de la placa muestra gravedad menor de datos no se soportan en los clientes VPN instalados en una máquina de Windows 7.
Alerta: "La “funcionalidad VPN puede no trabajar en absoluto”
Problema
Durante los intentos de habilitar ISAKMP en la interfaz externa de Cisco ASA, se recibe este mensaje de alerta:
ASA(config)# crypto isakmp enable outside WARNING, system is running low on memory. Performance may start to degrade. VPN functionality may not work at all.
En este momento, accesso al ASA a través del ssh. Se para el HTTPS y otros clientes SSL son también afectados.
Solución
Este problema es debido a los requisitos de memoria por diversos módulos tales como maderero y crypto.
Asegúrese de no tener el comando logging queue 0. Hace que el tamaño de la cola se establezca en 8192 y aumenta la asignación de memoria.
En plataformas como ASA5505 y ASA5510, esta asignación de memoria tiende a agotar la memoria de otros módulos.
Error de Padding de IPSec
Problema
Se recibe este mensaje de error:
%ASA-3-402130: CRYPTO: Received an ESP packet (SPI = 0xXXXXXXX, sequence number= 0xXXXX) from x.x.x.x (user= user) to y.y.y.y with incorrect IPsec padding
Solución
El problema se produce porque la VPN IPSec negocia sin un algoritmo hash. El hash de paquete garantiza la comprobación de integridad del canal ESP.
Por lo tanto, sin hash, Cisco ASA acepta los paquetes con formato incorrecto e intenta descifrarlos.
Sin embargo, debido a que estos paquetes tienen un formato incorrecto, Cisco ASA detecta errores durante el descifrado de paquetes. Esto causa los mensajes de error de padding.
Se recomienda incluir un algoritmo de troceo en el conjunto de transformación para la VPN y asegurarse de que el enlace entre los pares tenga una malformación mínima.
El Túnel VPN se Desconecta Después de 18 Horas de Actividad
Problema
El túnel VPN se desconecta después de 18 horas de actividad, aunque el tiempo de actividad esté configurado en 24 horas.
Solución
La duración es el tiempo máximo que la SA puede utilizarse para la regeneración de claves. El valor que usted ingresa en la configuración para definir el tiempo de actividad es diferente al tiempo de reinicio de señal del SA.
Por lo tanto, es necesario negociar un nuevo SA (o par de SA en el caso de la IPSec) antes de que expire el actual.
El tiempo de reinicio debe ser siempre más pequeño que el tiempo de actividad para poder realizar nuevos intentos en caso de que el primer intento de falle.
Los no especifican cómo calcular el tiempo de reinicio. Esto se deja a la discreción de los ejecutores.
Por lo tanto, el tiempo varía según la plataforma. Algunas implementaciones pueden utilizar un factor al azar para calcular el temporizador de reinicio.
Por ejemplo, si Cisco ASA inicia el túnel, es normal que vuelva a regenerar claves a los 64 800 segundos = 75 % de 86 400.
Si se inicia el enrutador, el ASA puede esperar más para dar al par más tiempo de iniciar la reintroducción.
Entonces, es normal que la sesión de VPN caduque cada 18 horas para utilizar otra clave para la negociación VPN. Esto no debe causar una desconexión o problema en la VPN.
El Flujo de Tráfico no se Mantiene Después de que el Túnel LAN-LAN se Renegocie
Problema
El flujo de tráfico no se mantiene después de que el túnel LAN-LAN se renegocie.
Solución
Cisco ASA monitorea cada conexión que pasa a través de él y mantiene una entrada en su tabla de estado de acuerdo con la función de inspección de la aplicación.
Los detalles del tráfico encriptado que pasan por la VPN se mantienen bajo la forma de base de datos de asociación de seguridad (SA). Las conexiones VPN LAN-LAN mantienen dos flujos de tráfico distintos.
Uno es el tráfico encriptado entre los gateways VPN. El otro es el flujo de tráfico entre el recurso de red detrás del gateway de VPN y el usuario final detrás del otro extremo.
Cuando la VPN se desactiva, los detalles del flujo para este SA determinado se borran.
Sin embargo, la entrada de la tabla de estado guardada por el ASA para esta conexión TCP queda desactualizada debido a la falta de actividad, que obstaculiza la descarga.
Esto significa que Cisco ASA aún conserva la conexión TCP para ese flujo particular mientras la aplicación de usuario finaliza.
Sin embargo, las conexiones TCP se pierden y, finalmente, se agota el tiempo de espera después de que caduque el temporizador de inactividad TCP
Este problema se resolvió con la introducción de una función llamada Flujos de túnel IPSec persistentes.
Se ha integrado un comando nuevo de preservación de flujos VPN en el sistema operativo (sysopt connection preserve-vpn-flows) al Cisco ASA para retener la información de la tabla de estado durante la renegociación del túnel VPN.
Por defecto, este comando está desactivado. Para habilitar esto, Cisco ASA mantiene la información de la tabla de estado TCP cuando la VPN L2L se recupera de la interrupción y restablece el túnel.
Mensaje de Error que Indica que se ha Alcanzado el Ancho de Bando de la Funcionalidad Crypto
Problema
Este mensaje de error se recibe en el enrutador Serie 2900:
Error: 20 de marzo 10:51:29: %CERM-4-TX_BW_LIMIT: Maximum Tx Bandwidth limit of Kbps reached for Crypto functionality with securityk9 technology package license.
Solución
Éste es un problema conocido que ocurre debido a las guías de consulta estrictas publicadas por el gobierno de los Estados Unidos.
De acuerdo con esto, la licencia de securityk9 solo puede permitir una encriptación de carga útil de hasta velocidades cercanas a 90 Mbps y limitar el número de sesiones TLS/túneles cifrados al dispositivo.
Para más información sobre las restricciones de exportación de criptografía, consulte Licencias de Cisco ISR G2 y HSEC.
En los dispositivos Cisco, la encripción de carga se deriva para que sea menor que 85 Mbps de carga unidireccional de salida o entrada del enrutador ISR G2, con un total de 170 Mbps de carga bidireccional.
Este requisito aplica para las platadormas Cisco ISR G2 1900, 2900 y 3900. Este comando ayuda a ver estas limitaciones:
Router#show platform cerm-information Crypto Export Restrictions Manager(CERM) Information: CERM functionality: ENABLED ---------------------------------------------------------------- Resource Maximum Limit Available ---------------------------------------------------------------- Tx Bandwidth(in kbps) 85000 85000 Rx Bandwidth(in kbps) 85000 85000 Number of tunnels 225 225 Number of TLS sessions 1000 1000 ---Output truncated----
Para evitar este problema, compre una licencia HSECK9. La licencia de función HSECK9 incorpora las funciones aumentadas de encripción de carga útil con recuentos de túnel mayores y sesiones de voz seguras.
Para más información sobre las licencias del router Cisco ISR, consulte Activación de software.
Problema: El tráfico de cifrado saliente en un túnel IPsec falla, incluso si el tráfico de descifrado entrante funciona.
Solución
Este problema se ha observado en conexiones IPSec después de reinicios múltiples, pero la causa no está clara.
La presencia de este problema se puede establecer si comprueba el resultado del comando show asp drop y verifica que el contador de contexto VPN caducado aumente para cada paquete saliente enviado.
Miscelánea
AG_INIT_EXCH el mensaje aparece en “isakmp crypto sa de la demostración” y la “salida de los comandos debug "
Si el túnel no se inicia, aparece el mensaje AG_INIT_EXCH en el resultado del comando show crypto isakmp sa y también en el resultado debug.
El motivo puede deberse a una discordancia de las políticas ISAKMP o si el puerto udp 500 se bloquea en el camino.
El mensaje del debug “recibió un mensaje IPC durante el estado inválido” aparece
Este mensaje es un mensaje de información y no tiene nada hacer con la desconexión del túnel VPN.
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
31-Mar-2014 |
Versión inicial |
Con la colaboración de ingenieros de Cisco
- Cisco TAC Engineering
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)