Monta tu propio VPN con WireGuard en 30 minutos

WireGuard es el protocolo VPN más moderno: código más simple, más rápido que OpenVPN e IPSec, y configuración en minutos. Esta guía te lleva desde cero hasta tener tu VPN casera funcionando, con clientes para móvil y desktop.

—

¿Por qué WireGuard y no OpenVPN?

• Más rápido: WireGuard usa Curve25519 para intercambio de claves y ChaCha20 para cifrado. En benchmarks mueve 2-3x más throughput que OpenVPN con la misma CPU.
• Más simple: ~4,000 líneas de código vs ~600,000 de OpenVPN. Menos superficie de ataque, menos bugs.
• Moderno: integrado en el kernel de Linux desde 5.6. No requiere módulo externo.
• Móvil-friendly: el roaming entre redes (WiFi → 4G) es transparente, no se corta la conexión.

La única contra: requiere UDP (algunos firewalls corporativos lo bloquean). Pero para uso personal, perfecto.

—

Lo que necesitas

• Servidor Linux (Ubuntu 22.04 en esta guía, pero funciona igual en Debian, Fedora, Raspberry Pi OS).
• Acceso root o sudo.
• IP pública o dominio apuntando al servidor.
• Puerto UDP libre (default 51820).

Tiempo total: 20-30 minutos la primera vez.

—

Paso 1: Instalar WireGuard

WireGuard viene en los repos oficiales de las distros modernas. En Ubuntu/Debian el paquete wireguard es meta-paquete que incluye el módulo del kernel (si es necesario) y las herramientas CLI; wireguard-tools agrega wg, wg-quick y man pages; qrencode lo necesitas después para generar QR codes para los móviles. El apt upgrade previo no es decorativo: en kernels viejos (5.4 y anteriores) WireGuard se distribuía como módulo DKMS, y un sistema desactualizado puede tener headers que no compilen.

sudo apt update && sudo apt upgrade -y
sudo apt install -y wireguard wireguard-tools qrencode

Si apt install wireguard falla con “no se puede encontrar el paquete”: estás en Ubuntu 18.04 o Debian 10 con repos viejos. Hay dos opciones: actualizar la distro, o agregar el PPA wireguard/wireguard (Ubuntu) / backports (Debian). En Ubuntu, sudo add-apt-repository ppa:wireguard/wireguard && sudo apt update && sudo apt install wireguard. En general, actualizá la distro — WireGuard requiere un kernel razonablemente nuevo y mantener un backport es pedir problemas a futuro.

Verifica la versión del kernel (debe ser 5.6+):

uname -r
# 5.15.0-91-generic o superior = perfecto

Antes de Linux 5.6 (publicado en marzo 2020), WireGuard no estaba integrado al kernel y se instalaba como módulo out-of-tree via DKMS. Funcionaba igual, pero si tienes un kernel más viejo y el módulo DKMS no compiló (por ejemplo, faltan los linux-headers), modprobe wireguard falla con “module not found”. Solución: sudo apt install linux-headers-$(uname -r) y reinstalá wireguard.

Verifica que el módulo está cargado:

sudo modprobe wireguard
lsmod | grep wireguard
# wireguard  110592  0

modprobe carga el módulo on-demand (no hace nada si ya está cargado, no da error). lsmod | grep wireguard confirma que el módulo está en memoria. Si la línea no aparece, el módulo no se cargó — revisa dmesg | tail por errores DKMS. En kernels 5.6+ modernos, el módulo está built-in (no aparece en lsmod por separado) y modprobe es innecesario.

—

Paso 2: Generar claves del servidor

WireGuard usa criptografía asimétrica. Cada peer (servidor y cliente) tiene un par clave privada/pública. La privada nunca sale del equipo (es la identidad criptográfica); la pública se comparte para que el otro peer te pueda mandar mensajes cifrados. Las claves son Curve25519 (32 bytes base64).

# Crear directorio con permisos estrictos
umask 077
mkdir -p /etc/wireguard
cd /etc/wireguard
# Generar clave privada del servidor
wg genkey | tee server_private.key | wg pubkey > server_public.key
# Ver las claves (NO compartirlas)
cat server_private.key
cat server_public.key

umask 077 es crítico: hace que cualquier archivo creado en esta sesión tenga permisos 600 (solo owner puede leer/escribir). Sin esto, wg genkey crearía las claves legibles por todo el sistema — cualquier usuario sin privilegios podría robarlas. El patrón wg genkey | tee private.key | wg pubkey > public.key aprovecha la pipe: tee graba la privada y la pasa por stdin a wg pubkey, que genera la pública a partir de la privada. Si tu distro tiene un umask raro (algunas imágenes cloud, default 022), puedes verificar que las claves quedaron con permisos correctos: ls -la /etc/wireguard/*.key debe mostrar -rw-------.

Guarda estas claves. La privada solo va en el servidor, la pública la usaremos en los clientes.

—

Paso 3: Configurar el servidor

Crea el archivo /etc/wireguard/wg0.conf:

[Interface]
# Clave privada del servidor (la que generaste arriba)
PrivateKey = 
# Dirección IP del servidor dentro del túnel VPN
Address = 10.0.0.1/24
# Puerto UDP donde escucha WireGuard
ListenPort = 51820
# Reglas para que el servidor enrute tráfico y haga NAT
# Reemplaza eth0 con tu interfaz de red (puede ser ens3, venet0, etc.)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# Sección para cada cliente (se llena después)
# [Peer]
# PublicKey = 
# AllowedIPs = 10.0.0.2/32

Importante: identifica tu interfaz de red real con ip -o -4 route show to default | awk '{print $5}'. En la mayoría de servidores VPS es eth0, en Raspberry Pi puede ser wlan0 o eth0.

Activa el IP forwarding (sin esto, el servidor VPN no puede reenviar tráfico). El sysctl net.ipv4.ip_forward le dice al kernel que cuando reciba un paquete que no es para él mismo, lo reenvíe por otra interfaz (en vez de descartarlo). Sin esto, los clientes VPN pueden hablar con el server pero el server no puede mandarles tráfico de internet, ni enrutar entre ellos.

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

tee -a appendea al final del archivo (no sobreescribe). Si corres este comando dos veces por error, te quedan dos líneas duplicadas — funciona igual, pero limpia después. Para ipv6, agregá también net.ipv6.conf.all.forwarding=1 si quieres que la VPN soporte tráfico IPv6 (cada peer debe tener una Address IPv6 en la sección [Interface]). El -p de sysctl relee /etc/sysctl.conf y aplica todos los cambios. Para ver el efecto inmediato: cat /proc/sys/net/ipv4/ip_forward debe devolver 1. Si devuelve 0, el cambio no se aplicó (puede ser que sysctl.conf tenga la línea comentada con # más abajo, sobreescribiendo el append).

—

Paso 4: Abrir el puerto en el firewall

WireGuard escucha en UDP 51820 (configurable). Si tienes un firewall delante (ufw, nftables, el firewall del panel de tu VPS), ese puerto tiene que estar abierto para que los clientes puedan handshake-ar. El protocolo WireGuard es silencioso hasta que el cliente manda el primer handshake — si el firewall drop silenciosamente los UDP al 51820, el cliente ve “handshake does not complete” sin razón aparente.

sudo ufw allow 51820/udp
sudo ufw reload
sudo ufw status

ufw allow 51820/udp (no /tcp — WireGuard es UDP-only). Después de reload, ufw status debe mostrar la regla 51820/udp ALLOW en Anywhere. Si usas nftables en vez de ufw (recomendado, ver guía anterior), la regla equivalente es: sudo nft add rule inet filter input udp dport 51820 accept. Si tu server está detrás de un cloud firewall (AWS Security Group, GCP firewall, Hetzner firewall panel), también tienes que abrir el puerto ahí — es un firewall separado del que está adentro de la VM.

Si usas Cloudflare o algún proxy delante, también necesitas abrir el puerto allí. Un proxy como Cloudflare Tunnel o nginx stream_pass puede manejar la terminación UDP, pero la mayoría de CDNs solo manejan HTTP — si tu idea es esconder la IP del server detrás de Cloudflare, WireGuard directo no funciona, tienes que usar WireGuard over WebSocket o similar (soluciones más experimentales).

—

Paso 5: Arrancar WireGuard

wg-quick@wg0 es un template unit de systemd: el @ indica que el nombre de la interfaz (wg0) se pasa como parámetro. systemd instancia el unit como [email protected] y al arrancar lee /etc/wireguard/wg0.conf, levanta la interfaz, configura IPs, rutas, y las reglas de iptables que pusiste en PostUp/PostDown. enable lo registra para auto-arranque en cada boot.

sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0
sudo systemctl status wg-quick@wg0

Cuidado con start después de editar el config: si WireGuard ya está corriendo con la config vieja, start falla porque la interfaz wg0 ya existe. Hay que hacer systemctl restart wg-quick@wg0 (que la baja y la sube) o usar wg syncconf wg0 <(wg-quick strip wg0.conf) para recargar config sin drop de la interfaz (los peers activos se reconectan sin tirar la sesión).

Verifica que esté corriendo:

sudo wg show
# interface: wg0
#   public key: 
#   private key: (hidden)
#   listening port: 51820

wg show te muestra el estado runtime: interfaz activa con su public key (que coincide con la que generaste en el paso 2 — si no coincide, tienes dos pares de claves generadas y estás usando la equivocada en el config), puerto de escucha, y peers conectados (al principio ninguno hasta que agregues clientes).

Si ves la interfaz listada, el servidor está listo.

---

Paso 6: Generar claves y configs para cada cliente

Para cada dispositivo que se conectará a tu VPN, necesitas:

1. Generar un par de claves.

2. Agregar la clave pública al servidor.

3. Crear un archivo de configuración para el cliente.

Generar claves del cliente

Repite por cada cliente (laptop, móvil, etc.). La generación de claves se hace en el server porque wg genkey solo viene con el paquete wireguard-tools; no necesitas instalar nada en el cliente todavía. Después le pasás la clave privada y el config al cliente por un canal seguro (scp, Signal, lo que sea).

# Para laptop personal
wg genkey | tee laptop_private.key | wg pubkey > laptop_public.key
cat laptop_public.key
# Para móvil Android
wg genkey | tee android_private.key | wg pubkey > android_public.key
cat android_public.key
# Para iPhone
wg genkey | tee iphone_private.key | wg pubkey > iphone_public.key
cat iphone_public.key

No reutilices claves entre clientes: cada uno necesita su propio par. Si dos clientes comparten la misma clave privada, la seguridad criptográfica se rompe (WireGuard no puede distinguir quién mandó qué, y un atacante que comprometa uno compromete al otro). Si te equivocas y quieres borrar las claves, wg genkey no tiene flag "overwrite" — simplemente borrá los archivos y volvé a generarlos. Mantené los .key con permisos 600.

Agregar cada cliente al servidor

Edita /etc/wireguard/wg0.conf y agrega por cada peer:

[Peer]
# Laptop
PublicKey = 
AllowedIPs = 10.0.0.2/32
[Peer]
# Android
PublicKey = 
AllowedIPs = 10.0.0.3/32
[Peer]
# iPhone
PublicKey = 
AllowedIPs = 10.0.0.4/32

AllowedIPs indica qué IPs puede usar ese cliente dentro del túnel. Asignamos una IP distinta a cada uno.

Después de editar, recarga. No usar restart: tira abajo la interfaz y desconecta a todos los peers activos por unos segundos (interrumpe la sesión, los handshakes se renegocian, hay un blip). reload lee el archivo de config y aplica los cambios sin tirar la interfaz.

sudo systemctl reload wg-quick@wg0

Si reload falla con "Unit wg-quick@wg0 not loaded", es porque el unit no soporta reload en esa versión de systemd — caés a restart. Una alternativa más quirúrgica es wg addconf wg0 <(wg-quick strip wg0.conf), que actualiza solo los peers sin tocar IPs ni rutas.

Crear archivo de configuración del cliente

Crea un archivo .conf por cliente:

[Interface]
# Clave privada del cliente
PrivateKey = 
# IP que tendrá este cliente dentro del túnel
Address = 10.0.0.2/24
# DNS que usará cuando esté conectado (Cloudflare o tu Pi-hole)
DNS = 1.1.1.1
[Peer]
# Clave pública del SERVIDOR
PublicKey = 
# AllowedIPs = 0.0.0.0/0 → todo el tráfico pasa por la VPN
# AllowedIPs = 10.0.0.0/24, 192.168.1.0/24 → solo tráfico de esas redes
Endpoint = tu-servidor.com:51820
# Keepalive (útil para NAT traversal y mantener conexión activa)
PersistentKeepalive = 25

---

Paso 7: Importar en el cliente

Linux (NetworkManager)

nmcli connection import toma el .conf y lo convierte en un perfil NetworkManager persistente. Después puedes administrarlo desde la GUI o desde el CLI (nmcli connection up/down). Si tu distro usa systemd-networkd en vez de NetworkManager, el archivo .conf se puede usar directamente con wg-quick (la herramienta lee el mismo formato).

sudo nmcli connection import type wireguard file laptop.conf
sudo nmcli connection up laptop

Si el import dice "unknown connection type 'wireguard'": NetworkManager no tiene el plugin de WireGuard instalado. En Debian/Ubuntu: sudo apt install network-manager-wireguard. En Fedora: ya viene integrado en NetworkManager-wireguard (que se instala junto con el paquete wireguard-tools). Sin el plugin, NM no sabe qué hacer con el tipo wireguard y rechaza el import.

macOS / iOS / Android / Windows

Descarga la app oficial de WireGuard:

• Windows/macOS/iOS: https://www.wireguard.com/install/
• Android: https://play.google.com/store/apps/details?id=com.wireguard.android

Abre la app, selecciona "Importar desde archivo o código QR", y carga el .conf que creaste.

Tip para móvil: usa qrencode para generar un QR del config:

sudo apt install qrencode
qrencode -t ansiutf8 < laptop.conf

-t ansiutf8 renderiza el QR como bloques Unicode directamente en la terminal — puedes escanearlo con la cámara del móvil sin tener que guardar el .conf en un archivo ni mandártelo por mail. Si prefieres un PNG: qrencode -o laptop.png < laptop.conf. Atención de seguridad: el QR contiene la clave privada en texto plano. Si lo dejás en una terminal compartida o lo guardas en una screenshot, alguien puede capturar la clave. Generá el QR en un equipo confiable y borrá el archivo inmediatamente después de escanear.

Escanéalo con la app de WireGuard en el móvil. Más fácil que copiar/pegar la clave.

---

Paso 8: Probar que todo funciona

Desde el cliente (con la VPN activa):

# Verificar IP pública (debería ser la del servidor VPN)
curl https://ifconfig.me
# Verificar que puedes hacer ping al servidor
ping 10.0.0.1
# Probar acceso a recursos internos (si configuraste para split-tunnel)
ping 192.168.1.1

Tres checks progresivos: 1) la IP pública cambió a la del server (verificas que el tráfico sale por el túnel), 2) ping al endpoint del túnel (10.0.0.1 es la IP interna del server, si responde, la VPN está tunnelando), 3) ping a un recurso de la LAN remota (si usas AllowedIPs con la subnet de tu casa/oficina, verificas que el split-tunnel enruta bien).

Si todo responde correctamente, tu VPN está operativa. Si el primer curl devuelve la IP de tu ISP en vez de la del server, las AllowedIPs no están bien configuradas en el cliente — para "todo por VPN" usa 0.0.0.0/0, ::/0. Si el ping a 10.0.0.1 falla pero el curl sí, el cliente está conectado pero el server no está aceptando tráfico del túnel (revisa las reglas de iptables en PostUp y la chain forward).

---

Casos de uso reales

1. Acceder a tu red casera desde fuera

Cuando estás en un café o de viaje, conectas la VPN y accedes a:

• Tu servidor Nextcloud (cloud.tudominio.com).
• Tu NAS o servidor de archivos.
• Las cámaras IP de seguridad.
• Tu Home Assistant.

En la config del cliente, usa:

AllowedIPs = 10.0.0.0/24, 192.168.1.0/24

Así solo el tráfico a tu red local va por la VPN, el resto del tráfico usa la conexión normal (más rápido).

2. Protegerte en WiFi público

Cuando te conectas al WiFi de un hotel o aeropuerto:

AllowedIPs = 0.0.0.0/0, ::/0

Todo el tráfico pasa por tu VPN. Nadie en esa red puede ver qué haces. Tampoco pueden inyectarte anuncios ni redirigirte a sitios maliciosos.

3. Saltar restricciones geográficas

Si viajas a un país que bloquea servicios (China, Rusia, etc.), la VPN te permite acceder a tu contenido habitual.

4. Conectar dos oficinas / redes

WireGuard también sirve para conectar dos redes remotas. Configuras un peer en cada lado con las subnets de cada red:

# En el servidor "oficina A"
[Peer]
PublicKey = 
AllowedIPs = 10.0.0.0/24, 192.168.1.0/24  # Subred de oficina A y B

---

Monitoreo y mantenimiento

Ver quién está conectado

sudo wg show
# Muestra interfaz, peers, últimas conexiones, transferencia de datos

Para cada peer, wg show te lista: endpoint (la IP:puerto desde donde se conectó, puede cambiar si el cliente está detrás de NAT y roaming), latest handshake (cuándo fue el último handshake exitoso — si dice 1 minute ago o menos, el peer está activo; si dice 5 hours ago, está conectado pero sin tráfico; si dice never, nunca se conectó o se perdió el keep-alive), transfer (bytes recibidos/enviados — útil para detectar abuso o peer con problemas).

Script de monitorización básico

Este script recorre todos los peers y muestra estado resumido. Útil para poner en cron y loguear a un archivo. Si lo metés en /etc/cron.d/wireguard-monitor, tienes un mini dashboard sin herramientas externas.

#!/bin/bash
echo "=== WireGuard Status ==="
sudo wg show
echo ""
echo "=== Connected Peers ==="
sudo wg show wg0 peers | while read pubkey; do
    echo "Peer: $pubkey"
    sudo wg show wg0 | grep -A 5 "$pubkey" | grep "endpoint|latest handshake|transfer"
    echo "---"
done

Cuidado con grep -A 5: en realidad WireGuard pone los campos en bloques, y grep -A 5 agarra las 5 líneas siguientes al peer. Si tienes muchos peers y el formato cambia entre versiones, puedes capturar líneas de otro peer. La versión robusta: wg show wg0 transfer (mismo formato para todos los peers) y wg show wg0 endpoints por separado.

Por seguridad, regenera las claves de servidor y clientes. Es tedioso porque tienes que actualizar todos los clientes, pero es buena práctica.

---

Solución de problemas comunes

"Handshake does not complete"

Causa típica: el puerto UDP 51820 está bloqueado. Verifica:

sudo ufw status
# Debe haber 51820/udp ALLOW
# Desde un cliente, prueba:
nc -uv tu-servidor.com 51820

nc -uv manda un probe UDP al puerto 51820. Si el server está alcanzable, el probe queda "abierto" (UDP es connectionless, nc espera 1-2 segundos y termina). Si el firewall drop, nc falla con "Connection refused" o timeout. Otra herramienta más confiable para diagnóstico: mtr tu-servidor.com para ver si hay pérdida de paquetes en el path (a veces el problema no es el firewall local sino un router intermedio que rate-limita UDP). Si la salida de wg show del server muestra el peer pero latest handshake: never después de varios minutos, el handshake se está perdiendo en algún lado.

"Permission denied" al leer las claves

Las claves deben tener permisos 600 (solo owner lee/escribe). Si están con 644 (world-readable), cualquier proceso del sistema puede robarlas. Más grave: algunos demonios se niegan a arrancar si las claves son world-readable, por seguridad.

sudo chmod 600 /etc/wireguard/*.key

El chmod 600 (no chmod 700) es lo que pide wg-quick. Si después de cambiar permisos wg-quick sigue dando permission denied, revisa que el dueño del archivo sea root (chown root:root /etc/wireguard/*.key). En algunas instalaciones automatizadas (Ansible, cloud-init), los archivos quedan con dueño admin o el usuario de deploy.

La VPN conecta pero no navegas

Causa típica: el servidor no está haciendo NAT correctamente. Verifica:

# El IP forwarding está activo
cat /proc/sys/net/ipv4/ip_forward
# Debe devolver 1
# Las reglas de iptables están activas
sudo iptables -t nat -L POSTROUTING
# Debe haber una línea MASQUERADE para tu interfaz

Dos cosas a chequear por separado: 1) el sysctl ip_forward tiene que ser 1 (si es 0, ningún paquete se reenvía aunque las reglas de NAT estén bien), 2) la regla MASQUERADE en iptables -t nat -L POSTROUTING tiene que existir (si no, los paquetes salen al internet con la IP privada del túnel, los routers no saben rutear de vuelta, y se pierden). Si estás en systemd-networkd en vez de NetworkManager: revisa también que ip_forward no esté siendo forzado a 0 por algún .network con IPForward=ipv4:no.

El cliente móvil no se mantiene conectado

Añade PersistentKeepalive = 25 a la sección [Peer] del config del cliente. 25 segundos es el sweet spot: suficiente para mantener el NAT mapping abierto en redes mobile (los NAT entries expiran típicamente en 30-60 segundos sin tráfico), sin gastar batería con handshakes innecesarios. Sin esta línea, los móviles detrás de NAT agresivo (4G en roaming, WiFi de hotel) ven la conexión "dormida" cuando no hay tráfico, el NAT mapping expira, y el server no sabe cómo mandarle el próximo paquete.

---

Comparativa con Tailscale (alternativa moderna)

Tailscale es una capa sobre WireGuard que automatiza el descubrimiento de peers y la autenticación. No necesitas abrir puertos, no necesitas configurar claves, todo se hace por una app.

¿Cuándo usar WireGuard puro?

• Quieres control total.
• Tienes tu propio servidor público.
• No quieres depender de un servicio externo.

¿Cuándo usar Tailscale?

• Quieres algo que funciona en 5 minutos sin configurar nada.
• Tienes dispositivos detrás de NAT que no puedes exponer.
• Estás dispuesto a confiar en un servicio externo (los servidores de Tailscale ven tus metadatos, no tu tráfico).

Mi setup real: tengo los dos. Tailscale para acceso rápido a mis dispositivos, WireGuard puro como backup.

---

Siguientes pasos

Si quieres profundizar más:

• Múltiples subredes: configura AllowedIPs para enrutar entre redes.
• DNS personalizado: usa tu Pi-hole como DNS dentro de la VPN.
• IPv6: WireGuard soporta IPv6 nativo.
• Bridges: WireGuard sobre TCP para atravesar firewalls estrictos (usando udp2raw).

¿Próximo post? Estaba pensando en una guía de Tailscale + bloqueador DNS o WireGuard + Pi-hole: tu red privada y sin publicidad. Déjamelo en comentarios.

Si te sirvió, suscríbete al blog para no perderte los siguientes tutoriales.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux