Ajuste del MTU en VPN: por qué los archivos grandes se detienen mientras la web funciona (y cómo elegir el MTU correcto)

El modelo mental: por qué “la web funciona” pero los archivos grandes no

MTU (Maximum Transmission Unit) es la mayor carga útil de paquete IP que tu interfaz está dispuesta a enviar sin fragmentar.
El MTU clásico de Ethernet es 1500 bytes. Muchas VPNs funcionan sobre Ethernet. Mucha gente asume que la VPN hereda esos 1500. Esa suposición ha perjudicado más carreras que cualquier bug individual en un servicio.

Las VPN añaden cabeceras. A veces muchas cabeceras.
Tu paquete “interno” (el que tu aplicación cree que envía) queda envuelto dentro de un paquete “externo” (el que realmente transporta Internet).
Si el camino externo no puede manejar el tamaño, el paquete debe fragmentarse o el emisor debe reducir el tamaño del paquete.

De aquí viene la ilusión de “la web funciona”:

• Lo interactivo es pequeño. Pulsaciones de SSH y llamadas API normalmente caben en unos cientos de bytes. Incluso si el MTU es incorrecto, muchos de esos paquetes atraviesan.
• El tráfico web es resistente. Los navegadores reintentan. Los CDN toleran pérdidas. Algunos sitios usan ventanas iniciales de congestión más pequeñas. Y muchas rutas reducen silenciosamente el MSS de TCP o simplemente tienen suficiente margen.
• Las transferencias grandes golpean constantemente el techo del MTU. SCP, rsync, SMB, NFS sobre TCP—estos intentan llenar la tubería. Eso significa muchos segmentos TCP de tamaño completo. Si esos segmentos quedan en un agujero negro, el rendimiento colapsa.
• PMTUD es frágil en redes corporativas. Depende de los mensajes ICMP “Fragmentation Needed” que vuelvan al emisor. Los firewalls adoran bloquear ICMP porque “parece peligroso”.

Cuando PMTUD está roto, obtienes el clásico “agujero negro de MTU”: los paquetes grandes desaparecen, nadie informa al emisor, TCP retransmite el mismo segmento condenado y la transferencia “se cuelga”.

Broma #1: Los problemas de MTU son como las sillas de oficina—nadie piensa en ellas hasta que la espalda les falla a mitad de trimestre.

Datos interesantes y contexto histórico (edición MTU)

1. 1500 bytes no era una ley de la física. Fue una elección de diseño de los primeros trade-offs de Ethernet: eficiencia vs. dominio de colisión y limitaciones de hardware.
2. La fragmentación IP existe porque Internet se ensambló a partir de muchas redes. El IP temprano tuvo que cruzar enlaces con diferentes tamaños máximos de trama, así que la fragmentación fue un truco de compatibilidad.
3. IPv6 cambió las reglas: los routers no fragmentan. En IPv6, la fragmentación la hace solo el emisor, lo que hace que PMTUD sea aún más crítico.
4. El MTU 1492 de PPPoE es un clásico. Ocho bytes de overhead de PPPoE significan que 1500 no entra, y las VPN apiladas encima se ajustan todavía menos.
5. Los “jumbo frames” son comunes dentro de centros de datos. MTU de 9000 bytes mejora eficiencia, pero MTU mezclados a través de overlays (VXLAN/Geneve) crean fallos que parecen exactamente problemas de MTU de VPN.
6. PMTUD ha fallado desde los 90. El problema del “agujero negro” es antiguo: el filtrado de ICMP rompe el bucle de retroalimentación.
7. El clamp de TCP MSS se popularizó porque la gente se rindió con PMTUD. No es elegante, pero es pragmático cuando no controlas todos los firewalls en el camino.
8. IPsec puede añadir más overhead de lo que la gente espera. Dependiendo del modo (túnel vs transporte), NAT traversal y algoritmos, el overhead varía—y tu MTU seguro cambia.

Cómo se manifiesta el dolor del MTU en producción

Los problemas de MTU rara vez aparecen como “paquete demasiado grande”. Aparecen como rarezas: fallos selectivos, comportamiento inconsistente entre aplicaciones y rendimiento que parece un mal día en un ISP.
Los síntomas que deberían hacerte sospechar del MTU primero:

• Transferencias SCP/rsync/SMB se atascan después de enviar algunos datos, a menudo en un desplazamiento repetible.
• HTTPS funciona, pero subir un artefacto grande caduca.
• SSH funciona, pero ejecutar git clone sobre la VPN es dolorosamente lento o se cuelga.
• Algunos sitios funcionan, otros no, especialmente los que envían cookies/cabeceras grandes o usan registros TLS más grandes.
• La VPN funciona desde una red pero no desde otra (fibra doméstica vs. cafetería vs. Wi‑Fi de invitados corporativos).
• Las cosas fallan solo cuando activas “túnel completo” o enrutas subredes adicionales.

Detrás de esos síntomas suele estar una de estas causas mecánicas:
paquetes sobredimensionados + DF establecido (no fragmentar) + PMTUD roto = agujero negro.
O la fragmentación ocurre, pero ocurre mal (fragmentos perdidos, problemas de reasamblaje, sobrecarga CPU, problemas con firewalls stateful).

PMTUD y los mensajes ICMP que todos bloquean

Path MTU Discovery debería ser simple: envía un paquete con DF establecido, y si un router no puede reenviarlo, el router responde con un mensaje ICMP indicando el MTU del siguiente salto.
El emisor reduce el tamaño y vuelve a intentarlo. Todos contentos.

En la práctica, PMTUD es una negociación entre dos hosts a través de una cadena de dispositivos que pueden:
bloquear ICMP, reescribir cabeceras, encapsular paquetes o “normalizar” el tráfico de forma “útil”.
Si el ICMP “Fragmentation Needed” (IPv4) o “Packet Too Big” (IPv6) está filtrado, el emisor sigue transmitiendo paquetes sobredimensionados y no recibe retroalimentación.

Esa es toda la historia del agujero negro. Una sola regla de seguridad escrita en 2014 (“drop all ICMP”) puede dejar de rodillas a una VPN moderna en 2025.

Toma de posición: no soluciones fallos de PMTUD esperando que PMTUD empiece a funcionar.
En la realidad corporativa, debes asumir que algún middlebox va a bloquear ICMP en el peor lugar posible.
Tu trabajo es elegir un MTU seguro o clavar el MSS para que TCP nunca envíe paquetes que necesiten PMTUD en primer lugar.

Sobrecarga de encapsulación VPN: los bytes que no ves

La encapsulación no es gratis. Cada protocolo VPN añade cabeceras (y a veces padding) que consumen espacio dentro del MTU externo.
Si tu MTU de interfaz física es 1500 y tu VPN añade 80 bytes de overhead, tu paquete interno ya no puede ser 1500.

La sobrecarga varía. Varía según el protocolo, el modo, si se usa NAT traversal y si estás en IPv4 o IPv6 en el transporte externo.
Aquí hay números aproximados con los que puedes razonar (no promesas, solo estimaciones útiles):

• WireGuard sobre IPv4/UDP: a menudo ~60 bytes de overhead; MTU seguro real comúnmente 1420.
• WireGuard sobre IPv6/UDP: ligeramente más overhead; MTU seguro a menudo algo menor.
• IPsec ESP en modo túnel: comúnmente 50–80+ bytes; NAT-T añade más (encapsulado UDP).
• OpenVPN sobre UDP: el overhead depende del cifrado y ajustes; 1500→ típicamente 1400–1472 según afinación.
• GRE/VXLAN overlays: añaden su propio overhead; cuando se apilan con VPN, puedes perder 100+ bytes con rapidez.

La forma correcta de pensar: tienes un path MTU externo, y debes elegir un MTU interno que siempre quepa después de añadir la sobrecarga.
Si no conoces el path MTU, lo mides. Si no puedes medirlo con fiabilidad, eliges de forma conservadora y clamas.

Broma #2: La sobrecarga de encapsulación es como las reuniones—nadie la presupuestó y, de algún modo, se come toda la tarde.

Cómo elegir el MTU “correcto” para la VPN

No existe un MTU mágico. Hay un MTU seguro para tu camino externo y tu pila de encapsulación.
Elegirlo es un ejercicio de ingeniería: mide la ruta, resta el overhead y verifica con tráfico real.

Paso 1: averigua el MTU externo más pequeño que encontrarás

Si controlas el underlay (una WAN privada), puede que sepas que es 1500 de extremo a extremo o 9000 de extremo a extremo.
Si tu VPN circula por Internet pública, asume que no la controlas.
Los ISP de consumo, PPPoE, LTE y el Wi‑Fi de hoteles pueden reducir el MTU de maneras que cambian según la ubicación.

Un objetivo pragmático para VPNs basadas en Internet suele ser:
MTU 1420 para WireGuard, o
MTU 1400 como línea base conservadora “funciona en la mayoría de sitios” cuando tienes redes mixtas y middleboxes desconocidos.

Paso 2: decide si confiarás en PMTUD o clamarás MSS

Si puedes garantizar que ICMP está permitido de extremo a extremo y tienes visibilidad de los firewalls, PMTUD puede funcionar.
La mayoría de organizaciones no pueden garantizar eso a través de redes de socios, puestos remotos y Wi‑Fi de invitados variados.

Mi recomendación por defecto:
establece un MTU de túnel seguro y además clama el MSS de TCP en el borde de la VPN como defensa en profundidad.
Es aburrido. Funciona. Es el tipo de aburrido que mantiene tu canal de incidentes tranquilo.

Paso 3: valida con pruebas “no fragmentar” y transferencias reales

Una prueba de ping con DF establecido no cuenta toda la historia, pero es una forma rápida de encontrar el límite de fallo.
Luego valida con una transferencia real de volumen (iperf3, scp de un archivo grande o rsync) porque algunas rutas tratan ICMP diferente a UDP/TCP.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando alguien dice “la VPN va lenta” y sospechas del MTU, quieres un camino corto determinista hacia la verdad.
Aquí el orden más rápido que detecta la mayoría de fallos del mundo real sin convertirse en una excavación arqueológica de una semana.

Primero: confirma que el síntoma depende del tamaño

• Las solicitudes HTTP pequeñas funcionan; las cargas grandes fallan.
• SSH conecta; scp de un archivo de varios GB se atasca.
• Ping funciona con carga pequeña; falla con carga mayor + DF.

Segundo: encuentra el MTU efectivo en el túnel y su underlay

• Revisa el MTU de la interfaz del túnel.
• Revisa el MTU de la interfaz de salida física.
• Busca PPPoE (1492), rarezas de LTE o restricciones de redes cloud.

Tercero: detecta fallo de PMTUD y decide clamar vs permitir ICMP

• Ejecuta pings con DF para hacer una búsqueda binaria del tamaño máximo.
• Captura tráfico para ver retransmisiones y ICMP faltantes.
• Si ICMP está bloqueado en algún lugar que no controlas: clama MSS y baja MTU.

Cuarto: valida la solución con una transferencia real de volumen

• Usa iperf3 o scp/rsync de un archivo de varios GB.
• Observa retransmisiones, desorden y estabilidad del throughput.
• Confirma que no rompiste otra cosa (como una red overlay).

Tareas prácticas (comandos, salidas, decisiones)

El objetivo de la resolución de problemas de MTU es dejar de adivinar.
Abajo hay tareas concretas que puedes ejecutar en hosts Linux y gateways VPN típicos.
Cada tarea incluye: un comando, salida de ejemplo, lo que significa y qué decisión tomar después.

Task 1: Check MTU on all interfaces (find the tunnel and the real egress)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
eth0             UP             0a:1b:2c:3d:4e:5f <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
wg0              UP             8a:9b:aa:bb:cc:dd <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Qué significa: El túnel (wg0) está configurado a 1420, el underlay eth0 es 1500. Es un punto de partida sensato para WireGuard.

Decisión: Si el MTU del túnel está a 1500 mientras el underlay también es 1500, casi con seguridad estás sobredimensionado tras el overhead. Planea reducir el MTU del túnel o clamar MSS.

Task 2: Inspect the route and learn which interface actually carries VPN traffic

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Qué significa: Tu salida a Internet es eth0. Ese es el underlay para la VPN si tus peers VPN están en Internet.

Decisión: Si la interfaz de salida es un dispositivo PPPoE (a menudo ppp0) o una VLAN con MTU menor, usa ese valor como límite superior para el tamaño del paquete externo.

Task 3: Check for PPPoE or other reduced-MTU links

cr0x@server:~$ ip -d link show dev ppp0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp

Qué significa: El MTU externo es 1492, no 1500. Si asumiste 1500, tu MTU interno del túnel debe reducirse más.

Decisión: Baja el MTU del túnel y/o clama MSS en consecuencia. No “optimices” esto a menos que controles el método de acceso.

Task 4: Quick DF ping to detect fragmentation/black hole (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 198.51.100.20 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2053ms

Qué significa: Tu sistema local ya conoce una restricción de MTU (1420) en la ruta/interfaz usada. Un paquete de 1500 bytes no cabrá.

Decisión: No envíes segmentos TCP que requieran paquetes de 1500 sobre este camino. Ajusta el MTU del túnel para que coincida con la realidad o clama MSS.

Task 5: Binary search the maximum DF payload that works

cr0x@server:~$ ping -M do -s 1392 -c 2 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1392(1420) bytes of data.
1400 bytes from 198.51.100.20: icmp_seq=1 ttl=57 time=28.1 ms
1400 bytes from 198.51.100.20: icmp_seq=2 ttl=57 time=27.8 ms

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 27.825/27.948/28.071/0.123 ms

Qué significa: 1420 bytes de paquete IP total funcionan (1392 payload + 28 bytes de cabecera ICMP+IP). Eso sugiere un path MTU seguro cercano a 1420 para este flujo.

Decisión: Elige el MTU del túnel en o por debajo de este límite (ten en cuenta el overhead VPN). Para WireGuard, 1420 suele ser correcto; para encapsulaciones más pesadas, ve más bajo.

Task 6: Detect PMTUD being blocked (classic black hole pattern)

cr0x@server:~$ ping -M do -s 1412 -c 2 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1412(1440) bytes of data.

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2038ms

Qué significa: Sin respuesta, y tampoco recibiste un ICMP “frag needed” útil de vuelta. Esto podría ser pérdida simple, pero si tamaños menores funcionan de forma fiable, es sospechoso.

Decisión: Asume un agujero negro de MTU hasta que se demuestre lo contrario. Prefiere clamar MSS y un MTU de túnel conservador. También revisa reglas de firewall para ICMP tipo 3 código 4 (IPv4) e ICMPv6 tipo 2.

Task 7: Check TCP MSS and observed path behavior with ss

cr0x@server:~$ ss -ti dst 198.51.100.20
ESTAB 0 0 10.0.0.5:48216 198.51.100.20:443
	 cubic wscale:7,7 rto:204 rtt:32.4/4.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:10 bytes_sent:128734 bytes_acked:128734

Qué significa: La conexión usa MSS 1360 y PMTU 1420. Es coherente: 1420 menos 40 bytes de cabecera TCP+IP = 1380 (cerca; las opciones pueden reducirlo un poco).

Decisión: Si ves MSS cerca de 1460 pero tu MTU de túnel es menor, probablemente hay un desajuste y deberías clamar o arreglar el MTU.

Task 8: Verify WireGuard’s configured MTU and peer path

cr0x@server:~$ wg show
interface: wg0
  public key: 8n3r...redacted...
  listening port: 51820

peer: pQ1k...redacted...
  endpoint: 198.51.100.20:51820
  allowed ips: 10.42.0.0/16
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.23 GiB received, 2.98 GiB sent

Qué significa: El túnel está activo y moviendo datos. Los problemas de MTU no necesariamente detendrán los handshakes; castigan las transferencias bulk y ciertos tamaños de paquete.

Decisión: Si los handshakes están bien pero el throughput es pésimo, céntrate en MTU/MSS/PMTUD en lugar de claves o enrutamiento.

Task 9: Check and set interface MTU (temporary change for testing)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Qué significa: Forzaste un MTU menor en el túnel. Esto reduce el riesgo de fragmentación a costa de un ligero overhead por paquete transferido.

Decisión: Si las transferencias grandes se estabilizan tras bajar el MTU, has confirmado que el MTU era el cuello de botella. Ahora calcula el valor más alto seguro y aplícalo permanentemente en la gestión de configuración.

Task 10: Clamp TCP MSS on a Linux gateway with iptables

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD
-P FORWARD ACCEPT
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Qué significa: Para paquetes SYN TCP que salen por wg0, el MSS se ajustará para encajar el PMTU descubierto (o el MTU de la interfaz).

Decisión: Usa esto cuando no puedas confiar en PMTUD de extremo a extremo o cuando los clientes tengan MTU inconsistentes. Luego verifica con ss -ti que el MSS se redujo.

Task 11: Do the same with nftables (common in modern distros)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft 'add chain inet mangle forward { type filter hook forward priority -150; }'
cr0x@server:~$ sudo nft add rule inet mangle forward oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
cr0x@server:~$ sudo nft list ruleset
table inet mangle {
	chain forward {
		type filter hook forward priority -150; policy accept;
		oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
	}
}

Qué significa: El MSS se fija según el MTU de ruta. Esto es el equivalente en nftables de “clamp to PMTU”.

Decisión: Prefiere nftables si eso es lo que usa tu flota. Hazlo persistente usando el mecanismo de tu distro (no mostrado aquí) y prueba después de reiniciar.

Task 12: Confirm ICMP “fragmentation needed” isn’t being dropped locally

cr0x@server:~$ sudo iptables -S INPUT
-P INPUT DROP
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j DROP

Qué significa: Estás descartando todo ICMP en el firewall del host. Eso puede romper PMTUD (incluso si las reglas RELATED podrían haber ayudado en algunos casos).

Decisión: Permite los tipos ICMP necesarios, o clama MSS para no depender de ICMP. Si estás en IPv6, “descartar todo ICMPv6” es una forma fiable de romper tu red de maneras creativas.

Task 13: Capture evidence of black-holing (retransmits, no ICMP back)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp port 443 or icmp' -vv
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:15:01.102334 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360
12:15:01.304982 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360
12:15:01.708115 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360

Qué significa: Retransmisiones del mismo segmento sin progreso. Si nunca ves mensajes ICMP “too big” y los MSS menores funcionan, tienes un problema de PMTUD/MTU.

Decisión: Reduce el MTU del túnel y clama MSS. Luego vuelve a probar y confirma que las retransmisiones desaparecen.

Task 14: Measure throughput and stability with iperf3 (TCP)

cr0x@server:~$ iperf3 -c 10.42.0.20 -t 15
Connecting to host 10.42.0.20, port 5201
[  5] local 10.42.0.10 port 46012 connected to 10.42.0.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.50 MBytes  54.5 Mbits/sec   12   34.0 KBytes
[  5]   1.00-2.00   sec  2.00 MBytes  16.8 Mbits/sec   31   19.8 KBytes
[  5]   2.00-3.00   sec  1.25 MBytes  10.5 Mbits/sec   45   14.1 KBytes
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec   60   10.0 KBytes

Qué significa: Las retransmisiones suben y el throughput colapsa a cero; es consistente con segmentos en agujero negro o pérdida severa. Los problemas de MTU suelen presentarse así cuando alcanzas el “tamaño malo”.

Decisión: Baja MTU / clama MSS y vuelve a ejecutar. Un buen resultado es un bitrate estable con pocas retransmisiones.

Task 15: Spot local offload features that can confuse captures (not usually the root cause)

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'tso|gso|gro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Qué significa: Las offloads pueden hacer que las capturas parezcan extrañas (grandes “super paquetes” en el host). Normalmente no causan agujeros negros de MTU, pero pueden hacer que interpretes mal la evidencia.

Decisión: Si estás profundizando en el análisis de paquetes, deshabilita temporalmente las offloads para mayor claridad (no como “solución”), luego vuelve a activarlas para evitar regresión de rendimiento.

Task 16: Verify MTU on a remote client (because your gateway isn’t the only liar)

cr0x@server:~$ ssh user@client 'ip -br link show dev wg0'
wg0              UP             3a:44:55:66:77:88 <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500

Qué significa: El wg0 del cliente está en 1500. Ese cliente puede enviar paquetes internos que no quepan una vez encapsulados, dependiendo de la ruta.

Decisión: Estandariza el MTU en clientes vía gestión de configuración (o empuja un perfil si usas un cliente gestionado). La consistencia vence a la depuración heroica.

Tres microhistorias corporativas (porque la producción enseña)

1) El incidente causado por una suposición errónea

Una empresa mediana desplegó una VPN site-to-site nueva entre una VPC en la nube y una oficina on‑prem.
Las pruebas de conectividad parecían limpias: los pings funcionaban, DNS funcionaba, la gente podía SSH a bastiones. Todos declararon éxito.
Dos días después, el sistema CI empezó a fallar al subir artefactos de build a un registro interno accesible solo por esa VPN.

Los logs de build mostraban timeouts y reintentos. Los desarrolladores culparon al registro. El equipo de registro culpó a los runners de CI. SRE fue arrastrado porque el canal de incidentes tenía esa energía especial de “esto es urgente pero nadie sabe por qué”.
Alguien notó un patrón: las imágenes pequeñas se empujaban bien. Las capas grandes se quedaban atascadas indefinidamente.

La suposición errónea fue simple y común: “La red es Ethernet, así que el MTU es 1500 en todas partes.”
El uplink on‑prem usaba PPPoE. El MTU externo era 1492. La VPN añadió overhead encima. PMTUD estaba roto porque una política de firewall antigua bloqueaba ICMP tipo 3 código 4.
Así que segmentos TCP grandes desaparecían en el vacío, y TCP hizo lo que hace: retransmitir, disminuir la ventana y sufrir en silencio.

La solución no fue heroica. Bajaron el MTU del túnel a un valor seguro y clavaron MSS en el gateway.
Las subidas volvieron a ser aburridas. El incidente terminó.
La acción del postmortem fue más aguda: dejar de usar “ping funciona” como proxy de “el tráfico bulk funciona” y dejar de bloquear todo ICMP por defecto.

2) La optimización que salió mal

Otra organización tenía una fuerza remota y un cliente VPN que por defecto usaba MTU 1420.
Un ingeniero de red, intentando exprimir más throughput en transferencias grandes, aplicó una política para poner MTU a 1500 “para igualar Ethernet”.
También deshabilitó el clamp de MSS porque “no debería ser necesario”.

Durante una semana, pareció una ganancia en la oficina: transferencias más rápidas a ciertos servicios internos sobre un ISP bien comportado.
Luego la cola de helpdesk explotó con usuarios remotos: las videollamadas iban bien, pero subir informes a un portal interno fallaba, y algunas webs cargaban sin CSS.
Los fallos eran inconsistentes según ISP y ubicación, que es exactamente cómo se presentan los problemas de MTU cuando el underlay varía.

El desastre vino del mundo real: algunos usuarios estaban en hotspots LTE con MTU efectivo menor; otros detrás de routers de consumo haciendo cosas raras con ICMP; algunos tenían rutas ISP que simplemente no pasaban 1500+encapsulación con fiabilidad.
PMTUD debería haber negociado tamaños menores, pero no pudo porque los mensajes ICMP “too big” no llegaban consistentemente.

El rollback a 1420 arregló a la mayoría de usuarios al instante. Reintrodujeron el clamp MSS en el borde VPN y luego hicieron un experimento controlado para ver si algún subconjunto podía usar un MTU mayor de forma segura.
La conclusión fue predecible y molesta: un MTU más alto globalmente no valía el coste de soporte. Mantuvieron 1420 y se centraron en throughput mediante mejor enrutamiento y planificación de capacidad.

3) La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros operaba múltiples tipos de VPN: WireGuard para ingenieros, túneles IPsec para socios y una red overlay en Kubernetes.
Tenían una regla: cada nuevo túnel debe incluir una prueba de MTU y una política MSS, más un runbook de una página con el procedimiento de “búsqueda binaria con ping DF”.
Nadie amaba esa regla. Todos la seguían porque evitaba que los fines de semana se destruyeran.

Un viernes, un socio cambió su postura de firewall y empezó a bloquear más ICMP.
Su túnel IPsec siguió “up” pero mensajes grandes a una API de liquidaciones empezaron a fallar de forma esporádica. Se dispararon alertas, pero el equipo no se puso en pánico; tenían un playbook y una línea base conocida buena.

Ejecutaron sus comprobaciones estándar: pruebas DF ping, tcpdump para retransmisiones y verificación del clamp MSS en el borde.
Resultado: el clamp ya estaba evitando segmentos TCP sobredimensionados, así que el impacto quedó limitado a un subconjunto de tráfico no TCP y a un servicio específico que enviaba payloads UDP mayores de lo esperado.
Como el MTU del túnel ya era conservador, el radio de impacto fue menor del que podría haber sido.

Ajustaron el tamaño de payload de la aplicación para esa ruta UDP y coordinaron con el socio para permitir los tipos ICMP necesarios.
La práctica “aburrida”—ajustes estándar de MTU, clamp y pruebas repetibles—convirtió lo que podría haber sido un outage multi‑equipo en un ticket operativo contenido.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: SCP se atasca; SSH interactivo está bien

Causa raíz: Segmentos TCP dimensionados para MTU 1500 están siendo engullidos tras la encapsulación VPN; PMTUD/ICMP está bloqueado.

Solución: Reduce el MTU del túnel (p. ej., 1420→1380 si es necesario) y clama MSS en el borde VPN. Verifica con ss -ti y una transferencia real.

2) Síntoma: Algunos sitios cargan, otros cuelgan o pierden activos (CSS/imagenes)

Causa raíz: Tamaños de paquete mixtos en TLS/HTTP; respuestas más grandes disparan fragmentación. Frecuente con túnel completo y desajuste MTU.

Solución: Clama MSS en TCP saliente desde el cliente o gateway VPN. Si gestionas clientes, estandariza el MTU del túnel.

3) Síntoma: VPN “conecta” pero el throughput es terrible y las retransmisiones son altas

Causa raíz: Fragmentación o pérdida en un límite de tamaño específico; a veces agravado por overlay sobre overlay (VXLAN sobre VPN, etc.).

Solución: Mide el tamaño DF máximo, reduce MTU y evita apilar encapsulaciones sin presupuestar MTU. Si debes apilar, incluye la aritmética de MTU en el diseño.

4) Síntoma: Funciona desde la red de la oficina, falla desde casa o LTE

Causa raíz: El MTU del underlay difiere (PPPoE/LTE), y tu MTU de túnel elegido es demasiado alto para algunas rutas. PMTUD puede no funcionar a través de gear de consumo.

Solución: Usa MTU conservador para accesos remotos y clama MSS. Deja de tratar la oficina como “Internet”.

5) Síntoma: Tráfico IPv6 por VPN es inestable; IPv4 está bien

Causa raíz: ICMPv6 filtrado (especialmente “Packet Too Big”), lo que rompe PMTUD en IPv6. Además, las cabeceras IPv6 son más grandes, reduciendo la carga útil efectiva.

Solución: Permite los tipos ICMPv6 necesarios o clama MSS / reduce MTU más agresivamente para IPv6. No descartes ICMPv6 en bloque.

6) Síntoma: Pods de Kubernetes alcanzan servicios, pero respuestas grandes fallan

Causa raíz: Desajuste de MTU del CNI vs. MTU del nodo/túnel; el overlay añade overhead; el MTU del pod es demasiado grande; PMTUD bloqueado dentro de overlays.

Solución: Establece explícitamente el MTU del CNI para que encaje con el underlay y cualquier VPN. Luego clama MSS en el egress del nodo si es necesario.

7) Síntoma: Aplicaciones basadas en UDP fallan (VoIP bien, pero payloads UDP grandes fallan)

Causa raíz: UDP no tiene negociación MSS como TCP; datagramas sobredimensionados se fragmentan y los fragmentos se pierden/descartan; o el comportamiento DF difiere.

Solución: Reduce el tamaño de payload de la aplicación; evita datagramas UDP grandes sobre la VPN; asegura que la fragmentación no sea necesaria o se maneje con fiabilidad.

Listas de verificación / plan paso a paso

Checklist A: Cuando estás de guardia y necesitas una solución en menos de una hora

1. Confirma dependencia por tamaño. Prueba un scp/rsync/iperf3 grande; compáralo con una petición HTTP pequeña.
2. Lee los valores MTU actuales. ip -br link en ambos extremos; identifica túnel y egress.
3. Ejecuta pruebas DF ping. Búsqueda binaria de payloads para encontrar el límite.
4. Baja temporalmente el MTU del túnel. Prueba 1420 → 1380 → 1360 según necesidad.
5. Clama MSS en el borde VPN. Usa iptables/nftables para clamar al PMTU.
6. Vuelve a probar la transferencia bulk. iperf3 + scp de un archivo multi‑GB; asegura que las retransmisiones bajen.
7. Hazlo persistente. Actualiza la configuración VPN y la gestión de firewall; añade una prueba de regresión al runbook.

Checklist B: Cuando diseñas una VPN y quieres evitar el incidente por completo

1. Inventaría las capas de encapsulación. VPN + overlay + VLAN + PPPoE no es una vibra; es un presupuesto MTU.
2. Elige una MTU base conservadora. Para acceso remoto por Internet, empieza alrededor de 1420 (WireGuard) o 1400 si tienes rutas mixtas.
3. Estandariza MTU en los clientes. No dejes que los endpoints lo adivinen; proporciona una configuración.
4. Clama MSS en los límites. Especialmente donde el tráfico pasa de “dentro” a “túnel”.
5. Permite ICMP esencial. Autoriza fragmentation-needed/packet-too-big. No descartes todo ICMP porque un scanner se quejó una vez.
6. Prueba desde redes hostiles. LTE, Wi‑Fi de hoteles, PPPoE doméstico y lo que sea que use tu equipo financiero en ruta.
7. Escribe el runbook. Incluye comandos exactos, salidas esperadas y procedimientos de rollback.

Checklist C: Qué evitar (porque te arrepentirás)

• Configurar el MTU del túnel a 1500 “porque Ethernet”.
• Descartar todo ICMP/ICMPv6 sin entender PMTUD.
• Asumir que un ping exitoso significa que tu MTU es correcto.
• Apilar túneles/overlays sin calcular explícitamente el margen.
• Desplegar cambios de MTU en toda la flota sin un canario que incluya ISPs de consumo.

FAQ

1) ¿Por qué los paquetes pequeños funcionan pero los grandes se quedan colgados?

Porque los paquetes pequeños caben bajo el MTU efectivo incluso tras el overhead de la VPN. Los paquetes grandes lo exceden, se descartan o fragmentan, y PMTUD puede estar bloqueado.
TCP entonces retransmite y reduce la ventana, lo que parece un “colgado”.

2) ¿Cuál es un buen MTU por defecto para WireGuard?

1420 es un valor práctico común en underlays Ethernet con MTU 1500. Si ves síntomas de agujero negro en algunas redes, prueba 1380 o 1360.
Luego valida con pings DF y transferencias reales.

3) ¿Debo confiar en PMTUD en lugar de clamar MSS?

Si controlas todo el camino y permites los mensajes ICMP necesarios, PMTUD puede funcionar bien.
En la realidad mixta corporativa/consumo, clamar MSS suele ser la opción operacional más segura—especialmente para VPNs de acceso remoto.

4) ¿No reduce el rendimiento bajar el MTU?

Ligeramente, sí: más paquetes para los mismos datos, más overhead por paquete.
Pero el “rendimiento” que obtienes con un MTU demasiado grande es imaginario si provoca retransmisiones, fragmentación o bloqueos. La estabilidad vence a la eficiencia teórica.

5) ¿Y los jumbo frames (MTU 9000)? ¿Puedo usar un MTU mayor en el túnel?

Solo si todo el underlay lo soporta de extremo a extremo y cada capa de encapsulación está contabilizada.
Los MTU mixtos son comunes, y un salto con MTU 1500 arruinará tu día. Mide; no asumas.

6) Si clamo MSS, ¿sigo necesitando ajustar el MTU del túnel correctamente?

Clamar MSS protege flujos TCP. No hace nada por UDP ni por protocolos no TCP.
Un MTU de túnel sensato reduce el riesgo de fragmentación en general, así que normalmente quieres ambos: MTU de túnel seguro + clamp MSS.

7) ¿Por qué IPv6 es más sensible a esto?

Los routers no fragmentan paquetes IPv6. El emisor debe adaptar según ICMPv6 “Packet Too Big”.
Si ICMPv6 está filtrado, PMTUD falla con fuerza, y obtienes agujeros negros más reliably que con IPv4.

8) ¿Cuál es la diferencia entre MTU y MSS?

MTU es el tamaño máximo de paquete IP en un enlace. MSS es el tamaño máximo de carga útil TCP en un segmento.
MSS normalmente es MTU menos las cabeceras IP+TCP (y menos opciones). Clamar MSS evita que TCP genere paquetes que excedan el path MTU.

9) ¿Puedo “arreglar” esto permitiendo la fragmentación?

Puedes, pero es un intercambio: la fragmentación aumenta la sensibilidad a pérdidas (pierde un fragmento, pierdes todo el paquete), carga a los middleboxes y puede amplificar problemas de rendimiento.
Prefiere evitar la fragmentación eligiendo un MTU adecuado y clamando MSS.

10) ¿Cuál es una buena regla operativa para ICMP en firewalls?

Permite los mensajes ICMP necesarios para PMTUD (IPv4 fragmentation-needed, IPv6 packet-too-big) y la notificación de errores básica.
No descartes ICMP en bloque. Esa política es como consigues tickets de “la VPN está poseída”.

Una cita que vale la pena tener en la pared

Idea parafraseada de Werner Vogels: “Todo falla, todo el tiempo—diseña para ello.” Aplicado aquí: asume que PMTUD falla en algún punto y construye defensas (MTU/MSS) de todos modos.

Conclusión: pasos prácticos siguientes

Si los archivos grandes se quedan colgados sobre tu VPN mientras la navegación básica sigue funcionando, deja de perseguir fantasmas en la capa de aplicación.
MTU y PMTUD son los sospechosos habituales, y la solución suele ser una combinación de un MTU de túnel conservador y clamar MSS.

Siguientes pasos que puedes hacer hoy:

1. Ejecutar pruebas DF ping para encontrar el límite real de tamaño.
2. Estandarizar el MTU de túnel entre endpoints (no dejes que los clientes improvisen).
3. Clamar el TCP MSS en el límite de la VPN para no depender de PMTUD.
4. Auditar reglas de firewall: permitir ICMP/ICMPv6 esenciales.
5. Validar con una transferencia bulk real y conservar los comandos en un runbook.

Cuando el MTU está bien, la VPN se vuelve aburrida. Ese es el objetivo. Las redes aburridas mueven datos y te mantienen fuera de reuniones.