Problemas de MTU/MSS en VPN de oficina: por qué se bloquean archivos grandes (SMB/RDP) y cómo solucionarlo

El modo de falla: por qué los “archivos grandes” exponen errores de MTU/MSS

Cuando alguien dice: “La VPN se conecta pero copiar archivos grandes se cuelga”, está describiendo un problema clásico de Path MTU que parece un problema de rendimiento, un problema de firewall o un problema de almacenamiento—hasta que lo mides.

Esto es lo que suele suceder:

• Tus endpoints creen que pueden enviar paquetes hasta cierto tamaño (a menudo 1500 bytes en Ethernet).
• La VPN añade sobrecarga (encapsulado, cifrado, autenticación). Ahora la MTU efectiva dentro del túnel es menor que 1500.
• Algún dispositivo en la ruta no puede reenviar esos paquetes más grandes y trata de señalizarlo mediante ICMP “Fragmentation needed” (o el equivalente en IPv6).
• Ese mensaje ICMP se bloquea o nunca retorna (hola, “endurecimiento de seguridad”).
• TCP sigue retransmitiendo segmentos que nunca atraviesan la ruta con éxito. Los flujos pequeños sobreviven porque caben; los flujos grandes se quedan atascados porque no caben.

Esta es la definición de un agujero negro de PMTUD: Path MTU Discovery intenta hacer su trabajo, pero el canal de retroalimentación está roto.

SMB y RDP no necesariamente fallan instantáneamente. Fallan de la manera más molesta posible: funcionan parcialmente. Los primeros megabytes pueden transferirse, luego te topas con un paquete que debe ser más grande de lo que la ruta permite, y la sesión pasa de “bien” a “embrujada”.

Una regla práctica: si los paquetes pequeños funcionan pero los grandes se detienen, deja de culpar al almacenamiento, deja de culpar al DNS y empieza a probar la MTU.

Datos interesantes y contexto histórico

1. 1500 bytes se convirtió en “el valor por defecto” principalmente por Ethernet, no porque 1500 sea óptimo—simplemente conveniente y ampliamente interoperable.
2. PPPoE reduce la MTU a 1492 (8 bytes de sobrecarga), por eso “1492” es un personaje recurrente en la literatura de resolución de problemas VPN.
3. La sobrecarga de IPsec ESP no es un número fijo; depende de modo túnel vs transporte, NAT-T, cifrado, integridad, padding y alineación.
4. PMTUD data de finales de los 80/principios de los 90, creado para reducir la fragmentación y mejorar la eficiencia—buena idea, frágil frente al filtrado de ICMP.
5. “ICMP está bloqueado por seguridad” ha estado rompiendo redes durante décadas; es el equivalente operativo a poner cinta sobre las luces de advertencia del tablero.
6. IPv6 intenta hacer la fragmentación más sensata empujando la responsabilidad a los endpoints—aun así los agujeros negros de PMTUD siguen ocurriendo cuando ICMPv6 se maneja mal.
7. El MSS clamping se volvió común porque PMTUD suele fallar en el mundo real; es una solución pragmática cuando no puedes confiar en que la ruta señale la MTU correctamente.
8. Los jumbo frames (MTU 9000) hicieron los desajustes de MTU más frecuentes en entornos mixtos: geniales dentro de un centro de datos, problemáticos cuando se filtran expectativas hacia la WAN.

MTU, MSS, PMTUD: lo que importa en producción

MTU: el paquete más grande que puedes enviar por un enlace

MTU (Maximum Transmission Unit) es el tamaño máximo de paquete IP que puede atravesar una interfaz sin fragmentación en esa capa. En Ethernet, 1500 es común. Las VPN envuelven tu paquete en otro paquete. Ese envoltorio cuesta bytes.

Si tu paquete interior es de 1500 bytes y la VPN añade 60–100+ bytes de sobrecarga, el paquete exterior podría ser de 1560–1600 bytes. Si cualquier salto en la ruta solo permite 1500, algo tiene que ceder.

MSS: el mayor payload TCP por segmento

MSS (Maximum Segment Size) es el tamaño del payload TCP, excluyendo las cabeceras IP y TCP. Cuando ves MSS 1460, eso es 1500 MTU menos 20 bytes de cabecera IPv4 menos 20 bytes de cabecera TCP.

Cuando la MTU disminuye (debido a la sobrecarga de la VPN), la MSS segura también disminuye. Si no ajustas MSS y PMTUD falla, TCP intentará enviar segmentos demasiado grandes para la ruta, y obtendrás bloqueos bajo carga.

PMTUD: el bucle de retroalimentación que es fácil romper

Path MTU Discovery depende de que los routers digan a los remitentes: “Ese paquete es demasiado grande; esta es la MTU que necesitas”. En IPv4, eso es ICMP “Fragmentation needed” (tipo 3, código 4). En IPv6, es ICMPv6 “Packet Too Big”.

Bloquea esos mensajes y PMTUD se convierte en “adivinanza de Path MTU”. Si aciertas, bien; si no, TCP pierde tiempo retransmitiendo segmentos que nunca llegan.

Idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla; diseña para recuperarte rápido.” Los problemas de MTU son un ejemplo perfecto—construye para ese modo de falla en vez de esperar que la ruta sea educada.

Verdad operativa en una frase: si no puedes garantizar que PMTUD funcione de extremo a extremo, aplica MSS clamp en el borde del túnel.

Broma #1 (breve y relevante): Los errores de MTU son como las impresoras de oficina: solo se atascan cuando el CEO necesita algo en cinco minutos.

Por qué SMB y RDP son los primeros en quejarse

SMB: parlanchín, con estado y extremadamente bueno revelando pérdida de paquetes

Las copias de archivos SMB son flujos TCP de larga duración con ráfagas. También hacen un montón de charla de control sensible a latencia y retransmisiones. Cuando la MTU está mal, los segmentos de datos grandes se quedan atascados mientras mensajes de control más pequeños todavía pueden pasar. Eso produce un síntoma enloquecedor: el recurso compartido se navega, la autenticación funciona, los listados de carpetas aparecen, pero la copia de archivos se congela.

SMB3 añade opciones de cifrado y firmado que pueden cambiar tamaños de paquetes y comportamiento. Eso no es “la causa”, pero puede ser la chispa que empuje una MTU al límite de la falla.

RDP: mantendrá la sesión viva mientras tu payload se asfixia

RDP puede parecer conectado porque los keepalives y las pequeñas actualizaciones de pantalla caben. La redirección del portapapeles, el mapeo de unidades, la impresión y la copia de archivos son donde aparecen transferencias más grandes y la corriente TCP empieza a sufrir. Los usuarios lo describen como “RDP se congela”, pero a menudo es la ruta de E/S redirigida la que se queda atascada mientras los hilos de la sesión siguen cojeando.

Por qué la navegación web a menudo parece bien

El tráfico web moderno son muchas conexiones cortas, con control de congestión que se recupera rápido y mucho contenido entregado en fragmentos que puede no requerir segmentos sostenidos grandes. Además, los navegadores reintentán agresivamente y ocultan fallos tras spinners. Las copias SMB son honestas. Simplemente se detienen y te miran.

Guion para diagnóstico rápido

Este es el orden que te lleva a la verdad rápido, sin pasarte la tarde reescribiendo configuraciones VPN porque “se siente como MTU”.

Primero: confirma que el síntoma está relacionado con el tamaño, no con resolución de nombres o autenticación

• ¿Puedes listar el recurso SMB de manera fiable pero las copias de archivos grandes se estancan?
• ¿RDP se conecta al instante pero la copia de archivos por unidad redirigida se congela?
• ¿Pings pequeños funcionan pero pings grandes con DF establecido fallan?

Segundo: determina la MTU de ruta funcionando con una prueba de ping con DF

• Prueba desde el cliente al servidor (y a la inversa si es posible).
• Encuentra el payload más grande que tenga éxito sin fragmentación.
• Si ves “Frag needed” a veces, tienes suerte; si ves silencio, puede que tengas un agujero negro.

Tercero: revisa las suposiciones de sobrecarga del túnel y aplica MSS clamp en el borde

• Identifica si estás usando IPsec (ESP, NAT-T), OpenVPN (UDP/TCP), WireGuard o appliances SSL VPN.
• Establece la MTU de la interfaz del túnel adecuadamente y/o aplica MSS clamp en la puerta de enlace/firewall de la VPN.
• Vuelve a probar la copia de archivos grande y los flujos TCP de larga duración.

Cuarto: verifica el manejo de ICMP (no adivines)

• Permite los tipos ICMP requeridos a través del túnel y en los bordes WAN.
• Confirma que PMTUD funciona, o acepta que no funciona y confía en MSS clamping.

Quinto: solo entonces persigue “tunning” de rendimiento

• SMB multichannel, escalado de ventana, offloads—eso es de segundo orden una vez que la MTU es correcta.
• No optimices una ruta rota. Solo crearás una falla más rápida.

Tareas prácticas con comandos: pruébalo y luego arréglalo

A continuación hay tareas reales que puedes ejecutar. Cada una incluye: comando, salida de ejemplo, qué significa y la decisión que debes tomar.

Task 1: Identify the VPN interface and its MTU (Linux)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
eth0             UP             52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Qué significa: La interfaz de túnel (wg0) ya está en 1420, una elección común de WireGuard. Si ves 1500 en una interfaz VPN, eso es una señal de alarma en la mayoría de escenarios WAN.

Decisión: Si la MTU es 1500 en el túnel, planea reducirla o aplicar MSS clamp.

Task 2: Check route MTU hints (Linux)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 dev wg0 src 10.20.30.1 uid 1000
    cache

Qué significa: El tráfico hacia el host remoto usa wg0. Si inesperadamente usa eth0, tus reglas de split-tunnel pueden estar mal y estarás depurando la ruta equivocada.

Decisión: Confirma que realmente estás probando sobre la ruta VPN.

Task 3: Find the real path MTU using ping with DF (Linux, IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2042ms

Qué significa: Un paquete de 1500 bytes (1472 payload + 28 bytes de cabeceras) no llegó. Si obtuviste un “Frag needed” explícito, PMTUD está al menos parcialmente funcionando. El silencio puede significar un agujero negro.

Decisión: Reduce el tamaño del payload hasta que tenga éxito; registra el valor más grande que funciona.

Task 4: Binary search MTU until it works (Linux)

cr0x@server:~$ ping -M do -s 1364 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1364(1392) bytes of data.
1372 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=31.2 ms
1372 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=30.9 ms
1372 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=31.0 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 30.9/31.0/31.2/0.1 ms

Qué significa: Tu path MTU es al menos 1392 bytes para paquetes IPv4. Eso sugiere una MSS alrededor de 1352 (1392 – 40 bytes cabeceras IP+TCP), y deberías clamped por debajo de eso para estar seguro.

Decisión: Ajusta la MTU del túnel o el MSS clamp a un valor conservador (a menudo 1360–1380 MTU equivalente para la ruta interna, dependiendo de sobrecarga y variabilidad).

Task 5: Observe TCP MSS in SYN packets with tcpdump (Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp[tcpflags] & (tcp-syn) != 0' -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:10:11.123456 IP 10.20.30.10.51123 > 10.20.30.40.445: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
12:10:12.234567 IP 10.20.30.10.51124 > 10.20.30.40.3389: Flags [S], seq 987654321, win 64240, options [mss 1460,sackOK,TS val 112 ecr 0,nop,wscale 7], length 0

Qué significa: Se está anunciando MSS 1460 sobre un túnel que probablemente no puede soportar 1500 de MTU interior de extremo a extremo. Aquí es donde las transferencias grandes van a morir.

Decisión: Implementa MSS clamping en el egress/ingress de la VPN (o corrige la MTU del túnel para que los endpoints anuncien la MSS correcta).

Task 6: Clamp MSS with iptables (Linux gateway)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

Qué significa: Las nuevas conexiones TCP reenviadas saliendo por wg0 tendrán su MSS ajustada a 1360, evitando segmentos sobredimensionados incluso si PMTUD falla.

Decisión: Elige el MSS en base a la MTU medida y la sobrecarga. Errar hacia abajo ~20–40 bytes si la ruta cambia (LTE, Wi‑Fi doméstico, problemas de ISP).

Task 7: Verify MSS clamp is taking effect (Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp[tcpflags] & (tcp-syn) != 0' -c 2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:12:44.111111 IP 10.20.30.10.51200 > 10.20.30.40.445: Flags [S], seq 11111111, win 64240, options [mss 1360,sackOK,TS val 210 ecr 0,nop,wscale 7], length 0
12:12:45.222222 IP 10.20.30.10.51201 > 10.20.30.40.3389: Flags [S], seq 22222222, win 64240, options [mss 1360,sackOK,TS val 211 ecr 0,nop,wscale 7], length 0

Qué significa: El SYN ahora anuncia MSS 1360. Has sacado el drama del tamaño de paquetes de la ecuación.

Decisión: Vuelve a probar la copia SMB y la transferencia RDP. Si sigue mal, pasa al diagnóstico de pérdida/latencia.

Task 8: Check if ICMP “fragmentation needed” is being dropped (Linux firewall counters)

cr0x@server:~$ sudo iptables -L INPUT -v -n | head
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 120K  96M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  120  9600 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0            icmp type 3 code 4
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

Qué significa: Estás permitiendo explícitamente ICMP tipo 3 código 4 (frag needed). Si esos contadores están en cero mientras reproduces el problema, el mensaje puede estar bloqueado por upstream o no generarse.

Decisión: Asegura que ICMP “frag needed” y “packet too big” se permitan a través de los bordes. Si no puedes garantizarlo, mantén el MSS clamp.

Task 9: Confirm WireGuard MTU setting (Linux)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
  private key: (hidden)
  listening port: 51820

peer: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.20.30.0/24
  latest handshake: 1 minute, 2 seconds ago
  transfer: 2.31 GiB received, 3.02 GiB sent
  persistent keepalive: every 25 seconds

Qué significa: WireGuard no muestra MTU aquí; debes revisar la MTU de la interfaz vía ip link. El handshake y las transferencias confirman que el túnel está vivo; la MTU aún puede estar mal.

Decisión: Si la MTU de la interfaz es demasiado alta, bájala y mantén MSS clamp para seguridad en redes clientes mixtas.

Task 10: Set MTU on a Linux tunnel interface (WireGuard example)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380

Qué significa: Estás forzando la MTU del túnel hacia abajo. Los endpoints en general elegirán MSS más pequeñas, reduciendo la dependencia de PMTUD.

Decisión: Prefiere configurar correctamente la MTU en el túnel más el MSS clamp en el borde si atiendes clientes no gestionados.

Task 11: Inspect MTU on Windows (client-side reality check)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 ifIndex,InterfaceAlias,AddressFamily,NlMtu,InterfaceMetric"
ifIndex InterfaceAlias            AddressFamily NlMtu InterfaceMetric
------ --------------            ------------- ----- ---------------
12     Wi-Fi                      IPv4         1500  25
19     VPN - Corp                  IPv4         1500  35
12     Wi-Fi                      IPv6         1500  25
19     VPN - Corp                  IPv6         1500  35

Qué significa: Windows cree que la MTU de la interfaz VPN es 1500. Si la ruta subyacente no puede soportar eso dentro del túnel, verás bloqueos a menos que PMTUD funcione perfectamente.

Decisión: Corrige la MTU en el perfil del adaptador VPN cuando sea posible, o aplica MSS clamp en la puerta de enlace VPN para que los clientes no tengan que ser perfectos.

Task 12: Test SMB throughput and stalls from Windows without guesswork

cr0x@server:~$ powershell -NoProfile -Command "robocopy \\10.20.30.40\share C:\Temp\mtu-test bigfile.bin /J /R:1 /W:1 /NP"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------
  Started : Sunday, December 28, 2025 12:20:01
   Source : \\10.20.30.40\share\
     Dest : C:\Temp\mtu-test\

    Files : bigfile.bin

  Options : /NP /R:1 /W:1 /J

------------------------------------------------------------------------------

         1    \\10.20.30.40\share\bigfile.bin
           0%        0.0 MB         0.0 MB/s        0:00:05

Qué significa: Si esto se cuelga al 0% o se estanca en un punto consistente, probablemente tienes un problema de transporte (MTU/MSS, pérdida, inspección de firewall), no un problema de permisos de archivo. El flag /J usa I/O sin caché, reduciendo ilusiones por caching del cliente.

Decisión: Vuelve a ejecutar después del MSS clamp / cambio de MTU. Si se estabiliza inmediatamente, has probado la causa.

Task 13: Validate OpenVPN-style MSS fix on Linux client (if applicable)

cr0x@server:~$ grep -E 'mssfix|tun-mtu|fragment' -n /etc/openvpn/client.conf
41:mssfix 1360
42:tun-mtu 1400

Qué significa: OpenVPN puede forzar una fragmentación menor. Ten cuidado: fragment generalmente no es recomendable; mssfix suele ser más seguro.

Decisión: Prefiere arreglos de MSS sobre hacks de fragmentación. Si debes tocar MTU, hazlo de forma consistente en ambos extremos.

Task 14: Spot retransmits that scream “black hole” (Linux)

cr0x@server:~$ ss -ti dst 10.20.30.40 | head -n 20
ESTAB 0 0 10.20.30.10:51200 10.20.30.40:445
	 cubic wscale:7,7 rto:204 retrans:8/12 lost:0 sacked:0 unacked:1
	 bytes_sent:10485760 bytes_retrans:5242880 bytes_acked:5242880

Qué significa: Retransmisiones altas y bytes retransmitidos durante una sesión SMB son consistentes con paquetes siendo descartados. Los agujeros negros de MTU a menudo producen retransmisiones repetidas a un ritmo constante.

Decisión: Si aplicar MSS clamp reduce retransmisiones y restaura el rendimiento, consérvalo. Si no, busca pérdida, shaping o middleboxes rotos.

Tres mini-historias empresariales (anonimizadas)

1) El incidente causado por una suposición equivocada

Tenían una configuración ordenada: una pequeña sede, un puñado de sucursales y una VPN IPsec “moderna” entre sitios. El marketing del vendedor de firewalls prometía “optimización automática de ruta”, así que el equipo asumió que la MTU estaba gestionada. Nadie la midió porque “funcionaba”.

El primer gran incidente ocurrió en la mañana de nómina. Contabilidad no podía abrir hojas grandes almacenadas en un recurso SMB en la sede. Las hojas pequeñas se abrían al instante. Las grandes cargaban hasta la mitad y luego Excel se quedaba colgado el tiempo suficiente como para que la gente empezara a forzar el cierre y abrir tickets. Las sesiones RDP en el servidor terminal de finanzas permanecían conectadas pero lentas siempre que alguien copiaba archivos por unidades redirigidas.

El equipo de almacenamiento fue arrastrado porque “los archivos son lentos”. Revisaron CPU del servidor, latencia de disco y contadores SMB. Todo parecía normal. Red declaró “sin pérdida de paquetes” basado en errores de interfaz y unos pings. El equipo de VPN insistía en que el cifrado era estable porque el túnel seguía arriba.

La suposición equivocada fue simple: “Si el túnel está arriba, la MTU debe estar bien.” Una prueba de ping con DF a través del túnel falló por encima de un payload que implicaba una MTU interior alrededor de los altos 1300. Los mensajes PMTUD estaban bloqueados por un ACL upstream que alguien había copiado y pegado años atrás. Una vez que aplicaron MSS clamp en el firewall de la sucursal, el problema desapareció al instante—sin cambios en almacenamiento, sin ajuste de servidores, sin vudú de Excel.

Podrían haberse ahorrado un día midiendo el tamaño de los paquetes primero. En su lugar, celebraron tres reuniones y culparon a un servidor de archivos que solo estaba haciendo su trabajo.

2) La optimización que salió mal

Otra empresa quería “mejor rendimiento” para ingenieros remotos. Alguien activó jumbo frames dentro de un switch virtual porque el equipo SAN había obtenido buenos resultados con MTU 9000 en el centro de datos. Luego extendieron el mismo perfil de VLAN a un conjunto de VMs de terminación VPN porque “consistencia”.

Localmente, las cosas funcionaron de maravilla. El tráfico iSCSI mejoró. El tráfico este-oeste de VMs fue espectacular. Sobre la VPN, fue un desastre lento. Algunos clientes funcionaban bien, otros tenían bloqueos intermitentes. Las copias SMB sobre la VPN comenzaban rápido y luego se desplomaban. RDP se sentía como una línea de marcación siempre que alguien movía archivos.

El mecanismo del fallo no fue mágico. Fue lo peor de ambos mundos: servidores y VMs empezaron a asumir que podían enviar tramas más grandes, mientras que la WAN y los ISPs de consumidores no podían. PMTUD debería haberlos salvado, pero una regla de IDS estaba bloqueando ICMP como “ruido”. El resultado fue un agujero negro que solo aparecía con tamaños de segmento grandes. Los flujos interactivos más pequeños se mantenían mayormente bien, lo que dificultó convencer a la gestión de que era un problema de red.

La solución fue dejar de tratar “jumbo frames en todas partes” como un rasgo de personalidad. Revirtieron la MTU en las interfaces frente a la VPN a un valor sensato, habilitaron MSS clamping y permitieron explícitamente ICMP “packet too big” a través del stack de seguridad. El rendimiento se estabilizó, y el único daño duradero fue la confianza del equipo en “una MTU para gobernarlas a todas”.

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

Un equipo de TI que ejecutaba una mezcla de WireGuard para desarrolladores e IPsec para site-to-site hizo algo poco glamuroso: mantuvieron un “contrato de tamaño de paquetes” de una página. Enumeraba la MTU esperada por tipo de túnel, suposiciones de sobrecarga y los valores estándar de MSS clamp que usaban en cada borde.

Cuando añadieron un nuevo circuito ISP en una sucursal, un ingeniero junior notó que las copias SMB grandes a la sede se estaban estancando, pero solo desde esa sucursal. Antes de escalar, ejecutó la prueba DF estándar de su checklist y documentó el payload máximo que funcionaba. Era menor de lo esperado por unos 60 bytes.

Porque tenían un contrato, no debatieron si “tunear SMB” o “actualizar el servidor de archivos”. Inmediatamente revisaron el handoff del nuevo ISP y encontraron una capa de encapsulado extra introducida por el CPE del proveedor. Nadie lo había mencionado; nadie se sorprendió. Bajaron la MTU del túnel y mantuvieron consistente el MSS clamp.

Esa sucursal entró en producción según lo planeado. Nadie fuera de TI lo notó. Esto es a lo que se parece una buena operación: aburrida, repetible y silenciosamente correcta.

Estrategias de solución que realmente funcionan

Estrategia A: Configurar la MTU de la interfaz del túnel correctamente (mejor cuando controlas ambos extremos)

Si gestionas ambos endpoints VPN (site-to-site, clientes gestionados), configurar la MTU en la interfaz del túnel es limpio. Hace que los endpoints elijan tamaños de paquete más pequeños y reduce fragmentación y retransmisiones.

Qué evitar: números aleatorios de MTU copiados de foros. Mide tu ruta y elige valores con margen.

Estrategia B: Aplicar MSS clamp en el borde de la VPN (mejor cuando los clientes son desordenados)

El MSS clamping es la solución de fuerza. No requiere que cada cliente se comporte correctamente. No requiere que PMTUD tenga éxito. Simplemente fuerza a TCP a segmentar de forma conservadora.

Dónde aplicar: en la ruta de reenvío que lleva tráfico de clientes al túnel (cadena FORWARD en gateways Linux, política de firewall en appliances, o equivalente).

Qué evitar: aplicar un clamp demasiado bajo “por seguridad”. Puedes limitar el rendimiento si eliges una MSS diminuta. Conservador está bien; paranoico es costoso.

Estrategia C: Corregir el manejo de ICMP para que PMTUD funcione (mejor para la corrección, a menudo políticamente difícil)

Si puedes, permite los mensajes ICMP esenciales. No tienes que permitir todo ICMP. Tienes que permitir los tipos ICMP que hacen funcionar Internet.

Realidad operativa: los equipos de seguridad a menudo temen ICMP porque es visible y fácil de malinterpretar. Tu trabajo es explicar que PMTUD no es un lujo opcional. Es plomería.

Estrategia D: Eliminar capas de encapsulado adicionales (mejor para la cordura a largo plazo)

A veces la MTU está mal porque tienes superposiciones apiladas: GRE sobre IPsec sobre PPPoE sobre LTE, con un toque de NAT. Cada capa roba bytes y añade modos de fallo.

Qué hacer: simplifica. Si necesitas cifrado y enrutamiento, prefiere un túnel bien soportado en lugar de anidar.

Estrategia E: No lo “arregles” forzando TCP sobre TCP a menos que disfrutes el dolor

OpenVPN sobre TCP puede ocultar algunos síntomas pero introduce comportamiento de colapso bajo pérdida (retransmisiones TCP dentro de retransmisiones TCP). Puede hacer que el estancamiento parezca menos como un estancamiento y más como melaza.

Recomendación: prefiere túneles basados en UDP para transporte VPN, y luego gestiona MTU/MSS limpiamente.

Broma #2 (breve y relevante): Bloquear ICMP para “mejorar la seguridad” es como quitar la luz de aceite para evitar advertencias del motor.

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

1) Síntoma: El recurso SMB se navega, pero copiar un archivo grande se cuelga al 0% o unos pocos por ciento

Causa raíz: MSS demasiado alto; segmentos TCP grandes no pueden atravesar el túnel; la retroalimentación PMTUD está bloqueada.

Solución: aplicar MSS clamp en el gateway VPN (por ejemplo, 1360) y/o bajar la MTU del túnel; permitir ICMP frag-needed/packet-too-big.

2) Síntoma: RDP está bien hasta que la copia de archivos o transferencia del portapapeles, luego la sesión “se congela”

Causa raíz: el canal bulk de RDP choca con un agujero negro de MTU; keepalives y pequeñas actualizaciones siguen pasando.

Solución: igual que arriba; verifica MSS en SYN; vuelve a probar con una transferencia controlada de archivos.

3) Síntoma: Funciona desde algunos ISPs domésticos pero no desde otros

Causa raíz: MTU WAN variable (PPPoE, LTE, peculiaridades DOCSIS) más una suposición fija de MTU/MSS del túnel.

Solución: elige una MTU de túnel conservadora (por ejemplo, 1380–1420 según la tecnología), aplica MSS clamp y no confíes en PMTUD a través de equipos de consumidores.

4) Síntoma: Pings pequeños funcionan; pings grandes con DF fallan sin error

Causa raíz: agujero negro de PMTUD; los mensajes ICMP se descartan.

Solución: permite los tipos ICMP requeridos; si eso es una batalla política, aplica MSS clamp y sigue con tu vida.

5) Síntoma: “Bajamos la MTU y ahora todo es más lento”

Causa raíz: la MTU se bajó en exceso; la sobrecarga aumentó por segmentos demasiado pequeños; el CPU aumenta la carga.

Solución: mide la MTU máxima real y fija MTU/MSS con un margen de seguridad mínimo. No cortes a 1200 salvo que sea estrictamente necesario.

6) Síntoma: Solo SMB sobre VPN está mal; iperf parece bien

Causa raíz: prueba no representativa: iperf puede usar flujos diferentes, MSS distinto o tolerar retransmisiones de forma distinta; SMB está revelando el dolor de retransmisiones.

Solución: reproduce con ping DF y captura de paquetes; verifica MSS; prueba con un solo flujo TCP largo similar a SMB.

7) Síntoma: Los problemas comenzaron después del “endurecimiento de seguridad”

Causa raíz: filtrado de ICMP o funciones de inspección VPN interfiriendo con fragmentación/PMTUD u opciones TCP.

Solución: permite explícitamente tipos ICMP; deshabilita funciones “útiles” rotas (por ejemplo, reescritura agresiva de MSS sin entenderla).

8) Síntoma: La VPN funcionó meses y luego falla intermitentemente en horas pico

Causa raíz: cambios de ruta (nuevo camino ISP), variabilidad de MTU o un middlebox nuevo que descarta ICMP bajo carga.

Solución: aplica MSS clamp (estabilidad), luego investiga comportamiento ICMP y path MTU a lo largo del tiempo.

Listas de verificación / plan paso a paso

Paso a paso: de “SMB se cuelga” a transferencias estables

1. Elige un flujo que falle: un cliente, un servidor, un recurso compartido, un archivo grande.
2. Confirma el enrutamiento: asegúrate de que el tráfico realmente use la interfaz VPN (Linux: ip route get).
3. Ejecuta pruebas de ping con DF para encontrar el payload máximo que funcione (Linux: ping -M do -s). Documenta el resultado.
4. Captura paquetes SYN y anota la MSS anunciada (Linux: filtro tcpdump para SYN).
5. Compara MSS con la MTU medida: si MSS implica 1500 MTU pero mediste ~1392 MTU, hallaste el desajuste.
6. Implementa MSS clamping en el borde VPN para el tráfico reenviado; deja nota del valor y por qué.
7. Opcionalmente baja la MTU del túnel para que los endpoints anuncien naturalmente una MSS más segura.
8. Vuelve a probar la misma copia de archivo. No cambies tres cosas a la vez; mantenlo controlado.
9. Verifica reducción de retransmisiones (Linux: ss -ti, o estadísticas de captura de paquetes).
10. Decide si arreglar ICMP correctamente: permite los tipos ICMP requeridos o acepta MSS clamp como solución permanente.
11. Despliega en capas: pilota una sucursal, luego expande; evita cambios masivos de MTU en toda la flota.
12. Escribe un contrato de tamaño de paquetes: MTU/MSS estándar por tipo de VPN y cómo medirlo. Esta práctica aburrida salva fines de semana.

Lista de políticas: qué permitir a través de los firewalls

• IPv4: ICMP tipo 3 código 4 (“Fragmentation needed”) en las direcciones correctas.
• IPv6: ICMPv6 “Packet Too Big” y neighbor discovery relacionado (no rompas fundamentos de IPv6 mientras lo haces).
• Limitación de tasa: rate limiting razonable de ICMP está bien; drops totales no lo están.

Lista operativa: qué registrar en los tickets

• Tipo de red del cliente (Wi‑Fi doméstico, hotspot LTE, LAN de oficina).
• Tipo de VPN y encapsulado (IPsec NAT-T, WireGuard, SSL VPN).
• Payload máximo de ping DF que funciona.
• MSS observada en SYN antes y después de cambios.
• Si se ven mensajes ICMP frag-needed/packet-too-big.
• Si el problema es simétrico (cliente→servidor y servidor→cliente).

Preguntas frecuentes (FAQ)

1) ¿Por qué los archivos pequeños se copian bien pero los archivos grandes se cuelgan?

Las transferencias pequeñas suelen caber en segmentos TCP menores o completarse antes de que la conexión alcance tamaños de paquete problemáticos. Las transferencias grandes sostienen segmentos más grandes y eventualmente alcanzan el límite real de MTU de la ruta.

2) Si PMTUD existe, ¿por qué necesitamos MSS clamping?

Porque PMTUD depende de que los mensajes ICMP sobrevivan el viaje de retorno. En muchas redes corporativas y de consumidores, esos mensajes están bloqueados, limitados por tasa o dañados. El MSS clamping elimina la dependencia.

3) ¿Qué valor de MSS debo aplicar?

Usa medición. Encuentra el tamaño máximo de paquete IPv4 que funciona con ping DF (por ejemplo, 1392). Resta 40 bytes para cabeceras IP+TCP: MSS ≈ 1352. Luego elige un clamp ligeramente inferior (p. ej., 1340–1352) para tener en cuenta la variabilidad.

4) ¿Es mejor bajar la MTU del túnel que aplicar MSS clamping?

Si controlas ambos extremos del túnel y los clientes son consistentes, configurar la MTU del túnel es limpio. En entornos de clientes mixtos (redes domésticas, portátiles en roaming), el MSS clamping en la gateway es más robusto.

5) ¿Puede el cifrado o firmado de SMB causar esto?

Puedes hacer que los tamaños de paquete y el comportamiento de throughput cambien, lo que puede exponer un problema de MTU existente más rápido. Pero la raíz sigue siendo transporte: paquetes demasiado grandes para la ruta y ausencia de feedback.

6) ¿Por qué a veces falla solo en una dirección?

Las rutas asimétricas son comunes: diferentes ISPs, diferentes dispositivos NAT, diferentes reglas de filtrado. Una dirección puede permitir ICMP “packet too big” mientras la otra lo bloquea.

7) ¿Se aplica esto también a IPv6?

Sí. IPv6 depende fuertemente de ICMPv6 para PMTUD. Si bloqueas ICMPv6 “Packet Too Big”, puedes crear el mismo comportamiento de agujero negro, a menudo con aún más confusión.

8) ¿Puedo simplemente permitir fragmentación y listo?

Confiar en la fragmentación suele ser un último recurso. Aumenta la sobrecarga, incrementa la sensibilidad a la pérdida y puede interactuar mal con firewalls y NAT. Prefiere MTU correcta y MSS clamping.

9) ¿Por qué el tráfico de pruebas de velocidad parece bien mientras SMB se cuelga?

Herramientas diferentes usan patrones distintos (múltiples flujos, diferentes tamaños de segmento, UDP vs TCP). SMB es un flujo TCP largo y con estado que es excelente para exponer condiciones con muchas retransmisiones.

10) Usamos un appliance firewall todo en uno. ¿Dónde aplico MSS clamping?

En la regla de política que permite tráfico de la zona interna hacia la zona/túnel VPN, o en el egress de la interfaz VPN. Los vendedores lo nombran de forma distinta, pero el objetivo es el mismo: reescribir MSS en paquetes SYN que crucen hacia el túnel.

Conclusión: siguientes pasos que no te avergonzarán

Si la VPN de tu oficina “funciona en su mayoría” pero las copias SMB grandes se cuelgan o las transferencias de archivos por RDP se congelan, trátalo como un incidente de MTU/MSS hasta que se demuestre lo contrario. Mide la path MTU con pings DF. Observa la MSS en paquetes SYN. Aplica MSS clamping en el borde de la VPN. Luego—solo entonces—discute sobre tuning de SMB o rendimiento de almacenamiento.

Siguientes pasos que puedes hacer hoy:

1. Ejecuta una prueba de ping DF a través de la VPN y registra el payload máximo que funcione.
2. Captura un SYN y confirma qué MSS se está anunciando.
3. Implementa MSS clamping en el gateway VPN para tráfico dirigido al túnel.
4. Opcionalmente ajusta la MTU de la interfaz del túnel para que coincida con la realidad.
5. Escribe los valores MTU/MSS elegidos y la medición que los respalda. El futuro tú querrá recibos.