SSD Nodes Learn Hosting plans →
Guías Matt ConnorPor Matt Connor · Actualizado 2026-08-07

WireGuard frente a OpenVPN: cuál alojar tú mismo

WireGuard gana en velocidad, tamaño de configuración y superficie de auditoría. Compara las pruebas y los cuatro casos concretos en los que OpenVPN sigue siendo mejor.

La respuesta breve

WireGuard frente a OpenVPN, para una persona que ejecuta un servidor VPN en su propio VPS, no plantea una comparación equilibrada: elija WireGuard. Es más pequeño, se ejecuta dentro del kernel de Linux, establece la conexión en una fracción de segundo y una configuración funcional del cliente ocupa unas diez líneas. OpenVPN conserva cuatro usos reales. Si ninguno corresponde a su caso, no lo necesita.

Esos cuatro usos son salir de una red que sólo permite el puerto TCP 443, integrarse con una autoridad de certificación existente, autenticar a usuarios identificados mediante una contraseña o un segundo factor, y crear un puente en la capa 2. Todo lo que sigue aporta las pruebas en las que se basa esta recomendación y señala el punto exacto en el que cada excepción empieza a aplicarse a su caso.

Por qué WireGuard es la opción preferida para quienes administran sus propios servidores

El código es lo bastante pequeño como para leerlo. El proyecto WireGuard implementa su protocolo en aproximadamente 4,000 líneas de código. OpenVPN supera las 100,000 líneas cuando se cuenta la biblioteca OpenSSL de la que depende para todas las operaciones criptográficas. El tamaño importa porque cada línea amplía la superficie de ataque, y ni usted ni quien revise el código van a leer 100,000 líneas. 4,000 sí se pueden leer.

Se ejecuta en el kernel. WireGuard forma parte del kernel principal de Linux desde la versión 5.6, por lo que Ubuntu 24.04 y Debian 13 lo incluyen sin necesidad de compilar nada. Los paquetes se cifran donde ya se encuentran, en el espacio del kernel, sin copiarlos a un proceso del espacio de usuario y de vuelta. Compruébelo antes de hacer cualquier otra cosa:

sudo modprobe wireguard && echo ok

En un VPS KVM, muestra ok. En una virtualización de contenedores que comparte el kernel del host, como OpenVZ o LXC, falla con Operation not supported, porque no se puede cargar un módulo en un kernel que no es suyo.

No hay nada que negociar. WireGuard tiene un único conjunto de cifrado fijo: ChaCha20-Poly1305 para los datos y claves Curve25519. No hay ninguna versión que degradar ni ninguna opción que configurar incorrectamente. OpenVPN negocia el cifrado y la versión de TLS (seguridad de la capa de transporte) con cada cliente. Esto aporta flexibilidad, pero también permite errores de configuración. Un servidor configurado con data-ciphers AES-256-GCM:AES-128-CBC volverá a usar sin problemas el cifrado CBC para un cliente que no ofrezca nada mejor, y el registro no indicará que eso sea un problema.

El puerto no responde. Un paquete de WireGuard que no supera la comprobación de autenticación del mensaje se descarta sin responder, por lo que nmap -sU -p 51820 devuelve open|filtered tanto si hay algo escuchando como si no. Un servidor OpenVPN en modo TCP completa el handshake de TCP antes de decidir que no se permite la conexión. Eso basta para demostrar a un escáner que hay algo presente. OpenVPN sobre UDP con tls-crypt es casi igual de silencioso, por lo que este argumento se aplica a ejecutar OpenVPN sobre TCP, no a OpenVPN en sí.

La itinerancia no tiene coste. Un peer de WireGuard se identifica mediante su clave pública, no mediante su dirección. El portátil cambia de la red doméstica a un hotspot móvil, envía un handshake desde la nueva dirección y el servidor actualiza el endpoint al que responde. Nada se reconecta porque nunca hubo una conexión persistente. OpenVPN puede hacer algo similar con float, pero normalmente el cliente cierra y vuelve a establecer una sesión TLS completa. Por eso la pausa al abrir la tapa es perceptible con OpenVPN, pero no con WireGuard.

Velocidad en 2026: la diferencia se ha reducido

Durante años, el argumento honesto sobre la velocidad era que OpenVPN copiaba cada paquete al espacio de usuario, lo cifraba allí y volvía a copiarlo, mientras WireGuard nunca salía del kernel. Esta ya no es toda la historia, y una comparación que ignore este cambio está desactualizada.

OpenVPN 2.7 se publicó en febrero de 2026 con compatibilidad con el módulo del kernel ovpn, que se integró en Linux 6.16. Esto es DCO (descarga del canal de datos): el canal de control permanece en el espacio de usuario y la ruta de datos principal pasa al kernel, que es aproximadamente lo que WireGuard siempre ha hecho. Con un kernel y una versión de OpenVPN suficientemente recientes para usarlo, el rendimiento está en la misma categoría, no en una diferente. Compruebe qué tiene realmente:

uname -r
openvpn --version | head -n 1
modinfo ovpn 2>/dev/null | head -n 3

En julio de 2026, Ubuntu 24.04 LTS estándar incluye OpenVPN 2.6, no 2.7, y el módulo ovpn necesita la versión 2.7. En esa versión sólo puede usar la descarga mediante el paquete openvpn-dco-dkms antiguo, que compila un módulo externo para el kernel en ejecución y, por tanto, debe volver a compilarse con cada actualización del kernel. Es un componente adicional que WireGuard no necesita.

Lea las limitaciones de DCO antes de considerarlo un motivo para seguir usando OpenVPN. Sólo admite túneles de capa 3, acepta únicamente cifrados AEAD (cifrado autenticado con datos asociados: AES-GCM o ChaCha20-Poly1305), no admite compresión y, en un servidor, sólo funciona con topology subnet. Cada una de estas restricciones elimina parte de la flexibilidad que originalmente justificaba OpenVPN. Un OpenVPN rápido es un OpenVPN configurado para parecerse a WireGuard.

No confíe en ninguna cifra de rendimiento publicada, incluida la de esta página. En una VPS, el límite suele ser la capacidad asignada de CPU o de red, no el protocolo. Mida su propio rendimiento con iperf3 ejecutándose a través del túnel y repita la prueba fuera de él. Después compare ambos resultados.

Cuándo sigue siendo útil OpenVPN

Debe salir por el puerto TCP 443. WireGuard sólo usa UDP de forma deliberada y no tendrá un modo TCP. Una red de hotel o un proxy corporativo que sólo permita TCP 443 dejará pasar OpenVPN configurado con proto tcp-server y port 443, porque ese tráfico parece una sesión TLS normal. WireGuard necesita un wrapper como wstunnel o udp2raw para atravesar la misma red. Esto añade otro proceso que ejecutar y mantener actualizado. Tenga en cuenta el conflicto: si un servidor web ya usa TCP 443 en esa dirección IP, uno de los dos servicios tendrá que cambiar de puerto.

Ya ejecuta una autoridad de certificación. OpenVPN se autentica con certificados X.509, por lo que se integra en una PKI (infraestructura de clave pública) que ya administra. Los certificados caducan automáticamente. Para revocar uno, basta con añadirlo a una lista de revocación de certificados que el servidor lee mediante crl-verify. WireGuard no utiliza certificados, caducidad ni listas de revocación. Para eliminar un peer, debe editar la configuración del servidor y volver a cargarla. Con diez peers, esto es aceptable. Con cuatrocientos y un requisito de auditoría, el modelo de certificados aporta una ventaja real.

Necesita usuarios identificados, no sólo claves. OpenVPN puede delegar la autenticación en un sistema externo mediante auth-user-pass-verify o un plugin como openvpn-plugin-auth-pam.so. Así puede añadir LDAP o un segundo factor basado en una contraseña de un solo uso. WireGuard no tiene ningún concepto de usuario. Una clave está en la configuración o no lo está. Si el requisito es «Sara debe introducir un código de su teléfono», WireGuard no puede expresarlo por sí solo.

Necesita Layer 2 o un cliente para algo antiguo. OpenVPN con dev tap puentea tramas Ethernet. Esto es importante para los protocolos de difusión y para los juegos LAN antiguos. WireGuard sólo funciona en Layer 3 y siempre será así. OpenVPN también tiene clientes para hardware y sistemas operativos que nunca tendrán una aplicación de WireGuard. Ambos motivos son cada vez menos frecuentes. Además, dev tap es incompatible con DCO, por lo que el puente utiliza la ruta más lenta.

El coste real de las dos configuraciones

Una identidad de WireGuard se crea con un comando. Los paréntesis son importantes porque establecen los permisos del archivo antes de que exista la clave:

(umask 077; wg genkey > private.key)
wg pubkey < private.key > public.key

El equivalente en OpenVPN es una autoridad certificadora que pasa a ser responsabilidad suya mientras exista la VPN:

sudo apt install -y easy-rsa
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
./easyrsa gen-req server nopass
./easyrsa sign-req server server

Ninguna de las dos listas es injusta. La autoridad certificadora permite gestionar la caducidad y la revocación. A cambio, debe proteger durante años una clave privada, recordar las renovaciones y reconstruir la infraestructura si la pierde. Si no utiliza esas funciones, paga por nada. El procedimiento completo de WireGuard, incluido el reenvío, NAT (traducción de direcciones de red) y los fallos del handshake que pueden consumir toda una tarde, se describe en la guía para alojar una VPN de WireGuard en su VPS.

Qué exige cada uno al firewall

WireGuard necesita exactamente una regla de entrada para UDP en el puerto indicado en ListenPort:

sudo ufw allow 51820/udp
sudo ufw status verbose

OpenVPN necesita UDP 1194 de forma predeterminada, o TCP 443 si eligió esa opción. Después, ambos necesitan que el reenvío de IP esté habilitado y una regla de NAT de origen, porque un sistema Linux descarta los paquetes que no están dirigidos a él. Esta parte es idéntica para ambos protocolos y es la causa de la mayoría de los informes de «el túnel se conecta, pero no hay Internet». Si no conoce ufw, empiece por los conceptos básicos del firewall ufw en un VPS y recuerde que la mayoría de los proveedores ejecutan un segundo firewall de red en su panel de control: una regla que añada en el servidor no sirve de nada si el paquete nunca llega al servidor. Entender qué es un puerto y cómo escucha Linux en él permite completar ambas comprobaciones más rápido.

Cómo elegir, en un solo párrafo

Ejecute WireGuard, salvo que pueda indicar qué función concreta no puede realizar. Si necesita TCP 443 para atravesar una red restrictiva, ejecute OpenVPN en ese puerto y considere ejecutar ambos: usan puertos diferentes y pueden coexistir en un mismo servidor sin conflictos. Si necesita cuentas por usuario o un segundo factor, no intente forzar esa función en WireGuard. Añada una capa de identidad por encima. Un servidor de control Headscale autohospedado usa WireGuard en la capa subyacente y añade el modelo de cuentas, la distribución de claves y la aprobación de dispositivos que WireGuard sin más deja bajo su responsabilidad.

Migrar desde OpenVPN sin una interrupción

No existe una conversión. La PKI de OpenVPN no se convierte en claves de WireGuard, porque WireGuard no tiene certificados que se puedan convertir. Cada cliente obtiene un par de claves nuevo, generado de la misma forma que el del servidor.

Haga la migración en paralelo en lugar de cambiar de un servicio a otro. WireGuard en UDP 51820 y OpenVPN en 1194 pueden ejecutarse al mismo tiempo en el mismo equipo. Active wg0, confirme su funcionamiento con sudo wg show mostrando un latest handshake reciente y, después, migre los clientes uno por uno. Cuando la lista de pares de OpenVPN deje de cambiar, detenga el servicio con sudo systemctl disable --now openvpn-server@server. Conserve los archivos de la CA hasta estar seguro, porque no es posible volver a crear un cliente revocado usando una CA que haya eliminado.

Hay un elemento que realmente no se conserva: las cuentas de usuario y contraseña, junto con el historial de revocaciones asociado. Decida dónde se almacenará antes de apagar el servidor antiguo, no después.

FAQ

¿WireGuard es más rápido que OpenVPN?

En un servidor Ubuntu 24.04 estándar, sí, y por un margen amplio, porque WireGuard cifra en el kernel, mientras que OpenVPN 2.6 mueve cada paquete mediante un proceso en el espacio de usuario. Con OpenVPN 2.7 y el módulo del kernel ovpn de Linux 6.16, la ruta de datos también está en el kernel y ambos están en la misma categoría. Mida su propio rendimiento con iperf3 a través del túnel en lugar de confiar en una cifra de un blog, porque en un VPS el límite suele ser la CPU o el ancho de banda asignado.

¿Puede WireGuard funcionar sobre el puerto TCP 443?

No por sí solo. WireGuard usa únicamente UDP por diseño y no está previsto añadir un modo TCP. Para atravesar una red que sólo permite TCP 443, debe encapsularlo en un túnel como wstunnel o udp2raw, lo que añade un proceso que ejecutar y actualizar en ambos extremos. Si esa restricción forma parte de su entorno de trabajo habitual, OpenVPN con proto tcp-server y port 443 es la opción más sencilla.

¿OpenVPN es inseguro actualmente?

No. Una versión actual de OpenVPN con un cifrado AEAD como AES-256-GCM y tls-crypt habilitado es una VPN segura. La ventaja de WireGuard se basa en otro aspecto: OpenVPN incluye mucho más código y muchas más opciones, por lo que ofrece a un administrador cansado muchas más formas de configurarlo mal. Menos opciones significa menos configuraciones incorrectas.

¿Cuál debería elegir para una VPN personal en un VPS?

WireGuard. Un par de claves por dispositivo, un archivo de configuración de unas diez líneas, un puerto UDP abierto y un handshake que termina antes de que note que ha comenzado. Elija OpenVPN sólo si se conecta habitualmente desde redes que bloquean UDP o si debe integrarse con una autoridad de certificación o un directorio de usuarios que ya existe.