Buenas jcnfutre
Te contesto por aquí si no te importa, sin datos privados obviamente, que al final lo que es por privado se queda privado, y puede no ser de ayuda para otros.
El servicio está levantado y funcionando bien, el puerto está correctamente mapeado, y el servidor DDNS también funciona bien. Como te decía, hay que saber hacer e interpretar un escáner de puertos. Para ilustrar esto lo he lanzado a dos puertos, para que veas que funciona:
nmap -sU -A -Pn -p1194-1195 TU_IP
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-12 13:55 Hora estßndar romance
Nmap scan report for TU_IP
Host is up.
PORT STATE SERVICE VERSION
1194/udp open openvpn OpenVPN
1195/udp open|filtered rsf-1
Too many fingerprints match this host to give specific OS details
Al ser puertos UDP, en principio es imposible diferenciarlos de puertos filtrados, por eso el segundo pone abierto/filtrado. Porque los puertos UDP no están orientados a conexión, no tienen un handshake como TCP.
Entonces... ¿por qué puede saber que el 1194 sí está abierto y no pone Abierto/Filtrado como el otro? Pues porque el puerto por defecto para OpenVPN es el 1194, y le he dicho a nmap que intente averiguar que tipo de servicio/versión se está ejecutando, y si doy por sentado que lo que hay detrás del puerto es un servidor OpenVPN, sí se puede inducir a que el servidor responda algo. Pero esto depende del servicio que esté detrás, si no fuese un servidor OVPN, el intento específico de nmap no serviría, porque ese intento específico es para OVPN. Lo que intenta aquí como digo es que lograr algún tipo de respuesta desde dicho puerto. Dado que lo logra y el servidor responde con tráfico, queda constancia de que efectivamente el puerto está en uso. Es más, como puedes ver identifica que se está usando OpenVPN. La columna "Service" es por defecto lo que nmap cree que hay detrás debido a los puertos conocidos, pero repito que puede ser en realidad otra cosa diferente. En "Version" sin embargo es el resultado al que llega nmap después de las pruebas pertinentes.
Dicho de otro modo, el puerto está mapeado de forma correcta, el tráfico está llegando al servidor VPN. Con lo que si tienes cualquier tipo de problema de conexión, realmente no tiene nada que ver con la comunicación, el tráfico está llegando bien, es un problema en todo caso de configuración del servidor VPN o del cliente VPN.
Lo único que sí es verdad que el Router está filtrando es el tráfico ICMP (ping), que creo recordar que la mayoría de Router de Movistar por defecto lo permite. No obstante esto no tiene efecto alguno en un servidor VPN ni en nada por el estilo. Es más, por seguridad, yo soy el primero que siempre bloqueo las respuestas ICMP de cualquier Router que configuro, empezando por los míos propios.
Así que te insto a repasar la configuración de cliente/servidor, porque si no te funciona, algo estás haciendo mal, me temo. OVPN no necesita más que un puerto para funcionar de forma correcta, y este está operativo. No soy nada fan de Synology y los muchos problemas con los que te puedes encontrar, sin entrar ya en precio/prestaciones. Además, a estas alturas deberías de poder usar y configurar además WireGuard en vez de OVPN. No es que OVPN vaya mal, ni mucho menos, ha sido una gran maravilla... en el pasado. Pero es totalmente imposible a día de hoy alcanzar la obra de arte que es WireGuard, sobre todo si el sistema posee un Kernel mínimamente actual que lo tenga integrado. En esencia es mucho más rápido, sencillo, seguro...
No te puedo decir mucho más desde aquí, como te digo la redirección está funcionando bien y el tráfico está llegando al servidor OVPN. Revisa configuraciones, y yo empezaría por el que es el principal error habitual, que es el MTU del servidor/cliente VPN