MTU de WireGuard: el valor correcto y cómo arreglar el túnel bloqueado (2026)

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 comando y valor de abajo está documentado a partir de fuentes oficiales de WireGuard y escrito para ser reproducible en tu propia máquina.

Tu túnel WireGuard dice que está conectado. wg show muestra un handshake reciente, el ping al servidor responde al instante — y sin embargo las páginas web giran sin fin, SSH se congela a mitad de transferencia, y las descargas grandes mueren a los pocos kilobytes. Nueve de cada diez veces el culpable es el MTU: el tamaño máximo de paquete que tu túnel puede transportar. Esta guía explica por qué el MTU rompe un túnel que por lo demás parece perfectamente sano, cómo medir el valor correcto para tu enlace, y exactamente qué ajustar.

Si tu handshake nunca se completa de entrada, el MTU aún no es tu problema — empieza por la lista completa de arreglos del handshake de WireGuard y vuelve aquí cuando el túnel esté levantado pero se atasque.

Qué es el MTU y por qué le importa a WireGuard

El MTU (Maximum Transmission Unit) es el paquete más grande, en bytes, que una interfaz enviará sin fragmentarlo. En un enlace Ethernet o de fibra normal son 1500 bytes. WireGuard envuelve cada uno de tus paquetes dentro de su propio paquete UDP, y esa envoltura cuesta espacio:

• Cabecera externa IPv4: 20 bytes
• Cabecera externa IPv6: 40 bytes
• Cabecera UDP: 8 bytes
• Cabecera de datos de WireGuard: 32 bytes

Así que un paquete de WireGuard sobre IPv6 necesita unos 80 bytes de sobrecarga. Réstalos de una ruta de 1500 bytes y te quedan unos 1420 bytes dentro del túnel — que es exactamente por qué WireGuard pone su interfaz a 1420 por defecto. Confirma el valor por defecto en cualquier túnel activo:

ip link show wg0
# ... mtu 1420 ...

El problema empieza cuando la ruta entre tú y tu servidor transporta menos de 1500 bytes. Entonces 1420 es demasiado grande, tu tráfico real se desborda, y los paquetes sobrantes desaparecen en silencio.

Por qué el túnel responde al ping pero las páginas se cuelgan

Es el síntoma característico, y confunde a todos la primera vez:

• Un ping es minúsculo — cabe en cualquier MTU, así que funciona y te convence de que el túnel va bien.
• Una consulta DNS y el handshake TCP de tres vías también son minúsculos, así que las conexiones empiezan.
• El primer paquete de tamaño completo — una página web, una imagen, un trozo de archivo — supera el MTU de la ruta y se descarta.

Normalmente un router devolvería un mensaje ICMP «fragmentación necesaria» diciendo al emisor que use paquetes más pequeños (esto es el descubrimiento del MTU de ruta, PMTUD). Pero el ICMP está filtrado en una enorme parte de internet, así que ese mensaje nunca llega. El emisor sigue lanzando paquetes sobredimensionados a un agujero negro. Eso es un agujero negro de PMTU, y por eso un túnel puede parecer vivo y aun así ser inútil para el trabajo real.

La misma lógica explica los informes de «conectado pero sin internet»: el pequeño tráfico de control pasa, los datos grandes no. Si has descartado el reenvío IP y la regla de masquerade (cubiertos en la guía de instalación Contabo + WireGuard), el MTU es el siguiente sospechoso.

Mide el MTU correcto para tu enlace

No copies un número de un foro. Mide tu propia ruta con un ping sin fragmentación a la IP pública real del servidor (no su IP de túnel), reduciendo la carga útil hasta que los paquetes pasen:

# -M do = no fragmentar, -s = tamaño de carga útil
ping -M do -s 1472 IP_PUBLICA_SERVIDOR

La carga útil -s 1472 más 28 bytes de cabecera ICMP+IP es igual a 1500. Si falla con «message too long» o sin respuesta, baja y reintenta:

ping -M do -s 1464 IP_PUBLICA_SERVIDOR
ping -M do -s 1400 IP_PUBLICA_SERVIDOR
ping -M do -s 1372 IP_PUBLICA_SERVIDOR

En Windows el equivalente es ping -f -l 1472 IP_PUBLICA_SERVIDOR; en macOS, ping -D -s 1472 IP_PUBLICA_SERVIDOR.

Toma la mayor carga útil que pase, y haz la cuenta:

1. Mayor carga útil que pasa + 28 = tu MTU de ruta.
2. MTU de ruta − 80 = un MTU de WireGuard seguro (usa 80 para el caso IPv6; las rutas solo IPv4 pueden usar −60, pero −80 es la opción universal segura).

Ejemplo resuelto. Supón que -s 1400 es el mayor que responde y -s 1408 falla. MTU de ruta = 1400 + 28 = 1428. MTU de WireGuard = 1428 − 80 = 1348 → redondea a un 1340 limpio.

Ajusta el MTU de WireGuard

Añade una línea al bloque [Interface] del lado limitado (normalmente el cliente) y reinicia el túnel:

[Interface]
PrivateKey = ...
Address = 10.66.66.2/32
MTU = 1340

sudo wg-quick down wg0 && sudo wg-quick up wg0
# o, sin un reinicio completo:
sudo ip link set dev wg0 mtu 1340

Vuelve a probar de inmediato: carga una página pesada, lanza una transferencia de archivo, o haz un ping sin fragmentación a través del túnel a la IP de túnel del servidor. Si el tráfico grande ahora fluye, tienes tu valor. Si construyes configuraciones desde cero, las plantillas de configuración listas para usar incluyen la línea MTU en el sitio correcto para cada plataforma.

Valores razonables por tipo de enlace

Cuando no puedes medir — o quieres un punto de partida seguro — estos valores de referencia documentados cubren la mayoría de los enlaces reales:

1280 es el valor que toda ruta con IPv6 está obligada a transportar, así que es el recurso seguro cuando nada más funciona: pierdes algo de eficiencia pero el bloqueo desaparece. Prefiere siempre un valor medido cuando puedas obtenerlo — 1280 deja rendimiento sobre la mesa en una ruta limpia de 1500 bytes.

Cuándo el MTU no es la respuesta

Bajar el MTU es el arreglo cuando los paquetes pequeños pasan y los grandes no. Si nada fluye después del handshake, el problema está en otra parte — comprueba, en orden:

• net.ipv4.ip_forward = 1 y la regla MASQUERADE en el servidor.
• Los AllowedIPs del lado servidor sin solaparse entre pares.
• Un PersistentKeepalive = 25 en cualquier par detrás de NAT.

Los tres se recorren en la guía de resolución de problemas del handshake. Y si solo necesitas ciertas apps en el túnel, bajar el MTU combina de forma natural con un enrutamiento en split-tunnel para que el grueso de tu tráfico esquive la sobrecarga del túnel.

Un enlace limpio hace el MTU predecible

La mitad del dolor del MTU viene de una ruta desordenada: doble NAT, un router doméstico inestable, un túnel apilado sobre un túnel. Un VPS con una IPv4 pública limpia te da un único salto bien educado, donde el valor por defecto estándar de 1420 suele funcionar solo. Un Contabo VPS S a 4,99 €/mes te da root completo y una IP pública sin cortafuegos del proveedor contra el que pelear — exactamente las condiciones en las que el descubrimiento del MTU de ruta se comporta bien. Sigue la instalación paso a paso de Contabo + WireGuard, y si aún eliges proveedor, compara opciones en la guía Contabo vs Hetzner vs OVH.

Para profundizar

• El handshake de WireGuard no se completa: la lista completa de arreglos
• Qué puerto usa WireGuard y cómo abrirlo
• Plantillas de configuración de WireGuard listas para usar 2026
• VPN autoalojada en Contabo: guía completa de WireGuard 2026
• VPN en split-tunnel con tablas de rutas
• Glosario de VPN autoalojada — AllowedIPs, MTU, NAT explicados

Fuentes y referencias:

• Documento técnico de WireGuard — Jason A. Donenfeld
• Quickstart de WireGuard y docs de wg-quick
• Arch Wiki — WireGuard (notas de MTU)
• RFC 8200 — MTU mínimo IPv6 de 1280

Publicado el 2026-06-24. Las cifras de sobrecarga provienen de las cabeceras del protocolo WireGuard; el método de medición es el descubrimiento estándar del MTU de ruta. Tus condiciones de enlace difieren — confirma siempre con un ping sin fragmentación antes de fijar un valor.

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.