WireGuard en Windows no se conecta: 10 soluciones que resuelven la mayoría de los casos

Manual rápido de diagnóstico (comprobar 1–2–3)

Cuando WireGuard en Windows “no se conecta”, necesitas dejar de tratarlo como un único problema.
Normalmente es uno de tres cuellos de botella: handshake, enrutamiento o resolución de nombres.
Encuentra cuál en menos de cinco minutos y luego profundiza.

1) ¿Hay handshake?

• En Windows: WireGuard UI → elegir túnel → mirar “Latest handshake”.
• En el servidor: comprobar wg show por “latest handshake” y contadores RX/TX.

Sin handshake suele ser un problema de puerto/firewall/NAT/clave.
Handshake presente pero el tráfico falla suele ser rutas, AllowedIPs, NAT/forwarding o MTU.

2) Si hay handshake: ¿puedes hacer ping a una IP (no a un nombre)?

• Haz ping a la IP de la interfaz WireGuard del servidor (ejemplo: 10.6.0.1).
• Haz ping a la IP de un recurso interno (ejemplo: 10.0.10.25).

Si el ping por IP funciona pero los nombres no, es DNS. Si ninguno funciona, es enrutamiento/AllowedIPs/firewall/MTU.

3) Si puedes hacer ping a IPs: ¿la tabla de rutas parece sensata?

En Windows, rutas erróneas causan miseria silenciosa: el tráfico sale por tu Wi‑Fi, no por el túnel, mientras el túnel presume que está “Active”.
Comprueba rutas y métricas de interfaz antes de culpar a WireGuard.

Hechos y contexto que explican las rarezas

• WireGuard usa solo UDP. Si tu red bloquea UDP saliente o lo limita agresivamente, verás handshakes intermitentes y conectividad “fantasma”.
• No hay “sesión” que mantener. WireGuard es algo estateless: envía paquetes cifrados; el estado es principalmente material de claves y marcas temporales de handshake. Los dispositivos NAT, sin embargo, adoran el estado.
• PersistentKeepalive existe sobre todo para apaciguar al NAT. No es una característica de rendimiento; es una táctica de supervivencia para clientes detrás de firewalls con estado.
• AllowedIPs es política de enrutamiento. No es un ACL en el sentido tradicional; le indica al peer qué cifrar y por dónde enrutar.
• Windows usa métricas de interfaz para elegir una ruta. Un “túnel dividido” puede convertirse accidentalmente en “sin túnel” si otra interfaz gana la decisión de ruta.
• El diseño de WireGuard fue intencionalmente pequeño. Menos piezas móviles significa menos modos de fallo—salvo que tu entorno proporcione la complejidad faltante mediante NAT, DNS y herramientas de seguridad corporativas.
• Las marcas temporales de handshake pueden engañar. Un handshake reciente no prueba que el camino de retorno funcione para el tráfico que realmente te importa (piensa: enrutamiento asimétrico, ICMP bloqueado o fallos solo de DNS).
• Los problemas de MTU son más antiguos que la mayoría de proveedores VPN. Los agujeros de PMTU existen desde hace décadas; WireGuard solo los hace visibles cuando empujas paquetes encapsulados a través de redes frágiles.

Una “idea parafraseada” que vale la pena tener pegada al monitor, atribuida a Werner Vogels (mentalidad de fiabilidad):
idea parafraseada: Todo falla, todo el tiempo; diseña y opera como si la falla fuera normal.

Las 10 soluciones (la mayoría de los casos, sin drama)

Solución 1: Demuestra que el servidor realmente está escuchando en UDP (y en el puerto que crees)

La mitad de los informes “WireGuard en Windows no se conecta” son simplemente “el servidor ya no está escuchando” o está escuchando en la interfaz equivocada.
Quizá alguien cambió el puerto. Quizá el servicio no se reinició. Quizá una regla de seguridad en la nube cambió silenciosamente.

Qué hacer: en el servidor, verifica el puerto de escucha y que lleguen paquetes.
Si el servidor nunca ve UDP entrante, deja de tocar Windows. El problema no está allí.

Solución 2: Confirma que el túnel WireGuard en Windows usa el endpoint esperado

Los usuarios de Windows copian configuraciones y luego alguien actualiza la IP del servidor, o cambia el DNS, o el endpoint resuelve distinto en una red corporativa.
Si tu endpoint es un nombre de host, has invitado al DNS a la historia de conectividad. A veces está bien. A veces es un pager a medianoche.

Solución 3: Deja de adivinar—valida las claves y el mapeo de peers en el servidor

WireGuard no tiene usuario/contraseña. Son claves todo el tiempo.
Un solo carácter equivocado en una clave pública, o reutilizar una configuración de cliente entre máquinas, puede causar un lío de “conecta a veces”—especialmente cuando dos clientes comparten la misma clave y pelean por el mismo slot de peer.

Solución 4: Arregla AllowedIPs en el cliente (la herida autoinfligida más común)

AllowedIPs decide qué tráfico entra en el túnel. Si tus AllowedIPs no incluyen lo que intentas alcanzar, WireGuard se comportará perfectamente mientras tú experimentas el fallo perfectamente.

• Túnel completo: AllowedIPs = 0.0.0.0/0, ::/0
• Túnel dividido: incluye solo prefijos internos, más la IP WG del servidor si hace falta.

Si tu objetivo es “alcanzar subredes internas pero mantener Internet local”, haz el túnel dividido deliberadamente.
No hagas medio túnel completo y te preguntes por qué las llamadas de Teams se ponen raras.

Solución 5: Arregla conflictos de enrutamiento y métricas de interfaz en Windows

La selección de rutas en Windows es determinista, no útil. Elige la “mejor” ruta basada en la longitud del prefijo, la métrica y el coste de la interfaz.
Si tienes múltiples VPNs, adaptadores virtuales o software de seguridad, puedes acabar con una tabla de rutas que parece un organigrama corporativo: complicada y ocasionalmente imaginaria.

Tu trabajo: asegúrate de que la interfaz WireGuard tenga rutas para los destinos que necesitas y que ninguna otra interfaz se las robe.

Solución 6: Arregla el DNS (porque “la VPN cae” suele ser “el DNS cae”)

La gente culpa a WireGuard cuando ping 10.0.0.10 funciona pero ping internal-app no.
Eso es DNS. Arregla el DNS primero; es más barato que la angustia existencial.

Si empujas servidores DNS internos vía la configuración de WireGuard, asegúrate de que:
(1) esos servidores DNS sean alcanzables a través del túnel, y
(2) Windows realmente los esté usando en esa interfaz.

Solución 7: Arregla NAT y forwarding en el servidor (handshake sin tráfico)

Un handshake demuestra que cliente y servidor pueden intercambiar tráfico de control cifrado.
No demuestra que el servidor pueda reenviar paquetes desde el túnel hacia la LAN o Internet.

Para túnel completo, el servidor normalmente necesita forwarding IP y NAT (mascaradeo) en la interfaz de salida.
Para túnel dividido hacia una LAN interna, puede que necesites rutas en la puerta de enlace LAN de vuelta a la subred de WireGuard.

Solución 8: Arregla el MTU (el clásico “conecta pero todo caduca”)

Los problemas de MTU aparecen como: handshake presente, pings pequeños funcionan, sitios web se cuelgan, RDP/SMB se estanca o solo algunas apps funcionan.
La encapsulación UDP cambia el tamaño de los paquetes. Algunas redes descartan fragmentos o bloquean ICMP “necesita fragmentar”.
Obtienes un agujero negro de PMTU. Buenos tiempos.

Solución 9: Arregla el firewall de Windows y las herramientas de seguridad que “inspeccionan” tu VPN

Windows Defender Firewall puede bloquear el adaptador, y herramientas de endpoint corporativas pueden bloquear u “optimizar” UDP.
Si estás en un portátil gestionado, asume que no eres el único con opiniones sobre el tráfico de red.

Solución 10: Arregla la deriva de tiempo y los primitivos de red rotos

WireGuard no es TLS, pero el tiempo sigue importando en el ecosistema circundante: DNS, validación de certificados para aplicaciones dentro del túnel y correlación de logs.
Además, si la pila de red de Windows está en un estado raro (rutas obsoletas, catálogo winsock roto, adaptadores virtuales medio instalados), WireGuard será culpado por crímenes que no cometió.

Broma #1: Un indicador “VPN conectada” es como la luz del lavavajillas: te dice que la máquina tiene sentimientos, no que los platos estén limpios.

Tareas prácticas con comandos (y cómo decidir)

Estas son tareas que realmente ejecuto durante incidentes. Cada una incluye un comando, qué significa la salida y la decisión que tomas.
Los comandos se muestran con un prompt de servidor Linux porque la mayoría de servidores WireGuard son Linux; para validación del cliente Windows usamos la GUI más la verdad del servidor.

Tarea 1: En el servidor, confirma que WireGuard está arriba y escuchando

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2y...serverpub...
  private key: (hidden)
  listening port: 51820

peer: 9Z...clientpub...
  endpoint: 203.0.113.55:61644
  allowed ips: 10.6.0.2/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 18.42 MiB received, 31.10 MiB sent

Significado: Si ves un puerto de escucha y un handshake reciente, WireGuard está vivo.
Si falta el “listening port”, la interfaz puede estar abajo o mal configurada.

Decisión: ¿Sin handshake y sin endpoint visto? Enfócate en la alcanzabilidad UDP (firewall/NAT/puerto). ¿Handshake presente pero transferencia atascada? Pasa a enrutamiento/NAT/MTU.

Tarea 2: Verifica el estado del servicio y la interfaz

cr0x@server:~$ sudo systemctl status wg-quick@wg0
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled)
     Active: active (exited) since Sat 2025-12-27 09:11:04 UTC; 2h 13min ago
       Docs: man:wg-quick(8)
             man:wg(8)
    Process: 1234 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)

Significado: Active (exited) es normal para wg-quick; configura y sale.

Decisión: Si está fallando, arregla la configuración del servidor antes de tocar Windows. Si está activo, continúa.

Tarea 3: Comprueba que el socket UDP está enlazado (errores por desajuste de puerto)

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0           0.0.0.0:51820      0.0.0.0:*    users:(("wireguard",pid=1240,fd=6))

Significado: El sistema está escuchando en UDP 51820 en todas las direcciones IPv4.

Decisión: Si no hay listener, arregla wg0 o cambia la configuración del cliente para que coincida con el puerto real.

Tarea 4: Verifica que los paquetes llegan al servidor (demuestra el camino de red)

cr0x@server:~$ sudo tcpdump -ni any udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
09:36:11.112233 eth0  IP 198.51.100.44.61644 > 203.0.113.10.51820: UDP, length 148
09:36:16.113901 eth0  IP 198.51.100.44.61644 > 203.0.113.10.51820: UDP, length 148

Significado: El cliente está alcanzando el puerto UDP de tu servidor.

Decisión: Si no ves nada mientras el cliente alterna el túnel, arregla reglas perimetrales, grupos de seguridad en la nube, bloqueos del ISP o la dirección del endpoint.

Tarea 5: Confirma que el forwarding está habilitado en el servidor

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Significado: El forwarding IPv4 está habilitado; es necesario para enrutar desde wg0 a otra interfaz.

Decisión: Si es 0 y esperas que el servidor enrute tráfico, actívalo y persístelo (luego vuelve a probar el tráfico).

Tarea 6: Revisa reglas NAT nftables/iptables para configuraciones de túnel completo

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE

Significado: Los clientes de 10.6.0.0/24 se NATean por eth0, así pueden alcanzar Internet (o upstream) sin necesitar rutas de retorno explícitas.

Decisión: Si falta esta regla y quieres egress por túnel completo, añádela. Si prefieres túnel dividido hacia una LAN, quizá prefieras enrutamiento correcto en lugar de NAT.

Tarea 7: Verifica que el servidor tiene ruta de vuelta a la subred cliente y que la LAN tiene ruta de retorno (túnel dividido)

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.0.10.0/24 dev br0 proto kernel scope link src 10.0.10.1
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1

Significado: El servidor sabe que la subred de WireGuard está en wg0.

Decisión: Si tu destino es 10.0.10.0/24 y los clientes no pueden alcanzarlo, asegúrate de que el lado LAN sepa cómo devolver el tráfico a 10.6.0.0/24 (vía este servidor). Sin eso verás flujos unidireccionales y tristeza.

Tarea 8: Confirma AllowedIPs del peer en el servidor (subredes equivocadas, /32 equivocado)

cr0x@server:~$ sudo wg show wg0 allowed-ips
9Z...clientpub... 10.6.0.2/32

Significado: El servidor dirigirá 10.6.0.2 a este peer. Eso es típico para direccionamiento de cliente.

Decisión: Si asignaste accidentalmente la misma IP de cliente a dos peers, o diste un /24 a un peer, provocarás enrutamiento incorrecto. Arregla el direccionamiento y AllowedIPs.

Tarea 9: Busca claves duplicadas (dos dispositivos compartiendo una configuración)

cr0x@server:~$ sudo wg show wg0 | sed -n '1,120p'
interface: wg0
  public key: 2y...serverpub...
  listening port: 51820

peer: 9Z...clientpub...
  endpoint: 198.51.100.44:61644
  latest handshake: 24 seconds ago
  transfer: 2.10 MiB received, 3.90 MiB sent

peer: 9Z...clientpub...
  endpoint: 203.0.113.200:54321
  latest handshake: 3 seconds ago
  transfer: 2.11 MiB received, 3.91 MiB sent

Significado: La misma clave pública apareciendo dos veces es una señal de alarma. En la práctica verás generalmente una entrada de peer, pero el endpoint “se moverá” entre dos IPs a medida que los dispositivos compiten.

Decisión: Emite pares de claves únicos por dispositivo. Nunca clones configuraciones con claves privadas entre portátiles.

Tarea 10: Prueba la alcanzabilidad desde el servidor hacia el túnel (servidor al cliente)

cr0x@server:~$ ping -c 3 10.6.0.2
PING 10.6.0.2 (10.6.0.2) 56(84) bytes of data.
64 bytes from 10.6.0.2: icmp_seq=1 ttl=128 time=32.1 ms
64 bytes from 10.6.0.2: icmp_seq=2 ttl=128 time=31.7 ms
64 bytes from 10.6.0.2: icmp_seq=3 ttl=128 time=33.0 ms

--- 10.6.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Significado: El servidor puede alcanzar la IP del túnel del cliente. Eso es una buena señal para enrutamiento y firewall en el lado del cliente.

Decisión: Si esto falla pero hay handshake, sospecha del firewall de Windows en el adaptador del túnel, o que ICMP esté bloqueado. Prueba también flujos TCP/UDP.

Tarea 11: Identifica agujeros MTU con una prueba “no fragmentar” (lado servidor)

cr0x@server:~$ ping -c 3 -M do -s 1360 10.6.0.2
PING 10.6.0.2 (10.6.0.2) 1360(1388) bytes of data.
From 10.6.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
From 10.6.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1420)
From 10.6.0.1 icmp_seq=3 Frag needed and DF set (mtu = 1420)

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

Significado: La MTU de la ruta es menor que tu tamaño de carga; el error sugiere una MTU alrededor de 1420.

Decisión: Ajusta la MTU de la interfaz WireGuard a un valor más bajo (comúnmente 1280–1420 según la ruta). Vuelve a probar hasta que la prueba “no fragmentar” tenga éxito.

Tarea 12: Revisa las reglas del firewall del servidor para tráfico wg0

cr0x@server:~$ sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 51820 -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Significado: UDP 51820 está permitido y el reenvío entre wg0 y eth0 está permitido.

Decisión: Si faltan reglas de FORWARD, el handshake puede funcionar pero el tráfico reenviado será descartado. Arregla las reglas FORWARD (o su equivalente en nftables) y vuelve a probar.

Tarea 13: Confirma la alcanzabilidad del servidor DNS a través del túnel (ejemplo desde el servidor)

cr0x@server:~$ dig @10.0.10.53 internal-app.example A +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> @10.0.10.53 internal-app.example A +time=2 +tries=1
;; ANSWER SECTION:
internal-app.example. 60 IN A 10.0.10.25

;; Query time: 34 msec

Significado: El servidor DNS interno responde rápidamente desde la perspectiva de la red del servidor.

Decisión: Si el DNS es alcanzable desde el servidor pero no desde el cliente, céntrate en el enrutamiento/enlace DNS del cliente. Si no es alcanzable desde el servidor, arregla primero el enrutamiento/firewall de la LAN.

Tarea 14: Valida que el archivo de configuración de peers del servidor no haya derivado

cr0x@server:~$ sudo grep -nE '^\[Interface\]|\[Peer\]|ListenPort|Address|AllowedIPs|PostUp|PostDown' /etc/wireguard/wg0.conf
1:[Interface]
2:Address = 10.6.0.1/24
3:ListenPort = 51820
4:PostUp = iptables -t nat -A POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE
5:PostDown = iptables -t nat -D POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE
7:[Peer]
8:PublicKey = 9Z...clientpub...
9:AllowedIPs = 10.6.0.2/32

Significado: Estás comprobando las claves y directivas de enrutamiento exactas que importan para “conectividad versus no conectividad.”

Decisión: Si la configuración tiene PostUp antiguos, nombre de interfaz incorrecto o AllowedIPs conflictivos, arréglalo, reinicia wg-quick y vuelve a probar.

Broma #2: Los bugs de MTU son el tipo de problema que te hace extrañar los días en que la red solo fallaba ruidosamente.

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

1) “El túnel está activo” pero nada funciona

Síntoma: La UI de WireGuard muestra Active; no hay sitios web, ni apps internas, ni pings.

Causa raíz: AllowedIPs no incluye los destinos; o la tabla de rutas de Windows envía el tráfico por otro sitio.

Solución: Decide túnel dividido vs completo y ajusta AllowedIPs en consecuencia. Verifica que existan las rutas y que no las anule otra interfaz por su métrica.

2) El handshake nunca aparece (Latest handshake: never)

Síntoma: El cliente lo activa/desactiva; el servidor no muestra endpoint ni handshake.

Causa raíz: UDP bloqueado, endpoint/puerto equivocado, servidor no escuchando, regla de firewall en la nube faltante o NAT sin reenvío.

Solución: Comandos servidor ss -lunp y tcpdump. Si los paquetes no llegan, arregla el perímetro. Si llegan pero no hay handshake, revisa claves y mapeo de peers.

3) Hay handshake, pero no se puede alcanzar recursos LAN

Síntoma: Latest handshake se actualiza, pero subredes internas están muertas.

Causa raíz: Faltan reglas de forwarding/NAT en el servidor, o la LAN no enruta de vuelta a la subred de WireGuard.

Solución: Habilita el forwarding IP; añade NAT para túnel completo, o agrega rutas de retorno en la puerta de enlace LAN para túnel dividido.

4) Conectividad IP funciona; el DNS falla

Síntoma: ping 10.0.10.25 funciona pero los nombres no se resuelven; los navegadores giran.

Causa raíz: Servidores DNS erróneos en la configuración, Windows no usa el DNS del túnel, o los servidores DNS no son alcanzables vía el túnel.

Solución: Asegura que la IP del servidor DNS esté dentro de AllowedIPs y sea alcanzable; confirma que Windows asocie el DNS a la interfaz WireGuard; evita empujar DNS públicos para zonas internas.

5) Funciona en el hotspot del móvil, falla en la red corporativa / hotel

Síntoma: Mismo portátil, misma configuración; otra red provoca “nunca handshake” o flapping.

Causa raíz: UDP saliente restringido, portal cautivo, NAT simétrico raro o timeouts agresivos de UDP.

Solución: Pon PersistentKeepalive = 25 en el cliente para redes con NAT; considera mover el servidor a un puerto más accesible; confirma que la red permite UDP saliente.

6) Algunos sitios cargan; otros se cuelgan; RDP/SMB se estanca

Síntoma: Éxito parcial; timeouts; descargas grandes se congelan.

Causa raíz: Agujero de MTU/fragmentación.

Solución: Reduce la MTU en el túnel; prueba con pings DF y tráfico real de aplicaciones.

7) “Funcionaba ayer” después de una actualización de Windows

Síntoma: Tras la actualización, el adaptador falta o el tráfico queda bloqueado.

Causa raíz: Problema de controladores, cambio en el perfil de firewall, nueva categoría de red o el software de seguridad reimpuso políticas.

Solución: Reinstala WireGuard, revisa reglas de firewall para la interfaz WireGuard, confirma que el adaptador exista y esté habilitado.

8) Dos usuarios no pueden conectarse al mismo tiempo

Síntoma: Uno conecta, el otro cae; los endpoints cambian en el servidor.

Causa raíz: Clave privada de cliente compartida (config clonada).

Solución: Claves únicas por dispositivo; IP de túnel única por peer; audita configuraciones para reutilización.

Listas de verificación / plan paso a paso

Paso a paso: de “no se conecta” a causa raíz

1. Define el fallo: “Sin handshake” vs “handshake pero sin tráfico” vs “tráfico pero DNS roto.” No te saltes esto.
2. La verdad del servidor primero: ejecuta wg show. Confirma puerto de escucha y si el servidor ve un endpoint.
3. Camino de red: tcpdump en el puerto UDP mientras alternas el túnel de Windows.
4. Claves y mapeo de peers: verifica que la clave pública del peer en el servidor coincida con la pública del cliente Windows; confirma que AllowedIPs de cada peer sean correctas y no se solapen.
5. Política de enrutamiento: decide túnel dividido o completo. Luego ajusta AllowedIPs y NAT/rutas del servidor de forma coherente con esa elección.
6. Forwarding/NAT: habilita IP forwarding; añade masquerade NAT para egress de túnel completo; o configura rutas de retorno en la LAN para túnel dividido.
7. DNS: confirma que el servidor DNS sea alcanzable por el túnel y que Windows lo esté usando para zonas internas.
8. MTU: si las cosas “casi funcionan”, prueba tamaños DF y reduce MTU.
9. Herramientas de seguridad: si todo está correcto pero sigue fallando en endpoints gestionados, sospecha de políticas de firewall/EDR; involucra al propietario de la política pronto.
10. Estabilizar: añade keepalive solo si el NAT lo requiere; documenta puertos, subredes y responsables.

Lista de comprobación de configuración (cliente + servidor)

• Endpoint IP/nombre de host es correcto; el puerto coincide con el listener del servidor.
• El cliente tiene clave privada única; el servidor tiene la clave pública de peer coincidente.
• AllowedIPs del cliente incluye los destinos que esperas enrutar por el túnel.
• AllowedIPs del peer en el servidor incluye la IP del túnel del cliente (/32) y no se solapa con otros peers.
• El servidor tiene net.ipv4.ip_forward=1 si se requiere enrutar más allá de wg0.
• Existen reglas de NAT/forwarding si haces egress por túnel completo.
• Los servidores DNS enviados al cliente son alcanzables a través del túnel.
• La MTU está adecuada para la ruta; evita pensar “por defecto para siempre”.

Tres microrelatos corporativos desde el frente

Microrelato 1: El incidente causado por una suposición equivocada (DNS siempre alcanzable)

Una empresa mediana desplegó WireGuard para permitir que ingenieros accedieran a dashboards internos. Túnel dividido, subredes simples, todo ordenado.
La configuración empujó dos servidores DNS internos, porque las apps internas vivían bajo nombres internos. Razonable.

El lunes por la mañana explotaron los tickets: “La VPN conecta pero nada funciona.” El helpdesk veía “Active” y dijo a la gente que reiniciara.
Reiniciar no hizo nada salvo desperdiciar la ventana de café de todos.

La suposición equivocada: que los servidores DNS fueran alcanzables desde el túnel. No lo eran.
Un cambio de red la semana anterior movió el DNS a otra VLAN y apretó ACLs. La subred de WireGuard no estaba incluida.
Los clientes podían alcanzar IPs internas si las conocían, pero la resolución de nombres fallaba, y la mayoría de las apps ni siquiera intentaban fallback por IP.

La solución fue aburrida y correcta: permitir que la subred de WireGuard consultara el DNS (preferido), o empujar un servidor DNS que fuera alcanzable desde la subred de WireGuard.
Tras la actualización de ACL, el “apagón de VPN” desapareció al instante—sin cambios en WireGuard.

La lección: trata al DNS como una dependencia que debes enrutar y permitir explícitamente. En redes corporativas, el DNS rara vez está “ahí por defecto”; suele estar protegido como una pieza de museo.

Microrelato 2: La optimización que salió mal (atajos de NAT ingeniosos)

Otro equipo quería túnel completo para que los portátiles egresaran por un stack de seguridad central. Construyeron una VM gateway de WireGuard.
Para “optimizar”, usaron una regla NAT mínima y quitaron lo que pensaban era lógica de forwarding redundante.
También ajustaron los firewalls por defecto para ser restrictivos, porque las revisiones de seguridad adoran los valores restrictivos.

Funcionó en una prueba básica de ping. Declararon victoria y lo desplegaron.
Luego el tráfico de aplicaciones empezó a fallar de maneras extrañas: algunos sitios HTTPS cargaban, otros hacían timeout; descargas grandes se estancaban; actualizaciones de software fallaban de forma impredecible.
Parecía una flaqueza aleatoria de Internet, que es el tipo de flaqueza más caro.

El traspié fue doble. Primero: no validaron MTU extremo a extremo. La encapsulación más un camino en la nube con comportamiento MTU raro creó un agujero negro de fragmentación.
Segundo: su conjunto “mínimo” de reglas de firewall permitía tráfico de retorno establecido solo en una dirección de interfaz; algunos flujos se caían según el camino que eligiera el kernel.

La remediación fue poco glamorosa: reglas FORWARD explícitas para wg0 ↔ egress, manejo correcto de conntrack y una MTU rebajada a un valor probado y seguro.
El rendimiento no empeoró. La fiabilidad mejoró dramáticamente, que es una métrica de rendimiento que importan los adultos.

La lección: “optimizar” la política de red quitando líneas que no entiendes es como “optimizar” un avión quitando tornillos que no sabes nombrar.

Microrelato 3: La práctica aburrida que salvó el día (claves únicas e inventario de peers)

Una organización global tenía una flota de portátiles de contratistas. Los contratistas iban y venían; los dispositivos se reimaginaban con frecuencia.
El equipo VPN instituyó una regla tediosa: cada dispositivo recibe claves WireGuard únicas, IP de túnel única y un registro de inventario.
Nada de configs compartidas. Nada de “simplemente copia el archivo de Alice”.

La gente se quejó. Era trabajo extra. Ralentizaba solicitudes de “acceso rápido”.
Pero hizo el sistema observable: cuando un peer aparecía en el servidor, sabías qué dispositivo era. Cuando fallaba, podías deshabilitarlo de forma segura.

Un viernes, la conectividad empezó a fluctuar para un subconjunto de usuarios. Los logs del servidor no eran muy verbosos (WireGuard es famoso por su minimalismo),
pero wg show mostró endpoints “vagando” rápidamente para una clave pública en particular.
Ese patrón gritaba “clave duplicada en circulación”.

Gracias al inventario, identificaron el dispositivo, contactaron al propietario y rotaron claves sin tocar a nadie más.
Sin outage amplio, sin reconfiguración masiva, sin adivinanzas sobre quién era qué peer.
La práctica aburrida se pagó sola en una sola tarde.

La lección: la unicidad y el inventario son características de fiabilidad. No se sienten como características hasta el día que las necesitas.

Preguntas frecuentes

1) ¿Por qué WireGuard muestra “Active” en Windows pero no tengo internet?

“Active” solo significa que la interfaz está arriba y la configuración cargada. No garantiza que el enrutamiento sea correcto.
Comprueba el handshake, luego verifica AllowedIPs y si Windows enruta 0.0.0.0/0 (túnel completo) por WireGuard o no.

2) Tengo handshake, pero no puedo alcanzar subredes internas. ¿Cuál es la explicación más rápida?

El servidor no está reenviando tráfico desde wg0 hacia la LAN, o la LAN no tiene ruta de vuelta a la subred de WireGuard.
El handshake demuestra “podemos hablar”. No demuestra “podemos enrutar”.

3) ¿Necesito PersistentKeepalive en Windows?

Solo si el cliente Windows está detrás de NAT/firewalls que eliminan mapeos UDP inactivos. Si ves handshakes solo después de enviar tráfico,
o la conectividad muere tras unos minutos de inactividad, pon PersistentKeepalive = 25 en la sección peer del cliente.

4) ¿Qué AllowedIPs debo usar para túnel dividido?

Incluye las redes internas que quieras alcanzar (ejemplo: 10.0.0.0/8 o /24s específicos), más cualquier otro rango privado que realmente necesites.
No pongas 0.0.0.0/0 “por si acaso”. Eso no es túnel dividido; es delegar tus decisiones de enrutamiento a tu yo del futuro.

5) ¿Por qué funciona en el hotspot del teléfono pero no en el Wi‑Fi de la oficina?

Las redes de oficina a menudo restringen UDP saliente, imponen portales cautivos o hacen inspección con estado que caduca UDP rápidamente.
Compruébalo con tcpdump en el servidor: si no llegan paquetes desde la red de la oficina, no es un problema de configuración de Windows.

6) ¿Pueden dos portátiles Windows usar la misma configuración de WireGuard?

No. No de forma segura. Si comparten la misma clave privada, el servidor los tratará como el mismo peer y el endpoint “deambulará” entre ellos.
Obtendrás flapping, tráfico intermitente y culpas que viajan más rápido que UDP.

7) ¿Qué MTU debo poner para WireGuard en Windows?

No hay un valor universal. Puntos de partida seguros comunes son 1420 o 1380; para rutas hostiles, 1280 es el valor “simplemente haz que funcione”.
Si hay handshake pero las aplicaciones se estancan, prueba PMTU y baja la MTU hasta que cese el estancamiento.

8) ¿Debería usar un nombre de host o IP para el Endpoint?

La IP es más determinista. Los nombres de host están bien si el DNS es fiable y controlado, pero añade una dependencia.
Si debes usar hostnames, asegúrate de que el cliente Windows pueda resolverlo en cada red que te importe (incluyendo portales cautivos y DNS restringidos).

9) ¿Por qué puedo hacer ping a la IP WireGuard del servidor pero no alcanzar nada detrás de él?

Porque alcanzar la IP wg0 del servidor es solo un salto directo del túnel. Alcanzar algo detrás requiere forwarding y a menudo NAT o rutas de retorno.
Arregla forwarding del servidor, firewall y enrutamiento upstream.

10) ¿Es WireGuard “menos compatible” que otras VPN en redes corporativas?

A menudo está más bloqueado simplemente porque es UDP y fácil de identificar por comportamiento (no necesariamente por contenido).
Muchos entornos corporativos permiten explícitamente TLS/443 pero tratan UDP arbitrario como sospechoso. Eso es política, no un bug de WireGuard.

Siguientes pasos para mantenerlo estable

Si quieres que WireGuard en Windows vuelva a ser aburrido, opéralo como cualquier dependencia de producción:
mide la realidad (handshake, rutas, DNS), aplica unicidad (claves, IPs) y documenta el modelo de enrutamiento previsto (túnel dividido vs completo).
La mayoría de los tickets “no se conecta” desaparecen cuando dejas de tratar la UI del cliente como verdad y empiezas a tratar al servidor como la fuente de registro.

1. Elige un estándar: túnel dividido o completo, y haz que AllowedIPs coincida.
2. En el servidor, mantiene una línea base verificada: wg show, comprobación de listener, forwarding, reglas de firewall/NAT.
3. Documenta la propiedad: quién controla DNS, quién controla reglas UDP perimetrales, quién controla políticas de seguridad de endpoints.
4. Cuando falle: sigue el manual rápido de diagnóstico—handshake → alcanzabilidad IP → DNS → MTU.

El objetivo no es “la VPN se conecta”. El objetivo es “los paquetes que te importan llegan a los servicios por los que pagas”, de forma consistente, en las redes donde realmente están tus usuarios.