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

1. Entra en tu suscripción con VPN y abre Troubleshooting / Logs.
2. Pulsa Generar logs.
3. 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.

{/* 📸 CAPTURA 1 · consola Troubleshooting / Logs con el botón Generar logs y el buscador */}

Consola de troubleshooting con la generación y búsqueda de logs

📘 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

1. Genera logs y busca error, failed, proposal, AUTH, TS_.
2. ¿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.
3. ¿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.
4. peer not responding → revisa UDP 500/4500 y firewall/NAT.
5. no proposal chosen → hay ajustes que no coinciden (cifrados, grupos, tiempos).
6. AUTHENTICATION_FAILED → revisa la clave (PSK) o certificados e IDs.
7. 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.