¿Qué puerto usa WireGuard? Puerto por defecto, cambiarlo y abrirlo (2026)

La red de WireGuard es agradablemente simple — pero el número que hace tropezar a todos es el puerto. Por defecto WireGuard escucha en UDP 51820, y casi todos los «mi VPN autoalojada no conecta» se reducen a ese puerto no abierto, no redirigido, o que no coincide con la config del cliente. Esta guía cubre el valor por defecto, cómo cambiarlo, y cómo abrirlo y redirigirlo correctamente.

El valor por defecto: UDP 51820

WireGuard escucha en el puerto UDP 51820 por convención, fijado por la línea ListenPort en la sección [Interface] del servidor. Importan dos cosas:

• Es UDP, no TCP. WireGuard no tiene modo TCP. Los firewalls o redes que bloquean UDP lo detienen en seco.
• 51820 es solo el valor por defecto, no una regla — puedes usar cualquier puerto UDP libre de 1 a 65535.

Los clientes alcanzan el servidor mediante la línea Endpoint = <ip-publica>:51820 de su config. Ese puerto debe coincidir exactamente con el ListenPort del servidor.

Elegir un puerto: ¿vale la pena el 443/UDP?

Cualquier puerto UDP libre de 1 a 65535 funciona, pero algunas opciones son más inteligentes:

• Mantén el 51820 por simplicidad si tu red no filtra UDP — es el valor por defecto documentado y el más fácil de mantener.
• Usa el UDP 443 en una red restrictiva. El puerto 443 es el de HTTPS, y el tráfico web moderno (HTTP/3 / QUIC) ya va por UDP 443: un túnel WireGuard ahí se mezcla con tráfico cifrado de apariencia normal y supera muchos bloqueos por puerto. Es el cambio de puerto más útil. Ojo: es camuflaje a nivel de puerto solo — la inspección profunda de paquetes aún puede reconocer el handshake (ver la sección de sigilo más abajo).
• Evita los puertos por debajo de 1024 sin motivo; son «privilegiados» y requieren root, sin ventaja aquí.

Abrir el puerto en el firewall

En el servidor, el puerto debe permitirse en UDP. Con UFW:

sudo ufw allow 51820/udp
sudo ufw reload

Con iptables es -A INPUT -p udp --dport 51820 -j ACCEPT. Es la causa más común de un servidor que «funciona» pero nunca acepta conexiones: el servicio WireGuard está activo, pero el firewall descarta los paquetes en silencio.

Redirigir el puerto en un router

Dónde vive tu servidor decide si también necesitas redirección de puerto:

• En un VPS (servidor alquilado con IP pública): sin redirección — la regla de firewall basta, porque la IP pública apunta directamente a la máquina.
• En un servidor casero tras un router: añade una regla de redirección en la administración del router — redirigir UDP 51820 (externo) a la IP local del servidor en UDP 51820 (interno). Sin ella, los paquetes de internet nunca llegan al servidor.

Prueba desde fuera de tu red (p. ej. un teléfono con datos móviles, Wi-Fi apagado): un cliente debe alcanzar ip-publica-servidor:51820. Si funciona en tu LAN pero no desde fuera, la redirección es la pieza que falta.

Cambiar el puerto

Para usar otro puerto, defínelo en el [Interface] del servidor:

[Interface]
ListenPort = 51821

Luego reinicia el túnel (systemctl restart wg-quick@wg0) y actualiza todo lo que referenciaba el puerto antiguo:

1. la regla de firewall (permitir el nuevo puerto UDP),
2. la redirección del router (si aplica),
3. la línea Endpoint en cada config de cliente.

Olvida uno solo y los clientes no conectarán. Un VPS autoalojado lo simplifica todo porque controlas el firewall y la IP pública directamente.

Verifica que el puerto escucha de verdad

Antes de culpar al cliente, confirma que el servidor escucha en el puerto que crees:

sudo wg show              # muestra la interfaz y su puerto de escucha
sudo ss -lunp | grep 51820   # ¿hay algo enlazado al UDP 51820?

wg show lista el listening port activo; ss -lunp (la u = UDP) prueba que un proceso está enlazado. Si wg show muestra un puerto distinto al de tu config, el servicio no recargó tras la edición — reinícialo. Desde otra máquina puedes sondear con nc -uvz ip-servidor 51820, pero las sondas UDP son poco fiables: un handshake real del cliente es la prueba definitiva.

Ejecutar varios túneles

Cada interfaz WireGuard necesita su propio ListenPort. Si ejecutas, por ejemplo, wg0 para el tráfico general y wg1 para otro grupo de pares, dales puertos distintos (p. ej. 51820 y 51821), abre y redirige ambos, y apunta cada cliente al correcto. Dos interfaces compartiendo un puerto fallan en silencio al arrancar.

¿Cambiar el puerto oculta tu VPN?

Un puerto no estándar reduce el ruido de los bots que escanean 51820, pero no es sigilo. La inspección profunda de paquetes identifica el saludo UDP característico de WireGuard sea cual sea el puerto. Si debes atravesar un firewall que bloquea o detecta activamente las VPN, necesitas ofuscación (envolver el túnel), no solo otro puerto — mira WireGuard con port knocking / sigilo. Para enrutar tráfico concreto o redirigir servicios por el túnel, mira la redirección de puertos.

En resumen

WireGuard usa UDP 51820 por defecto — solo UDP, sin TCP. Para hacer accesible un servidor autoalojado: abre el puerto en UDP en el firewall, redirígelo en el router si el servidor está tras uno (un VPS con IP pública lo evita), y asegúrate de que el Endpoint de cada cliente coincide. Cambia el puerto si quieres para menos ruido de escaneo, pero trátalo como endurecimiento ligero, no sigilo real.