Cómo Gestionar los logs de tu VPN y Diagnosticar Incidencias

La consola de troubleshooting te deja generar, consultar y descargar los logs del túnel VPN desde el panel, y diagnosticar la mayoría de incidencias por tu cuenta.

La clave está en leer el log para saber en qué fase falla la conexión.

👍
Qué consigues
Localizar el punto exacto del fallo (la conexión inicial o el paso de datos) y la acción que lo corrige, sin depender de soporte en la mayoría de los casos.

Antes de empezar

Tener acceso al panel con permisos sobre la suscripción de red.
Tener un túnel VPN creado, esté o no operativo.
De forma opcional, acceso a los logs del equipo remoto para correlacionar si necesitas ir más allá.

Paso 1. Genera y consulta los logs

Entra en tu suscripción con VPN y abre Troubleshooting / Logs.
Pulsa Generar logs.
En la consola puedes ver los eventos del intercambio, buscar términos, copiar fragmentos y descargar el fichero .log para revisarlo en local.

Términos de búsqueda recomendados: error, failed, proposal, AUTH, TS_, CHILD_SA, responding.

📘
Dos detalles para no confundirte

Zona horaria: los logs muestran la hora convertida a tu zona horaria, para que el timestamp cuadre con el momento real de la prueba y puedas compararlo con el log del equipo remoto.

Rotación por tamaño: el histórico se gestiona por tamaño, no por días. Si persigues un fallo concreto, reprodúcelo y genera los logs justo después.

Las dos fases de la conexión

Un túnel site-to-site se levanta en dos fases. Saber en cuál falla te lleva directo a la causa.

Fase 1 — Conexión inicial (IKE)

Los dos extremos se validan y acuerdan cómo van a hablarse. Cuando va bien, en el log aparece IKE_SA ... established. Si falla, lo típico es que el otro extremo no responde (conectividad o puertos cerrados), que no coinciden ajustes básicos (por ejemplo el cifrado) o que la clave (PSK) o la identidad no encajan.

Fase 2 — Paso de datos (IPsec / CHILD_SA)

Con la conexión inicial lista, se crea el túnel por donde va el tráfico real. Cuando va bien, aparece CHILD_SA ... established. Si falla, lo típico es que las subredes no coinciden en ambos lados, que un firewall o una política bloquea el tráfico, o que faltan rutas hacia la red remota.

📘
Regla rápida
Si ves IKE_SA ... established pero no CHILD_SA ... established, el problema está en redes, rutas o firewall (Fase 2). Si no llegas a IKE_SA ... established, está en la conexión inicial (Fase 1).

Interpreta los mensajes del log

Checklist de diagnóstico

Genera logs y busca error, failed, proposal, AUTH, TS_.
¿Aparece IKE_SA ... established? Si no, estás en un problema de Fase 1 (puedes ver initiating IKE_SA sin pasar de ahí). Si sí, sigue.
¿Aparece CHILD_SA ... established? Si ves failed to establish CHILD_SA, suele ser redes, rutas o firewall (Fase 2). Si sí aparece, el túnel está bien; si aun así no hay tráfico, mira rutas y políticas, no el túnel.
peer not responding → revisa UDP 500/4500 y firewall/NAT.
no proposal chosen → hay ajustes que no coinciden (cifrados, grupos, tiempos).
AUTHENTICATION_FAILED → revisa la clave (PSK) o certificados e IDs.
TS_UNACCEPTABLE → revisa que las subredes coinciden exactamente en ambos lados.

Comprueba desde el lado cliente

Los logs te dicen la fase; estos comandos te confirman la causa desde un servidor de tu red.

Para Fase 1, comprueba la conectividad con el peer y que los puertos IPsec están abiertos. En Linux:

ping <IP-PEER>
nc -vzu <IP-PEER> 500
nc -vzu <IP-PEER> 4500

En Windows, conectividad básica desde PowerShell (los puertos UDP 500/4500 deben estar abiertos en firewall y NAT de ambos lados):

Test-NetConnection <IP-PEER>

Para Fase 2, comprueba que llegas a la subred remota y que existe ruta hacia ella:

ping <IP-EN-LA-SUBRED-REMOTA>
ip route

route print

Cuándo escalar a Partner Success

Si tras estos pasos sigues atascado, el equipo de Partner Success te echa una mano. Para resolverlo cuanto antes, envía:

Del log: el primer error que aparece, 20-30 líneas antes y después para ver el contexto, y los timestamps tal cual salen.
Del túnel: versión de IKE (v1/v2/Auto), IP o FQDN del peer, subredes local y remota en CIDR, si hay NAT o firewall entre medias, y la hora exacta de la prueba.

Como los logs rotan por tamaño, reproduce el fallo y genera los logs justo después: así el fichero contiene exactamente lo que hay que mirar.

Conclusión

Con la consola de troubleshooting pasas de "la VPN no va" a "falla en la Fase 2 por subredes que no coinciden" en cuestión de minutos. El método es siempre el mismo: localiza si llegas a IKE_SA established y a CHILD_SA established, y eso te dice si miras la conexión inicial o el paso de datos. A partir de ahí, la tabla y los comandos te llevan a la causa.