La VPN de FRITZ!Box conecta pero nada responde: WireGuard o IPSec
Un túnel de FRITZ!Box conectado que no llega a la LAN es un problema de direccionamiento. Revise los cuatro campos de IPSec o el peer de WireGuard antes de volver a importar.
El túnel dice que está conectado, el icono está en verde y nada de la LAN de casa responde. Es la queja más habitual del acceso remoto de FRITZ!Box y casi nunca es el túnel en sí. El plan de direcciones, la identidad de la subred o la tabla de rutas del cliente están mal. Cuál de ellos acabe depurando depende de si eligió WireGuard o el antiguo IPSec Fernzugang, así que empiece sabiendo cuál configuró en realidad.
El túnel se levanta y la LAN sigue en silencio
Un túnel que se establece demuestra que las claves y el punto final son correctos. No demuestra que el cliente haya recibido una dirección a la que la caja pueda enrutar, ni que el cliente sepa qué prefijos pertenecen al túnel. Son dos éxitos distintos, y solo el segundo le permite llegar a una impresora.
Compruebe primero la dirección del cliente y después su tabla de rutas.
Si la dirección asignada queda fuera de la subred de la LAN, la caja no tiene a qué enrutar de vuelta. Si queda dentro del rango DHCP, la caja puede entregar la misma dirección a un dispositivo local. Ambas cosas producen un túnel que conecta y una LAN que le ignora.
Qué configura realmente cada opción
La opción IPSec genera un archivo de configuración para un usuario, con la clave precompartida y el direccionamiento. Lo importa en un cliente que hable el mismo perfil, lo que en Windows suele significar la herramienta del fabricante y no el cliente integrado. La opción WireGuard genera un peer para un dispositivo: un par de claves, una dirección dentro del túnel y un punto final.
Esa diferencia decide su modelo de mantenimiento. Cada dispositivo WireGuard es un peer aparte con su propia clave, así que revocar un móvil perdido significa borrar un peer mientras los demás siguen funcionando. IPSec revoca cambiando el secreto compartido o la configuración del usuario, algo más tosco que afecta a todos los dispositivos que lo usan.
Ninguna de las dos opciones está obsoleta. La ruta IPSec sigue siendo la admitida donde el extremo remoto no puede ejecutar WireGuard.
Los campos de IPSec que producen un túnel muerto
Cuatro valores tienen que concordar con su LAN, y tres de ellos fallan de forma que parece un túnel roto.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
La dirección de red es la que atrapa a la gente. Una subred se identifica por su primera dirección, que normalmente termina en cero, e introducir ahí una dirección de host produce una configuración que parece del todo plausible y nunca conecta. El rango DHCP importa por otro motivo: los clientes del túnel suelen asignarse por encima de él, así que un rango que consume toda la subred no deja nada que repartir.
Las subredes solapadas son el otro caso clásico. Si la LAN remota a la que se une usa el mismo prefijo que la LAN en la que está sentado, el enrutamiento no puede distinguirlas, y renumerar uno de los dos lados es la única solución real. Ninguna cantidad de configuración del cliente lo resuelve.
Por qué WireGuard falla de otra manera
WireGuard no tiene clave precompartida que escribir mal, así que sus fallos se agrupan en torno a la definición del peer. Una lista de IP permitidas que omite el prefijo de la LAN produce un túnel que no transporta nada, porque el cliente nunca le envía tráfico destinado a la LAN. Una clave pública antigua en cualquiera de los dos lados produce un saludo que nunca se completa. Un punto final ausente o un puerto equivocado producen silencio en lugar de un error.
Compare los dos lados campo por campo en vez de volver a importar el archivo y confiar.
El único fallo compartido es la colisión de subredes. WireGuard construirá encantado un túnel hacia una red que se solape con la suya, y luego la tabla de rutas decide cuál de los dos prefijos idénticos gana.
Demuéstrelo desde fuera y luego guarde una vía de vuelta
Pruebe desde una conexión móvil, nunca desde dentro de la LAN, porque desde dentro está probando un camino que no implica el túnel en absoluto. Anote qué puerto usa cada opción antes de activarla y redirija ese puerto a la caja.
Guarde el archivo generado en un sitio al que pueda llegar sin el túnel, y de paso anote el nombre externo de la caja.
Una configuración que nunca se ha probado desde fuera es un plan, no una vía de acceso remoto que funcione. Pruebe un equipo de la LAN por dirección y no por nombre, para que un fallo de DNS no se confunda con un fallo de enrutamiento.