OpenVPN: Configúralo correctamente (y por qué a menudo es más lento que WireGuard)

Un modelo mental de “velocidad VPN” que realmente ayuda

“Velocidad de la VPN” no es una sola cosa. Es una pila de cuellos de botella esperando el flujo de trabajo adecuado para exponerse.
Si no nombras las capas, optimizarás la equivocada y declararás victoria mientras los usuarios siguen sufriendo.

Capa 1: Calidad de la ruta (pérdida, jitter y bufferbloat)

Las VPNs amplifican redes mediocres. Si el último tramo pierde paquetes, el cifrado no lo arregla; lo hace más difícil de diagnosticar.
Un túnel también cambia el tamaño y el ritmo de los paquetes, lo que interactúa con los buffers de routers de consumo y redes LTE.
Picos de latencia se sienten como “VPN lenta” incluso cuando las pruebas de rendimiento de ancho de banda parecen correctas.

Capa 2: Sobrecarga de encapsulación (MTU/MSS)

Tus aplicaciones creen que envían tramas Ethernet de 1500 bytes. Tu VPN añade cabeceras.
Si el MTU efectivo es menor y no ajustas MSS o MTU, obtendrás fragmentación o paquetes que se pierden en un agujero negro.
La fragmentación parece bloqueos aleatorios. El blackholing parece “algunos sitios cargan, otros no”.

Capa 3: Cripto y procesamiento de paquetes

Aquí es donde OpenVPN vs WireGuard se vuelve visible. WireGuard vive en el kernel en Linux y mantiene la ruta caliente ligera.
OpenVPN clásico funciona mayormente en espacio de usuario. El espacio de usuario no es inherentemente lento, pero paga extra en cambios de contexto, copias de memoria
y planificación, especialmente a altas tasas de paquetes.

Capa 4: Elecciones de transporte (UDP vs TCP, y la trampa TCP sobre TCP)

UDP suele ser la elección correcta para el plano de datos de una VPN. TCP dentro de TCP puede crear un bucle de retroalimentación donde ambas capas retransmiten,
ambas se retraen y el rendimiento colapsa bajo pérdida. No es teórico; es cómo obtienes 2 Mbps en un enlace gigabit.

Hechos e historia interesantes (lo que explica las compensaciones actuales)

• OpenVPN data de 2001, construido alrededor de TLS y un diseño flexible en espacio de usuario. Esa flexibilidad es la razón por la que se ejecuta casi en todas partes—y por qué es más pesado.
• WireGuard empezó a mediados de los 2010 con una base de código deliberadamente pequeña y primitivas criptográficas modernas, optimizado para simplicidad y auditabilidad.
• OpenVPN se convirtió en el “predeterminado empresarial” en parte por ser temprano y funcionar bien a través de NAT/firewalls, mucho antes de que “zero trust” fuera un título de presentación.
• La historia de cifrados de OpenVPN evolucionó desde modos CBC antiguos y combinaciones HMAC hacia AES-GCM y valores predeterminados modernos, pero configuraciones heredadas persisten durante años.
• Durante mucho tiempo, ajustar el rendimiento de OpenVPN significaba “elige UDP y reza”; mejoras posteriores como ovpn-dco (offload del canal de datos) llegaron para reducir la carga en espacio de usuario.
• WireGuard usa handshakes basados en Noise y un concepto de “enrutamiento por clave criptográfica”, que reduce la complejidad del plano de control y evita dramas de renegociación en tiempo de ejecución.
• El conjunto de funciones de OpenVPN es enorme (plugins de autenticación, rutas empujadas, hooks de scripts, múltiples métodos de auth). Cada función es una palanca, y las palancas invitan a accidentes.
• En Linux, las rutas rápidas del kernel importan: procesar paquetes sin rebotar entre kernel y espacio de usuario suele ser la diferencia entre “aceptable” y “¿por qué un núcleo está al 100%?”

Una idea operacional parafraseada de un notable en confiabilidad aplica aquí: paráfrasis: “La simplicidad es prerrequisito para la fiabilidad.” — John Ousterhout (paráfrasis)

Configura OpenVPN correctamente: la base que evita dolores autoinfligidos

Elige una topología sensata: enrutada (tun) a menos que tengas una razón muy específica

Usa dev tun y enruta subredes IP. El bridging (tap) arrastra tráfico L2 broadcast dentro del túnel, aumenta el ruido
y hace que la resolución sea como perseguir mapaches en un falso falso techo.

Usa UDP para el plano de datos

A menos que tu entorno bloquee UDP de forma absoluta, elígelo. El modo TCP es para “estoy atrapado en un portal Wi‑Fi de hotel de 2009.”
Si controlas ambos extremos, no uses TCP por defecto. Te traicionará bajo pérdida.

Usa cifrado moderno acelerado por hardware

En servidores x86 típicos, AES-GCM con AES-NI es rápido. ChaCha20-Poly1305 también es excelente, especialmente en dispositivos sin aceleración AES.
No te pongas creativo con cifrados exóticos “por seguridad”. La seguridad incluye disponibilidad, y una VPN que va a paso de tortuga anima a los usuarios a eludirla.

Mantén la configuración aburrida

“Aburrido” significa: plugins mínimos, scripts mínimos, pushes mínimos personalizados, y pocas anulaciones por cliente.
Cada perilla extra es un nuevo modo de fallo, y OpenVPN tiene suficientes perillas como para calificar como órgano de tubos.

Planifica MTU y MSS desde el inicio

Quieres que el túnel evite fragmentación en la ruta real de Internet. En la práctica, debes clamar MSS para sesiones TCP
para que los endpoints no intenten enviar segmentos demasiado grandes. Esto no es opcional si quieres “que funcione en todas partes”.

Registro y observabilidad son parte de la configuración

Si no puedes responder “¿es CPU, MTU, pérdida o congestión?” en cinco minutos, no configuraste una VPN de producción.
Configuraste una novela de misterio.

Broma #1: Las configuraciones de OpenVPN son como cajones de cocina con cachivaches—todo funciona hasta que necesitas una cosa rápidamente.

Por qué OpenVPN suele ser más lento que WireGuard (sin religiones)

Ruta de datos en espacio de usuario vs kernel

WireGuard en Linux se ejecuta en el kernel, así que los paquetes entran al kernel, se cifran/descifran y siguen con menos transiciones.
OpenVPN clásico típicamente lee paquetes desde un dispositivo TUN en espacio de usuario, cifra/descifra y vuelve a escribir.
Eso significa más cambios de contexto y copias de memoria. A bajo ancho de banda no lo notarás. A altas tasas de paquetes sí.

La tasa de paquetes importa más que el ancho de banda para la CPU. Muchos paquetes pequeños (VoIP, gaming, RPC, microservicios chatos)
pueden saturar un núcleo de CPU mucho antes de que satures un enlace. La sobrecarga de OpenVPN se manifiesta aquí primero.

Complejidad del protocolo y charla del plano de control

OpenVPN está construido sobre TLS, soporta renegociación, múltiples mecanismos de auth y un set rico de extensiones.
Eso es poderoso. También son más partes móviles: más estado, más rutas de código y más formas de caer en un camino lento.
El modelo de WireGuard es intencionalmente más estrecho.

Opciones de cripto y detalles de implementación

OpenVPN puede ser muy rápido con el cifrado correcto, pero también puede ser dolorosamente lento con el equivocado.
AES-CBC + HMAC puede ser aceptable, pero AES-GCM suele ser mejor, y valores predeterminados obsoletos aún pueden acechar en despliegues antiguos.
WireGuard estandariza primitivas modernas; no “eliges” de un menú, así no eliges lo incorrecto.

El colapso TCP sobre TCP es real

Si ejecutas OpenVPN sobre TCP y llevas tráfico de aplicaciones TCP dentro, has creado dos bucles de control de congestión.
La pérdida desencadena retransmisiones en ambas capas; la latencia sube; las ventanas se reducen; el rendimiento colapsa.
WireGuard es solo UDP; evita toda esta categoría por diseño.

Manejo del MTU y penalizaciones por fragmentación

Tanto OpenVPN como WireGuard pueden sufrir si el MTU está mal. Pero las implementaciones de OpenVPN con más frecuencia heredan configuraciones legadas como
MTUs fijas, compresión extra (no lo hagas), y scripts heredados. Las configuraciones de WireGuard tienden a ser más cortas y más nuevas,
lo que significa menos minas históricas.

DCO cambia la comparación

OpenVPN con Data Channel Offload (ovpn-dco) mueve el plano de datos más cerca del kernel, reduciendo sustancialmente la sobrecarga.
Si necesitas las funciones empresariales de OpenVPN pero quieres rendimiento similar a WireGuard, DCO es lo primero a evaluar.
No todas las plataformas lo soportan por igual, y la madurez operativa varía según la distribución.

Broma #2: Ejecutar TCP sobre TCP para “fiabilidad” es como llevar dos impermeables y quejarte de que no puedes mover los brazos.

Guía rápida de diagnóstico: encuentra el cuello de botella en minutos

Cuando alguien dice “OpenVPN está lento”, necesitas un orden de triage repetible. No empieces cambiando cifrados.
Empieza por demostrar dónde viven los tiempos y las pérdidas.

Primero: confirma lo obvio (transporte, ruta, MTU)

1. Comprueba si estás usando UDP. Si es TCP: sospecha de inmediato el colapso TCP sobre TCP.
2. Comprueba síntomas de MTU/MSS. Si “algunos sitios cuelgan” o “descargas grandes se detienen”, sospecha del MTU.
3. Comprueba pérdida y jitter. Si hay pérdida, el rendimiento caerá incluso con cifrado perfecto.

Segundo: confirma si el servidor está limitado por CPU o por tasa de paquetes

1. Busca un único núcleo acaparado. OpenVPN frecuentemente se convierte en cuello de botella en un hilo que maneja cripto o I/O.
2. Mide presión de softirq y drops de NIC. Si estás perdiendo antes de que OpenVPN vea paquetes, afinar OpenVPN es cosmético.
3. Comprueba cifrado y opciones de offload del kernel. Si usas un cifrado lento o falta DCO, lo notarás.

Tercero: valida enrutamiento/NAT y colas

1. Revisa qdisc y bufferbloat. Una disciplina de colas equivocada puede añadir latencia enorme bajo carga.
2. Confirma enrutamiento correcto. Si el tráfico hace hairpin a través de un firewall o cruza zonas innecesariamente, tu “problema VPN” es topología.
3. Mide el rendimiento con y sin el túnel. Necesitas una línea base para evitar perseguir fantasmas.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decides

Estas tareas asumen un servidor OpenVPN en Linux. Ajusta rutas según tu distro. Cada tarea incluye: comando, salida de ejemplo, significado y decisión.
Ejecútalas en este orden cuando estés en modo respuesta a incidentes en producción.

Tarea 1: Confirma que OpenVPN usa UDP (no TCP)

cr0x@server:~$ sudo ss -lunpt | grep openvpn
udp   UNCONN 0      0            0.0.0.0:1194       0.0.0.0:*    users:(("openvpn",pid=1324,fd=6))

Qué significa: El servidor escucha en UDP/1194. Si ves tcp en su lugar, espera peor rendimiento bajo pérdida.
Decisión: Si TCP está presente por accidente, cambia a UDP salvo que tengas una restricción de firewall estricta.

Tarea 2: Comprueba el cifrado negociado y parámetros del canal de datos

cr0x@server:~$ sudo journalctl -u openvpn-server@server --since "1 hour ago" | egrep -i "Data Channel|Cipher|peer info" | tail -n 8
Dec 27 09:20:11 server openvpn[1324]: Control Channel: TLSv1.3, cipher TLS_AES_256_GCM_SHA384
Dec 27 09:20:11 server openvpn[1324]: [client1] Peer Connection Initiated with [AF_INET]203.0.113.10:51234
Dec 27 09:20:11 server openvpn[1324]: [client1] Data Channel: cipher 'AES-256-GCM', peer-id: 0

Qué significa: Estás con AES-256-GCM para el canal de datos. Buen valor predeterminado en hardware con AES-NI.
Decisión: Si ves cifrados solo CBC o ajustes legados, moderniza. Si los clientes son dispositivos ARM débiles, considera ChaCha20 si tu pila OpenVPN lo soporta bien.

Tarea 3: Comprueba si DCO está activo (si lo esperas)

cr0x@server:~$ sudo modprobe -n ovpn-dco && lsmod | grep ovpn
insmod /lib/modules/6.1.0-18-amd64/kernel/drivers/net/ovpn/ovpn-dco.ko
ovpn_dco               94208  0

Qué significa: El módulo DCO existe y está cargado.
Decisión: Si esperabas DCO pero falta, deja de afinar el espacio de usuario primero. Arregla la capacidad de la plataforma y las elecciones de build/paquete de OpenVPN.

Tarea 4: Mide saturación de CPU del servidor y acaparamiento por hilo

cr0x@server:~$ top -b -n 1 | head -n 12
top - 09:31:02 up 32 days,  3:11,  2 users,  load average: 3.12, 2.98, 2.71
Tasks: 189 total,   1 running, 188 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  2.1 sy,  0.0 ni, 85.2 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  32118.5 total,  11234.7 free,   4231.9 used,  16651.9 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1324 nobody    20   0  143832  21572   9856 R  98.7   0.1  10:44.02 openvpn

Qué significa: OpenVPN está consumiendo un núcleo de CPU (~99%). Este es un comportamiento clásico de techo de rendimiento para OpenVPN en espacio de usuario.
Decisión: Si esto se correlaciona con “VPN lenta”, estás limitado por CPU/tasa de paquetes. Considera DCO, escalar horizontalmente o mover cargas a WireGuard.

Tarea 5: Confirma que AES-NI / aceleración cripto está disponible

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

Qué significa: La CPU tiene las banderas AES y PCLMULQDQ—buenos indicios para AES-GCM rápido.
Decisión: Si faltan las banderas AES (común en algunas VMs pequeñas o hardware viejo), espera que AES-GCM sea más lento. Considera ChaCha20 si tu stack OpenVPN lo soporta sin problemas.

Tarea 6: Comprueba errores y drops de la NIC (no culpes a OpenVPN por un mal día de NIC)

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  missed   mcast
    9876543210 8432190      0    1274       0  10233
    TX:  bytes packets errors dropped carrier collsns
    8765432109 7321987      0       9       0      0

Qué significa: Existen drops en RX. Podrían ser ráfagas, límites del ring buffer o congestión upstream.
Decisión: Si los drops suben durante las quejas, investiga colas de NIC, driver y congestión del host antes de editar configuraciones de OpenVPN.

Tarea 7: Busca presión en el buffer de recepción UDP

cr0x@server:~$ netstat -su | egrep -i "receive errors|packet receive errors|RcvbufErrors|InErrors"
    204 packet receive errors
    198 RcvbufErrors

Qué significa: El kernel está descartando paquetes UDP por límites de buffer de recepción.
Decisión: Aumenta los buffers de socket y revisa ajustes sysctl; de lo contrario perseguirás una “lentitud de VPN” que en realidad son drops del kernel.

Tarea 8: Inspecciona sysctls clave para buffers UDP y reenvío

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

Qué significa: Los buffers son pequeños para un servidor VPN ocupado.
Decisión: Si viste RcvbufErrors, incrementa estos con cuidado y monitoriza. Si ip_forward está apagado, el enrutamiento fallará y verás “VPN conectada pero nada funciona.”

Tarea 9: Confirma enrutamiento y que existan rutas de retorno

cr0x@server:~$ ip route show table main | head
default via 198.51.100.1 dev eth0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.20

Qué significa: La subred VPN existe y está adjunta a tun0.
Decisión: Si falta la ruta, tu instancia OpenVPN no está creando el dispositivo túnel o está mal configurada. Arregla eso antes del trabajo de rendimiento.

Tarea 10: Comprueba reglas NAT si los clientes necesitan acceso a Internet

cr0x@server:~$ sudo iptables -t nat -S | egrep 'POSTROUTING|MASQUERADE'
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Qué significa: El tráfico de clientes VPN se NATea por eth0.
Decisión: Si los clientes se quejan “conectado pero sin internet”, la falta de NAT es un sospechoso habitual (asumiendo que haces túnel completo).

Tarea 11: Detecta agujeros negros MTU con ping + DF (no fragmentar)

cr0x@server:~$ ping -c 3 -M do -s 1472 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=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

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

Qué significa: El MTU efectivo a lo largo de la ruta (desde este contexto de host/interfaz) está alrededor de 1420. Tu suposición de 1500 falla.
Decisión: Establece un MTU de túnel apropiado y/o clampa MSS. Si lo ignoras, tendrás bloqueos intermitentes y “funciona en Wi‑Fi, falla en LTE.”

Tarea 12: Comprueba que el clamping MSS esté en su lugar (cuando el enrutamiento/NAT lo requiere)

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

Qué significa: El MSS se está recortando basado en PMTU, reduciendo problemas de fragmentación para flujos TCP.
Decisión: Si falta y tienes problemas de MTU, añade el clamping y vuelve a probar el síntoma “algunos sitios cuelgan”.

Tarea 13: Mide rendimiento base fuera de la VPN

cr0x@server:~$ iperf3 -c 198.51.100.50 -P 4 -t 10
[SUM]   0.00-10.00  sec  4.82 GBytes  4.14 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  4.78 GBytes  4.10 Gbits/sec  12            receiver

Qué significa: La ruta de red cruda puede hacer ~4.1 Gbit/s.
Decisión: Si el rendimiento VPN está muy por debajo de esto, no es el uplink. Es el procesamiento del túnel, MTU o limitaciones de endpoint.

Tarea 14: Mide rendimiento a través de la VPN (servidor→cliente o cliente→servidor)

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

Qué significa: Estás listo para probar desde un cliente VPN conectado hacia la IP VPN del servidor.
Decisión: Compara rendimiento VPN vs no VPN. Si la brecha es enorme y la CPU del servidor está acaparada, encontraste tu límite.

Tarea 15: Inspecciona qdisc (disciplina de colas) para latencia bajo carga

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
 Sent 8765432109 bytes 7321987 pkt (dropped 9, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Qué significa: fq_codel está activo, drops bajos, backlog vacío. Esto suele ser bueno para la latencia.
Decisión: Si ves una qdisc FIFO tonta y gran backlog, espera bufferbloat. Arregla la gestión de colas antes de culpar a la VPN.

Tarea 16: Comprueba la tasa de paquetes por proceso y los cambios de contexto

cr0x@server:~$ pidstat -p $(pgrep -n openvpn) -w 1 3
Linux 6.1.0-18-amd64 (server)  12/27/2025  _x86_64_  (8 CPU)

09:44:01      UID       PID   cswch/s nvcswch/s  Command
09:44:02      65534    1324    120.00   8400.00  openvpn
09:44:02      65534    1324    115.00   8600.00  openvpn
09:44:03      65534    1324    118.00   8550.00  openvpn

Qué significa: Muchos context switches no voluntarios pueden indicar contención y presión del planificador, común cuando una ruta de datos en espacio de usuario está ocupada.
Decisión: Si esto es alto durante pruebas de rendimiento, te beneficiará DCO, reducir paquetes (MTU/agrupación) o mover flujos pesados a un túnel más eficiente.

Tres micro-historias corporativas (realistas, anonimadas, levemente dolorosas)

Micro-historia 1: El incidente causado por una suposición equivocada

Una compañía mediana desplegó OpenVPN para conectar sitios retail con la sede. El despliegue parecía limpio: mismo modelo de appliance, misma plantilla de configuración,
mismo nivel de ISP en papel. Validaron una ubicación piloto y luego la clonan a cuarenta más.

Dos semanas después empezaron las llamadas de soporte: “la herramienta de inventario caduca”, “el batch de tarjetas falla”, “la VPN es inestable”. La VPN seguía conectada.
Los pings funcionaban. Pero transferencias grandes se quedaban atascadas de forma impredecible. Los ingenieros hicieron lo que hacen bajo presión: cambiaron cifrados y subieron keepalives.
Nada cambió.

La suposición equivocada fue simple: “MTU es 1500 en todas partes.” Varios ISPs entregaban PPPoE o enlaces con restricciones.
Dentro del túnel, los paquetes crecían, se fragmentaban y algunos caminos descartaban fragmentos. Clásico PMTU blackholing.
Los bloqueos eran más visibles en respuestas HTTPS grandes y consultas de base de datos con conjuntos de resultados voluminosos.

La solución fue aburrida: aplicar MSS clamping, fijar un MTU de túnel conservador y volver a probar desde los peores sitios.
El incidente se cerró sin heroísmos, solo humildad y una nota permanente en la checklist de despliegue:
nunca asumas el MTU, mídelo siempre.

Micro-historia 2: La optimización que salió mal

Un equipo de plataforma interno quería más rendimiento de su concentrador OpenVPN. Encontraron un post antiguo que sugería buffers de socket más grandes
y aumentaron net.core.rmem_max y wmem_max drásticamente. También incrementaron los buffers internos de OpenVPN.
En pruebas sintéticas en una red de laboratorio limpia mejoró. Lo llevaron a producción.

Un mes después llegó otra queja: “la VPN se siente con lag durante las llamadas.” No “descargas lentas”—lag. Las reuniones de video tartamudeaban.
Las sesiones SSH se sentían pegajosas. Los gráficos de throughput estaban bien. El equipo estaba confundido, una emoción corporativa popular.

El contragolpe fue colas. Buffers enormes más un enlace ocupado crearon bufferbloat: paquetes se quedaban en colas más tiempo, y el tráfico interactivo sufría.
Voz y video son sensibles a la latencia. No les importa que tu túnel pueda empujar más bits por segundo si esos bits llegan tarde.

Revirtieron a buffers moderados, aseguraron fq_codel en la interfaz de salida y moldearon el tráfico ligeramente por debajo del uplink físico
para controlar la ubicación de las colas. El throughput bajó un poco. La experiencia de usuario mejoró mucho. La lección real: “más rápido” no es un escalar.
Depende de lo que hagan tus usuarios y de lo que tu red esté ocultando.

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

Una organización centrada en seguridad ejecutaba WireGuard y OpenVPN: WireGuard para laptops gestionadas, OpenVPN para contratistas y “dispositivos raros”
que no podían ejecutar el cliente estándar. El servicio OpenVPN no era glamuroso, así que lo trataron como cualquier otro servicio de producción:
versiones de paquetes fijadas, ventana de cambios y un canario.

Un día necesitaban rotar certificados y ajustar preferencias de cifrado por cumplimiento. El cambio estaba programado y probado.
El grupo canario era pequeño pero diverso: un cliente macOS, uno Windows, uno Linux, uno móvil.
Vigilaron logs por fallos de negociación y midieron throughput y tasas de reconexión.

El canario captó una sorpresa: un cliente contratista más antiguo no soportaba la nueva combinación de suites de cifrado que el equipo había elegido.
A escala de producción eso habría sido un incidente el lunes por la mañana con audiencia ejecutiva.
En su lugar, ajustaron la lista de cifrados para mantener una alternativa compatible y publicaron una recomendación de actualización de cliente.

No pasó nada dramático. Ese es el punto. La práctica aburrida—canario más una pequeña matriz de compatibilidad—previno una caída por compatibilidad.
No te dan un trofeo por esto. Te dan la comida tranquila.

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

1) “La VPN está conectada, pero algunos sitios nunca terminan de cargar”

Causa raíz: MTU/PMTU blackholing; fragmentación descartada en algunos caminos; falta de MSS clamping.
Solución: Mide MTU efectivo con pings DF; clampa MSS (TCPMSS --clamp-mss-to-pmtu); fija un tun-mtu conservador si es necesario.

2) “Es rápido en la Wi‑Fi de la oficina pero terrible en LTE o redes de hotel”

Causa raíz: Pérdida/jitter en la ruta más presión en buffers UDP; a veces UDP es limitado por redes cautivas; variabilidad de MTU.
Solución: Asegura que los buffers UDP no estén descartando; considera un listener TCP secundario solo para redes hostiles; ajusta MTU; valida con pruebas del mundo real.

3) “El throughput se queda en ~100–300 Mbps en un servidor grande”

Causa raíz: OpenVPN en espacio de usuario está limitado por CPU/tasa de paquetes; un núcleo acaparado; cifrado lento o sin aceleración AES.
Solución: Cambia a AES-GCM con soporte hardware; habilita DCO donde sea posible; escala horizontalmente; considera WireGuard para cargas de alto throughput.

4) “La latencia explota durante descargas grandes”

Causa raíz: Bufferbloat por buffers sobredimensionados o qdisc pobre; uplink congestionado; colas en el lugar equivocado.
Solución: Usa fq_codel o CAKE; modela ligeramente por debajo del uplink; no infles buffers a ciegas.

5) “Los clientes se conectan, pero no alcanzan subredes internas”

Causa raíz: Rutas faltantes en el servidor o routers downstream; ip_forward deshabilitado; conflictos de policy routing/NAT.
Solución: Confirma que existan rutas, habilita forwarding, empuja rutas correctas, asegura que exista la ruta de retorno correcta (no confíes en NAT por accidente).

6) “Reconexiones aleatorias o bloqueos bajo carga”

Causa raíz: Pérdida de paquetes, drops UDP, errores de receive buffer, o servidor sobrecargado causando keepalives retardados.
Solución: Revisa netstat -su errores, drops de NIC, acaparamiento de CPU; reduce tasa de paquetes; aumenta buffers con cuidado; escala horizontalmente.

7) “Se volvió más lento después de habilitar compresión”

Causa raíz: La compresión añade carga de CPU y puede interactuar mal con tráfico ya comprimido y con restricciones de seguridad.
Solución: Desactiva compresión para el canal de datos; céntrate en MTU, cripto y enrutamiento. La compresión no es un almuerzo gratis; normalmente no lo es.

8) “Cambiamos a TCP para hacerlo más fiable, y ahora está peor”

Causa raíz: Colapso TCP sobre TCP bajo pérdida y reordenamiento.
Solución: Usa UDP. Si está bloqueado, usa TCP como perfil de fallback solo y deja claras las expectativas: es modo de compatibilidad, no de rendimiento.

Listas de verificación / plan paso a paso

Paso a paso: una base correcta de OpenVPN para producción

1. Elige modo TUN enrutado a menos que realmente necesites bridging L2.
2. Usa UDP como transporte predeterminado.
3. Elige cifrados modernos (AES-GCM en servidores con AES-NI; evita setups legados solo CBC).
4. Desactiva compresión para el canal de datos en entornos modernos.
5. Planifica MTU: prueba pings DF; clampa MSS para flujos TCP.
6. Configura enrutamiento correctamente: empuja rutas deliberadamente; asegura rutas de retorno.
7. Decide NAT vs enrutado para acceso a Internet de clientes y alcance interno. Documenta la elección.
8. Observabilidad: registra negociaciones, conexiones de clientes, razones de desconexión; recoge CPU, drops y contadores de error UDP.
9. Prueba de capacidad usando iperf3 a través del túnel con concurrencia y tamaños de paquete realistas.
10. Ten un perfil de fallback (TCP o puerto alternativo) para redes hostiles—claramente etiquetado como más lento.
11. Automatiza distribución de configs cliente y mantén una pequeña matriz de compatibilidad.
12. Cadencia de parches: trata OpenVPN como cualquier servicio edge. Ventanas de cambio y canarios.

Paso a paso: decide si mantener OpenVPN o mover tráfico a WireGuard

1. Mide el techo actual: throughput de la VPN vs utilización de CPU y drops de paquetes.
2. Si un núcleo está acaparado, evalúa DCO primero si necesitas funciones de OpenVPN.
3. Si principalmente necesitas site-to-site o clientes gestionados, WireGuard suele ser operacionalmente más simple y rápido.
4. Mantén OpenVPN para entornos que necesitan integraciones maduras de auth empresarial y amplia compatibilidad de clientes.
5. Realiza un piloto: un pequeño grupo con WireGuard; compara latencia bajo carga, comportamiento de reconexión y carga de soporte.

Preguntas frecuentes

¿OpenVPN es inherentemente lento?

No. A menudo es más lento que WireGuard a altas tasas de paquetes porque OpenVPN clásico ejecuta la ruta de datos en espacio de usuario y paga la sobrecarga.
Con buenas configuraciones y soporte DCO, OpenVPN puede ser suficientemente rápido para muchas organizaciones.

¿Por qué OpenVPN a veces satura un núcleo de CPU?

El cifrado/descifrado y mover paquetes entre kernel y espacio de usuario pueden convertirse en caminos calientes monohilo.
Paquetes pequeños empeoran el problema porque la tasa de paquetes aumenta. El síntoma es un núcleo al 100% mientras los demás están ociosos.

¿Debería ejecutar OpenVPN sobre TCP por fiabilidad?

No como predeterminado. El colapso TCP sobre TCP es un modo de fallo clásico bajo pérdida. Usa UDP a menos que tus clientes estén en redes que lo bloqueen.
Si debes ofrecer TCP, trátalo como perfil de fallback.

¿Cuál es el bug de rendimiento más común en OpenVPN?

Problemas de MTU. Se disfrazan de “lentitud aleatoria” y “algunos sitios no funcionan.” Mide MTU y clampa MSS.
No es glamuroso, por eso sigue ocurriendo.

¿AES-256-GCM hace que OpenVPN sea más lento que AES-128-GCM?

A veces un poco, dependiendo de la CPU e implementación, pero las ganancias mayores suelen venir de la arquitectura y la tasa de paquetes.
No persigas micro-optimizaciones hasta confirmar que estás limitado por CPU y que usas aceleración hardware.

¿Cómo sé si estoy limitado por pérdida de paquetes vs CPU?

Si el servidor muestra errores de receive buffer UDP, drops de NIC o pérdida en la ruta (y la CPU no está al máximo), probablemente estás limitado por pérdida/congestión.
Si OpenVPN está al ~100% en un núcleo durante pruebas, probablemente estás limitado por CPU/tasa de paquetes.

¿WireGuard siempre es más rápido?

A menudo, pero no siempre. Si tu cuello de botella es el ISP, Wi‑Fi, pérdida LTE o CPU del cliente remoto, cambiar de VPN no generará ancho de banda.
La ventaja de WireGuard es mayor en Linux donde la ruta in-kernel y el protocolo ligero reducen la sobrecarga.

¿Puedo simplemente aumentar buffers para hacer OpenVPN más rápido?

Aumentar buffers puede reducir drops, pero también puede incrementar la latencia y empeorar las cargas interactivas.
Ajusta buffers en función de drops y latencia medidos bajo carga, y mantén disciplinas de colas sensatas en la salida.

¿Qué es OpenVPN DCO y debería usarlo?

DCO (Data Channel Offload) mueve más procesamiento de paquetes al kernel, reduciendo la sobrecarga en espacio de usuario.
Si necesitas funciones de OpenVPN pero quieres mejor throughput/latencia, vale la pena evaluarlo—con cuidado, usando canarios y pruebas de compatibilidad de clientes.

¿Cuándo debería mantener OpenVPN en lugar de migrar?

Si dependes de integraciones maduras de autenticación empresarial, pushes de políticas complejas o amplia compatibilidad con clientes de terceros, OpenVPN sigue siendo práctico.
También puedes ejecutar ambos: WireGuard para endpoints gestionados, OpenVPN para “todo lo demás.”

Conclusión: qué hacer a continuación

Si quieres que OpenVPN se comporte, hazlo aburrido: UDP, TUN enrutado, cifrados modernos, sin compresión y MTU manejado deliberadamente.
Luego instrumentalo como si realmente te importara—CPU, drops, errores de buffer UDP y colas.

Si necesitas máximo throughput y baja latencia a escala en Linux, WireGuard suele ganar porque fue diseñado para evitar el impuesto del espacio de usuario.
Si necesitas el ecosistema y controles de OpenVPN, considera DCO y diseños de escala horizontal. En cualquier caso: mide primero, cambia después y escribe lo aprendido para no volver a aprenderlo a las 2 a.m.