WireGuard en un router: errores de NAT que rompen el acceso LAN (y soluciones)

El modelo mental: primero enrutamiento, al final NAT

WireGuard es aburrido de la mejor manera. Es una interfaz punto a punto que cifra paquetes y los coloca en una NIC virtual.
Todo lo demás—quién puede alcanzar qué, cómo regresan los paquetes, si los dispositivos LAN ven las IP reales de los clientes—lo decide la misma vieja
tabla de enrutamiento y las mismas reglas de firewall con las que lidias desde 2003.

Tres verdades que explican el 90% de los casos “la VPN rompe la LAN”

• AllowedIPs es enrutamiento. En un peer, AllowedIPs es un selector de rutas de política y un filtro anti‑suplantación. No es “una ACL.” Trátalo como un mapa de rutas.
• NAT oculta errores hasta que deja de hacerlo. Mascarar el túnel puede hacer que el tráfico de retorno “funcione” sin añadir rutas, pero rompe la visibilidad en la LAN, las políticas entrantes y a veces incluso la conectividad.
• Los caminos de retorno importan más que los de ida. La mayoría de fallos son enrutamiento asimétrico: el paquete entra, la respuesta sale por la interfaz equivocada.

Cuando ejecutas WireGuard en un router, estás combinando dos roles: endpoint VPN y director de tráfico.
Si haces NAT en la pata equivocada (o para las subredes equivocadas), puedes acabar con un túnel que funciona perfectamente mientras la red actúa como si estuviera encantada.

Qué significa realmente “acceso a la LAN”

La gente dice “no puedo acceder a mi LAN”, pero se refieren a varias cosas distintas:

• No se alcanzan IPs de la LAN: Ping a 192.168.1.10 falla desde un cliente remoto a través del túnel.
• Se alcanzan IPs de la LAN pero los servicios fallan: SMB funciona intermitente, mDNS/Bonjour no funciona, descubrimiento de impresoras muerto.
• Los dispositivos LAN no pueden alcanzar al cliente VPN: Puedes conectar al NAS, pero el NAS no puede llamar de regreso a tu portátil (común en backups, agentes de monitorización o conexiones inversas).
• Todo va por la VPN y la LAN muere: El túnel completo captura tráfico RFC1918 y lo enruta al túnel, dejando redes locales inaccesibles.

Las soluciones son diferentes. Si saltas directamente a “añadir masquerade”, estás eligiendo la gratificación rápida por sobre la corrección.
A veces NAT es necesario (especialmente para clientes road warrior), pero quieres entender qué estás intercambiando: observabilidad, identidad y política.

Idea parafraseada de John Allspaw: La fiabilidad viene de entender cómo fallan los sistemas, no de fingir que no fallarán.
Eso también aplica al NAT de WireGuard.

Chiste #1: NAT es como un programa de protección de testigos para paquetes. Genial para privacidad, terrible cuando intentas interrogar al testigo.

Hechos y contexto: por qué esto sigue ocurriendo

Unos pocos hechos concretos ayudan a explicar por qué WireGuard en router + NAT se convierte en un patrón de incidentes recurrente:

1. NAT no formó parte del diseño original de Internet. Se popularizó porque IPv4 se agotó y porque permitió despliegues con “una IP pública” económicos.
2. El reenvío IP en Linux viene por defecto desactivado. El comportamiento de router es opt‑in; los tutoriales de VPN que omiten esto generan confusión de “handshake pero sin tráfico”.
3. La configuración de WireGuard es intencionalmente mínima. No hay “modo servidor” integrado, no empuja rutas mágicamente, no tiene interruptores NAT; lo pegas con el enrutamiento del SO y el firewall.
4. AllowedIPs funciona como ruta y como filtro. Este diseño evita la suplantación pero sorprende a quienes esperan un push de rutas estilo OpenVPN.
5. Los routers de consumo a menudo incluyen NAT helper agresivo. Algunos firmware añaden reglas de masquerade de forma amplia; pueden NATear accidentalmente tráfico LAN‑a‑LAN o túnel‑a‑LAN.
6. Split‑tunnel es lo predeterminado, full‑tunnel es el arma peligrosa. En el momento en que enrutas 0.0.0.0/0 por el túnel, entras en el negocio de excepciones y rutas de política.
7. Los problemas de MTU se intensificaron con VPN sobre CGNAT del ISP. El descubrimiento de MTU de ruta puede ser poco fiable; ICMP bloqueado hace que “funciona para pings pequeños” sea un síntoma clásico.
8. El doble NAT es normal ahora. Usuarios domésticos suelen estar detrás del NAT del ISP además del NAT de su router; las VPN añaden una tercera capa de traducción si no tienes cuidado.
9. NAT rompe la identidad de extremo a extremo. Complica el registro, las ACL y a veces protocolos que incrustan IPs.

Guía rápida de diagnóstico

Cuando el acceso a la LAN falla, no “pruebes cosas al azar en el firewall.” Haz esto en orden. El objetivo es identificar la capa bloqueada:
crypto/handshake de WireGuard, enrutamiento, NAT o filtrado.

Primero: prueba que el túnel está vivo (plano de control)

• Comprueba el tiempo de handshake y los contadores de transferencia en el router.
• Confirma que el cliente tenga una ruta para la LAN (split tunnel) o al menos una ruta por defecto (full tunnel).

Segundo: prueba que el reenvío básico funciona (plano de datos)

• Desde el cliente, haz ping a la IP LAN del router y a la IP del túnel.
• Desde el router, haz ping a un host LAN usando la IP origen del túnel (o usa tcpdump para ver paquetes entrar y salir).

Tercero: valida los caminos de retorno (aquí es donde suele romper)

• En el host LAN (o gateway LAN), verifica que tenga una ruta de vuelta a la subred del cliente WireGuard.
• Si no la tiene, decide: añadir rutas (correcto) o hacer NAT selectivo (compromiso aceptable).

Cuarto: revisa la política de firewall y el alcance del NAT

• Confirma que las reglas de reenvío permitan wg0 → br-lan y br-lan → wg0.
• Confirma que el NAT se aplique solo donde sea necesario (usualmente wg0 → wan para túnel completo, no wg0 → lan salvo que ocultes intencionalmente clientes).

Quinto: MTU y DNS (el cubo de “todo es inestable”)

• Si paquetes pequeños funcionan pero conexiones grandes se estancan, prueba MTU.
• Si “acceso a LAN” es en realidad “los nombres no se resuelven”, inspecciona DNS y split DNS.

Tareas prácticas: comandos, salidas, decisiones

Estas son las tareas que realmente ejecuto durante incidentes. Cada una incluye: comando, salida realista, qué significa y qué decisión tomar después.
Los ejemplos asumen un router basado en Linux (userland tipo Debian/OpenWrt). Traduce a tu plataforma según sea necesario, pero mantén la lógica.

Task 1: Check WireGuard handshake and counters

cr0x@server:~$ sudo wg show
interface: wg0
  public key: oR7...routerpub...
  listening port: 51820

peer: k9T...clientpub...
  endpoint: 198.51.100.23:53312
  allowed ips: 10.6.0.2/32
  latest handshake: 42 seconds ago
  transfer: 18.34 MiB received, 22.91 MiB sent
  persistent keepalive: every 25 seconds

Qué significa: El handshake es reciente, los contadores se mueven. Cripto y el camino UDP están bien.

Decisión: Deja de culpar a “WireGuard que no funciona.” Pasa a enrutamiento/reenvío/NAT.

Task 2: Confirm the router has the expected tunnel address

cr0x@server:~$ ip -brief address show dev wg0
wg0             UP             10.6.0.1/24

Qué significa: La interfaz está arriba y con dirección. Si está DOWN o le falta IP, arregla la configuración de la interfaz antes de cualquier otra cosa.

Decisión: Si la dirección es incorrecta (por ejemplo, /32 en lugar de /24 cuando esperas una subred), corrige y reinicia la interfaz.

Task 3: Verify IP forwarding is enabled

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

Qué significa: El router está actuando como un host. Los paquetes no se reenviarán entre wg0 y LAN/WAN.

Decisión: Habilita el reenvío y persístelo.

Task 4: Enable forwarding (temporary + persistent)

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

Qué significa: El reenvío está activado ahora; vuelve a probar el tráfico inmediatamente.

Decisión: Si esto lo arregla, persiste en /etc/sysctl.conf o el equivalente de la distro y audita por qué estaba apagado.

Task 5: Check routes on the router (main table)

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan0
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1
192.168.50.0/24 dev br-lan proto kernel scope link src 192.168.50.1

Qué significa: El router conoce ambas redes. Bien. Si falta la subred LAN, tu bridge LAN no está configurado. Si falta la ruta wg0, WireGuard no aplicó la dirección.

Decisión: Si las rutas parecen correctas, enfócate en firewall y alcance de NAT.

Task 6: Check policy routing rules (full tunnel setups often add these)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.6.0.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Qué significa: El tráfico originado desde la subred WireGuard usa la tabla 100. Esto es común cuando fuerzas a clientes VPN a salir por WAN u otro uplink.

Decisión: Si el acceso a la LAN falla solo para clientes VPN, la tabla 100 podría no tener una ruta a 192.168.50.0/24 (o lo está enviando por WAN). Inspecciona la tabla 100 a continuación.

Task 7: Inspect the alternate routing table

cr0x@server:~$ ip route show table 100
default via 203.0.113.1 dev wan0

Qué significa: Para el tráfico con origen en la subred VPN, todo—incluida la subred LAN—sigue la ruta por defecto hacia wan0. Eso hace que el acceso LAN sea inalcanzable o que el tráfico salga fuera.

Decisión: Añade una ruta explícita a la LAN en la tabla 100, o corrige tu regla de política para que los destinos LAN usen main.

Task 8: Add LAN route to policy table (example fix)

cr0x@server:~$ sudo ip route add 192.168.50.0/24 dev br-lan table 100

Qué significa: Ahora el tráfico cliente VPN destinado a la LAN se queda local.

Decisión: Vuelve a probar. Si esto lo arregla, persiste la ruta mediante el sistema de configuración de red del router.

Task 9: Confirm the client is actually routing LAN via the tunnel

cr0x@server:~$ ip route get 192.168.50.10
192.168.50.10 via 10.6.0.1 dev wg0 src 10.6.0.2 uid 1000
    cache

Qué significa: El cliente enviará tráfico LAN a wg0. Si muestra dev wlan0 o tu interfaz normal, la AllowedIPs/split‑tunnel del cliente está mal.

Decisión: Arregla la configuración del cliente (AllowedIPs debe incluir las subredes LAN que quieres alcanzar) antes de cambiar el NAT del router.

Task 10: Watch packets enter wg0 and leave toward LAN

cr0x@server:~$ sudo tcpdump -ni wg0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:01:10.112233 IP 10.6.0.2 > 192.168.50.10: ICMP echo request, id 4421, seq 1, length 64

Qué significa: El router está recibiendo el ping desde el túnel.

Decisión: Si lo ves en wg0 pero no en LAN, tu reenvío/firewall lo está bloqueando. Si lo ves en LAN pero no hay respuesta, es un problema de camino de retorno.

Task 11: Confirm it leaves via the LAN interface

cr0x@server:~$ sudo tcpdump -ni br-lan icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112987 IP 10.6.0.2 > 192.168.50.10: ICMP echo request, id 4421, seq 1, length 64

Qué significa: El reenvío funciona al menos en una dirección: wg0 → LAN.

Decisión: Si no llega eco de vuelta a wg0, el host LAN no sabe cómo devolver a 10.6.0.0/24 (o un firewall lo bloquea). Decide entre añadir rutas o aplicar NAT.

Task 12: Check NAT rules (iptables legacy example)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o wan0 -j MASQUERADE
-A POSTROUTING -o br-lan -j MASQUERADE

Qué significa: Esa segunda regla es sospechosa: masquerading hacia br-lan significa que los paquetes enviados a la LAN serán source‑NATeados a la IP LAN del router. Tus hosts LAN nunca verán la IP real del cliente VPN.

Decisión: Si tu objetivo es “los clientes VPN son miembros de la LAN de primera clase”, elimina esa regla. Si tu objetivo es “acceder a la LAN sin cambiar rutas LAN”, entonces mantenla—pero entiende el coste y delimítala estrictamente.

Task 13: Remove overly broad masquerade (dangerous if you rely on it)

cr0x@server:~$ sudo iptables -t nat -D POSTROUTING -o br-lan -j MASQUERADE

Qué significa: El tráfico VPN→LAN preservará ahora las IPs origen (10.6.0.x). El enrutamiento de retorno debe ser correcto.

Decisión: Si algo se rompe después de esto, has demostrado que dependías del NAT para encubrir rutas faltantes. Arregla el enrutamiento correctamente.

Task 14: Add a proper LAN route on the LAN gateway (example)

cr0x@server:~$ sudo ip route add 10.6.0.0/24 via 192.168.50.1

Qué significa: Los dispositivos LAN que usan ese gateway ahora pueden devolver tráfico a la subred WireGuard a través del router.

Decisión: Si no puedes añadir rutas en cada dispositivo LAN, añádela en el gateway por defecto (o usa la opción DHCP 121/rutas estáticas sin clase) para que los clientes la aprendan automáticamente.

Task 15: Inspect nftables ruleset (modern routers often use nft)

cr0x@server:~$ sudo nft list ruleset
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "wg0" oifname "br-lan" accept
    iifname "br-lan" oifname "wg0" ct state established,related accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wan0" masquerade
  }
}

Qué significa: La cadena forward permite wg0 → LAN, pero LAN → wg0 solo acepta conexiones established/related. Eso bloquea inicios de conexión desde la LAN hacia clientes VPN (y rompe algunos protocolos que no parecen “establecidos” como esperas).

Decisión: Decide si quieres que la LAN pueda iniciar conexiones a la VPN. Si sí, añade un accept explícito para iif br-lan oif wg0 con las restricciones adecuadas.

Task 16: Test MTU if you see “works for ping, fails for apps”

cr0x@server:~$ ping -M do -s 1420 192.168.50.10 -c 2
PING 192.168.50.10 (192.168.50.10) 1420(1448) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 192.168.50.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Qué significa: Tu camino no soporta ese tamaño con DF activado. Necesitas una MTU de túnel menor o clamping de MSS.

Decisión: Baja la MTU de WireGuard (por ejemplo, 1280–1380 dependiendo del WAN) y vuelve a probar con tamaños incrementales.

Chiste #2: El paquete era demasiado grande para el túnel, como un ingeniero de almacenamiento intentando meter “solo un dataset más” en un pool lleno.

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

Esta sección es opinada porque debe serlo. Estos son los errores que aparecen una y otra vez en colas de tickets y en writeups de laboratorios caseros.
Cada uno incluye el síntoma que verás, la causa real y una solución que no cree el siguiente incidente.

1) “Hace handshake, pero no puedo hacer ping a hosts LAN”

Síntoma: wg show muestra handshake reciente; los contadores de tráfico aumentan; las IPs LAN no responden.

Causa raíz: Falta la ruta de retorno desde la LAN a la subred del cliente WireGuard (10.6.0.0/24, 10.0.0.0/24, etc.).

Solución: Añade una ruta en el gateway LAN apuntando la subred WireGuard a la IP LAN del router. Si eso es imposible, haz NAT selectivo para wg0 → LAN, acotado a la subred LAN únicamente.

2) “El acceso LAN funciona, pero los dispositivos LAN ven todo viniendo del router”

Síntoma: Los logs del NAS muestran IP origen = 192.168.50.1 para todos los clientes VPN; las ACL por cliente fallan.

Causa raíz: Mascarade aplicado en wg0 → LAN (POSTROUTING en br-lan). Convertiste a los clientes remotos en “el router”.

Solución: Elimina el NAT para tráfico hacia la LAN; añade enrutamiento correcto. Si debes NATear, restringe a un conjunto pequeño de dispositivos legacy y documenta el motivo.

3) “Activé túnel completo y ahora el acceso local falla en el cliente”

Síntoma: El cliente no puede alcanzar 192.168.0.1 en la Wi‑Fi local después de habilitar AllowedIPs = 0.0.0.0/0.

Causa raíz: El túnel completo secuestra todas las rutas IPv4, incluidas las RFC1918. El cliente intenta alcanzar el gateway local por el túnel.

Solución: Usa split tunnel (solo enruta lo necesario), o añade rutas explícitas de bypass LAN en el cliente. En algunos clientes es “excluir IPs privadas”, en otros añades rutas manuales.

4) “Algunos servicios funcionan, pero SMB/RDP es inestable o se cuelga”

Síntoma: Ping funciona, HTTP pequeño funciona, pero transferencias grandes se quedan o escritorio remoto se congela.

Causa raíz: MTU/PMTUD en blackhole. La sobrecarga del túnel empuja paquetes por encima del MTU de la ruta; los ICMP fragmentation‑needed están bloqueados por el firewall de alguien.

Solución: Baja la MTU de WireGuard (comienza alrededor de 1380, baja hasta 1280 si hace falta) o aplica clamping de TCP MSS en el router para flujos wg0.

5) “Solo una VLAN funciona sobre la VPN; otras VLANs están muertas”

Síntoma: Puedes alcanzar 192.168.50.0/24 pero no 192.168.60.0/24.

Causa raíz: AllowedIPs en el peer cliente o servidor no incluye todos los prefijos LAN, o las reglas de firewall solo permiten una interfaz/zona.

Solución: Añade las subredes VLAN faltantes a AllowedIPs en el cliente y asegúrate de que el router reenvíe wg0 hacia las interfaces VLAN.

6) “Los clientes VPN pueden alcanzar la LAN, pero la LAN no puede alcanzar a los clientes VPN”

Síntoma: El cliente remoto puede SSH al NAS, pero el NAS no puede conectar de vuelta al cliente para un callback inverso.

Causa raíz: La política de forward del firewall solo permite flujos establecidos desde LAN hacia wg0, o el NAT oculta al cliente y rompe inicios entrantes.

Solución: Permite LAN → wg0 donde sea necesario, o mantenlo bloqueado intencionalmente y acepta que la VPN solo puede iniciar conexiones desde el cliente. No bloquees accidentalmente y luego te preguntes por qué los backups no pueden empujar.

7) “El DNS funciona para Internet, pero nombres internos no se resuelven”

Síntoma: nas.lan falla pero 1.1.1.1 funciona bien.

Causa raíz: El cliente usa DNS público sobre el túnel; no hay split DNS; faltan dominios de búsqueda. La gente lo llama “acceso LAN” pero es resolución de nombres.

Solución: Forzar/usar DNS interno para el dominio LAN cuando estés en la VPN. Si ejecutes túnel completo, usa el resolver del router; si es split, configura DNS por dominio si tu cliente lo soporta.

8) “Funcionó ayer, ahora no y nada cambió (supuestamente)”

Síntoma: Falla repentinamente tras reinicio del ISP o del router; los handshakes aún ocurren.

Causa raíz: La IP WAN dinámica cambió y el endpoint del peer no se actualizó, o el estado NAT/conntrack se reseteó y reveló un enrutamiento asimétrico que NAT había estado enmascarando.

Solución: Asegura keepalive para clientes road‑warrior, considera estrategias de actualización dinámica de endpoints, y arregla el enrutamiento para no depender de estados conntrack obsoletos.

Tres mini-historias corporativas desde las trincheras del NAT

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó WireGuard en un router de sucursal para que los ingenieros on‑call pudieran acceder a herramientas internas durante una mudanza de oficina.
La persona que lo construyó supuso “los clientes VPN deberían parecer que están en la LAN.” Objetivo razonable, implementación equivocada.

Activaron una regla de masquerade amplia para cualquier cosa que viniera de wg0 y fuera al bridge LAN. Eso “arregló” la conectividad inmediatamente.
Los ingenieros podían acceder a Jira, Grafana y al servidor de ficheros. Todos celebraron y siguieron con su día.

Dos semanas después, seguridad preguntó por qué los logs del servidor de ficheros mostraban al router como origen de cada sesión VPN.
Luego operaciones notó que el rate limiting se disparaba contra la IP LAN del router, no contra las IPs reales de los clientes.
Un par de ACL internas que debían ser “solo administradores” se convirtieron en “cualquier usuario VPN” porque la ACL se basaba en IP origen y el router estaba en la allowlist.

El incidente no fue “inseguridad de WireGuard.” Fue colapso de identidad causado por NAT.
La solución fue aburrida: eliminar el NAT wg0→LAN, añadir una ruta para la subred VPN en el gateway LAN y actualizar la política de firewall para permitir explícitamente los flujos intentados.
Después de eso, los logs y las ACL volvieron a tener sentido, lo cual es una extraña clase de alegría.

Mini-historia 2: La optimización que salió mal

Otra organización quería acceso remoto más rápido para desarrolladores. Alguien leyó que “NAT es caro” y trató de optimizar evitando conntrack.
Implementaron enrutamiento por política para que el tráfico de clientes VPN usara una tabla especial y evitara algunas cadenas de firewall, esperando menor latencia.

Aislado, el cambio parecía limpio. El túnel se mantuvo activo. Los benchmarks de throughput a Internet mejoraron un poco.
Entonces otra cosa totalmente diferente se rompió: el acceso al Git interno sobre la VLAN LAN se volvió intermitente, pero solo para ciertos desarrolladores.

El culpable fue que la tabla de política no tenía una ruta específica para una de las subredes internas.
El tráfico de 10.6.0.0/24 hacia 192.168.70.0/24 siguió la ruta por defecto de la política hacia la interfaz WAN.
Las respuestas nunca volvieron, porque esos paquetes nunca deberían haber salido del edificio.

La “optimización” creó un universo paralelo de enrutamiento que derivó de la realidad. La solución también fue aburrida: replicar las rutas LAN requeridas en la tabla de política,
añadir un test de regresión que valide reachability a cada prefijo interno, y dejar de tratar el enrutamiento por política como un tweak de rendimiento para un viernes por la tarde.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un tercer equipo gestionaba una flota de routers pequeños para sitios remotos, todos administrados de la misma forma. Su plantilla de WireGuard nunca incluía masquerade wg0→LAN.
En su lugar, cada gateway de sitio llevaba una ruta estática para la subred de clientes VPN de vuelta al router, y DHCP distribuía rutas sin clase cuando era necesario.

No era glamuroso. Requería mantener un inventario de qué subredes existían y asegurarse de que las plantillas no divergieran.
Pero significaba que los paquetes preservaban la identidad de origen de extremo a extremo. Los logs eran precisos. La política de firewall tenía sentido.

Durante una molesta caída del ISP en un sitio, tuvieron que cambiar temporalmente el egress VPN a un uplink de respaldo.
Como su diseño no dependía de trucos NAT para el acceso LAN, el cambio fue mayormente sobre rutas por defecto y failover.
El acceso interno siguió funcionando mientras el uplink fallaba. El on‑call pudo dormir.

La lección: la corrección escala. Los “arreglos rápidos” también escalan, pero en la dirección contraria.

Patrones que realmente funcionan (y por qué)

Patrón A: Enrútalo correctamente (preferido)

Si tu objetivo es pertenencia real a la LAN—los clientes tienen IPs de túnel estables, quieres logging y ACLs por cliente—haz enrutamiento, no NAT.
Eso significa:

• Los clientes WireGuard viven en una subred dedicada (p. ej., 10.6.0.0/24).
• El router conoce tanto la LAN como la subred VPN (lo hace por defecto si está configurado).
• El gateway LAN tiene una ruta de vuelta a la subred WireGuard vía el router.
• El firewall permite los flujos que quieres; niega el resto.

Esta es la única aproximación que hace que la identidad, el monitorizado y la depuración sean sensatos. Si operas redes profesionalmente, elige esto salvo que tengas una buena razón para no hacerlo.

Patrón B: NAT selectivo para LANs legacy (compromiso aceptable)

A veces no puedes añadir rutas en el gateway LAN. Quizá es un equipo del ISP, quizá es una red gestionada que no controlas,
o la LAN es un zoológico de dispositivos estáticos que no puedes tocar.

En ese caso, NAT puede ser una herramienta pragmática—pero delimítala:

• NAT solo desde la subred WireGuard a prefijos LAN específicos.
• No masqueradees todo el tráfico wg0 en todas las direcciones.
• Mantén una lista de dispositivos/subredes que dependen de esto para poder deshacerlo después.

El objetivo es evitar el síndrome “todos los clientes VPN se convierten en el router” y evitar NAT LAN‑a‑LAN no intencionado.

Patrón C: Túnel completo en un router (potente, pero exige trabajo)

Túnel completo es cuando los clientes enrutan 0.0.0.0/0 (y a veces ::/0) hacia wg0. En un router, esto normalmente significa que quieres que los clientes remotos usen el egress de tu casa/oficina
(por confianza, geolocalización, filtrado de contenido, o porque el Wi‑Fi del hotel es malicioso).

El túnel completo casi siempre necesita NAT en el egress WAN, porque estás enviando direcciones privadas del túnel hacia Internet. Pero ese NAT pertenece a wg0→WAN, no a wg0→LAN.
Además, el túnel completo introduce estos requisitos recurrentes:

• Excepciones LAN: asegúrate de que los prefijos internos sigan ruteándose localmente (especialmente si usas tablas de política).
• Estrategia DNS: DNS interno para nombres internos; decide si resolver via router o usar split DNS.
• Ajuste MTU: más saltos, más encapsulación, más posibilidades de problemas con PMTUD.

Dónde se equivocan las personas: confundir “hacerlo alcanzable” con “hacerlo correcto”

NAT seduce porque puede hacer que los paquetes vuelvan sin tocar la LAN. Pero cuando NATeas el túnel hacia la LAN, estás reescribiendo la historia que cuentan tus paquetes.
Todo lo que viene después—logs, ACLs, límites de tasa, auditorías de aplicaciones—ahora ve “lo hizo el router”.

Si haces esto en casa y no te importa, perfecto. Si lo haces en el trabajo y te importa la atribución, no lo hagas.

Listas de verificación / plan paso a paso

Paso a paso: restaurar acceso LAN sin NAT cargo‑cult

1. Confirma handshake y contadores: wg show debe mostrar handshake reciente y transferencia no nula. Si no, arregla endpoints/keys/alcance UDP.
2. Revisa el reenvío del router: habilita net.ipv4.ip_forward=1. Si hay IPv6 involucrado, también habilita el reenvío IPv6 intencionalmente.
3. Confirma la intención de enrutamiento del cliente: AllowedIPs del cliente debe incluir las subredes LAN que quieres alcanzar (split tunnel) o 0.0.0.0/0 (túnel completo).
4. Confirma rutas del router: el router debe tener rutas conectadas para LAN y wg0. Si usas enrutamiento por política, confirma que esas tablas incluyen también rutas LAN.
5. Prueba el flujo de paquetes con tcpdump: observa ICMP/TCP en wg0 y br-lan. Si no atraviesa, es firewall/reenvío.
6. Arregla el camino de retorno correctamente: añade una ruta para la subred WireGuard en el gateway LAN apuntando al router. Prefiere hacerlo una vez en el gateway, no en cada host.
7. Solo entonces considera NAT: si realmente no puedes arreglar el enrutamiento, añade una regla NAT acotada desde la subred wg0 a la subred LAN, no una masquerade amplia.
8. Asegura la política de firewall: permite solo los protocolos necesarios desde wg0 hacia la LAN; considera bloquear el movimiento lateral por defecto.
9. Valida MTU: prueba paquetes grandes y ajusta MTU/MSS si es necesario.
10. Documenta: incluye qué subredes existen, dónde hay NAT y qué significa “funciona” (pruebas que puedas ejecutar).

Lista de decisiones: ¿deberías NATear VPN→LAN?

• ¿Controlas el gateway LAN? Si sí, enrútalo. Si no, NAT puede ser tu única opción.
• ¿Necesitas atribución por cliente en sistemas LAN? Si sí, no hagas NAT wg0→LAN.
• ¿Esperas conexiones iniciadas desde la LAN hacia clientes VPN? Si sí, el enrutamiento es mucho más fácil que NAT + redirecciones de puerto + frustración.
• ¿Es temporal? Si debes NATear, trátalo como deuda técnica con un plan de salida.

Tests de regresión (ejecutar tras cada cambio)

Haz estas pruebas hasta que sean reflejo muscular. Detectan la mayoría de roturas:

• Desde cliente VPN: ping a IP LAN del router, ping a un host LAN, conectar a un servicio TCP (SSH/HTTPS/SMB).
• Desde el router: ping a host LAN, ping a IP de túnel del cliente VPN.
• Desde un host LAN: ping a IP de túnel del cliente VPN (si quieres LAN→VPN), o confirma que está bloqueado (si no lo quieres).
• Revisa logs: confirma que el servicio LAN ve la IP del cliente VPN (si diseño por enrutamiento) o ve al router (si diseño con NAT, intencionalmente).

Preguntas frecuentes

1) ¿Por qué WireGuard “se conecta” pero el tráfico LAN no se mueve?

El handshake solo demuestra establecimiento criptográfico de la sesión. El tráfico de datos aún necesita reenvío IP, rutas correctas y permiso del firewall.
Con mayor frecuencia el camino de ida funciona pero falta la ruta de retorno desde la LAN hacia la subred VPN.

2) ¿Es AllowedIPs una regla de firewall?

No exactamente. Se comporta como un selector de enrutamiento (qué destinos van a ese peer) y como filtro de origen (qué direcciones origen se aceptan de ese peer).
Trátalo como política de enrutamiento, luego usa el firewall real para control de acceso.

3) ¿Debería masqueradear el tráfico de WireGuard?

Mascarade suele ser correcto para wg0→WAN cuando haces egress de túnel completo. Mascaradear wg0→LAN suele ser un parche para rutas faltantes.
Usa enrutamiento si puedes; usa NAT acotado solo cuando sea imprescindible.

4) Mi LAN es 192.168.1.0/24 y la red remota también es 192.168.1.0/24. ¿Ahora qué?

Subredes solapadas son un callejón sin salida para el enrutamiento. Necesitas renumerar un lado, o NATear un lado a un rango no solapado, o usar proxies a nivel de aplicación.
Si es una VPN site‑to‑site, planifica un proyecto de renumeración y deja de fingir que no va a pasar.

5) ¿Por qué puedo alcanzar IPs pero no nombres de host?

Eso es DNS, no enrutamiento. Tu cliente puede estar usando DNS público o carecer del dominio de búsqueda LAN.
Configura el cliente VPN para usar tu DNS interno (o ejecuta un resolvedor en el router) y asegúrate de que las zonas internas sean alcanzables.

6) ¿Cómo permito que los clientes VPN accedan solo a un host LAN (como un NAS) y a nada más?

Enruta correctamente (sin NAT), luego aplica reglas de firewall: permite wg0 hacia la IP/puertos del NAS, deniega wg0 al resto de la LAN.
Hacer esto con NAT dificulta la auditoría y puede crear accesos accidentales vía los privilegios del router.

7) ¿Por qué el tráfico falla solo en descargas grandes o copias de archivos?

Problemas de MTU/PMTUD. El camino no puede transportar paquetes grandes encapsulados, y los ICMP “fragmentation needed” pueden estar bloqueados.
Baja la MTU de WireGuard o aplica clamping de TCP MSS en el router para tráfico que cruza wg0.

8) ¿Cuál es la forma más limpia de evitar añadir rutas en cada dispositivo LAN?

Añade una ruta en el gateway por defecto de la LAN a la subred WireGuard vía el router. Si tu LAN tiene múltiples gateways/VLANs, coloca la ruta en el L3 core.
Para endpoints, las rutas estáticas sin clase por DHCP pueden ayudar, pero la ruta en el gateway es la más simple.

9) ¿Necesito permitir el reenvío br-lan → wg0?

Solo si quieres que la LAN inicie conexiones hacia los clientes VPN. Muchas configuraciones lo bloquean intencionalmente por seguridad.
Pero sé explícito: si lo bloqueas, documenta que la VPN es iniciada solo por clientes para que nadie pierda un fin de semana depurando “callbacks rotos.”

Próximos pasos que deberías hacer hoy

Si tu configuración actual “funciona” solo porque mascaradeas wg0 hacia la LAN, estás a un cambio de distancia de una intervención extraña o un misterio en los logs.
Arréglalo como si te importara.

1. Audita el alcance del NAT: asegura que exista masquerade para wg0→WAN si es necesario, y elimina masquerade wg0→LAN a menos que sea un compromiso explícito y documentado.
2. Haz correcto el enrutamiento de retorno: añade la ruta de la subred WireGuard en el gateway LAN y verifica con un ping desde la LAN a una IP cliente VPN.
3. Valida con capturas de paquetes: tcpdump en wg0 y en LAN para demostrar dónde se detiene el paquete.
4. Decide tu postura de seguridad: ¿la LAN puede iniciar hacia los clientes VPN? Si sí, permite cuidadosamente; si no, bloquéalo de forma audible e intencional.
5. Escribe un runbook de una página: incluye tus subredes, dónde existe NAT y tres tests de regresión. El tú del futuro te lo agradecerá menos enojado.

Haz esas cosas, y WireGuard será lo que debe ser: una interfaz cifrada simple, no un ejercicio recurrente de interpretación del NAT.