Buenas Butterkast
WireGuard es totalmente agnóstico al Router que se use, lo mismo pasaría con OpenVPN, o muchos otros protocolos.
Del mismo modo que protocolos como PPTP o L2TP/IPSec si son muy problemáticos para estos debido a NAT, aquí no existe tal problema. Para el Router o para Movistar lo que contenga el paquete UDP es totalmente indiferente, da exactamente igual que el payload UDP sea un paquete de WireGuard, sea un paquete de una conversión SIP (mal ejemplo porque SIP si puede tener problemas con NAT), sean los paquetes de un juego, sean peticiones DNS (suelen usar UDP)... Sí, el Router o Movistar "ven" que hay tráfico UDP de un lado para otro, pero les es totalmente indiferente. Esto es exactamente lo mismo con TCP ojo, lo que haya dentro del paquete de datos les da igual.
Cambiar el MTU al Router no es necesario ni adecuado. La degradación podría ser importante y no es necesario. Es más, veo una pequeña confusión muy habitual en como has comprobado el MTU, y a pesar de que podría no ser el problema como luego sigo diciendo, no has realizado lo correcto:
A ver, el MTU es un valor y propiedad de las interfaces de red. Da igual que sea la interfaz WAN del Router, la interfaz Ethernet de tu PC, la WIFI del Móvil, la Ethernet del Cudy o la virtual de Wireguard. Por regla general en el 99.99% de los casos nadie modifica el MTU de una interfaz de red, y menos física (virtuales a veces). No es necesario simplemente gracias a los mecanismos que existen para ajustar el MTU. Es decir, no tienes que pelearte porque el servidor Cudy (y aquí me refiero a las interfaces físicas/virtuales que tenga) tenga un MTU u otro. Por defecto posiblemente esté en 1500, como tu PC y la mayoría de dispositivos en red local. Esto no entraña problema alguno, puesto como digo ya se encarga el Router con el destino/origen de negociar correctamente en 1492 en el caso de conexiones PPPoE como es el caso.
Todo ello afecta y es relativo al paquete externo, el frame Ethernet que envía el equipo tenga los datos que tenga dentro. Esto no cambia, da igual que sea VPN o no.
Otra cosa totalmente diferente es, exactamente lo que hemos aplicado para el paquete digamos envoltorio, para el paquete que va dentro. Piensa en las muñecas matriusca, porque es exactamente eso, aunque en vez de meterla tu una encima de otra, imagina más bien que se inflan dentro, porque el simil será más visual, en vez de abrirla y meter una dentro.
El MTU del sistema operativo, del Router... todo ello sería la matriusca grande. A más grande sea, mayor puede ser la muñeca que se infle dentro, que en este caso sería el frame o paquete de la VPN. Pero como es lógico, la muñeca de dentro no podrá jamás inflarse tanto por mucho que quieras hasta sobrepasar a la de fuera, porque terminas rompiéndola. Si cambias el MTU de fuera, lo único que haces es que la muñeca de fuera la hagas más pequeña.... mal negocio en todos los aspectos, porque ahora tienes además mucha más posibilidades de que rompa.
El Router/Movistar o cualquier otro únicamente ve la muñeca de fuera, es lo que les importa, y el tamaño total que tenga, porque el Router va a coger todo ello y lo va a meter a su vez en otra muñeca un poquito más grande!! Y si no cabe... es como si reventase.
Cuando hablamos por tanto de configurar el servidor, no me refiero a las interfaces de red del Cudy, sino a la configuración tanto del servidor WireGuard como del cliente Wireguard, en sus archivos de configuración. ¿Por qué? Porque estos son los que van a configurar y ajustar el MTU en la interfaz virtual específica para Wireguard y poder construir esa muñeca interior del tamaño adecuado.
--------
Eso es lo primero y más importante que hay que hacer. No es lo único, pero damos por sentado que el resto estaría bien configurado y ajustado:
1º. Que el mapeo de puertos UDP se ha ralizado correctamente en el Router a la IP correcta de la red local (con lo que asegurarse de que se configura por DHCP estático), y en la interfaz WAN correcta (los HGU tienen 3)
2º. Que el Cudy está configurado correctamente, no tiene ningún servicio/FW interno que pueda estar bloqueando las conexiones
3º. Que el servicio DDNS que se use se compruebe que apunta correctamente al dominio en cuestións
4º. Etc
Hay un modo de todos modos relativamente sencillo de ver que pasa... realmente 2.
El primero y más fácil, es habilitar los registros por parte del servidor, y ver si detecta cualquier tipo de intento, mucho o poco, algún intento de conexión. Si no hay ni rastro, el tráfico ni siquiera está llegando a él, o lo bloquea antes de. Si hay rastro, ver si lanza error y de que tipo en caso de que lo lanza. Si no lanza error y en teoría responde de forma correcta pasamos de todos modos al siguiente punto
El segundo, y complementario, captura de paquetes en el servidor. No conozco los Cudy, pero por malo que fuese (que no digo que lo sea ojo) seguro que permite captura de paquetes con tcpdump o equivalente. Con eso se puede capturar el tráfico en la interfaz física conectada al HGU y ver que pasa, si hay tráfico que entra o sale del Cudy, se debería de poder ver perfectamente. No es necesario ver el contenido (ni se podría, va cifrado), pero si ves que llega tráfico pero no sale nada... tienes un problema con el Cudy Si ves que el tráfico llega y sale de forma correcta, el problema en principio no estaría en el Cudy y habría que analizarlo en otro lado, pero nos da una información de gran valor.
-----------
Si te sirve el dato, y te de cierta "tranquilidad", he tenido mucho tiempo ese HGU (el que más tiempo he tenido), y he usado WireGuard sin ningún tipo de problema. Revisa y repasa, porque con seguridad lo deberías de poder hacer andar. Por parte del Router lo único que le implica, si está el servidor detrás de él, es el correcto mapeo de puerto, nada más.
Saludos.
