> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/productos/servers-2/how-to/vpn-logs-and-troubleshooting.md).
# 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 \*/}
> #### 📘 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:
```bash
ping
nc -vzu 500
nc -vzu 4500
```
En Windows, conectividad básica desde PowerShell (los puertos UDP 500/4500 deben estar abiertos en firewall y NAT de ambos lados):
```powershell
Test-NetConnection
```
Para Fase 2, comprueba que llegas a la subred remota y que existe ruta hacia ella:
```bash
ping
ip route
```
```powershell
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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.plenit.com/productos/servers-2/how-to/vpn-logs-and-troubleshooting.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
