Un túnel que se niega a formarse, o que se establece y aun así no deja pasar tráfico, es uno de los problemas más comunes en IPSec sitio a sitio. Este es el orden de diagnóstico que encuentra la falla más rápido — qué revisar en cada etapa, los comandos display que hay que ejecutar, y las causas que explican la mayoría de estos casos.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Siempre vuelvo a la misma secuencia breve de comprobaciones — no porque IPSec sea simple, sino porque las formas en que falla se repiten.
Un túnel IPSec que no se establece, o que se establece y aun así no deja pasar tráfico, es uno de los problemas más comunes en la conectividad sitio a sitio. El instinto es cambiar la configuración en ambos extremos a la vez — pero es mucho más rápido recorrer las etapas de negociación en orden: si la negociación IKE siquiera se dispara, si la fase 1 (la IKE SA) se completa, si la fase 2 (la IPSec SA) se completa, y solo entonces si el tráfico protegido realmente está fluyendo.
A continuación, el árbol de fallas en el que se basa este texto, las comprobaciones de cada etapa con los comandos exactos, las causas que aparecen una y otra vez una vez superadas las primeras comprobaciones, y algunas respuestas de preguntas frecuentes extraídas de casos reales de campo.
Las fallas de IPSec se dividen en exactamente dos formas: el túnel nunca se establece, o se establece y algo sigue sin funcionar.
Ubicar primero el síntoma en este árbol ahorra mucho retroceso más adelante — indica cuál de las secciones siguientes aplica realmente a lo que está viendo.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
El fallo de negociación de la IKE SA o la IPSec SA es el núcleo de la mayoría de las fallas de IPSec, y vale la pena analizarlo directamente junto al proceso de negociación. Casi todo lo demás en este árbol — una interfaz, una ruta, una ACL, una regla NAT — es un simple error de configuración de otra función, que hay que rastrear en su propio contexto, no en el proceso de IPSec en sí.
Cuatro etapas, cuatro conjuntos distintos de cosas a revisar — y el comando que indica en qué etapa está realmente atascado.
Si display ike sa no muestra nada en absoluto, no asuma que la fase 1 falló — primero verifique si la negociación siquiera se disparó.
<Huawei> display ipsec policy
===========================================
IPSec policy group: "10"
Using interface: GigabitEthernet1/0/0
===========================================
Sequence number: 10
Security data flow: 3100/IPv4
SA trigger mode: Traffic-based // default trigger mode
<Huawei> display ipsec statistics
negotiate about packet statistics:
IKE ctrl packet inbound ok: 0, outbound ok: 0
trigger ok: 0, switch sa: 0, sync sa: 0
// outbound ok = 0 -> no IKE packet has left this router yet
<Huawei> display ipsec interface brief
------------------------------------------------
IPSec policy : policy1
Using interface : GigabitEthernet1/0/0
------------------------------------------------
<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 times matched)Tres combinaciones distintas de contadores en display ipsec statistics apuntan a tres lugares diferentes a revisar — vale la pena comprobarlo antes que nada.
<Router1> display ipsec statistics
negotiate about packet statistics:
IKE ctrl packet inbound ok: 0, outbound ok: 4
// outbound ok not 0 but the peer's inbound stays 0 -> peer never received it
<Router> display ike peer name 1
------------------------------------------
Remote IP : 1.1.1.1(www.huawei.com)
IKE version : v1
Exchange mode : main on phase 1
Local ID type : IP
Remote ID type : any
NAT-traversal : Enable
<Router> display ike proposal number 10
-------------------------------------------
Authentication Method : PRE_SHARED
Authentication Algorithm : SHA2-256
Encryption Algorithm : AES-256
Diffie-Hellman Group : MODP-2048
Prf Algorithm : HMAC-SHA2-256
-------------------------------------------La fase 1 tiene éxito, display ike sa muestra una SA establecida, pero aún no hay IPSec SA — esto casi siempre es la ACL o la propuesta.
<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
// the peer's rule should mirror this: source 10.1.1.0/24 destination 10.1.2.0/24
<Huawei> display ipsec proposal
IPSec proposal name: p1
Encapsulation mode: Tunnel
Transform : ah-esp-new
ESP protocol : Authentication SHA2-HMAC-256
Encryption AES-256
<Huawei> display ipsec policy brief
Policy name Mode ACL Peer name
policy1-100 isakmp 3002/IPv4 peer1
// Perfect forward secrecy: DH group 14 -- must match on both ends if configureddisplay ipsec sa muestra una SA establecida en ambos extremos — eso confirma que el túnel existe, no que el tráfico lo esté usando.
<Huawei> display ipsec sa
-----------------------------
Flow source : 10.1.0.0/255.255.0.0 0/0
Flow destination : 10.2.0.0/255.255.0.0 0/0
// compare this against the real business subnets, not just "tunnel is up"
<Huawei> display ike peer
NAT-traversal : Enable
<Huawei> display ipsec proposal
Transform : esp-new // must be ESP, not AH, when NAT-T is in play
<Huawei> display ipsec statistics
dropped security packet detail:
authentication: 33, replay: 0
// non-zero authentication drops with SHA-2 in the proposal -> compat mode needed
[Huawei] ipsec authentication sha2 compatible enableUna vez que las cuatro etapas anteriores le han indicado dónde está el problema, estas seis causas explican la mayor parte de lo que realmente falla.
SÍNTOMALa IKE SA nunca se forma — display ike sa permanece vacío o muestra la conexión atascada negociando, y este es el único parámetro de fase 1 que aún parece sin confirmar.
CAUSACon la autenticación por clave precompartida, las claves de ambos extremos deben ser idénticas, carácter por carácter. Como la clave configurada se almacena y se muestra en forma cifrada, un error tipográfico en cualquiera de los extremos no se detecta releyendo la configuración en ejecución — ambos extremos pueden parecer «configurados» y aun así no coincidir.
SOLUCIÓNVuelva a ingresar deliberadamente la misma clave en texto plano en ambos extremos, en lugar de confiar en que un valor copiado anteriormente sigue siendo correcto en ambos lados.
[Router] ike peer huawei
[Router-ike-peer-huawei] pre-shared-key cipher <same-key-on-both-ends>SÍNTOMAdisplay ike error-info informa phase1 proposal mismatch.
CAUSAEn un caso real con exactamente este código de error, la propuesta IKE de un router usaba AES-128 mientras que el peer (un equipo de otro fabricante) usaba AES-256 — un solo parámetro diferente basta para que falle toda la negociación de fase 1.
SOLUCIÓNCompare display ike proposal lado a lado; cuando el peer es de otro fabricante y no puede obtener su configuración directamente, debugging ikev1 all (o debugging ikev2 all) en su propio router muestra los atributos de la propuesta que el otro lado realmente envió.
<AR1> display ike error-info
peer port error-reason version error-time
2.1.1.1 500 phase1 proposal mismatch v1 2017-09-05 15:22:32
// debugging ikev1 all on AR1 showed what the peer actually sent:
Attribute ENCRYPTION_ALGORITHM value AES_CBC
Attribute KEY_LENGTH value 256
Attribute HASH_ALGORITHM value SHA2-256
Attribute AUTHENTICATION_METHOD value PRE_SHARED
Attribute GROUP_DESCRIPTION value MODP_2048
// AR1 was configured for AES-128; the peer proposed AES-256 -- align the two
[AR1] ike proposal 10
[AR1-ike-proposal-10] encryption-algorithm aes-256SÍNTOMALa IPSec SA no se negocia en absoluto, o — en un hub con varias sucursales — solo el tráfico de una sucursal no pasa mientras las demás funcionan bien.
CAUSALas ACL de ambos extremos deberían ser imágenes espejo entre sí (origen y destino invertidos); cuando no lo son, la negociación solo tiene éxito si el rango del iniciador es un subconjunto del respondedor. Además, cuando un hub tiene varios túneles de sucursal, rangos de direcciones superpuestos entre distintas ACL del mismo grupo de políticas hacen que el tráfico de una sucursal sea reclamado silenciosamente por el túnel de otra sucursal.
SOLUCIÓNHaga que el origen/destino de la ACL sea un espejo en ambos extremos, y asegúrese de que ninguna de las ACL referenciadas por el mismo grupo de políticas IPSec tenga rangos de reglas superpuestos.
SÍNTOMAEl túnel aparece como establecido en ambos extremos, pero el contador de encapsulación saliente nunca se mueve — no se está enviando realmente ningún paquete cifrado.
CAUSAEn un router que también hace NAT, el NAT se aplica antes que IPSec en el orden de reenvío. Si la ACL del NAT sigue coincidiendo con el tráfico destinado al túnel, ese tráfico se traduce y se enruta hacia internet en lugar de hacia el túnel — sin error, sin registro, nada que observar salvo un contador de paquetes estancado. Además, cuando hay un dispositivo NAT entre los dos peers, ambos extremos necesitan la traversía NAT habilitada explícitamente, y el protocolo de seguridad debe ser ESP — AH no sobrevive a la traducción de direcciones.
SOLUCIÓNAgregue una regla deny para las direcciones protegidas del túnel al principio de la ACL de NAT para que ese tráfico nunca se traduzca; habilite nat traversal en ambos peers IKE cuando haya un dispositivo NAT en la ruta; y use ESP, no AH, siempre que esté implicado el NAT-T.
acl number 3300
rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
rule 10 permit ip
[Router-ike-peer-huawei] nat traversalSÍNTOMAEl túnel no está caído por ninguna razón evidente, pero fluctúa — se cae y se reconstruye — aunque el enlace y ambos routers estén bien.
CAUSALa detección de peer muerto (DPD) debe coincidir en la secuencia de carga útil de sus propios paquetes de keepalive. Cuando el orden de los mensajes DPD de ambos extremos no coincide, el DPD falla silenciosamente en confirmar que el peer está vivo, y el túnel se derriba y reconstruye por una falsa alarma.
SOLUCIÓNConfigure parámetros DPD idénticos en ambos extremos — secuencia de mensaje, modo de detección, tiempo de inactividad, intervalo de retransmisión, límite de reintentos.
[Router-ike-peer-huawei] dpd msg seq-hash-notify
[Router-ike-peer-huawei] dpd type periodic
[Router-ike-peer-huawei] dpd idle-time 20
[Router-ike-peer-huawei] dpd retransmit-interval 10
[Router-ike-peer-huawei] dpd retry-limit 4SÍNTOMALos registros muestran eventos repetidos de phase1 hard expiry o phase2 hard expiry, y el túnel parece renegociar con más frecuencia — o de forma menos simétrica — de lo esperado.
CAUSATanto la IKE SA como la IPSec SA llevan una duración configurada (sa duration, o el ipsec sa global-duration global). Si los dos extremos no están configurados con el mismo valor, un lado envejece su SA y comienza a renegociar mientras el otro todavía mantiene la antigua, lo que se manifiesta como una agitación innecesaria en lugar de una renovación limpia y simultánea.
SOLUCIÓNCompare el campo SA Duration de display ike proposal y la duración equivalente de la IPSec SA en ambos extremos, e iguálelas con sa duration o ipsec sa global-duration.
<sysname> display ike proposal number 10
SA Duration(Seconds) : 86400
<sysname> display ipsec global config
IPSec sa global-duration time-based(seconds) : 3600Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
AH (Authentication Header) proporciona autenticación de origen de datos, verificación de integridad y anti-repetición, pero no cifra en absoluto la carga útil — es para tráfico donde la confidencialidad no importa pero la manipulación sí. ESP (Encapsulating Security Payload) hace todo lo que hace AH, además de poder cifrar la carga útil, y puede configurarse solo para cifrado, solo para autenticación, o ambos. Los dos pueden combinarse en el mismo túnel; cuando se combinan, ESP se aplica primero, luego AH, para mayor seguridad.
Primero haga Ping para confirmar la alcanzabilidad de la red pública. Si el túnel se negocia por IKE, revise display ike sa — si la fase 1 ni siquiera se estableció, ahí está su respuesta. Si la fase 1 se ve bien, espere unos diez segundos y vuelva a revisar; la instalación de la SA no siempre es instantánea. Luego confirme que la interfaz que lleva la política IPSec esté realmente Up, y solo entonces empiece a revisar la configuración de IPSec en sí.
Sí. El extremo de IP fija configura una política IPSec basada en plantilla de política que no requiere conocer la dirección del peer de antemano, y su entrada de peer IKE simplemente omite remote-address. El extremo de IP dinámica se configura normalmente, apuntando remote-address al peer fijo. El extremo con la dirección impredecible debe ser el que inicia.
Esto generalmente significa que una nueva sucursal está intentando proteger tráfico que se superpone con un flujo de datos que un túnel existente en el hub ya está protegiendo. El conflicto bloquea la nueva negociación por completo, y solo se resuelve una vez que se derriba el túnel antiguo — lo que un reinicio fuerza. ipsec remote traffic-identical accept permite que un nuevo peer con una definición de flujo protegido idéntica tome el control rápidamente, dejando que la SA antigua envejezca en lugar de ser bloqueada por ella.
Cuatro sospechosos habituales: carga de CPU de otras funciones (defensa contra ataques, otras SA) ejecutándose junto a IPSec; una discrepancia en el orden de carga útil del DPD que hace fluctuar el túnel por falsas alarmas de peer caído; pérdida ordinaria en la ruta de internet aguas arriba del túnel; y fragmentación IP — la propia sobrecarga de encapsulación de IPSec empuja los paquetes por encima del MTU de la ruta, y tanto fragmentar como reensamblar tráfico cifrado cuesta CPU que un router ocupado no siempre tiene de sobra. Probar con distintos tamaños de ping para encontrar el punto de quiebre, y luego ajustar el MTU de la interfaz y tcp adjust-mss, es la solución estándar para este último caso.
Esta nota se basa en el modelo de clasificación de fallas de IPSec del router Huawei serie AR y sus comandos display ike sa / ipsec sa / ipsec statistics, además de los casos de campo que los respaldan. Si su gateway es de otro fabricante, los comandos exactos cambian, pero la lógica de negociación subyacente — activación, fase 1, fase 2, coincidencia de ACL, interacción con NAT, DPD, duración de la SA — se traslada directamente. No cubre en profundidad casos específicos de IKEv2 como la autenticación EAP o por sobre digital, ni escenarios de overlay SD-WAN.
Cuéntenos en qué etapa está atascado — fase 1, fase 2, o activo pero sin tráfico — junto con la salida de display ike sa / display ipsec sa, y le ayudamos a interpretarla.