El túnel a la sucursal está caído. En la interfaz web, un punto rojo y cero pistas. Reinicias el túnel, sigue rojo. Revisas la config tres veces, se ve idéntica a la del otro lado. ¿Ahora qué?
El error más común aquí es tratar el túnel como una sola cosa. No lo es: un IPsec levanta en dos fases, y casi cualquier falla vive claramente en una de ellas. Separarlas es el 80% del diagnóstico.
- Fase 1 (IKE): los dos extremos se reconocen y se autentican. Aquí caen los problemas de llave precompartida, de propuesta de cifrado y de identidad del par.
- Fase 2 (IPsec): ya autenticados, negocian qué tráfico va a viajar cifrado y cómo. Aquí caen los problemas de selectors (las subredes que cada lado espera) y de propuesta de fase 2.
Si la fase 1 no cierra, ni siquiera llegas a discutir subredes. Si la fase 1 cierra pero la 2 no, el problema es qué quieres cifrar, no con quién. Saber en cuál moriste te dice dónde buscar.
Ver el estado sin encender nada
Antes del debug, una foto rápida de en qué punto quedó cada túnel:
diagnose vpn ike gateway list
diagnose vpn tunnel list
Ahí ves si la fase 1 (gateway) está established y si hay SAs de fase 2 instaladas. Si el gateway ni aparece o dice que la negociación falló, tu problema es fase 1. Si el gateway está bien pero no hay SAs de fase 2, ya sabes hacia dónde ir.
El debug de IKE: la película de la negociación
Para ver la negociación en vivo, enciendes el debug de IKE —filtrando por el par para no ahogarte, igual que con el debug flow:
diagnose vpn ike log filter name BRANCH-VPN
diagnose debug application ike -1
diagnose debug enable
# ...reproduces el intento de levantar el túnel...
diagnose debug disable
diagnose debug reset
La salida es larga, pero buscas una línea de veredicto. Estas tres son las que resuelven la mayoría de los casos:
ike 0:BRANCH-VPN: no SA proposal chosen
-> FASE 1: no hay cifrado/hash/DH en común. Revisa la propuesta de fase 1.
ike 0:BRANCH-VPN: PSK auth failed / probable pre-shared key mismatch
-> FASE 1: la llave precompartida no coincide entre los dos lados.
ike 0:BRANCH-VPN:BRANCH-P2: no matching IPsec selector, drop
-> FASE 2: las subredes (selectors) que espera cada lado no cuadran.
Los cuatro culpables de siempre
- Llave precompartida (fase 1): un espacio de más, un copiar-pegar con un carácter invisible. El clásico.
- Propuesta de fase 1 (fase 1): un lado ofrece AES256/SHA256/DH14 y el otro AES128/SHA1/DH5. Sin intersección,
no proposal chosen. - Selectors de fase 2 (fase 2): un lado espera cifrar
10.0.0.0/24 ↔ 10.1.0.0/24y el otro tiene las subredes al revés o distintas. El túnel "levanta" en fase 1 y muere en fase 2. - NAT en medio (fase 1): si hay un router haciendo NAT entre los dos firewalls y NAT-T no está bien, la fase 1 no completa. Un caso que no ves en la config, sino en la red.
Este tipo de conexión sitio-a-sitio es la base de enlazar sucursales; si lo tuyo es más bien dar acceso a usuarios remotos, el modelo cambia y lo desarrollamos en VPN de acceso remoto vs ZTNA. Y si la sucursal no tiene IP pública fija, el arreglo está en la VPN dial-up.
Sea cual sea el escenario, el reflejo es el mismo: cuando un túnel no levanta, no lo trates como una caja negra en rojo. Pregúntate primero en qué fase murió —fase 1 o fase 2— y deja que el debug de IKE te lo diga.
Preguntas frecuentes
help ¿Cómo sé si mi túnel IPsec falla en la fase 1 o en la fase 2?
Con diagnose vpn ike gateway list ves la fase 1: si el gateway no queda established, el problema es fase 1 (autenticación o propuesta). Si el gateway está bien pero diagnose vpn tunnel list no muestra SAs de fase 2, el problema es fase 2 (selectors o propuesta de fase 2). El debug de IKE confirma en cuál moriste.
help ¿Qué significa "no SA proposal chosen" en el debug de IKE?
Significa que los dos extremos no tienen ningún conjunto de cifrado, hash y grupo Diffie-Hellman en común para la fase que negocian. Es un desajuste de propuesta: revisa que ambos lados ofrezcan al menos una combinación idéntica de algoritmo de cifrado, autenticación y grupo DH.
help El túnel levanta pero no pasa tráfico, ¿por qué?
Suele ser un problema de fase 2: las fases negociaron y el túnel figura arriba, pero los selectors —las subredes que cada lado declara para el tráfico cifrado— no coinciden, así que ningún paquete califica para entrar al túnel. Verifica que las subredes local y remota estén configuradas de forma espejo en ambos extremos.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →