Analizar problemas de MTU y de fragmentación y evitarlos mediante GRE/IPsec

Los problemas de MTU y de fragmentación encabezan la lista de errores inesperados de rendimiento y accesibilidad en VPNs Site‑to‑Site y túneles GRE. Explico la palabra clave de enfoque MTU- und Fragmentierungsprobleme justo al principio, porque muchas incidencias están directamente relacionadas: MTU efectivas demasiado pequeñas debido a encabezados adicionales (GRE, IPsec/ESP, NAT‑T) provocan fragmentación o paquetes descartados, y si se bloquean los errores ICMP, la Path‑MTU‑Discovery (PMTUD) falla. Esta entrada muestra de forma práctica las causas, secuencias de comprobación con comandos claros, medidas concretas y una estrategia de retroceso segura para el funcionamiento productivo.

Problemas de MTU y fragmentación: Por qué GRE e IPsec causan problemas de MTU

Un breve resumen técnico: MTU (Maximum Transmission Unit) es el tamaño máximo de un paquete de capa 3 que un enlace puede transportar sin fragmentación. GRE (Generic Routing Encapsulation) es un protocolo de túnel que encapsula un paquete interno con un encabezado GRE adicional; el encabezado GRE básico tiene 4 Bytes, las opciones adicionales (Key, Sequence) lo amplían. IPsec/ESP (Encapsulating Security Payload) cifra y autentica datos, generando más encabezados (ESP Header, Initialization Vector, Padding, ICV/Authentication‑Tag). Además, NAT‑Traversal (NAT‑T) provoca una encapsulación UDP (encabezado UDP 8 Bytes). En conjunto, estas sobrecargas reducen de forma notable la MTU efectiva para el tráfico interno.

Componentes típicos de sobrecarga

• Encabezado IP externo (IPv4: 20 Bytes, IPv6: 40 Bytes)
• UDP (opcional con NAT‑T): 8 Bytes
• ESP Header + Sequence: 8 Bytes (SPI 4 + Seq 4) + IV (p. ej. 16 Bytes con AES) + ICV (p. ej. 12–16 Bytes) + Padding
• Encabezado GRE básico: 4 Bytes (más, si procede, 4 Bytes Key, 4 Bytes Seq)

Dado que el tamaño exacto varía según el mecanismo de cifrado (p. ej. AES‑GCM vs. AES‑CBC + HMAC), el cálculo general ofrece solo orientación. En la práctica, en GRE sobre IPsec con NAT‑T pueden sumarse fácilmente 60–100 Bytes adicionales — suficiente para que una carga útil de 1500 Bytes se fragmente en varios fragmentos.

Por qué PMTUD falla y qué riesgos conlleva

Path‑MTU‑Discovery (PMTUD) es un mecanismo por el que un host intenta determinar el tamaño máximo de paquete utilizable a lo largo de un camino. Los routers que ven un paquete demasiado grande y que impiden la fragmentación (DF‑Bit = Don’t Fragment) envían un ICMP Type 3 Code 4 (Fragmentation Needed). En la práctica surgen con frecuencia dos problemas:

• ICMP es bloqueado por cortafuegos o filtros, de modo que el mensaje Fragmentation‑Needed nunca alcanza al emisor y la conexión queda efectivamente colgada. Esto es especialmente habitual en túneles IPsec, porque las respuestas ICMP no siempre se reencaminan correctamente hacia la dirección interior.
• La encapsulación cambia las direcciones o puertos de origen/destino (por ejemplo en NAT‑T), de modo que los mensajes ICMP no pueden asociarse de forma útil.

El resultado: las conexiones TCP se atascan durante el establecimiento (frecuente en TLS/HTTPS), el streaming UDP se interrumpe o los paquetes se fragmentan, incrementando la carga de CPU y la pérdida de paquetes.

Detección: ¿Qué comprobaciones deben incluirse en el diagnóstico inicial?

Empiece de forma sistemática y documente cada paso. El objetivo es localizar el punto en el que la MTU efectiva se reduce o en el que se suprimen los errores ICMP.

1) Comprobar las MTU configuradas

Verifique la MTU en todas las interfaces implicadas: físicas, túneles e interfaces virtuales.

ip link show dev eth0
ip link show dev gre1   # Ejemplo de interfaz GRE
ip -4 route get 10.0.0.1   # muestra, entre otras cosas, información de MTU

2) Prueba PMTUD con ping

Con la bandera DF (Don’t Fragment) compruebe cuál es el tamaño máximo permitido para un paquete sin fragmentar. El tamaño correcto de la carga útil para IPv4 suele ser MTU menos 28 bytes (IP + ICMP Header).

# Ejemplo: probar una carga útil de 1472 bytes da 1500 en total (IPv4: 20 + ICMP: 8)
ping -M do -s 1472 
# reducir lentamente hasta que el ping tenga éxito

Si el ping falla pero valores menores funcionan, ha encontrado el límite. Si no logra un ping con MTU alta a pesar de que la capacidad del camino parece suficiente, normalmente faltan los ICMP Fragmentation Needed.

3) Captura de fragmentación con tcpdump

Los paquetes IPv4 fragmentados se pueden capturar con un filtro BPF sencillo. Así encontrará paquetes ya fragmentados en el tráfico en vivo:

tcpdump -n -i eth0 'ip[6:2] & 0x1fff != 0'
# Opcional: solo paquetes hacia/desde una IP concreta
tcpdump -n -i eth0 'host 10.0.0.1 and ip[6:2] & 0x1fff != 0'

Explicación: en el encabezado IPv4 las banderas y el offset de fragmento están en los bytes 6–7; la máscara 0x1fff comprueba un offset > 0 (no primer fragmento).

4) Comprobar si vuelve ICMP Fragmentation

Si PMTUD falla, debe ejecutar tcpdump en ambos extremos y buscar ICMP Type 3 Code 4:

tcpdump -n -i eth0 icmp and 'icmp[0]=3 and icmp[1]=4'
# o, en general, buscar ICMP de mensajes de error
tcpdump -n -i eth0 icmp

Si no se observa „ICMP Fragmentation Needed“, pero se produce fragmentación, hay una alta probabilidad de que un cortafuegos esté bloqueando ICMP o de que los mensajes ICMP no se enruten correctamente de retorno.

Contramedidas concretas: ¿Qué ayuda de inmediato y de forma duradera?

Existen varias estrategias probadas para evitar problemas de MTU y fragmentación. Elija una combinación adecuada a su infraestructura y documente los cambios.

Opción A: Reducir la MTU del túnel (rápido, seguro)

Configure la MTU en la interfaz del túnel teniendo en cuenta la encapsulación adicional. Es fiable y seguro, pero reduce el tamaño útil de la carga (payload).

# Beispiel Linux GRE-Interface auf 1400 setzen
ip link set dev gre1 mtu 1400
# Beispiel für IPsec-Tunnel (veth/ifname) analog

Por qué funciona: Al reducir el tamaño de fragmentación de envío evita por completo la fragmentación. Cuándo falla: Si las aplicaciones envían datagramas UDP muy grandes (p. ej. transmisiones de vídeo), el límite será perceptible.

Opción B: MSS‑Clamping para TCP (recomendado para Web/SSH/SMB)

MSS (Maximum Segment Size) es la mayor cantidad de datos TCP en un segmento. Muchos stacks TCP respetan el MSS durante el establecimiento de la conexión; mediante clamping los NAT/routers ajustan el MSS en paquetes SYN.

# Beispiel iptables für MSS-Clamping (Linux-Router/Firewall)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Por qué funciona: Las nuevas conexiones TCP negocian segmentos más pequeños y evitan la fragmentación sin cambiar la MTU en los hosts finales. Cuándo falla: El tráfico UDP no se ve afectado; las conexiones TCP que sobrescriban el MSS pueden seguir causando problemas.

Opción C: Planificar conscientemente NAT‑T / encapsulación UDP

Si IPsec utiliza NAT‑Traversal (UDP/4500) se añaden 8 bytes adicionales del encabezado UDP. Incluya esto en la MTU del túnel o evite la encapsulación UDP si no se requiere función NAT.

Opción D: Aumentar la robustez de PMTUD

Asegúrese de que todos los cortafuegos permitan ICMP Type 3 Code 4 (Fragmentation Needed). Si esto no es posible, utilice una combinación de reducción de MTU del túnel y MSS‑Clamping.

GRE sobre IPsec: consideraciones especiales

GRE se utiliza a menudo cuando, además de IPv4, se deben transportar otros protocolos (p. ej. multicast, IPv6 dentro de IPv4) a través de la VPN. Sin embargo, en combinación con IPsec aumentan los riesgos relativos a la MTU:

• GRE añade encabezado adicional (mín. 4 bytes), a menudo más si hay opciones.
• IPsec en modo túnel encapsula adicionalmente; si hay NAT entre los extremos, se suma UDP‑NAT‑T.
• El ICMP interno puede verse afectado por IPsec/capas externas, lo que dificulta PMTUD.

Recomendación: Calcule la suma efectiva de overhead y reduzca la MTU del túnel de forma conservadora. Cálculo de ejemplo para IPv4 con NAT‑T, GRE y AES‑GCM (representación simplificada):

physische MTU: 1500
- äußeres IPv4-Header: 20
- UDP (NAT-T): 8
- ESP-Overhead (IV + ICV + ESP Header): z.B. 28
- GRE-Header: 4
= effektive MTU für innere Pakete: 1500 - 60 = 1440

Configure la MTU del túnel, por ejemplo, en 1400 para disponer de margen para padding/variaciones.

Lista de comprobación práctica: Procedimiento paso a paso

1. Documente la ruta y los dispositivos implicados (MTUs físicas, cortafuegos, NATs).
2. Realice pruebas PMTUD con ping usando la bandera DF y anote los tamaños máximos de payload.
3. Inicie tcpdump en ambos extremos del túnel y busque paquetes fragmentados y ICMP Type 3 Code 4.

Ejemplos concretos de resolución de problemas

Síntoma: las páginas web no cargan, SSH no se conecta a través del túnel

Procedimiento:

1. Comprobar ping con DF: si no se permiten ICMP grandes, probablemente exista un problema de PMTUD.
2. Revisar tcpdump en el extremo del túnel: ¿paquetes fragmentados o ICMP ausente?
3. Configurar MSS‑Clamping y probar; si funciona, el problema de TCP queda resuelto. Si no, reducir la MTU del túnel.

Síntoma: la transmisión UDP se interrumpe en ciertos streams

UDP no se ve afectado por MSS‑Clamping. Verifique la MTU del túnel, redúzcala y compruebe si el problema desaparece. Si la aplicación envía datagramas muy grandes, puede ser necesario ajustar su configuración para que emplee datagramas UDP más pequeños.

Estrategia de rollback y seguridad

Los cambios en MTU y en las reglas de firewall deben ser reversibles y realizarse en ventanas de mantenimiento coordinadas. Recomendaciones:

• Antes del cambio: copia de seguridad de la configuración y un plan de pruebas claro con puntos de medición (latencia, pérdida de paquetes, CPU).
• Aplicar cambios de forma incremental, primero en un segmento de prueba o en horarios de baja carga.
• Activar monitorización automática (SNMP/Netflow/IPS‑Alarmas) para detectar regresiones de inmediato.
• Fallback: restaurar las reglas MTU/MSS anteriores y comunicarlo de forma documentada a los equipos afectados.

¿Cuándo tiene sentido un cambio de arquitectura?

Si de forma recurrente tiene sobrecarga elevada por IPsec/GRE/NAT y numerosos problemas con aplicaciones UDP o multicast, debe evaluar si reducir la encapsulación de túneles (p. ej., solo IPsec para proteger subredes individuales en lugar de GRE para multicast) o emplear alternativas VPN nativas (p. ej., VXLAN con IPsec, soluciones SD‑WAN modernas) reduce a largo plazo el esfuerzo operativo. Sin embargo, estos cambios deben tratarse como proyectos que incluyan fases de prueba y planes de migración.

Resumen y guía de acción concreta

Los problemas de MTU y fragmentación son, en escenarios VPN con GRE e IPsec, una causa recurrente de desconexiones inexplicables y de degradación de rendimiento. El orden pragmático en un entorno productivo es:

1. Diagnosticar (comprobaciones de MTU, ping con DF, tcpdump sobre fragmentos e ICMP).
2. Medidas rápidas (MSS‑Clamping para TCP, reducción temporal de MTU del túnel).
3. Configuración permanente (MTU en el túnel, reglas de firewall para ICMP, plan de despliegue documentado).

Si sigue estos pasos de manera sistemática, la mayoría de los problemas puede resolverse sin cambios arquitectónicos profundos. Solo cuando la fragmentación y el bloqueo de ICMP se producen de forma habitual y afectan a servicios críticos, se recomienda una re‑arquitectura.

Snippets prácticos: comandos importantes de un vistazo

Comprobar MTU, establecer MTU del túnel, MSS‑Clamping, filtros tcpdump:

# Mostrar MTU
ip link show dev eth0
ip link show dev gre1

# Establecer MTU del túnel
ip link set dev gre1 mtu 1400

# MSS-Clamping (Linux Firewall/enrutador)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Encontrar paquetes fragmentados
tcpdump -n -i eth0 'ip[6:2] & 0x1fff != 0'

# Buscar ICMP Fragmentation Needed
tcpdump -n -i eth0 icmp and 'icmp[0]=3 and icmp[1]=4'

# Ping PMTUD (IPv4)
ping -M do -s 1472 

Enlaces adicionales y pautas de enlace interno

Para una resolución de problemas más profunda, resultan útiles artículos sobre resolución de problemas de IPsec con tcpdump/registros IKE, verificación de reglas de firewall y líneas base de monitorización. Planifique enlaces a sus runbooks internos: análisis de registros IKE, reglas ICMP del firewall, paneles de monitorización para fragmentación y alertas por picos de CPU.

Conclusión

Los problemas de MTU y fragmentación son evitables si planifica conscientemente los overheads del encapsulamiento, mantiene intactas las rutas de señalización PMTUD o, como alternativa, emplea MSS‑Clamping y una MTU de túnel conservadora. Pruebas conservadoras, mediciones reproducibles con tcpdump y ping, así como cambios desplegables, son la base de una operación estable. GRE sobre IPsec ofrece funcionalidad, pero exige una planificación disciplinada de la MTU; de lo contrario, lo pagará con pérdida de paquetes, latencia y mayores costes operativos.

Los túneles GRE también son importantes para este tema. El artículo sitúa estos aspectos de forma comprensible y muestra en qué conviene centrarse en la operativa diaria.