Problema con router y VPN
Buenas, Estoy intentando montar una VPN y he probado prácticamente de todo. También he consultado con varias personas que controlan bastante del tema para revisar si la configuración que tenía hecha...
Foro
Buenas Theliel,
Entiendo todo lo que me comentas. La verdad es que con el ejemplo de las muñecas matriuska se entiende perfectamente cómo funciona toda la parte de NAT y encapsulación.
Por lo que veo entonces, usando WireGuard no debería existir ningún problema “especial” a nivel del router de Movistar, sino que probablemente el problema venga del propio Cudy por todo lo que comentas.
1 - He comprobado que el mapeo de puertos UDP es correcto. De hecho, el 51820 es el puerto recomendado para WireGuard.
En el router de Movistar tengo configurado que a la IP que se le asigna al Cudy (192.168.1.52) nunca se le cambie aunque el router se reinicie. No sé si además convendría fijar también esa IP desde el propio Cudy usando DHCP estático o si eso podría entrar en conflicto.
2 - Sobre posibles bloqueos, ante la duda desactivé completamente el firewall que trae el Cudy.
3 - El servicio DDNS funciona correctamente. Resuelve bien incluso después de cambios de IP pública, así que esa parte prácticamente la descarto.
Resulta que el Cudy tiene unas herramientas de diagnóstico internas que permiten exportar capturas en formato .pcap. Analizándolas con GPT, me comenta que ve ciertos comportamientos raros provenientes del propio Cudy.
En la primera prueba que hice, el patrón era este:
3.269s entra a 51820
3.278s responde desde 1024
3.287s ICMP Port Unreachable
8.401s entra a 51820
8.411s responde desde 1024
8.419s ICMP Port Unreachable
13.495s entra a 51820
13.504s responde desde 1024
13.512s ICMP Port Unreachable
Según GPT, la conclusión era esta:
“El tráfico llega al Cudy por el puerto 51820, pero el Cudy sigue contestando desde el puerto 1024. Por eso la VPN no levanta.”
Y me sugirió probar esta configuración en el router de Movistar:
Nombre: Cudy_VPN
Protocolo: UDP
Puerto externo inicio: 51820
Puerto externo fin: 51820
Puerto interno inicio: 1024
Puerto interno fin: 1024
IP servidor interna: 192.168.1.52
WAN Interface: ppp0.1
Después de aplicar esa configuración hice una segunda captura .pcap y GPT me devolvió esto:
ippublica:51683 → 192.168.1.52:1024 - WireGuard handshake initiation
192.168.1.52 → ippublica - ICMP Port Unreachable
Y la conclusión fue:
“Ahora el PCAP deja claro que poner el puerto interno a 1024 no sirve. El Movistar sí está enviando correctamente el tráfico al Cudy por el puerto interno 1024, pero el propio Cudy responde que no tiene nada escuchando en UDP 1024.”
Así que ahora mismo estoy completamente descolocado. No entiendo por qué el Cudy parece utilizar o responder desde el puerto 1024 cuando yo realmente tengo configurado WireGuard utilizando el puerto 51820 para todo.
Ahora sí que me ha despistado completamente.
Un saludo.
Buenas Butterkast
Perdona, entre que se me pasan las notificaciones y el tiempo libre... no vi tu post.
Exactamente, para el Router o incluso la misma Movistar, el tráfico que portes en un paquete UDP es totalmente irrelevante. A ver esto es cierto que tiene matices, pero sería liar todo mucho más, y en cualquier caso es lo mismo.
No, no es necesario fijarla en el Cudy, simplemente con verificar que, efectivamente en el HGU se le tiene asociada la IP en el DHCP estático y listo, y comprobar que obviamene es la IP que dice tener, sin mas. Parecen tonterías, y no digo que sea tu caso, pero está dentro del "ckcklist" clásico.
Sobre la IA... varios consejos... jajajaja:
1º. Usa Gemini
2º. La IA alucina que da gusto, es extremadamente y políticamente correcta, y experta en que creas todo lo que dice... pero hay que saber "llevarla".
Lo que está pasando es mucho más simple que todo eso: El servidor VPN no está levantado o hay un error en él.
No tengo el pcap que has generado, pero voy a asumir que es correcto el patrón que pones
1º. El tráfico llega al servidor, este ve tráfico de entrada al puerto 51820, con lo que el Router está haciendo su trabajo, está realizando el mapeo de puertos que tendrá configurados, pasar lo que le llega por X y enviarlo al Y (que puede ser también X) de la IP .52.
2º. El Cudy "te está diciendo" claramente cual es el problema, el sistema operativo no encuentra ningún servicio que tenga el socket/puerto 51820 a la escucha, no hay nada en él. Aquí entraríamos ahora en ver por qué esto es así, pero eso es otra cosa, no está dentro del análisis de la captura
3º. La pila de red del Cudy hace lo que tiene que hacer, dado que dicho puerto no está disponible (no hay nada en él), responde con un paquete ICMP de "Port Unreachable". No es el servidor VPN el que responde, es el OS, y obviamente no va a responder por el mismo puerto al que se le está consultando. El OS usa para la respuesta un puerto no privilegiado para ello que tenga libre. Normalmente es un puerto alto aleatorio, pero puede ser perfectamente el 1024 como origen.
Es decir... no es que el servidor VPN esté en el 1024, es una respuesta automática del sistema operativo advirtiendo al origen que no hay nada en el 51820, Un escaner de puertos externos interpretaría este resultado como un "Close" en toda regla, en vez de un Open/Filtered, dado que al ser un puerto UDP normalmente son silenciosos y no hay respuesta alguna. En este caso sí que hay respuesta: El servidor no tiene nada en ese puerto (51820)
----------
La cuestión por ende es... por qué no hay nada en ese puerto a la escucha?? Debería de estar a la escucha el propio servidor VPN, como es lógico, pero el sistema operativo del Cudy dice que no. Esto nos deja algunas opciones:
1º. Error de configuración en el servidor WireGuard, hace como que se ejecuta pero por cualquier motivo falla, y el servidor realmente no se levanta.
2º. Error de puerto en el servidor WireGuard, hay un error en el puerto especificado... a veces pasa que nos baile un número
3º. De nuevo, algún tipo de FW interno que tenga el Cudy que está filtrando el tráfico, pero esto lo dudo más, porque normalmente cuando esto pasa se usa un DROP de paquete, con lo que no veríamos un Port Unrechable, simplemente no habría ningún tipo de respuesta.
4º. Está levantado, pero en una interfaz del Cudy que no es la que le entra el tráfico al Cudy, habitual si por ejemplo el Servidor WireGuard fuese un Docker, o tuviese VLAN internas o cualquier otra cosa. Cuando levantas un servicio, el que sea, puede estar levantado para todo el sistema o sólo escuchando en una teinrfaz concreta.
5º. Un problema ya más generalizado del propio OS del Cudy
Lo primero y más simple es revisar la configuración de WIreguard del servidor, y asegurarse que está levantado. Si permite acceso por Shell el Cudy, no sé si tendrá Linux o no, ver con netstat -nap si el puerto configurado está a la escucha, en la interfaz correcta y en el proceso correcto. Si no lo está, ya sabes que es que el servidor WireGuard no está corriendo, con lo que sería mirar los logs de WireGuard y ver que error da y por qué no se levanta. Si está levantado comprobar la IP/Interfaz en la que se está levantando.
Saludos.
Hola Butterkast
No hemos vuelto a recibir mas respuesta por tu parte, ¿Nos puedes confirmar si la información facilitada por Theliel te ha sido de ayuda? Si ha sido así, ¿Te podemos ayudar en algo mas?
Quedamos atentos a tu respuesta.
Un saludo.
Oscar.
Hola Butterkast
Agradecemos a Theliel por su colaboración.
Seguimos a la espera de tu confirmación sobre si con la información proporcionada por Theliel se ha resuelto tu consulta. Si es así, ¿tienes alguna otra duda o inquietud en la que podamos ayudarte? Por otro lado si no tienes ninguna consulta adicional, te agradeceríamos que puedas dar por finalizado este hilo, para cerrarlo, pincha en el botón “Marcar como solución” del post.
Quedamos atentos a tu respuesta.
Un saludo.
Dayana.
Buenas Butterkast
No te sabría decir, mira que he puesto mas de una vez datos sensibles de Movistar de todo tipo y nunca me han censurado ni restringido nada, todos los años que llevo por el foro lo único que normalmente se editan/restringen son: Datos personales que los usuarios ponen en el foro directamente y no por privado (lo cual es una barbaridad) y las imágenes, que tienen que ser generalmente validadas a mano, imagino que por seguridad/SPAM. Por lo demás, mientras que haya un respeto, ya te digo que no se tiene por aquí mano dura al respecto, suele haber bastante "buen rollo"
De todos modos, puedes explicarme si quieres, o en vez de incrustar la imagen poner un enlace externo a la imagen si así lo prefieres por si es el filtro de imagen aplicado.
Saludos.
Buenas Theliel,
Escribo este mensaje porque ayer por la tarde, aparte de responderte a ti, también dejé bastante claras algunas cosas al soporte de Movistar. Y curiosamente, el mensaje que escribí ayer todavía no se ha publicado en el foro, está “bajo revisión”.
Parece que en cuanto dices las cosas algo más claras o te pones un poco más serio con el tema, tardan bien poco en silenciarte.
Así que nada, toca esperar a que publiquen el mensaje, porque además expliqué bastante más información sobre el problema y añadí incluso una captura de la interfaz VPN del Cudy.
Siento tener que hacerte esperar para poder ver la respuesta completa que te dejé. Una pena que pasen estas cosas cuando simplemente intentas explicar el problema de manera seria y clara.
Saludos.
Hola Butterkast
Continuamos a la espera de que nos confirmes si, con la información facilitada, has podido resolver tu consulta. Si es así ¿te podemos ayudar en algo más? Por otra parte si consideras que tu consulta esta solventada, te agradeceríamos que puedas dar por finalizado este hilo, para cerrarlo, pincha en el botón “Marcar como solución” del post.
Quedamos atentos a tu respuesta.
Un saludo.
Dayana.
Hola Butterkast
Agradecemos a Theliel por su colaboración.
En cuanto al fallo que reportas, por favor confírmanos si con la información proporcionada por Theliel se ha resuelto tu inquietud. De ser así, ¿tienes alguna otra consulta?
Quedamos atentos a tu respuesta.
Un saludo.
Dayana.
Buenas Butterkast
Los HGU algunos bugs si que tienen, y si no se resetea desde sabe dios cuanto tiempo pues tampoco es algo que ea muy raro, la verdad. No obstante esto no está tampoco relacionado por lo general con que puedan los técnicos hacerlo de forma remota. SI el Router hace mucho que no se resetea o perdió la conexión con los servidores TR69 de Movistar, simplemente no pueden conectarse a él, para lo que requiere por lo general un reset
De todos modos ya te digo que el tráfico está fluyendo, sino fuese asi no verías ningún tráfico hacia el Cudy externo, ni port unrecheable ni conexión entrante a dicho puerto ni nada de nada, por eso te digo que eso me preocupa menos, ponga lo que ponga la interfaz básica.
No tengo ni he tenido nunca un Cudy, pero me extrañaría enormemente que no permitiese acceso interno por Shell o alguna otra herramienta de administración, la verdad. En eso ya no te puedo ayudar mucho más, tendría que tener uno aquí para ver si es posible sacarle más información... sorry.
A todo los efectos lo que parece que está pasando es lo que te digo... que el servidor VPN no se está levantado por un error de configuración o que está levantado en otra interfaz/puerto... esos sería lo más plausible, y la forma más rápida de verlo es con cualquier herramienta de monitorización de procesos/scokets del mismo Cudy.
Saludos.
Buenas Theliel,
Vale, entonces entiendo que probablemente sí sea algún tipo de bug del router o del firmware.
Lo que me hace sospechar todavía más es que llegué incluso a pedir al soporte de Movistar que me abrieran ellos los puertos remotamente, explicándoles precisamente este mismo problema que te comentaba de que las reglas aparecen como undefined.
Pues bien, ellos mismos me dijeron que tampoco podían abrirlos remotamente porque les daba error al intentarlo. Por eso me pregunto si el router puede estar realmente bugueado o tener algún problema interno.
La verdad es que me da bastante pereza hacerle un reset completo por perder toda la configuración y cómo lo tengo montado ahora mismo, pero bueno… si no queda otra, tocará probar.
Respecto a si el Cudy tiene shell o acceso más avanzado, creo que no, o al menos no he conseguido averiguar cómo acceder. He intentado conectarme de varias formas y no responde de ninguna manera.
El modelo exacto es el Cudy R700 V1.0 y actualmente tiene instalado el último firmware disponible: versión 2.5.4 del 11-Mar-2026.
Saludos.
Buenas Butterkast
Sí, son bugs ocasionados por doble interfaz, pero no te preocupes por ello el mapeo funciona bien, el tráfico entra en el servidor VPN perfectamente como has podido ver, si fuese un problema de mapeo no verías el tráfico circular, de ahí la seguridad de apuntar al Cudy... el tráfico le entra, pero no lo saca.
Si el Cudy permite como digo acceso shell y tiene linux, comprueba con netstat -nap y busca el puerto, a ver si está o no está a la escucha, y si el servidor VPN es el proceso asociado a él. Le llega el tráfico, y el dice que el puerto no está disponible. El mensaje lo está devolviendo Cudy, que es quien tendría que tener disponible el puerto.
Saludos.
Buenas Theliel,
Nada, ni te preocupes por no haber visto el post antes, bastante estás haciendo ya intentando ayudarme con todo esto.
Vale, me queda totalmente claro entonces lo de la IP fija asignada.
Sobre la IA, también me queda claro cuál utilizar entonces jajaja, gracias por la aclaración.
Y respecto al servidor VPN… sinceramente ya no sé muy bien qué hacer. Hoy he vuelto a pelearme otro rato con ello y no sé si realmente he sacado algo en claro o no, aunque sí he visto una cosa que me ha chocado bastante.
Cuando entro en las opciones avanzadas del router y voy al apartado NAT para abrir/mapear puertos, configuro todo correctamente y creo la regla sin problema. La regla aparentemente se guarda bien.
Pero luego, si salgo de la interfaz avanzada y entro en la interfaz básica del router —que también tiene apartado para abrir puertos— veo que la regla que acabo de crear aparece sin nombre, con el rango de puertos mostrando literalmente undefined:undefined y además figura como desactivada.
Lo curioso es que, si intento eliminar esa regla desde la interfaz básica pulsando la “X”, no se elimina. Tengo que volver otra vez a la configuración avanzada para poder borrarla correctamente.
No sé, sinceramente parece más un bug raro del firmware que otra cosa.
Ahora mismo lo único que me queda por probar es hacerle un reset completo al router, aunque todavía no puedo hacerlo porque no estoy físicamente donde está instalado.
Saludos.
