OpenVPN: Por qué parece lento (y los ajustes que lo hacen volar)

febrero 11, 2026 • febrero 11, 2026 • Lectura: 24 min • Views: 1

¿Te fue útil?

Parte de la lentitud en una VPN es real; otra parte es ilusión óptica; la mayoría es autoinfligida. Enciendes OpenVPN, tu prueba de velocidad cae de “bien” a “¿por qué pago fibra?”, y de repente todos son ingenieros de redes aficionados.

OpenVPN puede mover tráfico serio. También puede sabotearte silenciosamente con un solo MTU desajustado, un TCP-sobre-TCP que se estrella o una CPU al 100% cifrando en un hilo solitario. Diagnostiquemos como adultos: encuentra el cuello de botella, verifícalo con comandos y ajusta solo lo que puedas justificar.

Qué significa realmente “lento” en OpenVPN

“Lento” es una bolsa heterogénea. Necesitas nombrar el problema antes de tocar ajustes:

Bajo rendimiento: las descargas grandes se arrastran, las copias de seguridad caducan, los artefactos de CI tardan una eternidad.
Alta latencia: SSH se siente pegajoso, RDP tartamudea, VoIP pierde palabras.
Jitter: funciona hasta que no; cargas interactivas se sienten inquietantes.
Inestabilidad de la conexión: bucles de reconexión, renegociaciones TLS, paradas aleatorias.

El rendimiento de OpenVPN no es una sola perilla. Es una tubería: cifrado en espacio de usuario + tunelización en kernel + enrutamiento/NAT + la red real. Cualquier parte puede convertirse en el limitador. Empezamos con una triage rápida y luego profundizamos.

Guía rápida de diagnóstico (primeras/segundas/terceras comprobaciones)

Primero: determina si estás limitado por CPU o por la red

Comprueba la saturación de CPU del servidor durante una transferencia. Si un solo núcleo está al máximo, probablemente estés limitado por cifrado/espacio de usuario.
Revisa la calidad del enlace (pérdida, retransmisiones, problemas MTU). Si ves fragmentación o retransmisiones, probablemente estés limitado por la ruta/MTU.
Verifica la elección de protocolo. TCP sobre TCP es el clásico escenario de “funciona en pruebas, falla en producción”.

Segundo: valida que MTU/MSS sean correctos

Busca agujeros negros ICMP “Fragmentation needed”.
Confirma que no estás fragmentando dentro del túnel.
Configura mssfix/tun-mtu de forma conservadora y verifica con capturas de paquetes.

Tercero: comprueba buffers, colas y planificación

Buffers de socket y disciplinas de cola del kernel.
Opciones de OpenVPN como sndbuf/rcvbuf, y límites del SO como net.core.rmem_max.
Comportamiento de colas de TUN/TAP y multi-queue cuando aplique.

Si solo haces una cosa: prueba el cuello de botella con mediciones. Ajustar sin medir es condenar a tu yo futuro a la miseria.

Cómo OpenVPN mueve paquetes (y dónde pierde rendimiento)

OpenVPN está mayormente en espacio de usuario. Eso es a la vez su superpoder y su impuesto. Los paquetes viajan así:

La aplicación genera tráfico (TCP/UDP).
El kernel lo enruta hacia la interfaz TUN.
OpenVPN lee desde TUN en espacio de usuario.
OpenVPN cifra/autentica, añade overhead (cabeceras, IVs, tags).
OpenVPN escribe los paquetes encapsulados en un socket UDP o TCP.
Internet hace lo que hace: NAT, pérdida, reordenación, rarezas de MTU.
Al otro lado: se invierte el proceso.

Las implicaciones de rendimiento son previsibles:

Cambios de contexto: los bucles de lectura/escritura en espacio de usuario añaden overhead.
Puntos calientes de un solo hilo: un proceso puede convertirse en tu cuello de botella.
Costo de crypto: depende del cifrado, las características de la CPU y la distribución del tamaño de paquetes.
Overhead de encapsulación: reduce el MTU efectivo y puede desencadenar fragmentación.
Comportamiento de TCP: si tunelizas TCP dentro de TCP, el control de congestión se vuelve… filosófico.

Una cita que debería estar en todo manual de rendimiento de VPN: mide, luego decide; las conjeturas sobre rendimiento suelen estar equivocadas. Ese es el trabajo.

Broma #1: Afinar OpenVPN sin métricas es como optimizar una base de datos mirándola más intensamente. La base de datos no respetará tu confianza.

Hechos interesantes y contexto histórico

Las primeras versiones públicas de OpenVPN fueron a principios de los 2000, diseñadas para portabilidad y corrección cuando “appliance VPN” a menudo significaba “caja misteriosa”.
El diseño en espacio de usuario fue deliberado: evitó problemas con módulos kernel en distintos SO y facilitó auditorías, a costa de copias extra/cambios de contexto.
Las abstracciones TUN/TAP vienen de la historia de redes Unix; TUN (L3) suele ser más rápido y simple que TAP (L2) a menos que realmente necesites bridging Ethernet.
El modo UDP se volvió la recomendación por defecto porque el modo TCP magnifica la latencia y las patologías de retransmisión bajo pérdida.
Controles tipo “TLS auth” / “tls-crypt” evolucionaron en parte como respuesta práctica al ruido de fondo de Internet y el sondeo activo.
AES-NI cambió el juego para el throughput de OpenVPN en x86: de repente el cifrado dejó de ser siempre el cuello de botella—el procesamiento de paquetes a menudo lo era.
ChaCha20-Poly1305 ganó popularidad porque rinde bien en dispositivos sin aceleración AES (muchos routers pequeños y algunas VMs).
Offload del canal de datos no es la historia principal de OpenVPN como sí lo es para algunas VPN basadas en kernel; OpenVPN gana en madurez y flexibilidad, no en zero-copy espectacular.
Muchos reportes de “OpenVPN es lento” son en realidad agujeros negros MTU creados por redes que bloquean el ICMP necesario para Path MTU Discovery.

Los cuellos de botella habituales: CPU, MTU, buffers, enrutamiento y malas configuraciones

1) Cifrado limitado por CPU (o, más a menudo, churn de paquetes en espacio de usuario)

Si un proceso OpenVPN hace todo el trabajo, puedes saturar un solo núcleo mucho antes de saturar un enlace de 1 Gbps—especialmente con muchos paquetes pequeños (piensa en tráfico interactivo, APIs charlas, DNS, RDP, metadatos SMB). La crypto es costosa, pero también lo es “solo mover paquetes” en espacio de usuario.

Lo que lo empeora:

Ejecutar OpenVPN en una VM pequeña con planificación de CPU restringida.
Usar un cifrado lento en tu CPU (o sin aceleración por hardware).
Altas tasas de paquetes: el throughput puede parecer mediocre aunque los Mbps no sean enormes.

2) Desajuste MTU/MSS y fragmentación

La encapsulación ocupa bytes del payload. Si tu tráfico interno asume MTU 1500 y la ruta del túnel solo puede llevar, digamos, 1472 bytes (o menos), obtendrás fragmentación. La fragmentación puede ser solo ineficiente, o puede ser catastrófica cuando ICMP está bloqueado y PMTUD falla.

El patrón es clásico:

Las solicitudes pequeñas funcionan.
Las descargas grandes se quedan estancadas, especialmente sobre TCP.
Algunos sitios funcionan, otros cuelgan misteriosamente.

3) Colapso TCP-sobre-TCP

Tunelizar tráfico TCP a través de un túnel OpenVPN que usa TCP es el equivalente de rendimiento de apilar dos controladores de congestión y pedirles que coordinen con vibraciones. Bajo pérdida, ambas capas retransmiten y retroceden, y la latencia se dispara. Puede “funcionar” en redes de laboratorio perfectas y luego colapsar en enlaces del mundo real.

4) Buffers y encolamiento (aka “la latencia es un problema de almacenamiento con paquetes”)

Los buffers existen para suavizar ráfagas. Si son demasiado pequeños, descartas. Si son demasiado grandes, produces bufferbloat y añades latencia. OpenVPN tiene sus propios buffers de socket, y el SO tiene límites. Necesitas dimensionar con sensatez y disciplina de colas apropiada, especialmente para redes de alto BDP.

5) Errores de enrutamiento/NAT y rutas asimétricas

OpenVPN puede ir rápido mientras tu enrutamiento es lento. Si el tráfico toma un camino en U a través de un firewall, o tus reglas NAT fuerzan churn de conntrack, culparás a la VPN porque es el cambio visible. No lo hagas. Sigue los paquetes.

6) El asesino silencioso: DNS y resolución de nombres

A veces el túnel está bien pero el DNS por el túnel no. Picos de latencia, reintentos, split-DNS roto o resolvers que no deberías usar. Los usuarios reportan “la VPN está lenta” cuando en realidad quieren decir “toda la página espera por DNS”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas están pensadas para ejecutarse en servidores/clientes Linux. Ajusta los nombres de interfaz según sea necesario. Cada una incluye qué significa la salida y qué decisión tomar a partir de ella.

Task 1: Confirmar modo OpenVPN, cifrado y si estás en UDP

cr0x@server:~$ sudo ss -lntup | awk 'NR==1 || /openvpn/'
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp   UNCONN 0      0      0.0.0.0:1194      0.0.0.0:*     users:(("openvpn",pid=1324,fd=6))

Significado: Estás escuchando en UDP/1194. Buen valor por defecto para rendimiento.

Decisión: Si ves tcp aquí, desconfía. Usa TCP solo si realmente necesitas atravesar redes hostiles.

Task 2: Comprobar saturación de CPU del servidor durante una transferencia

cr0x@server:~$ top -b -n 1 -o %CPU | head -n 12
top - 10:21:33 up 31 days,  4:02,  1 user,  load average: 1.92, 1.41, 1.22
Tasks: 162 total,   1 running, 161 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.2 us,  1.0 sy,  0.0 ni, 90.5 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :  7986.4 total,  2141.2 free,  1680.0 used,  4165.2 buff/cache
MiB Swap:  2048.0 total,  2048.0 free,     0.0 used.  5789.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1324 nobody    20   0  178248  18624   7512 R  98.7   0.2  52:14.11 openvpn

Significado: OpenVPN está utilizando un núcleo al máximo. Probablemente estás limitado por CPU/espacio de usuario.

Decisión: Considera cifrados más rápidos para tu CPU, asegura que AES-NI esté disponible, reduce problemas de tasa de paquetes o escala horizontal (más instancias, más túneles, o otra tecnología VPN si necesitas multi-gigabit).

Task 3: Verificar capacidad de crypto hardware (AES-NI) en x86

cr0x@server:~$ lscpu | egrep 'Model name|Flags' | head -n 2
Model name:                           Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... aes ...

Significado: La bandera aes está presente; probablemente hay aceleración AES disponible.

Decisión: Prefiere AES-GCM en CPUs con AES-NI. Si está ausente (común en dispositivos ARM pequeños), considera ChaCha20-Poly1305 (si tu build de OpenVPN lo soporta).

Task 4: Identificar pérdida de paquetes y retransmisiones en la interfaz física

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
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9812345678 8123456      0   12890       0       0
    TX:  bytes packets errors dropped carrier collsns
    8765432109 7345678      0    4321       0       0

Significado: Los dropped en RX/TX pueden indicar congestión, problemas del driver o presión de buffers.

Decisión: Si los drops aumentan bajo carga VPN, ajusta las disciplinas de cola, incrementa buffers con precaución o corrige ajustes NIC/virtio. Los drops no son “normales”. Son una pista.

Task 5: Comprobar errores de recepción UDP a nivel kernel

cr0x@server:~$ netstat -su | egrep -i 'packet receive errors|receive buffer errors|ignored|InDatagrams'
    1892345 packets received
    0 packet receive errors
    0 receive buffer errors
    1892345 InDatagrams

Significado: Si receive buffer errors incrementa, el kernel está descartando UDP porque los buffers son demasiado pequeños o la CPU no puede seguir el ritmo.

Decisión: Aumenta los límites de buffer de socket del SO y considera rcvbuf/sndbuf de OpenVPN con push (pero no los pongas “infinitos” sin control).

Task 6: Medir el throughput real del túnel con iperf3 (no confíes en tests de velocidad)

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

cr0x@server:~$ iperf3 -c 10.8.0.1 -P 4 -t 15
Connecting to host 10.8.0.1, port 5201
[SUM]   0.00-15.00  sec   620 MBytes   347 Mbits/sec  sender
[SUM]   0.00-15.00  sec   616 MBytes   344 Mbits/sec  receiver

Significado: Tienes una línea base. Los streams paralelos ayudan a revelar si alcanzas límites por flujo único.

Decisión: Si un solo stream es lento pero varios en paralelo rinden bien, mira la ventana TCP/latencia y el control de congestión, no solo el ancho de banda bruto.

Task 7: Detectar agujero negro MTU con ping y “no fragmentar”

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

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

Significado: Tu path MTU es menor que la expectativa de 1500. Sobre un túnel será aún menor.

Decisión: Ajusta tun-mtu y mssfix para evitar fragmentación. No adivines; encuentra el mayor tamaño que funcione a lo largo de la ruta del túnel.

Task 8: Comprobar MTU efectivo en la interfaz de túnel

cr0x@server:~$ ip link show dev tun0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Significado: MTU es 1500 en tun0. Eso puede estar mal dependiendo de la encapsulación y la ruta.

Decisión: Si ves fragmentación o estancamientos, reduce tun-mtu (y clamp MSS). Un punto de partida sensato es 1500 menos overhead; muchos operadores se sitúan entre 1400–1450 según el entorno.

Task 9: Observar fragmentación real con tcpdump

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 1194 -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.123456 IP (tos 0x0, ttl 64, id 54321, offset 0, flags [+], proto UDP (17), length 1514)
    203.0.113.10.1194 > 198.51.100.20.51123: UDP, length 1486
10:25:11.123457 IP (tos 0x0, ttl 64, id 54321, offset 1480, flags [none], proto UDP (17), length 54)
    203.0.113.10.1194 > 198.51.100.20.51123: UDP, length 26

Significado: Las banderas [+] y los offsets indican fragmentación.

Decisión: Reduce MTU del túnel y usa MSS clamping. La fragmentación es un impuesto; la fragmentación que se pierde es una caída del servicio.

Task 10: Comprobar retransmisiones TCP (síntoma de pérdida o problema MTU)

cr0x@server:~$ ss -ti dst 10.8.0.2 | head -n 30
ESTAB 0 0 10.8.0.1:5201 10.8.0.2:51044
	 cubic wscale:7,7 rto:204 rtt:45.2/3.1 ato:40 mss:1360 pmtu:1400 rcvmss:1360 advmss:1360 cwnd:26 bytes_sent:12345678 bytes_retrans:23456 bytes_acked:12320000

Significado: bytes_retrans en aumento indica retransmisiones; observa también pmtu y mss.

Decisión: Si las retransmisiones suben, arregla la pérdida primero (Wi‑Fi, LTE, enlaces sobrecargados) y el MTU después. No “optimices” cifrados mientras la ruta esté en llamas.

Task 11: Verificar enrutamiento: ¿el tráfico realmente va por el túnel?

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 10.8.0.5 dev tun0 src 10.8.0.1 uid 0
    cache

Significado: Este destino se enruta vía tun0. Bien.

Decisión: Si se enruta por eth0 cuando esperas tun0, tienes un problema de policy routing o rutas empujadas—los usuarios pueden estar haciendo hairpinning, fugas o split-routing no intencionales.

Task 12: Confirmar NAT/forwarding para site-to-site o configuraciones con “push redirect-gateway”

cr0x@server:~$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "tun0" oifname "eth0" accept
    iifname "eth0" oifname "tun0" ct state established,related accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" ip saddr 10.8.0.0/24 masquerade
  }
}

Significado: El reenvío está habilitado y existe NAT para clientes del túnel saliendo por eth0.

Decisión: Si el reenvío está desactivado o las reglas descartan, verás “VPN conecta pero sin internet” o lentitud debida a rutas de retorno asimétricas.

Task 13: Comprobar máximos de buffer de socket (límites del SO)

cr0x@server:~$ sysctl net.core.rmem_max net.core.wmem_max net.ipv4.udp_rmem_min net.ipv4.udp_wmem_min
net.core.rmem_max = 212992
net.core.wmem_max = 212992
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096

Significado: Los valores por defecto son conservadores. En enlaces de alto BDP, esto puede limitar el throughput o causar drops.

Decisión: Auméntalos con precaución (y monitoriza). Si subes buffers en OpenVPN pero el máximo del SO es pequeño, tu ajuste no tendrá efecto.

Task 14: Validar la disciplina de cola (control de bufferbloat)

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: fq_codel es generalmente amigable para la latencia bajo carga.

Decisión: Si ves un pfifo_fast enorme o buffers masivos en egress WAN, considera cambiar a fq_codel o cake (donde esté disponible) para domar picos de latencia.

Ajustes que lo aceleran (y qué evitar)

Elige UDP a menos que tengas una razón real para no hacerlo

UDP no es “más rápido porque sí”. Es más rápido porque evitas el colapso TCP-sobre-TCP y permites que las sesiones TCP internas hagan su trabajo sin estar envueltas en otra capa de fiabilidad.

Haz: proto udp para la mayoría de despliegues.

Evita: proto tcp como valor por defecto. Úsalo para captive portals y redes muy restrictivas, y acepta la merma de rendimiento.

Usa TUN (ruteado) a menos que realmente necesites TAP (bridge)

TAP arrastra semántica Ethernet a tu vida: broadcasts, ruido ARP y tramas más grandes. A veces lo necesitas (apps legacy, adyacencia L2). A menudo no.

Haz: dev tun para site-to-site y VPNs de cliente.

Evita: dev tap cuando la única justificación es “salió en un post de blog”.

Acerta MTU/MSS y después deja de tocarlo

Si recuerdas una regla de tuning: evita la fragmentación dentro del túnel. Usa mssfix para clavar la MSS TCP y que los endpoints no envíen segmentos demasiado grandes para el MTU efectivo. Usa tun-mtu para fijar el MTU del túnel si es necesario.

Snippets típicos del lado servidor (ilustrativos, no universales):

mssfix: clampa la MSS TCP; bueno para evitar problemas de PMTUD.
tun-mtu: fija el MTU del túnel; ayuda a imponer tamaños sin fragmentar.
fragment: evita en general; la fragmentación suele ser un parche para una ruta rota y puede interactuar mal con redes modernas.

Elige cifrados modernos pensando en tu CPU

En x86 con AES-NI, AES-128-GCM suele ser un punto dulce. AES-256-GCM también puede funcionar, pero no pagues ciclos extra sin beneficio en tu modelo de amenazas. En dispositivos sin aceleración AES, ChaCha20-Poly1305 puede rendir mejor.

Además: la negociación de cifrado y la compatibilidad importan. Un cifrado “rápido” que no puedes usar en todas partes es solo un riesgo de cambios futuros.

No sobredimensiones los buffers a ciegas

Sí, buffers más grandes pueden ayudar el throughput en enlaces de alta latencia. También pueden crear segundos de cola y empeorar la interactividad. Piensa en los buffers como cache de escritura: útiles hasta que se convierten en tu incidente.

Keepalive y renegociación: no te crees jitter autoinfligido

Renegociaciones y keepalives agresivos pueden causar paradas periódicas. Ajusta keepalives según los timeouts NAT, y no renueves TLS innecesariamente. Si ves “todos se congelan por un segundo” periódicamente, revisa intervalos de renegociación y picos de CPU.

Escala horizontal cuando llegues a límites de proceso único

OpenVPN maneja múltiples clientes bien, pero existen techos reales por proceso según tasa de paquetes, crypto y CPU. Si empujas alto ancho de banda agregado, considera:

Múltiples instancias de OpenVPN vinculadas a distintos puertos/IPs.
Distribuir clientes entre instancias.
Más CPU y núcleos más rápidos (no solo más RAM).
Reevaluar si una VPN basada en kernel se adapta mejor si persigues rendimiento multi-gigabit por túnel.

Broma #2: Si pones todos los buffers a 16 MB, no sintonizaste la VPN. Construiste un museo de latencia y cobraste entrada a tus usuarios.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana desplegó OpenVPN para conectar al personal remoto a herramientas internas. Al grupo piloto le encantó. El despliegue fue global. Luego la cola de tickets empezó a parecer un ataque de denegación de servicio, excepto que los atacantes eran empleados.

Los síntomas eran inconsistentes: algunos usuarios podían cargar apps web internas bien, pero descargar archivos grandes de un repositorio interno se colgaba. Otros reportaban que solo ciertos sitios fallaban, y las fallas variaban según la Wi‑Fi del hotel. Naturalmente, todos culparon al servidor OpenVPN porque era lo nuevo.

La suposición errónea: “MTU funcionará porque Ethernet es 1500”. El equipo de red tenía un segmento en la ruta con MTU menor (un tramo del proveedor y un salto VPN‑en‑VPN), y los mensajes ICMP “fragmentation needed” estaban siendo filtrados. Path MTU Discovery no podía hacer su trabajo. Paquetes pequeños sobrevivían; los grandes morían en silencio.

La solución fue aburrida e inmediata: clamar MSS y bajar el MTU del túnel a un valor seguro en toda la flota. Una vez hecho, los “cuelgues aleatorios” desaparecieron. Más tarde arreglaron el filtrado de ICMP, pero las configuraciones de MTU/MSS fueron la correa y los tirantes de producción.

Microhistoria 2: La optimización que salió mal

Otra organización quiso más throughput para sincronización nocturna. Alguien leyó que “buffers más grandes mejoran rendimiento” y subió sndbuf/rcvbuf de OpenVPN mucho, además de aumentar los máximos del kernel. El ancho de banda subió en una prueba sintética. Celebración.

Luego empezaron las quejas: la calidad de VoIP bajó, las sesiones de terminal se sentían retardadas y el monitoreo empezó a oscilar. Nada estaba “caído”, pero todo se sentía peor. Era el tipo de degradación que te hace cuestionar tu carrera.

Habían creado bufferbloat en el egress de la VPN. La sincronización nocturna ganaba throughput sentada sobre una montaña de paquetes encolados, y el tráfico interactivo tenía que esperar detrás. Bajo carga, la latencia saltó de “bien” a “¿estamos bajo ataque?”. No había ataque. Solo buffers entusiastas.

Revertir los cambios mejoró la experiencia de usuarios al instante. La solución final fue usar fair queueing en egress, mantener buffers razonables y programar el tráfico masivo con rate limiting para que no aplastara al resto.

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

Una empresa regulada usaba OpenVPN para acceso de proveedores a un entorno segmentado. Nada glamouroso: reglas de firewall estrictas, rutas explícitas y ventanas de cambio que podían fosilizar un informe de bug.

El equipo hizo una cosa poco sexy pero consistente: mantuvieron un runbook de rendimiento con pruebas repetibles—iperf3 a través del túnel, sondas MTU, snapshots de CPU y capturas de paquetes para canales de control y datos. Cada cambio requería resultados “antes” y “después”.

Un mes, las quejas de rendimiento subieron tras una actualización de políticas de firewall. Como tenían líneas base, demostraron rápidamente que el servidor VPN no era el limitador: CPU bien, sin fragmentación, throughput estable en el servidor. Las capturas mostraron retransmisiones y entrega fuera de orden incrementándose en la periferia.

Resultó que una nueva política de inspección en el firewall interactuaba mal con flujos UDP a escala. Revirtieron esa política y el rendimiento volvió a la normalidad. Sin bases, la culpa habría caído sobre OpenVPN (y su equipo), y la solución habría llevado semanas de afinaciones erróneas.

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

Síntoma: “La VPN conecta, la navegación está bien, pero las descargas grandes se cuelgan.”

Causa raíz: Agujero negro MTU / PMTUD roto; mensajes de fragmentación necesarios bloqueados.

Solución: Configurar mssfix y posiblemente bajar tun-mtu; verificar con ping -M do y tcpdump para comprobar fragmentación.
Síntoma: “El throughput está limitado sospechosamente; la CPU se ve alta.”

Causa raíz: Proceso OpenVPN limitado por CPU; cifrado lento en esa CPU; alto overhead por tasa de paquetes.

Solución: Preferir AES-GCM en sistemas con AES-NI o ChaCha20 en sistemas sin AES; asignar núcleos más rápidos; escalar instancias.
Síntoma: “Funciona en la oficina, terrible en móvil o Wi‑Fi.”

Causa raíz: Pérdida de paquetes y reordenación; TCP-sobre-TCP si OpenVPN usa TCP; o MTU agresivo.

Solución: Usar transporte UDP; clamar MSS; considerar MTU conservador; asegurar keepalives adecuados para NAT.
Síntoma: “Las pruebas de velocidad muestran alta latencia bajo carga; las llamadas se entrecortan durante grandes transferencias.”

Causa raíz: Bufferbloat por buffers sobredimensionados o qdisc inadecuada.

Solución: Usar fq_codel/cake cuando sea posible; mantener buffers sensatos; limitar el ritmo de flujos masivos.
Síntoma: “Solo el DNS es lento; todo se siente retrasado al cargar una página.”

Causa raíz: Resolutores DNS empujados por el túnel lentos/inaccesibles; split DNS mal configurado.

Solución: Probar accesibilidad/latencia del resolver; push de DNS correcto; evitar hairpinning a un resolver distante.
Síntoma: “El throughput VPN bien para algunos clientes, terrible para otros.”

Causa raíz: Problemas MTU/Wi‑Fi/LTE del lado cliente; distinto comportamiento NAT de ISPs; rutas distintas al POP del servidor.

Solución: Probar MTU y pérdida por cliente; preferir endpoints más cercanos; estandarizar configs cliente; medir ruta con mtr.
Síntoma: “Tras habilitar compresión, la velocidad empeoró y la CPU subió.”

Causa raíz: Sobrecarga de compresión en tráfico ya comprimido; preocupaciones de seguridad; CPU extra en espacio de usuario.

Solución: Desactivar compresión para tráfico general de Internet; considerarla solo en casos controlados y con beneficio medible.
Síntoma: “Paradas intermitentes cada N minutos.”

Causa raíz: Eventos de rekey/renegociación que causan picos de CPU; timeouts NAT provocando breves cortes; reinicios de watchdog.

Solución: Inspeccionar logs por renegociaciones; ajustar keepalive; asegurar recursos del sistema estables; no fijar intervalos de rekey agresivos sin motivo.

Listas de verificación / plan paso a paso

Paso a paso: hacer OpenVPN rápido sin volverlo frágil

Establece una línea base: ejecuta iperf3 a través del túnel (1 stream y múltiples), registra RTT y retransmisiones.
Confirma el transporte: usa UDP a menos que tengas una restricción estricta que requiera TCP.
Revisa CPU: si un núcleo está pegado, arregla la elección de cifrado/asignación de CPU/escala antes de tocar MTU.
Arregla MTU/MSS: sondea MTU; ajusta mssfix; modifica tun-mtu si es necesario; verifica que la fragmentación desaparezca.
Verifica drops del kernel: usa ip -s link y netstat -su; si ocurren drops, aborda buffers/CPU/NIC.
Valida enrutamiento: asegúrate de que las rutas sean las esperadas; evita hairpinning; confirma simetría en rutas de retorno.
Controla el encolamiento: verifica qdisc; evita bufferbloat; si debes priorizar, hazlo explícito.
Re-prueba: repite las pruebas base y compara. Si no mediste, no lo arreglaste.
Documenta tu configuración “conocida buena”: incluye suposiciones MTU, elecciones de cifrado y sysctls del SO usados.
Monitorea continuamente: CPU, drops de paquetes y uptime del túnel deben estar en dashboards, no en la cabeza de alguien.

Lista rápida: qué hacer y qué no en tuning de rendimiento

Haz usar transporte UDP para rendimiento.
Haz clamar MSS para evitar sorpresas de fragmentación.
Haz verificar AES-NI / características de CPU y elegir cifrados en consecuencia.
Haz usar fair queueing en interfaces WAN cuando sea posible.
No ejecutes TCP-sobre-TCP salvo si te gusta depurar retransmisiones por deporte.
No “resuelvas” throughput inflando buffers hasta que la latencia sea un rasgo de personalidad.
No actives compresión como botón genérico de velocidad.
No ajustes a ciegas—registra, mide y cambia una cosa a la vez.

Preguntas frecuentes

1) ¿Por qué OpenVPN se siente más lento que mi conexión directa a internet?

Porque añadiste overhead de cifrado, cabeceras extra (MTU efectivo menor) y procesamiento de paquetes en espacio de usuario. Cualquiera de esas cosas puede convertirse en el límite.

2) ¿Es UDP siempre más rápido que TCP para OpenVPN?

No siempre, pero generalmente es más estable y rinde mejor bajo pérdida. El transporte TCP es necesario a veces en redes restrictivas, pero es un compromiso de rendimiento.

3) ¿Cuál es la causa más común en el mundo real de “OpenVPN está lento”?

Problemas MTU/PMTUD que llevan a fragmentación o agujeros negros. Crea el peor tipo de problema: intermitente, dependiente de la ruta y mal atribuido.

4) ¿Debo habilitar compresión para hacer OpenVPN más rápido?

Generalmente no. La mayor parte del tráfico moderno ya está comprimido (HTTPS, vídeo, descargas). La compresión consume CPU y puede introducir problemas de seguridad. Úsala solo si puedes demostrar que ayuda a tu mezcla de tráfico específica.

5) ¿Cómo sé si estoy limitado por CPU?

Durante una transferencia, si el proceso OpenVPN mantiene un núcleo al máximo y el throughput se estanca, estás limitado por CPU/espacio de usuario. Confírmalo con top y compara cambios de throughput después de cambiar cifrado/CPU.

6) ¿Qué MTU debería poner para OpenVPN?

No hay un número universal. Empieza midiendo path MTU y luego ajusta mssfix para evitar que segmentos TCP excedan el MTU efectivo. Muchos entornos acaban entre 1400–1450 para el MTU del túnel, pero mide tu ruta.

7) ¿Por qué múltiples streams iperf3 mejoran el throughput?

Un stream puede estar limitado por crecimiento de ventana TCP y recuperación ante pérdida. Varios streams pueden utilizar mejor el ancho de banda en rutas con alta latencia. También es una pista: si streams paralelos ayudan, el problema no es solo ancho de banda bruto.

8) ¿Puede OpenVPN alcanzar velocidades gigabit?

Sí, en algunos entornos con CPUs potentes y buen tuning. Pero la tasa de paquetes importa: muchos paquetes pequeños pueden limitarte antes de que los Mbps lo hagan. Llegado un punto, escalar o cambiar de tecnología VPN puede ser más limpio.

9) ¿Debería usar TAP bridging para “mejor rendimiento”?

No. TAP es para requisitos L2, no para velocidad. Suele aumentar overhead por broadcasts y ruido ARP. Usa TUN salvo que necesites adyacencia Ethernet.

10) ¿Por qué funciona bien en la oficina pero mal para usuarios remotos?

Porque Internet no es una sola red. Los usuarios remotos tienen MTUs, comportamientos NAT, tasas de pérdida y rutas distintas. Mide desde la ruta del usuario y afina para sobrevivir redes hostiles.

Conclusión: siguientes pasos prácticos

Si OpenVPN se siente lento, no empieces por una sesión de ocultismo con la configuración. Empieza con evidencia.

Ejecuta iperf3 a través del túnel (single y paralelo). Registra throughput y RTT.
Revisa la CPU mientras corre la prueba. Si un núcleo está al máximo, arregla eso primero.
Sondea MTU y elimina fragmentación. Clampa MSS. Verifica con tcpdump.
Busca drops y errores de buffer en estadísticas del kernel. Arregla colas y límites de buffer con sensatez.
Re-prueba y documenta una configuración “conocida buena” para que futuros incidentes tengan menos giros argumentales.

OpenVPN puede ser aburridamente rápido cuando lo tratas como un sistema, no como un túnel mágico. Mide. Cambia una cosa. Mide otra vez. Repite hasta que los gráficos dejen de gritar.