Dudas entre WireGuard y OpenVPN para tu VPN auto-alojado. Has leído por todas partes que "WireGuard es más rápido" sin mucha explicación del porqué, ni de cuándo OpenVPN sigue siendo la opción correcta. Esta guía compara ambos protocolos de forma honesta, en lo que de verdad importa para una VPN auto-alojada en VPS: throughput, latencia, coste de CPU, modelo de seguridad y compatibilidad - con un veredicto por caso de uso.
Versión corta: WireGuard gana en general en rendimiento bruto y simplicidad, pero OpenVPN conserva una ventaja legítima, a veces decisiva, en dos situaciones concretas.
¿Es WireGuard más rápido que OpenVPN en un VPS?
En general, sí. WireGuard corre en el kernel Linux, usa una sola suite criptográfica moderna y añade muy poco overhead por paquete: en un enlace VPS rápido entrega un throughput cercano a la línea bruta usando una fracción de la CPU. OpenVPN corre como demonio en userland: cada paquete cruza la frontera kernel/userland para el cifrado, lo que cuesta CPU y throughput - sobre todo en hardware poco potente. OpenVPN además reconecta más lento en cambios de red, donde el diseño stateless de WireGuard se reanuda casi al instante.
Respuesta directa
WireGuard vs OpenVPN en un VPS de 1 Gbps - comparación cualitativa:
| Aspecto | WireGuard | OpenVPN 2.6 |
|---|---|---|
| Throughput bruto | Generalmente mayor (cerca de la línea) | Generalmente menor (overhead TLS + userland) |
| Overhead de latencia | Menor | Mayor (sobre todo en TCP) |
| Coste de CPU | Bajo (espacio de kernel) | Mayor (userland, context-switches por paquete) |
| Tamaño del código | ~4.000 líneas C | ~70.000 líneas C (+ OpenSSL) |
| Espacio de kernel | Sí (Linux 5.6+, marzo 2020) | No (demonio en userland) |
| Bypass firewall (TCP/443) | No (solo UDP) | Sí |
| Historial de auditoría | Cure53 2018 - sin vulns críticas | OSTIF 2017/2018 - sin RCE crítico |
Veredicto: WireGuard para rendimiento y simplicidad en cualquier VPS moderno. OpenVPN cuando necesitas bypass TCP/443 (firewalls corporativos/hoteles) o soportar hardware legacy (routers DD-WRT, OpenWRT <21, OS clientes muy antiguos).
Esta comparativa se basa en las características públicas y documentadas de ambos protocolos, no en un único test privado. Nuestra metodología →
Por qué WireGuard suele ser más rápido
La brecha de rendimiento no es marketing: se deriva directamente de cómo está construido cada protocolo.
WireGuard corre en espacio de kernel. Se presenta como un módulo de kernel (wireguard.ko), incluido en el kernel Linux mainline desde la 5.6 (marzo 2020). Los paquetes se cifran y enrutan sin salir del kernel, evitando los costosos context-switches user/kernel que dominan el coste de OpenVPN en enlaces cargados.
WireGuard es pequeño y fijo. Unas 4.000 líneas de C, con una sola suite cripto moderna (Curve25519, ChaCha20-Poly1305, BLAKE2s). Nada que ajustar y ningún overhead de negociación - obtienes el mismo camino rápido cada vez.
OpenVPN corre en userland sobre TLS. Es un demonio que usa OpenSSL; cada paquete hace un ida-vuelta kernel → userland → kernel para el cifrado. Es flexible (sabe hacer casi todo) pero cuesta CPU y throughput, y el efecto es mucho mayor en hardware débil sin aceleración AES.
El overhead del protocolo en sí es pequeño para ambos. Una cabecera VPN más el framing UDP/IP se come unos pocos por ciento de cualquier enlace independientemente del protocolo - esa parte es aritmética, no ineficiencia.
Latencia y jitter
WireGuard suele añadir menos latencia de ida y vuelta que OpenVPN, y OpenVPN sobre TCP es el peor caso: pasar TCP dentro de un túnel TCP ("TCP-sobre-TCP") provoca retransmisiones en cascada en cuanto el enlace subyacente pierde un paquete, lo que dispara latencia y jitter. En un enlace cableado limpio es tolerable; en Wi-Fi o 4G con pérdida, se degrada bastante.
Para uso diario - navegación, streaming 4K, videollamadas - el overhead de WireGuard es imperceptible, y OpenVPN sobre UDP también sigue fluido. El caso a evitar para uso sensible a la latencia (gaming competitivo, VoIP exigente) es OpenVPN sobre TCP, salvo que lo necesites específicamente para atravesar un firewall.
Consumo de CPU
Como corre en el kernel, WireGuard usa bastante menos CPU por megabit que OpenVPN, que gasta ciclos moviendo cada paquete entre userland y kernel. En un VPS multinúcleo rara vez importa para un túnel personal. Importa mucho en hardware ARM modesto (p. ej. una Raspberry Pi sin AES-NI), donde OpenVPN puede saturar un núcleo bastante antes de llenar el enlace mientras WireGuard se mantiene holgado - dejando CPU para lo que la máquina haga además (un gestor de contraseñas, un pequeño cloud, analítica).
En hardware con aceleración AES (la mayoría de x86 modernos, Apple Silicon), el AES-256-GCM de OpenVPN está acelerado por hardware y la brecha de CPU se reduce; sin ella, ChaCha20 es la mejor elección de cifrado para OpenVPN. El ChaCha20-Poly1305 de WireGuard es rápido en ambos casos.
Estabilidad y roaming móvil
WireGuard es stateless por diseño: no hay "conexión" que establecer, solo peers conocidos. Cuando un cliente pasa de Wi-Fi a datos móviles y vuelve, el túnel se reanuda casi al instante sin renegociación. OpenVPN tiene que rehacer un handshake TLS en cada cambio de red, lo que tarda unos segundos. Para un teléfono que cambia de red todo el día, el comportamiento de roaming de WireGuard es una ventaja real y tangible.
Un pasillo de datacenter: una VPN auto-alojada corre en un único VPS en una instalación de este tipo - la elección de protocolo determina sobre todo la eficiencia con la que ese servidor mueve tu tráfico.
Análisis de seguridad
El debate de seguridad suele estar sesgado por "OpenVPN existe desde hace 20 años, así que es más maduro". Veamos los hechos:
WireGuard:
- Primitivas cripto modernas y fijas: Curve25519 (intercambio de claves), ChaCha20-Poly1305 (AEAD), BLAKE2s (hash), SipHash24 (tabla hash).
- ~4.000 líneas de código C en el módulo del kernel - una superficie de ataque pequeña y auditable.
- Auditoría formal por Cure53 publicada en 2018 - ninguna vulnerabilidad crítica encontrada. Una revisión aparte de Trail of Bits (2020) se centró en la implementación macOS.
- Incluido en el kernel Linux mainline desde la 5.6 (marzo 2020), revisado por la comunidad netdev.
- No hay configuración cripto posible por diseño: imposible elegir una opción débil por error.
OpenVPN:
- Primitivas configurables: el valor por defecto moderno es AES-256-GCM, pero una config descuidada copiada de un tutorial antiguo podría aún seleccionar algo débil.
- ~70.000 líneas de código C más OpenSSL como gran dependencia - una superficie mucho mayor que razonar.
- Auditorías OSTIF en 2017 y 2018 - algunos bugs encontrados y corregidos, ninguna RCE crítica.
- Históricamente expuesto a fallos de OpenSSL (Heartbleed en 2014 afectó a despliegues que usaban OpenSSL).
Veredicto honesto: ambos son sólidos en 2026. WireGuard tiene una ventaja arquitectónica (menor superficie de ataque, primitivas modernas, sin trampas de config). OpenVPN tiene una ventaja de madurez (dos décadas en producción, ampliamente auditado, enorme base de despliegue). Para auto-hosting, WireGuard es el valor por defecto fácil - la relación simplicidad/seguridad es excelente.
Throughput por plataforma cliente
Entre las plataformas de escritorio con soporte WireGuard nativo (Linux, macOS, Windows), el throughput sostenido es bastante similar, ya que los kernels recientes y el driver nativo moderno de Windows han cerrado la mayor parte de la brecha histórica. Donde verás una diferencia real es en teléfonos: en transferencia sostenida a máxima velocidad, los móviles hacen throttling por motivos térmicos y de batería y no igualan a un escritorio. Es un comportamiento móvil esperado, sin impacto para uso normal (navegación, streaming) - solo aparece si fuerzas un teléfono con iperf3 o un backup pesado.
Para medir tu propio setup en lugar de fiarte de las cifras de nadie, los comandos de test reproducibles están al final del artículo.
Cuándo OpenVPN sigue siendo relevante en 2026
El marketing WireGuard es tan dominante que olvidamos que OpenVPN aún tiene casos de uso sólidos. Estas son las situaciones donde sigue siendo la herramienta correcta.
Caso 1: bypass firewall corporativo / hotelero
Muchos firewalls corporativos (Fortinet, Palo Alto, Check Point) bloquean el UDP saliente no-DNS. Puedes toparte con esto en el Wi-Fi de un cliente, en ciertos hoteles, o en algunos hotspots de transporte. Como WireGuard es UDP-only, el túnel falla silenciosamente (el handshake no se completa). Puedes envolver WireGuard con wstunnel o Cloak para llevarlo por TCP/443, pero es una capa extra a mantener.
OpenVPN soporta de forma nativa el modo TCP en puerto 443, con un handshake TLS que se parece a tráfico HTTPS ordinario, así que pasa por muchos DPI simples. Para un uso "VPN de emergencia cuando estoy en Wi-Fi corporativo poco amigable", mantener un perfil OpenVPN TCP/443 listo es pragmático.
Setup mínimo en el mismo VPS Contabo, además de un WireGuard existente:
sudo apt install -y openvpn easy-rsa
sudo make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
sudo ./easyrsa init-pki
sudo ./easyrsa build-ca nopass
sudo ./easyrsa build-server-full vpnsmith nopass
# Config /etc/openvpn/server/server.conf con:
# proto tcp
# port 443
# dev tun
# cipher AES-256-GCM
Abres el puerto TCP/443 en UFW, luego systemctl enable --now openvpn-server@server. El cliente elige qué perfil usar (WireGuard por defecto, OpenVPN TCP/443 como fallback).
Caso 2: compatibilidad OS legacy
Si tienes que dar acceso al túnel a una máquina Windows 7/8.1, un Synology DSM antiguo, o un Android TV viejo, el cliente WireGuard oficial puede no existir o no estar mantenido ahí. OpenVPN tiene cliente para casi todo desde hace años - incluidos routers DD-WRT antiguos que nunca soportarán WireGuard. Para un familiar atascado en un OS viejo, levantar una segunda instancia OpenVPN dedicada a esa cuenta en el mismo VPS es una solución limpia.
Caso 3 (bonus): audit logging detallado
OpenVPN registra limpiamente cada conexión, desconexión y renegociación TLS. WireGuard mantiene un logging mínimo por diseño (ves sobre todo la interfaz up/down vía journalctl -u wg-quick@wg0). Si tu modelo de amenaza o tu cumplimiento (p. ej. DORA, NIS2, ISO 27001) exige un audit trail formal, OpenVPN es más fácil de satisfacer de entrada.
Veredicto honesto: para una VPN personal en 2026, WireGuard primero. Pero mantener un perfil OpenVPN TCP/443 como config secundaria en el mismo VPS es un pragmatismo sensato - cuesta unos minutos de setup y te salva cuando el UDP está bloqueado.
Veredicto por caso de uso
| Caso de uso | Recomendación |
|---|---|
| VPN auto-alojado personal (1-10 dispositivos) | WireGuard - sin debate |
| Móvil que alterna Wi-Fi/4G | WireGuard - roaming casi instantáneo |
| Saltar firewall corporativo (puerto 443/TCP requerido) | OpenVPN TCP en puerto 443 |
| Site-to-site entre dos datacenters | WireGuard - overhead mínimo |
| Gaming competitivo / VoIP exigente | WireGuard - latencia y jitter inferiores |
| Raspberry Pi / hardware ARM modesto | WireGuard - mucha menos CPU |
| Compatibilidad OS legacy (Windows 7, Android antiguo) | OpenVPN - soporte de cliente más amplio |
| Ofuscación anti-DPI (Irán, China, Rusia) | Ninguno en bruto → wstunnel o Cloak como capa superior |
Si partes de cero para alojar tu propia VPN en un Contabo VPS, sigue nuestra guía WireGuard paso a paso - y copias-pegas los scripts.
Si luchas contra DPI corporativo o estatal, mira la guía de routing custom con bypass DPI que combina WireGuard con una capa de ofuscación.
Si todavía dudas sobre el proveedor de VPS (Contabo vs Hetzner vs OVH), comparamos los tres en condiciones reales.
Mídelo tú mismo con iperf3
En lugar de fiarte de cualquier cifra publicada, mide tu propio VPS y enlace. Instala iperf3 en el servidor, lánzalo en modo servidor, y luego prueba desde tu cliente con y sin el túnel activo:
# Lado servidor (tu VPS)
sudo apt install -y iperf3
sudo iperf3 -s -D
# Lado cliente (Mac/Linux)
# Línea base (sin VPN)
iperf3 -c IP_VPS -t 30 -O 5 --json > baseline.json
# WireGuard (túnel activo)
iperf3 -c 10.66.66.1 -t 30 -O 5 --json > wireguard.json
# OpenVPN UDP (túnel activo)
iperf3 -c 10.8.0.1 -t 30 -O 5 --json > openvpn-udp.json
Lanza varios runs con un bucle for y calcula la mediana vía jq:
jq -s 'map(.end.sum_received.bits_per_second) | sort | .[length/2]' wireguard.json
Si tus cifras parecen anómalas: verifica la MTU (ping -M do -s 1372 IP), la calidad del enlace (un mtr hacia el VPS debe mostrar <1 % de loss), y que el VPS no esté en steal CPU (mpstat -P ALL 1). Un túnel WireGuard que conecta pero va lentísimo en transferencias grandes casi siempre es un problema de MTU - nuestra guía para arreglar el MTU de WireGuard muestra cómo encontrar y ajustar el valor correcto.
Pedir un VPS para tu túnel
Un VPS pequeño basta de sobra para un túnel WireGuard personal: Contabo Cloud VPS 10, plan 24 meses (~5,50 €/mes equivalente). Hace funcionar sin problema un túnel personal junto a un par de servicios auto-alojados ligeros.
Una vez listo el VPS, sáltate el paso de escritura manual de claves: nuestro generador de configuración WireGuard produce un wg0.conf con los parámetros criptográficos correctos en segundos. Para una decisión global de protocolo + proveedor, consulta el hub mejor VPN autoalojado 2026 - cubre WireGuard, Tailscale, Headscale, Nebula y OpenVPN.
Fuentes
- Cure53 - WireGuard formal verification (2018)
- WireGuard whitepaper (Jason A. Donenfeld)
- Documentación oficial OpenVPN 2.6
- Documentación de usuario iperf3
- Benchmarks Phoronix WireGuard kernel 6.x
- Auditoría Trail of Bits WireGuard macOS (2020)
Este artículo es una comparativa técnica cualitativa basada en las características públicas y documentadas de WireGuard y OpenVPN. No reporta un benchmark privado. Para cifras específicas de tu hardware y tu conexión, ejecuta el procedimiento iperf3 de arriba en tu propio VPS.
Disclosure de afiliado: el enlace Contabo de arriba es un enlace trackeado que nos remunera una comisión si te suscribes. No cambia tu precio.
★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados
Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región→

