Tenía el cursor encima de Desactivar DHCP cuando pensé en todo lo que podía dejar de funcionar.
Mi objetivo era bastante pequeño: montar un servidor WireGuard en casa para conectarme desde el portátil durante un viaje.
El router principal ya hacía todo lo demás.
Daba Wi-Fi a los móviles.
Asignaba direcciones a los dispositivos.
Mantenía conectada la televisión.
Las cámaras funcionaban.
Y yo estaba a punto de cambiar toda esa red porque varios tutoriales parecían conducir al mismo sitio: modo bridge, segundo router, DHCP fuera, Wi-Fi fuera.
Cerré la pestaña.
La pregunta que realmente necesitaba responder era mucho más sencilla:
¿Se puede montar un servidor VPN con DDNS sin desactivar el DHCP ni el Wi-Fi del router principal?
Sí.
Y descubrirlo evitó que desmontara una red que ya funcionaba.
Resumen del artículo y encaje del producto
¿Se puede montar un servidor VPN con DDNS sin apagar DHCP ni Wi‑Fi?
Sí. El router principal puede seguir dando Wi‑Fi y asignando direcciones mientras un servidor WireGuard vive detrás con una IP local estable y el puerto necesario redirigido. El obstáculo decisivo del relato no fue DHCP ni DDNS, sino que CGNAT impedía que una conexión entrante alcanzara la red doméstica.
Por qué este contexto importa
- Útil para: Quien quiere acceso remoto a su propia LAN sin convertir el router del operador en un simple módem ni rehacer una red doméstica que ya funciona.
- Detalle del relato: La prueba desde 5G falló aunque DDNS, claves y port forwarding parecían correctos; la dirección WAN del router no coincidía con la IP pública visible desde Internet.
- Límite importante: Si el operador coloca la conexión detrás de CGNAT, una reserva DHCP y un port forwarding correctos no crean por sí solos una entrada pública. Para un viaje cuyo objetivo es solo proteger portátil y teléfono, mantener un servidor doméstico puede ser más infraestructura de la necesaria.
Encaje de OnlydogVPN: En este relato OnlydogVPN solo encaja en la segunda necesidad: proteger los dos dispositivos que salen de casa sin depender de una conexión entrante al router doméstico. No sustituye al servidor WireGuard cuando el objetivo real es entrar al NAS o a otros servicios privados de la LAN. Fuente del producto: sitio oficial de OnlydogVPN.
Fuentes ya citadas en el artículo: El diagnóstico se apoya en la documentación de TP-Link sobre port forwarding detrás del router principal, su guía de DDNS, IP privada y CGNAT y la información oficial de DIGI sobre CG-NAT; el hilo de r/WireGuard queda solo como apoyo anecdótico.
El router principal puede seguir haciendo su trabajo
No necesitaba convertir el router del operador en un módem.
Podía mantener su DHCP y su Wi-Fi exactamente como estaban. El servidor VPN podía vivir detrás, dentro de la misma red local, en otro router, un mini PC o cualquier dispositivo preparado para ejecutar WireGuard.
El esquema era bastante simple:
Internet → router principal → servidor VPN.
El router seguía administrando la casa. Solo necesitaba saber a qué dispositivo debía enviar las conexiones destinadas al servidor.
TP-Link documenta precisamente este tipo de montaje: un servidor VPN detrás del router principal, con una redirección del puerto correspondiente hacia su dirección local. Para WireGuard, el ejemplo utiliza UDP 51820.
Eso también aclaró mi duda sobre DHCP.
No hacía falta apagarlo.
Solo convenía que el servidor VPN mantuviera siempre la misma IP dentro de casa. Una reserva DHCP resolvía esa parte sin tocar el resto de los dispositivos.
Hice los cambios.
WireGuard funcionaba dentro de la red.
Configuré DDNS.
Pensé que ya estaba.
Entonces apagué el Wi-Fi del móvil y probé desde 5G.
Nada.
DDNS resolvía el nombre, pero no abría la puerta
Revisé la configuración.
El nombre DDNS apuntaba correctamente.
Las claves estaban bien.
La redirección de puerto también.
Volví a probar.
Nada.
Hasta que comparé dos números: la dirección WAN que mostraba el router y la IP pública que veía desde Internet.
No coincidían.
Ahí apareció la pieza que había estado buscando en el lugar equivocado.
CGNAT.
DDNS sirve para que un nombre siga apuntando a tu conexión aunque cambie la IP pública. Pero si el operador coloca otra capa de NAT delante de tu router, el tráfico entrante ni siquiera llega hasta la red donde configuraste el port forwarding.
De pronto todo encajaba.
Mi servidor no estaba mal configurado.
El DHCP no molestaba.
El Wi-Fi tampoco.
El DDNS estaba funcionando.
Simplemente mi router no tenía una entrada pública directa desde Internet.
Y eso cambia por completo el diagnóstico.
En España es fácil descubrir el CGNAT justo cuando intentas entrar desde fuera
Yo había cambiado de fibra buscando más velocidad y mejor precio.
Eso tampoco era un caso extraño.
DIGI superó los 2,9 millones de clientes de fibra en España en junio de 2026, un crecimiento interanual del 28 %. La propia compañía explica que utiliza CG-NAT y ofrece Conexión Plus para quienes necesitan una IP exclusiva.
Para navegar, ver streaming o hacer videollamadas, puedes no notar ninguna diferencia.
El CGNAT suele aparecer en tu vida cuando intentas hacer justo lo contrario de lo habitual: en lugar de salir desde casa hacia Internet, quieres entrar desde Internet hacia casa.
Un hilo reciente de r/WireGuard mostraba la misma confusión en pocas líneas: alguien quería acceder desde el extranjero a su homelab sin poner el router del operador en bridge, y la cuestión decisiva terminó siendo si podía recibir conexiones entrantes o estaba detrás de CGNAT.
Eso era exactamente lo que necesitaba comprobar yo.
No si debía apagar DHCP.
Sino si Internet podía llegar hasta mi puerta.
Ahí tuve que decidir qué problema estaba intentando resolver
Si mi objetivo era entrar en el NAS, administrar máquinas de casa o acceder a servicios internos, el servidor WireGuard seguía teniendo sentido.
En ese caso, el camino era claro:
mantener el router principal como estaba, reservar una IP local para el servidor, abrir el puerto necesario, usar DDNS y conseguir una dirección pública accesible cuando el operador lo permitiera.
No hacía falta sacrificar el Wi-Fi de toda la casa.
Pero mi viaje no dependía realmente del NAS.
Yo había empezado todo aquello porque quería conectar el portátil desde hoteles y redes que no controlaba.
El servidor doméstico era el método que había elegido.
No era el objetivo.
Y llevaba una tarde administrando NAT, DDNS, WireGuard y puertos para proteger dos dispositivos que iba a meter en una mochila al día siguiente.
En ese momento probé OnlydogVPN↗.
El problema se redujo de toda la casa a dos dispositivos
No cambié nada más en el router.
El Wi-Fi siguió funcionando.
El DHCP siguió repartiendo direcciones.
El servidor WireGuard podía quedarse como proyecto para cuando realmente necesitara acceso remoto a la LAN.
En el portátil elegí el ajuste orientado a redes con restricciones y conecté.
Abrí el portal de trabajo que quería utilizar durante el viaje.
Cargó.
Inicié una transferencia.
Terminó.
Después añadí el teléfono mediante el código de verificación, sin montar otra ronda de correo, contraseña y configuración.
Eso resolvía la necesidad inmediata mucho mejor que seguir modificando la infraestructura doméstica.
El servicio utiliza transporte basado en HTTP/3 junto con ofuscación adicional. No puedo observar desde fuera las reglas internas con las que cada red u operador clasifica determinado tráfico; lo que sí podía observar era el resultado práctico: los dos dispositivos que iba a llevar conmigo estaban listos sin depender de que mi router doméstico aceptara una conexión entrante.
Ahí entendí por qué mi planteamiento inicial era demasiado grande.
Quería protección durante un viaje.
Había empezado a rediseñar mi casa.
El servidor doméstico seguía siendo útil, pero para otra cosa
Eso no convirtió WireGuard con DDNS en una mala idea.
Al contrario.
Si quiero entrar desde fuera en equipos que solo existen dentro de mi LAN, terminaré ese montaje. Y ahora sé que puedo hacerlo sin apagar DHCP ni Wi-Fi.
Pero para proteger el portátil y el teléfono cuando salgo de casa, mantener un servidor propio introduce varias piezas que no necesito para cumplir esa tarea:
la IP pública,
el DDNS,
el puerto,
el servidor encendido,
y la posibilidad de que el operador cambie las condiciones de acceso.
La aplicación pequeña evita toda esa cadena.
Tiene menos ubicaciones y una trayectoria pública más corta que los proveedores grandes, pero para este caso concreto eso me importaba bastante menos que poder sacar dos dispositivos de casa sin convertir el router familiar en infraestructura crítica.
Entonces, ¿se puede montar un servidor VPN con DDNS sin desactivar DHCP ni Wi-Fi?
Sí.
Mantendría el router principal funcionando normalmente.
Dejaría activo su DHCP.
Dejaría activo su Wi-Fi.
Reservaría una IP local para el servidor VPN.
Redirigiría únicamente el puerto necesario.
Configuraría DDNS.
Y antes de tocar nada más comprobaría si la dirección WAN del router es realmente accesible desde Internet.
Porque si estás detrás de CGNAT, apagar DHCP no arreglará el problema.
En mi caso, esa comprobación salvó la red doméstica de una reforma innecesaria.
También me hizo separar dos necesidades que había mezclado desde el principio.
Si necesito entrar en casa, montaré el servidor.
Si necesito salir de casa con una conexión VPN en el portátil y el teléfono, prefiero no depender de que mi casa esté esperando conexiones.
Mi error no fue dejar encendido el DHCP.
Fue intentar convertir toda la red doméstica en la solución de un problema que cabía en mi mochila.
Preguntas frecuentes
¿Hay que desactivar el DHCP o el Wi‑Fi del router principal para montar un servidor WireGuard en casa?
No. En el montaje descrito, el router principal puede conservar DHCP y Wi‑Fi. Lo importante es que el servidor VPN mantenga una IP local estable —por ejemplo mediante una reserva DHCP— y que el router redirija únicamente el puerto necesario hacia ese dispositivo.
¿Por qué DDNS puede resolver correctamente y aun así no llegar al servidor VPN desde fuera?
Porque DDNS solo mantiene un nombre apuntando a la dirección pública de la conexión. Si el operador coloca otra capa de NAT delante del router, como ocurre con CGNAT, el tráfico entrante puede no llegar hasta la red donde configuraste el port forwarding.
¿Qué conviene comprobar antes de cambiar toda la red doméstica?
El artículo propone comparar la dirección WAN que muestra el router con la IP pública visible desde Internet y confirmar si la conexión puede recibir tráfico entrante. Esa comprobación separa un problema de acceso público de un supuesto conflicto con DHCP o Wi‑Fi.
¿Cuándo tiene sentido un servidor VPN doméstico y cuándo basta una VPN en los dispositivos?
El servidor doméstico tiene sentido si necesitas entrar desde fuera al NAS, a máquinas o a servicios que solo existen en tu LAN. Si el objetivo inmediato es proteger un portátil y un teléfono en redes ajenas durante un viaje, una VPN instalada directamente en esos dispositivos evita depender de DDNS, puertos y una IP pública accesible.