MTU sin complicaciones: por qué el tamaño del paquete afecta al VPN y cómo solucionarlo rápido

Introducción: qué es el MTU y por qué importa

MTU explicado fácil

El MTU es el tamaño máximo de un paquete IP que una interfaz puede enviar sin fragmentarlo. Para entenderlo rápido, es el ancho del marco en una puerta de red: si el paquete es más grande, simplemente no cabe. La anchura es fija y la «caja» de datos debe entrar completa. Cuando hablamos de VPN, esa caja crece por la envoltura extra del túnel, y ahí empiezan los líos.

El MTU estándar para Ethernet es 1500 bytes. Para IPv6, el tamaño mínimo garantizado en ruta es 1280 bytes. En centros de datos existen los jumbo frames de hasta 9000 bytes, pero eso es lujo local. En Internet real, sobre todo con 4G/5G, CGNAT y Wi-Fi, el MTU disponible varía mucho: a veces 1500, otras 1472 e incluso 1400. Nosotros queremos que el VPN funcione sin sorpresas, ¿verdad?

Por qué el MTU es crucial para VPN

Todo VPN añade overhead. El túnel pone sus propios encabezados encima del paquete original. Por ejemplo, si usas WireGuard sobre UDP en IPv4, los encabezados IP, UDP y WireGuard suman cerca de 60 bytes. Si antes tenías 1500 bytes, ahora tienes cerca de 1440 bytes de datos útiles dentro del túnel. Si no consideras esto, los paquetes se fragmentan o se pierden porque a veces bloquean ICMP y tu Path MTU Discovery se ciega. El resultado: lentitud, páginas que se congelan, imágenes que no cargan y timeouts en RDP. ¿Molesto? Mucho.

MTU vs MSS: no confundas los términos

El MTU se refiere al nivel IP. El MSS, al TCP. MSS (Maximum Segment Size) es el tamaño máximo del segmento TCP sin incluir encabezados IP y TCP. Cuando alguien dice «haz MSS clamping», se refiere a reducir el MSS en el borde para que los flujos TCP segmenten bien desde el principio y no superen el MTU. ¿Es un parche? Más bien un seguro para evitar accidentes en carreteras resbaladizas: no arreglas el asfalto, pero reduces riesgos.

Cómo un MTU incorrecto arruina las conexiones VPN

Síntomas: detecta el problema escuchando

La imagen no carga completa. El sitio se abre, pero muchas solicitudes quedan colgadas. El correo se envía solo después de varios intentos. El video avanza a tirones. El RDP se desconecta al copiar archivos. El ping responde, pero el navegador tarda mucho en cargar. Esto es un caso clásico de “blackhole MTU”: los paquetes con el bit DF demasiado grandes se descartan en algún punto, no llega el ICMP «Fragmentation needed», TCP retransmite y reduce la ventana. Todo muy lento pero «funciona casi». Y eso enfada aún más.

Casos reales: WireGuard, OpenVPN, IPsec

WireGuard: suelen recomendar MTU 1420. Pero si el proveedor limita MTU a 1472 y encima usas VLAN o PPPoE, el MTU efectivo queda en 1380-1400. La solución es recalcular y fijar el MTU explícitamente en la interfaz wg a 1380 o 1360, un compromiso estable.

OpenVPN UDP: su overhead es mayor, sobre todo con TLS y opciones extras. Un patrón común es tun-mtu 1500 y mssfix 1360, pero en redes móviles suele funcionar mejor MTU de túnel 1400 y mssfix 1360 o incluso 1320. Mejor comenzar con un valor bajo y subirlo poco a poco.

IPsec con NAT-T: ESP sobre UDP suma encabezados adicionales. Si hay PPPoE, se reduce aún más (unos 8 bytes). También puede haber encabezados para marcaje y contenedores. Un buen rango es 1400-1440 según ruta y equipo. En el borde activamos MSS clamping a 1360-1380 para evitar fragmentación TCP.

Puntos débiles: móviles, CGNAT, Wi‑Fi

4G/5G y CGNAT suelen «recortar» MTU y frecuentemente bloquean ICMP. Resultado: PMTUD falla y enviamos datos a ciegas. En puertas Wi‑Fi SOHO algunos fabricantes activan «protección» contra ICMP. Buenas intenciones, cero resultados. En 2026 los operadores impulsan IPv6-only y transporte sobre QUIC/HTTP3, sumando capas de encapsulación. Otra vez contamos bytes, ahora también para UDP/QUIC sobre TLS.

Fragmentación, PMTUD y bit DF: aprende a convivir con la red

Cómo funciona la fragmentación en IPv4 e IPv6

IPv4 puede fragmentar en ruta: si el paquete es grande y DF=0, el router lo divide y el receptor los junta. Teóricamente bien, pero en la práctica fracasamos: los fragmentos se pierden, firewalls los bloquean, y baja el rendimiento. IPv6 obliga a fragmentar sólo en origen y garantiza mínimo MTU 1280. Por eso los errores MTU en IPv6 saltan más rápido y dolen más.

Path MTU Discovery: ¿por qué falla?

PMTUD busca el MTU mínimo en ruta basándose en ICMP «Fragmentation needed» o «Packet too big». Si bloquean ICMP, PMTUD se ciega, los paquetes tocan techo y desaparecen. Así aparece el blackhole MTU. En 2026 muchos usan PLPMTUD (Packetization Layer PMTUD) en TCP que no depende de ICMP, pero protocolos antiguos y apps no siempre lo soportan.

Bit DF, ICMP y políticas de filtrado

El bit DF prohíbe fragmentar en ruta y se usa mucho en VPN porque fragmentar fuera del túnel es peligroso. Si a la vez bloquean ICMP, estamos atrapados: no fragmentar ni avisar que hay que reducir tamaño. Resultado: sesiones TCP congeladas. La regla de oro: siempre permitir ICMP «Fragmentation needed» e IPv6 «Packet too big», aunque tengamos ganas de apretar seguridad ficticia.

MSS clamping: cuándo y cómo ayuda

MSS vs MTU: lo esencial

MSS clamping ajusta el MSS en los paquetes TCP SYN para que los remitentes no envíen segmentos muy grandes. No sustituye al MTU bien configurado, pero protege el tráfico TCP. No afecta UDP, pero resuelve el 80 % de problemas web de inmediato.

Dónde configurar MSS clamping

En Linux se usa firewall. En nftables o iptables añadimos reglas para reescribir MSS en SYN. En MikroTik hay mangle TCP, en Cisco y Juniper políticas firewall/zone con tcp-mss. Es vital activarlo en el borde del túnel para que el ajuste refleje el MTU real de la encapsulación.

Precauciones

MSS demasiado bajo reduce eficiencia TCP; muy alto vuelve a chocar con el MTU. Al cambiar MTU del túnel recuerda recalcular MSS. Fórmula clásica: MSS = MTU - 40 (IPv4 IP+TCP=20+20), igual para IPv6 por su estructura. Luego resta overhead VPN si ajustas antes de encapsular.

Diagnóstico de problemas MTU: paso a paso

Algoritmo rápido

1. Detecta síntomas de blackhole: sites que cargan parcialmente, peticiones largas bloqueadas, desconexiones RDP.
2. Haz ping con tamaños grandes y bit DF. IPv4: «ping -M do -s TAMAÑO dirección». IPv6: «ping -s TAMAÑO -M do» según sistema. Busca el máximo sin fragmentación.
3. Ejecuta tracepath o «traceroute --mtu» para localizar dónde baja MTU.
4. Verifica si ICMP «Fragmentation needed» e IPv6 «Packet too big» pasan. Si no, cambia la política y habilita esos ICMP.
5. Reduce MTU del túnel y activa MSS clamping. Empieza en rango seguro (p.ej. 1360-1380) y sube poco a poco.

Herramientas prácticas

El ping con DF/size ayuda a encontrar el máximo tamaño sin pérdida. Para Ethernet y WireGuard suelen estar entre 1380-1420, pero verifica tu ruta. Tracepath muestra la estimación PMTU de la ruta. Wireshark detecta ICMP «Packet too big» y ayuda a determinar el tamaño exacto. En Linux «ip link show dev wg0» y «ip route get» muestran la configuración actual y el PMTU.

Detalles según protocolo

GRE y L2TP añaden overhead y suelen chocar con PPPoE. IPsec ESP con NAT-T suma encabezados UDP y ESP que pueden superar 60-80 bytes perdidos. WireGuard es limpio pero sensible a bloqueos ICMP e inestabilidad MTU móvil. OpenVPN UDP sufre fragmentación por apps que envían grandes paquetes y TLS.

Cómo determinar el MTU mínimo en ruta

El método es sencillo: búsqueda binaria con ping DF entre 1400-1500, afina con pasos de 10 y luego 2 bytes. El valor final menos 20-40 bytes es el margen para fluctuaciones. La ruta cambia regularmente: por la mañana un operador, por la noche otro. Por eso un margen razonable salva de sorpresas.

Soluciones y ajuste MTU para VPN en 2026

Valores recomendados por protocolo

• WireGuard sobre IPv4/UDP: empieza con MTU 1380-1420. En 5G y CGNAT, mejor 1380-1400. Para IPv6, nunca menos de 1280 dentro del túnel, con encapsulación ideal entre 1280-1360.
• OpenVPN UDP: tun-mtu 1400-1500, mssfix 1360 por defecto. En móviles y Wi-Fi, prefiere 1400/1360 o menos.
• IPsec ESP NAT-T: MTU túnel 1400-1440, MSS 1360-1380. Si hay PPPoE, baja 8-12 bytes más.
• GRE/L2TP: prueba la ruta, suele ser 1400-1460, pero con PPPoE apunta a 1380 o menos.

Automatización y gestión

En 2026 son tendencia scripts que revisan PMTU periódicamente y ajustan MTU en interfaces. Para WireGuard es práctico usar pre-up hooks con wg-quick y systemd-networkd para testear al iniciar túnel, calcular MTU seguro y aplicar configuración. Un colchón de 20 bytes bajo el resultado evita muchas horas de soporte.

Políticas en el perímetro

Permite ICMP «Fragmentation needed» e IPv6 «Packet too big». No es una vulnerabilidad, es esencial para PMTUD. Configura excepciones en ACL y grupos de seguridad. Si tienes DPI o WAF, asegúrate de que no bloquean ICMP por defecto. Es una práctica vieja que en 2026 ya no tiene sentido.

Tendencias 2026: QUIC, MASQUE, BBRv3, 5G SA

QUIC y MASQUE hacen que VPN sobre HTTP/3 sea común. El overhead es mayor y PMTUD para UDP es dos veces más importante. BBRv3 en kernels modernos mejora la respuesta a pérdidas pero no evita fragmentación tonta. En 5G SA y slicing, operadores aplican optimizaciones que modifican MTU sobre la marcha. La clave: ajuste automático y monitoreo constante, imprescindible.

Seguridad y rendimiento: no hagas daño

Riesgos de fragmentación

Ataques con fragmentos superpuestos y vulnerabilidades tipo teardrop siguen presentes en configuraciones erróneas. Permitir fragmentación amplía la superficie de ataque. Y con VPN, el camino ya es más complejo. Mejor evitarla bajando MTU y usando MSS clamping.

QoS, ECN y TFO

El MTU afecta la calidad del QoS: tamaños erróneos dañan clasificación y colas. ECN y TCP Fast Open mejoran respuesta, pero en blackhole MTU no ayudan e incluso empeoran por retransmisiones falsas. Primero MTU bien, luego los detalles finos.

Monitoreo SLO

Métricas clave: SRT (tiempo de respuesta servidor), RTT, pérdida de paquetes, retransmisiones TCP, cantidad de ICMP «Packet too big». Si aumentan los RST y FIN con sesiones cortas, revisa MSS. Si hay tormenta de time-waits, ajusta MTU y clamping. Un dashboard sencillo que relacione «cambios MTU - quejas» revela problemas rápido.

Checklists y plantillas listas

Checklist rápido MTU para VPN

1. Determina el PMTU real en ruta, no creas en 1500 por defecto.
2. Fija MTU del túnel por debajo con margen de 20-40 bytes.
3. Activa MSS clamping en el borde para TCP (empieza en 1360, ajusta luego).
4. Permite ICMP «Fragmentation needed» y «Packet too big».
5. Haz pruebas A/B en parte del tráfico y analiza quejas y métricas.
6. Automatiza comprobaciones de PMTU al iniciar interfaces.

Plantillas de ajustes: qué y dónde modificar

• WireGuard: configura MTU en el archivo de la interfaz. Prueba con 1380-1420 y ping DF. Si hay PPPoE, reduce más.
• OpenVPN: usa tun-mtu y mssfix. Para muchos clientes móviles, empieza con 1400/1360.
• IPsec: baja MTU en interfaz interna y configura MSS clamping. Cuidado con NAT-T y PPPoE.

Nubes y proveedores: detalles

En 2026 muchas nubes soportan Jumbo frames dentro del VPC, pero en la frontera a Internet la realidad es dura: 1500 o menos. O mantienes control end-to-end y ICMP, o espera regresiones aleatorias de rendimiento. Un caso aparte son túneles interregionales sobre 5G donde MTU varía con el día. Ajuste automático o estático en 1360 y olvida preocupaciones.

SOHO y routers móviles

Routers domésticos o semi-profesionales a menudo bloquean ICMP sin avisar. Desactívalo. Activa MSS clamping en «Firewall» o «Mangle». Para clientes OpenVPN no dudes en poner mtu en 1400 si reportan «uso de CPU al 90%».

Mitos comunes sobre MTU

«Menor MTU siempre es mejor»

No. MTU demasiado bajo baja la eficiencia: más encabezados por carga útil, más paquetes y más interrupciones. Lo importante es el equilibrio. Empieza con un valor prudente y súbelo si la ruta aguanta.

«1500 es ley de la naturaleza»

Es una tradición conveniente de Ethernet, no un dogma. Por PPPoE, túneles y móviles, el MTU real suele ser menor. Acepta la realidad y trabaja con datos del camino, no con mitos de libro.

«IPv6 siempre maneja mejor el MTU»

IPv6 es más estricto con la fragmentación, por eso los errores MTU aparecen más rápido. Eso es bueno porque se siente el problema de inmediato, no diluido en retransmisiones. Pero «mejor» no significa «sin ajustes». Activa PMTUD para IPv6, vigila ICMPv6 y nunca bloquees «Packet too big».

Conclusión: resumen rápido y siguiente paso

Resumen en un párrafo

El MTU es física de red y sentido común. El VPN añade bytes y abre la puerta a ruidos y filtros. O respetamos PMTUD y dejamos pasar ICMP, o jugamos a adivinar y perdemos horas en soporte. Elige lo primero y duerme tranquilo.

Errores a evitar

• Bloquear ICMP «Fragmentation needed» y «Packet too big».
• Creer que «1500 funciona sin pruebas».
• No usar MSS clamping para TCP.
• Ignorar overhead de PPPoE y NAT-T.

Qué hacer después

1. Testea rutas clave con DF y tracepath.
2. Configura MTU del túnel con margen y activa MSS clamping.
3. Automatiza comprobaciones al levantar interfaces.
4. Agrega monitoreo de métricas relacionadas con MTU.

Preguntas frecuentes: respuestas breves a dudas clave

¿Cómo saber rápido si el problema es MTU?

Si «parece haber internet pero parte del contenido no carga», especialmente recursos grandes o descargas que se cortan, probablemente es MTU. Prueba ping con DF y tamaños grandes, compara con tracepath. Si ICMP está bloqueado, es casi seguro.

¿Qué MTU usar en WireGuard en 5G?

Empieza con 1380. Si todo va estable, sube a 1400-1420. Si ves cuelgues extraños en hora punta, baja a 1380. No olvides configurar MSS clamping a 1360.

¿Puedo solo activar MSS clamping y no tocar MTU?

Facilita la vida al TCP pero no soluciona UDP ni elimina todos los problemas. Lo ideal es MTU correcto junto con MSS clamping. Ignorar alguno deja molestias persistentes a los usuarios.

¿Por qué en local va rápido y para empleados remotos falla?

Cada ruta tiene diferente MTU mínima. En oficina hay un solo proveedor y 1500 justos. En casa, CGNAT, Wi‑Fi y routers que bloquean ICMP afectan. Así que el MTU «ideal» en teoría no coincide con la ruta real.

IPv6 y VPN: ¿qué MTU mínimo mantener?

No bajes de 1280 dentro del túnel. Recuerda overhead de encapsulación. La mayoría de escenarios funcionan bien entre 1280-1360. Permite siempre ICMPv6 «Packet too big».

¿Es tan crítico permitir ICMP en producción?

Sí, es como conducir de noche sin luces. Hay PLPMTUD y trucos, pero ahorrar en ICMP cuesta más tiempo a ingenieros y usuarios frustrados.

¿Qué pasa con QUIC/HTTP3 y MTU?

QUIC sobre UDP es muy sensible a pérdidas de datagramas grandes. Si el MTU es incorrecto, notas lag y fluctuaciones. Revisa el PMTU, usa un valor conservador y mantén MSS clamping para el TCP que va de la mano.