VPNSmith
self-host-vpnINFO

WireGuard PersistentKeepalive: mantener el túnel accesible detrás de NAT (2026)

¿Tu par de WireGuard se queda mudo tras un minuto detrás de NAT? Pon PersistentKeepalive = 25 en el cliente. Qué hace la opción, por qué 25 s y dónde colocarla.

Por Eric Gerard · Fundador · VPNSmith — Especialista en VPN self-host y VPS GDPR7 min de lecturaFoto vía Unsplash

Aviso de afiliación — Esta entrada contiene enlaces de afiliado de Contabo. Si contratas un VPS a través de ellos, ganamos una comisión sin coste extra para ti. Cada valor y comportamiento de abajo está documentado a partir de fuentes oficiales de WireGuard y escrito para ser reproducible en tu propia máquina.

Tu cliente WireGuard conecta, funciona un minuto y luego se calla: alcanzas el servidor desde el cliente, pero el servidor ya no puede devolverte nada. Un SSH desde el servidor se cuelga, un dispositivo de la LAN detrás del cliente queda inaccesible, el handshake caduca en silencio. El arreglo casi siempre es una línea en el cliente: PersistentKeepalive = 25. Esta guía explica exactamente qué hace esa opción, por qué 25 segundos es el número mágico, y en qué lado del túnel debe ir.

La respuesta corta

Si un par está detrás de NAT y debe seguir accesible, añade esto al bloque [Peer] de la configuración de ese par:

[Peer]
PublicKey = ...
Endpoint = server.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Reinicia el túnel y el problema del túnel mudo tras la inactividad desaparece. Todo lo de abajo es el porqué.

Qué hace PersistentKeepalive

Por diseño, WireGuard es silencioso: cuando no hay nada que enviar, no envía nada. Sin keepalives, sin latidos, sin ruido. Eso lo hace eficiente y difícil de identificar — pero rompe un escenario concreto.

Cuando un cliente está detrás de NAT (router doméstico, operador móvil, cortafuegos de oficina), el dispositivo NAT crea un mapeo temporal la primera vez que el cliente envía un paquete. Ese mapeo es lo que permite al servidor enviar respuestas de vuelta a la dirección interna correcta — piénsalo como un agujero perforado en el NAT. Y lo crucial: ese agujero caduca tras un periodo de inactividad, a menudo entre 30 segundos y un par de minutos para UDP. Una vez cerrado, los paquetes del servidor no tienen a dónde ir, y el par queda inaccesible hasta que el cliente vuelve a hablar.

PersistentKeepalive resuelve esto enviando un pequeño paquete keepalive vacío al par cada N segundos. Ese mínimo tráfico mantiene el mapeo NAT refrescado, así que el agujero nunca se cierra y el par sigue accesible incluso en reposo.

Cableado y equipos de red en un rack de centro de datos — el lado de IP pública de un túnel WireGuard autoalojado
Cableado y equipos de red en un rack de centro de datos — el lado de IP pública de un túnel WireGuard autoalojado

Por qué 25 segundos

La recomendación oficial de WireGuard es de 25 segundos, y el razonamiento es sencillo. Los tiempos de caducidad NAT UDP comunes se agrupan entre 30 segundos y unos minutos, y el valor más corto que se da con regularidad ronda los 30 segundos. Enviar un keepalive cada 25 segundos refresca el mapeo con un pequeño margen antes de ese suelo de 30 segundos — lo bastante frecuente para no dejar nunca que el agujero se cierre, lo bastante espaciado para no costar casi nada.

Puedes bajar más si tu NAT es inusualmente agresivo (15 es el siguiente paso razonable), o subir para ahorrar batería en el móvil, pero 25 es el valor documentado por defecto, y no es casualidad. No le des más vueltas.

Dónde ponerlo: cliente o servidor

Aquí es donde la gente se equivoca. El keepalive va en el par que debe seguir accesible a través de un NAT:

Configuración¿Keepalive en el cliente?¿Keepalive en el servidor?
Cliente itinerante detrás de NAT → servidor con IP públicaSí (= 25)No
Servidor con IP pública limpia(no aplica)No hace falta
Ambos extremos detrás de NAT (par a par)SíSí

En el caso normal — un portátil o un móvil detrás de un router hablando con un VPS de IP pública real — solo el cliente necesita PersistentKeepalive = 25, en el bloque [Peer] que describe el servidor. El servidor no lo necesita hacia sus clientes: el cliente siempre inicia, y el servidor solo responde a la dirección de origen del último paquete recibido. Un servidor con IP pública limpia es exactamente la configuración donde evitas por completo el problema NAT del lado del servidor.

Ejemplo de configuración [Peer]

Aquí tienes un bloque de par completo del lado cliente con el keepalive puesto:

[Interface]
PrivateKey = <clave-privada-cliente>
Address = 10.66.66.2/32
DNS = 10.66.66.1

[Peer]
PublicKey = <clave-publica-servidor>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Aplícalo con un reinicio del túnel:

sudo wg-quick down wg0 && sudo wg-quick up wg0

Confirma que se aplicó — wg show lista el intervalo bajo el par:

sudo wg show
# persistent keepalive: every 25 seconds

Si montas configuraciones desde cero, las plantillas de configuración de WireGuard listas para usar ya incluyen la línea keepalive en el bloque correcto para cada plataforma.

El error «interval must be in range»

PersistentKeepalive espera un número entero de segundos, validado contra el rango 0 a 65535. Si ves interval must be in range o must be in range 0 to 65535, pasaste algo que no es un entero válido en esa ventana:

  • Un sufijo de unidad — escribe 25, no 25s.
  • Un decimal — 25, no 25.0.
  • Un número negativo, o un valor por encima de 65535.
  • Un espacio extraño o un carácter invisible pegado desde una página web.

El valor 0 es legal y significa desactivado — lo mismo que dejar la línea fuera. Así que PersistentKeepalive = 0 no sirve de nada; usa un intervalo real como 25.

Keepalive puesto pero sigue sin funcionar

Si añadiste la línea y el túnel sigue quedando mudo tras la inactividad, repasa estas causas honestas en orden:

  • Puesto en el lado equivocado. El par que está detrás de NAT es el que lo necesita. Un keepalive solo en el servidor de IP pública no mantiene abierto el agujero NAT de un cliente.
  • Timeout NAT más corto que tu intervalo. Algún CGNAT cierra los mapeos UDP más rápido que 30 segundos. Baja el intervalo a 15 y vuelve a probar.
  • Un cortafuegos bloquea la ruta. Si el puerto UDP subyacente está filtrado, ningún keepalive pasará — confirma que el puerto de WireGuard esté realmente abierto en ambos extremos.
  • El endpoint cambió (roaming). Si el cliente cambió de red y su dirección pública cambió, el servidor puede seguir apuntando al Endpoint antiguo. El keepalive ayuda al servidor a seguir la nueva fuente, pero un Endpoint obsoleto del lado cliente aún puede fallar.

Keepalive vs el handshake de WireGuard

Son dos temporizadores distintos, y conviene separarlos. WireGuard renueva su handshake criptográfico aproximadamente cada dos minutos — pero solo cuando hay tráfico real que proteger. En un enlace inactivo sin keepalive, sin tráfico no hay renovación del handshake, y mientras tanto el agujero NAT se cierra sin ruido.

PersistentKeepalive cubre exactamente ese hueco: mantiene un hilillo de tráfico en un enlace por lo demás inactivo, manteniendo el mapeo NAT abierto entre handshakes para que el túnel esté listo en cuanto un dato real tenga que moverse. El keepalive no sustituye al handshake; mantiene la ruta viva para que el handshake pueda ocurrir cuando haga falta.

Un servidor con IP pública elimina la mitad del problema

La mayoría de los dolores de keepalive vienen del NAT del lado servidor — una caja VPN detrás de un router doméstico, doble NAT, un cortafuegos del proveedor. Pon el servidor en una IPv4 pública limpia y el único NAT que queda es el del cliente, donde un solo PersistentKeepalive = 25 es todo lo que necesitas. Un Contabo Cloud VPS 10 a 5,50 €/mes te da root completo y una IP pública real sin cortafuegos del proveedor contra el que pelear — las condiciones exactas donde el keepalive del lado cliente es lo único que tienes que ajustar. Para entender la mecánica NAT que esta opción rodea, mira la explicación sencilla de qué es el NAT.

Para profundizar

Fuentes y referencias:

Publicado el 2026-06-29. La recomendación de 25 segundos y el comportamiento de PersistentKeepalive provienen de la documentación oficial de WireGuard; los rangos de timeout NAT varían según el dispositivo, así que confirma con tu propio router u operador si necesitas un intervalo más corto.

Recordatorio: ejecutar WireGuard y autoalojar una VPN es legal en la UE, EE. UU., Canadá y la mayoría de los países democráticos. VPNSmith publica este contenido con fines educativos.

★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados

Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región→

Preguntas frecuentes

¿Qué hace PersistentKeepalive en WireGuard?
PersistentKeepalive es una opción de la sección [Peer] de una configuración de WireGuard que hace que la interfaz envíe un pequeño paquete keepalive vacío a ese par cada N segundos, incluso sin tráfico real. Por defecto WireGuard es silencioso: no envía nada en un enlace inactivo. Ese silencio es un problema cuando un cliente está detrás de NAT, porque el mapeo NAT — el agujero que permite al servidor responder al cliente — caduca tras un breve periodo de inactividad. El keepalive periódico mantiene ese mapeo abierto, así que el par sigue accesible. Se activa con una línea: PersistentKeepalive = 25.
¿Por qué el valor recomendado de PersistentKeepalive es 25 segundos?
La recomendación oficial de WireGuard es de 25 segundos. Los mapeos NAT UDP de los routers domésticos y el CGNAT suelen caducar entre 30 segundos y un par de minutos, y el tiempo más corto que se encuentra habitualmente ronda los 30 segundos. Enviar un keepalive cada 25 segundos refresca el mapeo con un pequeño margen antes de ese suelo de 30 segundos. Valores más bajos también funcionan pero gastan algo de ancho de banda y batería; 25 es el punto de equilibrio documentado. Si tu NAT es más agresivo, bajar a 15 puede ayudar.
¿PersistentKeepalive va en el cliente o en el servidor?
Ponlo en el par que necesita seguir accesible a través de un NAT — casi siempre el cliente itinerante (tu portátil, móvil o router detrás de otro router). El cliente añade PersistentKeepalive = 25 en el bloque [Peer] que describe el servidor. Un servidor con IP pública real no necesita keepalive hacia sus clientes, porque el cliente siempre inicia y el servidor simplemente responde a la dirección de donde vino el último paquete. Si ambos extremos están detrás de NAT, ponlo en los dos.
¿Por qué me sale «interval must be in range 0 to 65535»?
PersistentKeepalive toma un número entero de segundos, y WireGuard lo valida contra el rango 0 a 65535. El error «interval must be in range» o «must be in range 0 to 65535» significa que pasaste algo fuera de ese rango — un número negativo, un decimal, un sufijo de unidad como «25s», o un carácter extraño. Usa un entero pelado: PersistentKeepalive = 25. El valor 0 (o dejar la línea fuera) desactiva la función por completo.
¿PersistentKeepalive agota la batería o los datos?
En ancho de banda es insignificante: un keepalive es un pequeño paquete vacío de unos 32 bytes enviado cada 25 segundos, unos pocos kilobytes por hora. El coste real está en el móvil, donde cada keepalive despierta la radio de su modo de bajo consumo, y los despertares frecuentes pueden acortar la batería. Por eso algunos suben el intervalo en el teléfono para ahorrar energía, aceptando que el túnel quede brevemente inaccesible en reposo. En un equipo o servidor siempre encendido el coste es prácticamente cero.
Artículos relacionados

Para profundizar