VPN más lenta de lo esperado: diagnostica CPU, criptografía y MSS como si importara

enero 7, 2026 • febrero 3, 2026 • Lectura: 28 min • Views: 15

¿Te fue útil?

Tu enlace VPN está “arriba”, el ping pinta bien y, sin embargo, las copias de archivos avanzan como si fuera 2003 y alguien levantó el auricular del teléfono.
Bienvenido al modo de fallo más común en producción: no está “caído”, sino vergonzosamente más lento que la línea por la que pagas.

La solución rara vez es mística. Suele ser un cuello de botella que puedes medir: CPU del router al límite por la criptografía, un demonio mono‑hilo,
discovery de MTU (PMTUD) bloqueado, o clamping de MSS hecho “casi bien” (el peor tipo de bien).
Así es como lo diagnosticamos sin aplicar configuraciones por imitación hasta que “parezca mejor”.

Guion de diagnóstico rápido (primeros 10 minutos)

Esta es la secuencia que encuentra el cuello de botella rápidamente. La meta no es “recopilar datos”. La meta es tomar una decisión después de cada paso:
¿CPU limitada? ¿MTU limitado? ¿pérdida/bufferbloat? ¿shaping? ¿mono‑hilo? ¿offload deshabilitado? Avanza solo cuando puedas decir “no es eso”.

1) Prueba si el túnel está limitado por los endpoints o por la ruta

Ejecuta iperf3 a través de la VPN en ambos sentidos. Usa múltiples streams paralelos (1 y 4).
Si 1 stream es lento pero 4 streams son mucho más rápidos, tienes un problema de TCP/congestión/MTU/pérdida, no un tope de enlace puro.
Compara con una prueba de iperf fuera de la VPN (si es posible). Si la velocidad WAN está bien pero la VPN no, es sobrecarga del túnel o cómputo en los endpoints.

2) Revisa la CPU del router (y específicamente la ruta de criptografía)

Busca un solo core al 100% (clásico en OpenVPN) o alto softirq / ksoftirqd (procesamiento de paquetes).
Confirma si la criptografía/acceleración hardware está activa. A menudo se desactiva cuando se habilita NAT, enrutamiento por políticas o una función “útil”.

3) Revisa MTU/PMTUD/MSS antes de “tunear TCP”

Haz una búsqueda binaria con ping DF (don’t fragment). Encuentra el MTU real de la ruta a través del túnel.
Si ICMP frag-needed está bloqueado en algún punto, PMTUD se rompe y TCP se queda atascado o retransmite. El clamping de MSS puede enmascararlo, pero solo si está configurado correctamente.

4) Mide pérdida, reordenamiento y bufferbloat

Usa mtr y el modo UDP de iperf3 con cuidado. Si ves pérdida bajo carga, arregla el encolamiento/shaping, no la encriptación.

5) Solo entonces: persigue detalles de configuración (ciphers, modo de túnel, fragmentación)

No empieces cambiando AES-256 por ChaCha20 “porque Reddit”. Si la CPU está ociosa y el MTU es correcto, la elección de cipher no es tu cuello de botella.

Un modelo mental que evita conjeturas tontas

El rendimiento de la VPN es el producto de tres sistemas separados que tienden a fallar de forma independiente:

Cómputo: ¿puede tu endpoint encriptar/descifrar paquetes a la velocidad de la línea? Esto incluye CPU, aceleración crypto, kernel vs userspace,
y si has forzado accidentalmente todos los paquetes por la ruta lenta.
Tamaño de paquetes: La encapsulación añade overhead. Si tu MTU efectivo es incorrecto, obtienes fragmentación, drops y comportamiento TCP extraño.
PMTUD debería manejar esto, hasta que alguien bloquee ICMP por “seguridad”.
Dinámica de transporte: El throughput TCP depende del RTT, la pérdida y el encolamiento. Las VPN suelen aumentar ligeramente RTT
y pueden amplificar el bufferbloat, lo que mata el throughput mucho antes de saturar el enlace.

La trampa: los ingenieros tratan la “VPN” como una sola perilla. No es una sola perilla. Es una tubería. Tu trabajo es encontrar qué etapa limita,
luego arreglar esa etapa sin romper las demás.

Una cita para pegar en un post‑it, porque aplica aquí con fuerza:
“La esperanza no es una estrategia.” — Gordon R. Sullivan

Hechos interesantes y breve historia (porque explica lo raro)

IPsec antecede la “ansiedad de internet moderna”. Los RFCs tempranos de IPsec son de mediados de los 90; se diseñó para asegurar IP
mucho antes de que “zero trust” fuera una diapositiva de presentación.
La arquitectura por defecto de OpenVPN es históricamente hostil a la CPU. OpenVPN clásico corre en userspace y (comúnmente) empuja la mayor parte del tráfico por
un único hilo, por eso un core ocupado puede limitar el throughput aun con ocho cores ociosos.
WireGuard es deliberadamente pequeño. Su base de código es famosa por ser compacta comparada con stacks VPN típicos, reduciendo superficie de ataque y muchas veces mejorando
rendimiento vía integración en el kernel y elecciones de crypto modernas.
PMTUD fue pensado para eliminar la fragmentación. Path MTU discovery (concepto de finales de los 80, implementado ampliamente más tarde) depende del feedback ICMP.
Bloquea ICMP y vuelves a los “stalls misteriosos”.
El clamping de MSS es un workaround viejo que no se muere. Se usa desde hace décadas para evitar fragmentación cuando PMTUD falla,
especialmente sobre PPPoE y túneles.
AES‑NI cambió la economía de las VPN. Cuando CPUs x86 comunes obtuvieron aceleración AES, “la criptografía es lenta” dejó de ser verdad universal.
En routers pequeños y SoC ARM sigue siendo muy relevante.
GCM vs CBC no es solo académico. Modos AEAD como AES‑GCM pueden ser más rápidos y seguros en implementaciones modernas, pero solo si el hardware y drivers
los manejan bien; de lo contrario puedes acabar más lento de lo esperado.
El overhead de la encapsulación no es física negociable. Pagas bytes por cabeceras, tags de autenticación y a veces por wrapping UDP.
Eso reduce la eficiencia de payload y puede empujarte sobre los límites de MTU.

Broma #1: El troubleshooting de VPN es como la arqueología: quitas capas de “arreglos temporales” hasta encontrar un MTU fosilizado de 2014.

Síntomas que importan (y los que confunden)

Síntomas que realmente acotan la búsqueda

Throughput se topa en un número sospechoso (como 80–200 Mbps) independientemente de la velocidad WAN: a menudo CPU/crypto o límites de un solo hilo.
Un sentido rápido, el otro lento: enrutamiento asimétrico, shaping asimétrico o CPU pegada solo en un extremo.
Transferencias pequeñas “se sienten bien”, grandes se arrastran: problemas MTU/PMTUD o bufferbloat bajo carga sostenida.
Varios streams TCP superan ampliamente a uno solo: pérdida de paquetes, reordenamiento o comportamiento de agujero negro de MTU; el enlace bruto probablemente está bien.
El tráfico UDP va bien; TCP es nefasto: señal clásica de pérdida/encolamiento/MTU más que de ancho de banda crudo.

Síntomas que te hacen perder el tiempo si te obsesionas con ellos

Ping parece genial: ping usa paquetes diminutos; tu problema suele estar en paquetes grandes bajo carga.
Promedio de CPU bajo: que un core esté saturado importa; los promedios mienten.
“Empeoró después de activar la función X de seguridad”: puede ser, pero mide. La correlación es una droga que limita carreras.

CPU del router y límites de criptografía: el asesino silencioso del rendimiento

Muchos casos de “VPN lenta” son simplemente “tu router está haciendo matemáticas caras a una tasa que no puede sostener”.
Esas matemáticas pueden ser cifrado, autenticación, encapsulación, checksums o simplemente mover paquetes entre interfaces.

Patrones de cuello de botella de CPU que puedes reconocer rápido

En routers commodity, el throughput VPN con frecuencia está limitado por:

Criptografía mono‑hilo (común en OpenVPN): un core llega al 100%, el throughput se estabiliza y no puedes “optimizar” salvo cambiando arquitectura (DCO, modo kernel, otro protocolo) o hardware.
Overhead de procesamiento de paquetes en kernel: softirq alto, actividad de ksoftirqd, muchos paquetes pequeños (ACKs), NAT, conntrack y reglas de firewall.
Aceleración crypto no usada: compraste un equipo con aceleración, pero la ruta del tráfico no la atraviesa.
O el cipher/setting elegido la evita.

Crypto no es solo “AES vs ChaCha”; es todo el datapath

A la gente le encantan los debates de ciphers porque se siente como tunear un coche de carreras. Pero la mayoría de los problemas de rendimiento son más parecidos a “las llantas están desinfladas”.
Haz las preguntas poco glamurosas:

¿La VPN corre en kernel o userspace?
¿Es transporte UDP o TCP?
¿Está activo el offload hardware de extremo a extremo?
¿Al habilitar NAT o routing por políticas se desactivó el fast‑path?
¿Hacen deep packet inspection o logging excesivo sobre flujos encriptados?

El diagnóstico clave: si aumentar streams paralelos incrementa el throughput dramáticamente, no estás puramente limitado por CPU/crypto.
Si el throughput se estanca en el mismo número sin importar streams y tamaño de paquete, probablemente sí lo estás.

MTU, PMTUD y MSS clamping: donde “funciona” se vuelve “lento”

Las VPN añaden cabeceras. Las cabeceras consumen MTU. Si ignoras eso, obtienes fragmentación o drops. Si PMTUD está roto, ni siquiera tienes una falla clara.
Obtienes timeouts, retransmisiones y throughput que parece generado por un RNG.

Overhead de encapsulación: las cuentas que realmente necesitas

Empieza simple: el MTU de Ethernet suele ser 1500 bytes. Un paquete VPN tiene que caber dentro.
Si añades (por ejemplo) IP + UDP + cabecera VPN + tag de auth, reduces la carga útil.

El overhead exacto varía por protocolo y ajustes. No adivines. Mide el MTU efectivo real a través del túnel.

PMTUD black hole: la clásica trampa de “endurecimiento”

PMTUD depende de mensajes ICMP “Fragmentation Needed”. Si los bloqueas, TCP sigue enviando paquetes demasiado grandes con DF activado, que se descartan silenciosamente.
TCP entonces se echa atrás, retransmite y se arrastra.

El clamping de MSS es una solución: si reduces el MSS TCP para que los endpoints nunca envíen paquetes que requieran fragmentación, evitas PMTUD.
Pero debes clamar en la interfaz correcta, en la dirección correcta y para el tráfico correcto.

Por qué el clamping de MSS a veces “ayuda un poco” pero no lo arregla

Clampaste MSS en la interfaz WAN en vez de la interfaz de túnel (o viceversa).
Clampaste solo tráfico reenviado pero no el generado localmente (o al revés).
Clampaste a un valor que aún es demasiado alto para el MTU encapsulado real.
Clampaste TCP, pero tu tráfico problemático es UDP (algunas apps) o tienes IPsec con problemas de fragmentación ESP.

Broma #2: El clamping de MSS es como recortar tu flequillo con una motosierra: puede funcionar, pero no te gustará el proceso ni los bordes.

Comportamiento de TCP sobre VPN: por qué latencia y pérdida multiplican el dolor

El throughput TCP no es “ancho de banda”. Es ancho de banda limitado por el control de congestión y el producto ancho de banda‑retardo.
Las VPN suelen añadir un poco de latencia. También suelen añadir encolamiento (especialmente si el router acumula demasiada cola).
Una pequeña cantidad de pérdida bajo carga puede reducir el throughput dramáticamente.

Lo que significa realmente “varios streams más rápidos que uno”

Cuando un flujo TCP es lento pero cuatro en paralelo saturan el enlace, estás viendo una o más de:

eventos de pérdida que colapsan la ventana de congestión de un flujo
bufferbloat causando alta variación de RTT y ACKs retardados
retransmisiones por problemas de MTU/fragmentación
shaping/policing por flujo en algún middlebox

No “arregles” esto diciendo a los usuarios que usen más paralelismo. Así conviertes tu red en un experimento de encolamiento.
Arregla el problema subyacente: corrección de MTU, gestión de colas (fq_codel/cake), shaping correcto en el borde, o un datapath VPN mejor.

VPN sobre TCP suele ser dolor auto‑infligido

Ejecutar un túnel VPN sobre TCP, y luego TCP dentro de él, crea el colapso TCP‑sobre‑TCP: retransmisiones y control de congestión pelean entre sí.
Si puedes usar transporte UDP para el túnel, hazlo. Si no puedes, espera “funciona pero extraño y lento cuando hay pérdida”.

Offload hardware, NAT y por qué la aceleración a veces desaparece

Muchos routers anuncian “VPN gigabit”. Luego activas NAT, QoS, IDS, tagging VLAN, routing por políticas, o solo un cipher distinto, y de pronto estás a 120 Mbps.
La pieza faltante suele ser fast‑path/offload. La aceleración hardware es exigente; muchas veces requiere una ruta de tráfico muy específica.

Maneras comunes de deshabilitar offload sin querer

NAT en la interfaz encriptada cuando el motor de offload espera solo reenvío por ruta.
Reglas de firewall que requieren inspección profunda en el datapath (o loguear cada paquete por “auditoría”).
Routing por políticas que saca paquetes de la tubería acelerada.
Uso de un cipher/modo no soportado por el motor hardware.
Manejo de fragmentación en software debido a mismatch de MTU.

No tienes que adorar el offload. Pero necesitas saber si está activo. Si no, estás afinando el motor equivocado.

Tareas prácticas (comandos, salidas, decisiones) — haz esto, no intuiciones

Abajo hay tareas concretas. Cada una incluye comandos, salida de ejemplo, qué significa y la decisión que tomas a partir de ello.
Ejecútalas en endpoints VPN (routers, gateways Linux o servidores) y en un cliente si hace falta.

Task 1: Measure raw throughput with iperf3 (1 stream vs 4 streams)

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

cr0x@server:~$ iperf3 -c 10.20.0.10 -P 1 -t 15
Connecting to host 10.20.0.10, port 5201
[  5]   0.00-15.00  sec   145 MBytes  81.0 Mbits/sec  0             sender
[  5]   0.00-15.01  sec   143 MBytes  79.8 Mbits/sec                receiver

cr0x@server:~$ iperf3 -c 10.20.0.10 -P 4 -t 15
Connecting to host 10.20.0.10, port 5201
[SUM]   0.00-15.00  sec   580 MBytes   324 Mbits/sec  12             sender
[SUM]   0.00-15.01  sec   575 MBytes   321 Mbits/sec                receiver

Significado: Un stream da 80 Mbps, cuatro streams alcanzan 320 Mbps. La ruta puede mover datos, pero TCP de flujo único está sufriendo.
Decisión: Prioriza diagnósticos MTU/PMTUD, pérdida y encolamiento. No compres hardware aún.

Task 2: Check CPU saturation and per-core hotspots (Linux)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (gw-a)  12/28/2025  _x86_64_  (8 CPU)

12:10:01 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal %idle
12:10:02 AM  all    6.2  0.0   9.8    0.0    0.0  4.1     0.0  79.9
12:10:02 AM    0    2.0  0.0   6.0    0.0    0.0  1.0     0.0  91.0
12:10:02 AM    1   38.0  0.0  55.0    0.0    0.0  7.0     0.0   0.0
12:10:02 AM    2    1.0  0.0   2.0    0.0    0.0  0.0     0.0  97.0

Significado: CPU1 está pegada (0% idle) mientras otras están mayormente ociosas. Eso indica “cuello de botella mono‑hilo” o una sola cola IRQ.
Decisión: Si es OpenVPN, prueba DCO o un protocolo distinto. Si es IRQ, considera tuneos RSS/RPS/XPS y ajustes de colas de la NIC.

Task 3: Identify the VPN process and whether it’s the hot spot

cr0x@server:~$ top -H -b -n 1 | head -30
top - 00:10:12 up 12 days,  3:44,  1 user,  load average: 1.12, 0.98, 0.91
Threads: 274 total,   2 running, 272 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.3 us, 10.4 sy,  0.0 ni, 44.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8421 root      20   0  164796  23452  10652 R  99.3   0.6  12:33.14 openvpn
 8428 root      20   0  164796  23452  10652 R  98.7   0.6  12:30.09 openvpn

Significado: Los hilos de OpenVPN consumen CPU. Aunque haya dos hilos, la ruta de datos puede seguir limitada por cómo se manejan los paquetes.
Decisión: Valida el modo de OpenVPN (userspace vs DCO), considera migrar a WireGuard o IPsec con aceleración en kernel si procede.

Task 4: Check whether AES acceleration is available (x86 AES-NI)

cr0x@server:~$ grep -m1 -o 'aes\|avx\|sha_ni' /proc/cpuinfo | sort -u
aes
avx

Significado: La CPU soporta instrucciones AES. Eso no garantiza que tu VPN las use, pero hace plausible alto throughput.
Decisión: Si el throughput sigue bajo y CPU alta, sospecha ruta de código no acelerada, overhead en userspace o offload deshabilitado.

Task 5: Confirm WireGuard handshake and per-peer transfer rates

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

peer: 9q3B...redacted...
  endpoint: 198.51.100.20:49012
  allowed ips: 10.20.0.0/24
  latest handshake: 38 seconds ago
  transfer: 21.14 GiB received, 18.02 GiB sent
  persistent keepalive: every 25 seconds

Significado: El túnel está vivo. Los contadores de transferencia se mueven. Si el rendimiento es malo, deja de culpar la “inestabilidad del handshake”.
Decisión: Pasa a pruebas MTU/encolamiento y perfilado de CPU; WireGuard rara vez es el cuello de botella a menos que la caja sea poco potente.

Task 6: Inspect IPsec state and whether it’s rekeying too often

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
	proto esp spi 0x0000000b reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x... 128
	anti-replay context: seq 0x0007a12f, oseq 0x0, bitmap 0x00000000
	lifetime config:
	  limit: soft (INF) hard (INF)
	lifetime current:
	  12345(s) 0(bytes)
	stats:
	  replay-window 0 replay 0 failed 0
	  bytes 9823141234 packets 912341 errors 0

Significado: IPsec es estable (sin errores, contadores en aumento). El churn por rekeying mostraría cambios repetidos de SA y a veces breves stalls.
Decisión: Si la CPU está alta aquí, busca aceleración hardware faltante o overhead por paquetes pequeños; si no, sigue a MTU/PMTUD.

Task 7: Find the effective MTU through the tunnel with DF pings (binary search)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 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

--- 10.20.0.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

cr0x@server:~$ ping -M do -s 1392 -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 1392(1420) bytes of data.
1400 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=18.6 ms
1400 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=18.7 ms
1400 bytes from 10.20.0.10: icmp_seq=3 ttl=64 time=18.5 ms

--- 10.20.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Significado: Has descubierto una restricción real de MTU (1420). Si la interfaz del túnel está configurada más alta, es probable fragmentación o drops.
Decisión: Ajusta el MTU del túnel adecuadamente y/o aplica clamping de MSS. También verifica que ICMP frag‑needed no esté bloqueado en la ruta.

Task 8: Check current interface MTU settings

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

Significado: wg0 MTU coincide con el límite descubierto. Bien.
Decisión: Si encontraste un MTU de ruta más bajo que la MTU de la interfaz, bájala; no “dejes que fragmente y esperes”.

Task 9: Verify MSS clamping rules (iptables) and confirm packet counters increment

cr0x@server:~$ sudo iptables -t mangle -S | grep -E 'TCPMSS|MSS'
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

cr0x@server:~$ sudo iptables -t mangle -L FORWARD -v -n | grep TCPMSS
  842K   52M TCP  --  *  wg0  0.0.0.0/0  0.0.0.0/0  tcp flags:0x02/0x02 TCPMSS clamp to PMTU
  799K   49M TCP  --  wg0 *   0.0.0.0/0  0.0.0.0/0  tcp flags:0x02/0x02 TCPMSS clamp to PMTU

Significado: El clamping de MSS se aplica en ambas direcciones y los contadores aumentan. Eso es lo que quieres cuando PMTUD es poco fiable.
Decisión: Si los contadores son cero, clampaste en la cadena/interfaz equivocada; corrige la ubicación. Si PMTUD funciona, el clamping puede ser opcional.

Task 10: Confirm ICMP “fragmentation needed” isn’t being dropped (nftables example)

cr0x@server:~$ sudo nft list ruleset | grep -n 'icmp type'
42:    ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded } accept

Significado: “destination-unreachable” incluye frag‑needed en muchas configuraciones; bloquearlo es cómo se manufacturan agujeros PMTUD.
Decisión: Si tu ruleset solo permite echo-request/echo-reply, amplíalo. Los equipos de seguridad pueden registrarlo; no deberían descartarlo.

Task 11: Look for fragmentation and reassembly signals in interface counters

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped overrun mcast
    9812312312 81231231 0       1234    0       0
    TX:  bytes  packets  errors  dropped carrier collsns
    8712312312 70123123 0       9876    0       0

Significado: Paquetes descartados bajo carga (TX dropped, RX dropped) correlacionan fuertemente con presión de buffer, errores de shaping o problemas de MTU.
Decisión: Si los drops suben durante pruebas iperf, arregla colas/shaping. Si los drops ocurren solo en paquetes grandes, revisa MTU/MSS.

Task 12: Check for retransmits and TCP pain (ss -i)

cr0x@server:~$ ss -ti dst 10.20.0.10 | head -20
ESTAB 0 0 10.10.0.5:46732 10.20.0.10:445
	 cubic wscale:7,7 rto:220 rtt:48.3/12.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:18 bytes_acked:8123412 segs_out:51234 segs_in:49871 send 40.5Mbps lastsnd:28 lastrcv:12 lastack:12 pacing_rate 81.0Mbps retrans:214/51234

Significado: Retransmisiones no triviales (214) más cwnd modesto sugiere pérdida/encolamiento/MTU afectando TCP.
Decisión: Si retrans aumenta durante transferencias, encuentra dónde se pierden paquetes. No tunées sysctls hasta que pares los drops.

Task 13: Detect bufferbloat under load using ping while saturating

cr0x@server:~$ ping -i 0.2 -c 20 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 56(84) bytes of data.
64 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=19.2 ms
64 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=18.9 ms
64 bytes from 10.20.0.10: icmp_seq=3 ttl=64 time=210.5 ms
64 bytes from 10.20.0.10: icmp_seq=4 ttl=64 time=243.1 ms
64 bytes from 10.20.0.10: icmp_seq=5 ttl=64 time=198.7 ms

Significado: Picos de latencia durante la carga son encolamiento/bufferbloat. Eso destroza throughput TCP y hace que las apps “se sientan rotas”.
Decisión: Implementa gestión de colas sensata (fq_codel/cake) y aplica shaping en el enlace cuello de botella, típicamente la salida WAN.

Task 14: Confirm qdisc and apply fq_codel (Linux) if appropriate

cr0x@server:~$ tc qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

cr0x@server:~$ sudo tc qdisc replace dev eth0 root fq_codel
cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn

Significado: pfifo_fast es una pieza de museo. fq_codel ofrece AQM que reduce bufferbloat.
Decisión: Si la latencia aumenta bajo carga, mantén fq_codel (o cake) y añade shaping si el cuello de botella está upstream.

Task 15: Check NIC and IRQ distribution (RSS/RPS hint)

cr0x@server:~$ cat /proc/interrupts | head -12
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  35:   9123412  781234123      12345      11234      10987      10321      10012       9987  IR-PCI-MSI 524288-edge  eth0-TxRx-0

Significado: Una cola de interrupciones recayendo mayormente en CPU1 puede crear un cuello de botella por core incluso si la CPU total parece bien.
Decisión: Si un core está pegado y las interrupciones están sesgadas, tunea RSS/RPS o ajusta afinidad de IRQ; o actualiza hardware/drivers de la NIC.

Tres micro‑historias corporativas desde el campo

Micro‑historia 1: El incidente causado por una asunción errónea (PMTUD “endurecimiento de seguridad”)

Una empresa mediana desplegó una VPN site‑to‑site entre dos oficinas y una VPC en la nube. Los pings estaban bien. RDP funcionaba.
Entonces finanzas empezó a exportar informes grandes y la transferencia se atascaba al 2–5% durante minutos, luego continuaba, luego volvía a atascarse.
La asunción inicial: “la crypto de la VPN es muy lenta; necesitamos cajas más grandes.”

El equipo de red comprobó la CPU. Mucho margen. Aun así cambiaron ciphers porque es lo que se hace cuando uno está atascado.
Ligera mejora en una dirección, peor en la otra. El problema siguió raro e intermitente, lo que alimentó teorías malas.

Un SRE hizo una prueba DF ping y de inmediato obtuvo “message too long” con MTU alrededor de 1412 bytes—más bajo de lo esperado.
Luego revisaron reglas de firewall y encontraron que ICMP destination‑unreachable se descartaba en un ACL perimetral “endurecido”.
PMTUD estaba muerto, así que las sesiones TCP se tragaban paquetes grandes hasta que retransmisiones y timeouts hacían avanzar algo.

La solución no fue un router más grande. Fue permitir los tipos ICMP específicos necesarios para PMTUD y añadir MSS clamping como medida complementaria.
Las transferencias pasaron de “minutos de stalls” a “aburridamente rápidas”. La acción del postmortem no fue “no endurecer”.
Fue “no romper protocolos fundamentales y llamarlo seguridad”.

Micro‑historia 2: La optimización que salió mal (activar “aceleración” que deshabilitó el fast path real)

Otra organización tenía un túnel IPsec con rendimiento aceptable. Un ingeniero activó una función de un vendor vendida como “inspección avanzada de tráfico”
para “mejor visibilidad”. Iba a ser ligera. También se habilitó globalmente porque la UI lo hacía la opción más fácil.

En un día, llegaron quejas: jitter en VoIP, transferencias lentas, replicación de base de datos con lag.
El monitoreo mostró menor utilización WAN de lo normal mientras la latencia de aplicaciones subía. Eso siempre es una pista: la red no está saturada; hay congestión interna.

La CPU del router no estaba pegada en el agregado, pero el procesamiento de paquetes saltó y las interrupciones subieron. Los contadores de offload se quedaron planos.
La función de inspección forzó paquetes fuera de la ruta acelerada y hacia un carril lento en software.
De pronto el mismo hardware hacía más trabajo por paquete y no podía seguir el ritmo en picos.

Deshabilitar la función restauró offload y throughput. Reintrodujeron visibilidad después usando flow logs en el lado desencriptado y muestreo selectivo,
no inspección por paquete en la interfaz de túnel. La lección no fue “nunca inspeccionar”.
Fue “si activas una función que toca cada paquete, prueba que no desactive lo que paga tu factura de rendimiento”.

Micro‑historia 3: La práctica aburrida pero correcta que salvó el día (tests baseline y disciplina de cambios)

Una empresa planeó migrar servicios entre datacenters sobre una VPN. La VPN “parecía bien” en pruebas casuales.
Pero el equipo SRE insistió en un baseline: iperf3 en ambos sentidos, 1 y 4 streams, pruebas DF MTU y ping bajo carga.
Registraron resultados, no como ejercicio académico, sino para tener una fuente de verdad antes/después.

Durante la ventana de migración, el throughput cayó ~60% y aparecieron picos de latencia bajo carga.
Como tenían baseline, no perdieron tiempo discutiendo si era “variabilidad normal de internet”.
Supieron exactamente cómo “normal” lucía para su ruta.

Revirtieron el cambio más reciente: una actualización de QoS en el borde WAN que accidentalmente estaba shapeando el tráfico del túnel dos veces
(una vez en la interfaz física y otra en una subinterfaz VLAN). El doble shaping causó encolamiento y drops.
La solución fue poco glamorosa: un shaper en el verdadero cuello de botella, fq_codel para justicia y claridad de propiedad de la política.

Nadie recibió un trofeo. Pero la replicación terminó a tiempo y la migración no se convirtió en un puente de incidentes de fin de semana.
Prácticas aburridas—baselines, cambios incrementales y “un shaper para gobernarlos”—son cómo los adultos mantienen las VPN rápidas.

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

Estos son los reincidentes. Si reconoces tu situación, salta la improvisación y aplica la solución específica.

1) Síntoma: Velocidad se topa en 80–200 Mbps sin importar nada

Causa raíz: cuello de botella CPU/crypto, VPN mono‑hilo o offload deshabilitado.
Solución: Verifica CPU por core. Confirma estado de offload. Muévete a datapath en kernel (WireGuard, IPsec kernel) o OpenVPN DCO donde sea viable; si no, actualiza hardware.

2) Síntoma: Navegación web pequeña bien, descargas grandes se estancan o ralentizan

Causa raíz: desajuste MTU o PMTUD black hole causando drops de paquetes grandes.
Solución: DF ping para encontrar MTU real. Permite ICMP destination‑unreachable/time‑exceeded. Clampa MSS en el camino de forwarding del túnel.

3) Síntoma: Un sentido rápido, el sentido inverso lento

Causa raíz: enrutamiento asimétrico, shaping asimétrico o un endpoint con CPU pegada en cifrar/descifrar.
Solución: Prueba iperf3 en ambos sentidos. Revisa CPU y qdisc en ambos lados. Verifica tablas de enrutamiento y policy routing.

4) Síntoma: VPN funciona hasta que el tráfico sube, luego la latencia explota

Causa raíz: bufferbloat o uplink sobre‑suscrito sin shaping/AQM.
Solución: Aplica fq_codel/cake y shape en el verdadero cuello de botella (usualmente la salida WAN). Vuelve a probar ping bajo carga.

5) Síntoma: “Habilitamos QoS y ahora la VPN es más lenta”

Causa raíz: mala clasificación (tráfico encriptado todo parece igual), doble shaping o rates de shaper demasiado bajos causando drops.
Solución: Shape solo una vez, en el egress real. Clasifica en el tráfico interno donde sea posible (lado desencriptado), si no usa políticas toscas.

6) Síntoma: Rendimiento terrible de OpenVPN en enlaces rápidos

Causa raíz: overhead de userspace y restricciones mono‑hilo.
Solución: Considera OpenVPN DCO, o migra a WireGuard/IPsec para alto throughput. Si estás atascado, asegúrate de modo UDP, ajusta MTU/MSS y asigna a cores más rápidos.

7) Síntoma: Throughput IPsec cayó tras habilitar NAT en la ruta del túnel

Causa raíz: offload deshabilitado o mismatch de políticas; NAT fuerza la ruta lenta.
Solución: Re‑arquitecta para evitar NAT a través del túnel cuando sea posible. Si es obligatorio, confirma que hardware/drivers lo soportan; si no, acepta menor throughput o actualiza.

8) Síntoma: Pruebas de velocidad varían mucho según la hora del día

Causa raíz: congestión upstream, shaping del ISP o saturación de medio compartido; la VPN solo lo hace más obvio.
Solución: Establece baselines, mide fuera de la VPN también y aplica shaping para reducir pérdida. Si es el ISP, escala con evidencia.

Listas de comprobación / plan paso a paso

Checklist A: La secuencia de medición “deja de adivinar”

Ejecuta iperf3 a través de la VPN: 1 stream y 4 streams, ambos sentidos.
Revisa CPU por core e interrupciones durante la prueba.
DF ping para hallar el MTU efectivo a través del túnel.
Verifica que ICMP frag‑needed no esté bloqueado; confirma que los contadores de clamp MSS se incrementan si se usan.
Prueba ping bajo carga para detectar bufferbloat.
Revisa drops en interfaces relevantes (WAN y túnel).

Checklist B: Árbol de decisión que puedes usar en un bridge de incidentes

Si un core está pegado: confirma tipo de VPN; muévete a kernel/offload o actualiza hardware; deja de tocar MTU hasta que puedas cifrar a velocidad.
Si multi‑stream ayuda mucho: persigue MTU/PMTUD y pérdida/encolamiento; implementa AQM y shaping antes de tocar crypto.
Si DF ping falla en tamaños sorprendentemente bajos: arregla MTU e ICMP; clampa MSS; vuelve a probar.
Si latencia explota bajo carga: implementa fq_codel/cake; shapea en el cuello de botella; vuelve a probar.
Si el rendimiento cambió tras habilitar una función: confirma estado de offload/fast path; revierte la función y reintrodúcela de forma quirúrgica.

Checklist C: Qué documentar para no reaprender esto el próximo trimestre

Resultados baseline de iperf3 (1 vs 4 streams, ambos sentidos) y condiciones de prueba.
MTU efectivo a través del túnel y MTU configurada en la interfaz.
Si se usa clamping MSS, dónde y por qué (PMTUD fiable o no).
Estado de offload/aceleración y qué características lo deshabilitan.
Configuraciones de encolamiento/shaping y la razón de las tasas.

Preguntas frecuentes

1) ¿Por qué mi VPN es lenta si la prueba de mi ISP es rápida?

Las pruebas de velocidad del ISP a menudo usan múltiples streams paralelos y pueden correr hacia servidores cercanos. Tu tráfico VPN podría ser de un solo stream,
con RTT más largo y limitado por crypto del endpoint o problemas de MTU. Prueba con iperf3 a través de la VPN y compara 1 vs 4 streams.

2) ¿Cómo sé si es CPU/crypto vs MTU?

Los cuellos de botella CPU/crypto suelen mostrar un techo duro de throughput y un core pegado durante la carga.
Los problemas MTU/PMTUD muestran stalls, retransmisiones y gran mejora cuando se clampa MSS o se reduce MTU; multi‑stream frecuentemente ayuda.

3) ¿Debería simplemente cambiar a WireGuard?

Si estás atascado en una VPN mono‑hilo en userspace y necesitas cientos de Mbps a Gbps, cambiar suele ayudar.
Pero no lo uses como sustituto de diagnosticar MTU y encolamiento; WireGuard también puede ser lento si la ruta descarta paquetes o hay bufferbloat.

4) ¿Es siempre necesario el clamping MSS?

No. Si PMTUD funciona end‑to‑end (ICMP frag‑needed permitido) y tu MTU de túnel está configurado correctamente, puede que no lo necesites.
En el mundo real, PMTUD frecuentemente está roto por middleboxes, así que MSS clamping es un workaround pragmático.

5) ¿Qué valor de MSS debo poner?

Prefiere --clamp-mss-to-pmtu cuando esté disponible; se adapta al MTU de la interfaz.
Si debes fijar un MSS, calcúlalo desde el MTU efectivo de la ruta y cabeceras estándar (típicamente MTU menos 40 para cabeceras IPv4 TCP, más para IPv6).
Mide primero; adivinar aquí es cómo creas problemas nuevos.

6) ¿Por qué ping se ve bien pero las transferencias son lentas?

Ping usa paquetes pequeños. Tu problema suele involucrar paquetes grandes (MTU/fragmentación) o colas sostenidas bajo carga (bufferbloat),
ninguna de las cuales ping revela a menos que pruebes bajo carga y con DF activado.

7) ¿Realmente el logging del firewall puede ralentizar una VPN?

Sí. Loguear por paquete añade CPU y I/O, y puede deshabilitar fast‑path/offload en algunas plataformas.
Registra flujos o eventos muestreados en vez de cada paquete en rutas de alto throughput.

8) ¿Cuál es el cambio “de seguridad” más común que rompe throughput VPN?

Bloquear ICMP destination‑unreachable/time‑exceeded. Rompe PMTUD y convierte problemas de MTU en drops silenciosos y tormentas de retransmisiones.
Permite los tipos ICMP necesarios; la seguridad puede seguir siendo estricta sin sabotearse a sí misma.

9) ¿Por qué varios streams TCP “arreglan” mi throughput?

Varios streams ocultan pérdida/encolamiento/MTU porque al menos algunos flujos progresan mientras otros se retraen.
Es una pista diagnóstica, no una solución real. Arregla drops, PMTUD y bufferbloat en su lugar.

10) ¿Cómo explico esto a la dirección sin sonar a excusas?

Muestra dos gráficos: throughput vs utilización por core CPU, y latencia de ping bajo carga. Añade resultados iperf3 1‑stream vs 4‑stream.
Esa es evidencia de dónde vive el cuello de botella y qué cambio lo solucionará.

Conclusión: siguientes pasos que puedes ejecutar hoy

Diagnostica la lentitud de la VPN como cualquier otro problema de rendimiento en producción: mide, aisla y luego cambia una variable.
No empieces por discutir ciphers. Empieza con el guion rápido: iperf3 (1 vs 4 streams), CPU por core, pruebas DF MTU, verificación MSS/ICMP,
y latencia bajo carga para detectar bufferbloat.

Pasos prácticos:

Ejecuta iperf3 a través de la VPN en ambos sentidos con 1 y 4 streams; anota los números.
Durante la prueba, captura CPU por core y distribución de interrupciones; prueba o descarta límites de cómputo en endpoints.
Mide MTU real de la ruta con DF pings; alinea MTU del túnel y aplica clamping MSS si PMTUD no es fiable.
Revisa drops y picos de latencia bajo carga; arregla gestión de colas y shaping en el cuello de botella.
Si confirmas un límite del datapath crypto, cambia la arquitectura (kernel/offload/DCO) o cambia hardware. Todo lo demás es teatro.