Buenas Butterkast
En primer lugar, creo que hay de base una pequeña equivocación... no existe el Mitrastar GPT-3505VW. Tenemos el Askey RTF3505VW, que entiendo es al que te refieres. Si no es así, por favor, corrígeme y pones el modelo de Mitrasta correcto que sea.
Dicho esto... ¿tiene Movistar a día de hoy algún problema conocido con servidores/cliente VPN en sus HGU? Ninguno que se conozca, en ningún modelo, y obviamente Movistar no bloquea ningún tipo de tráfico VPN. No obstante, a diferencia de otro tipo de "servicios/servidores" que queremos tener en nuestra red, las VPN entran dentro de un llamemos "exclusivo" grupo de tecnologías/software problemático para cualquier Router y/o dispositivo NAT.
Específicamente para las VPN, hay varias piezas importantes que hay que conocer bien, entender, y actuar en función de ellas. Tenemos dos especialmente, que es donde se acumulan el 99% de todos los problemas con VPN:
1º. El uso de protocolos arcaicos:
Este problema es más habitual en empresas, que siguen usando protocolos VPN de otras eras, donde se daba por sentado que cualquiera que montase una tendría una conexión dedicada y se establecería sin NAT. Hablamos de protocolos VPN como PPTP, L2TP/IPSec fundamentalmente. ¿Por qué? Porque no fueron diseñados para ser usados en entornos con NAT, simplemente. Para que estos protocolos funcionen bien los Router tienen que aplicar "parches" sucios para intentar que funcionen más o menos bien. El problema es que estos "parches" (que a veces se llaman ayudantes, passthrough, alg...) no son universales, pueden funcionar mejor o peor o no funcionar, y tampoco tienen por qué estar presentes en el Router. Es el fabricante quien decide si compensa o no implementar estas "trampas". A veces no se ponen por obsolescencia, otras veces porque como digo no son soluciones reales, pueden o no funcionar dependiendo del escenario del usuario.
2º. Configuración incorrecto -> MTU
Esta es la segunda causa más habitual. Vamos a suponer que usamos una VPN moderna, nos hemos quitado ya por fin la porquería de PPTP y de L2TP/IPSec. Ahora usamos un túnel moderno, por ejemplo OpenVPN, o mejor aun WireGuard. Perfecto, hemos ganado muchos muchos enteros, estos protocolos únicamente requieren por la parte del servidor un solo puerto abierto, que además suele ser UDP por eficiencia y que puede ser arbitrario. Todo son ventajas. Aquí el Router realmente ya no le afecta que sea VPN, para el Router el tráfico VPN es como cualquier otro tráfico, como cualquier aplicación tipo servidor que tengas, un puerto abierto si se usa ahí el servidor VPN y nada mas, y si usas el cliente no requieres de mapeos.
Problema? MTU. Técnicamente un frame Ethernet puede llevar un payload de 1500Bytes (sin contar frames tipo Jumbo). Si se intenta enviar un frame que sea de 1501Byte, la puerta de enlace que sea (Router, Switch, nodos intermedios de red...) simplemente lo descartan. Es indispensable total y absolutamente que origen-destino usen el mismo MTU, con lo que en principio cualquier valor de 1500Bytes o menos podría parecer bueno. Pero no es así. Cuando usas una VPN, estás encapsulando un frame Ethernet dentro de otro frame Ethernet. El frame que ven todos los dispositivos de red intermedios, desde que lo envías hasta que llega al destino es el de fuera, no ven el de dentro, ni les importa. Pero el MTU es importante, repito, no podemos exceder los 1500... pero entonces como se aplica esto al frame interno? El payload del frame interno jamás podrá ser por ende de 1500, es obvio, no?? Si el frame interno el payload fuese de 1500, el payload del frame exterior serían esos 1500 + cabeceras, sobrecargas y otros del frame Ethernet internor, lo que haría que el payload externo se fuese a 1518+.
Peor aun... eso es asumiendo que nuestra conexión permite y usa un MTU de 1500, y esto no tiene que ser así. Siempre jugamos con protocolos dentro de otros dentro de otros, y cada profundidad añade cabeceras y Bytes que nos comemos. En Fibra con Movistar por ejemplo se hace uso de PPPoE, lo que implica un bocadito e 8Bytes. Otros protocolos pueden comer más/menos, o usar 1500.
Un servidor VPN, así como la configuración de los clientes, tiene que estar preparado para lidiar con todo esto, porque el Router/PC que manda el frame no le importa nada que a medida que vaya construyendo protocolos y cabeceras encima exceda los 1500.
Ejemplo simple: Si el MTU del frame de la VPN (interno) es de 1500 y el servidor/cliente VPN lo establece así, construirá su paquete VPN con 1500 en mente... ojo, que no significa uqe todos los paquetes sean de 1500Bytes, la mayoría serán pequeños y no darán problema. Pero si se envía un paquete más "grande", el equipo cuando lo construya y lo envíe el paquete final será de más de 1500+, el Router simplemente lo quitará. Esto se aplica exactamente igual a la inversa. A la red de Movistar no le puede llegar un paquete mayor de 1500, alguien lo habrá descartado antes... pero si puede pasar que llegue un paquete de 1500 al BRAS, porque es legítimo... pero al llegar al BRAS este le añade los 8Bytes por PPPoE... el paquete excede los 1500, es descartado automáticamente.
Existen mecanismos muy eficientes para evitar esto, como el clamping, que es a día de hoy lo que hace cualquier Router moderno, así "engaña y negocia" el MTU entre origen destino. Así si tu conexión solo permite 1492, el Router ya le informa al destino que como mucho 1492. Y funciona perfectamente. El problema es que UDP no tiene este mecanismo, y aun cuando lo tuviese tampoco solventaría el problema del frame interno, el que porta la VPN. Esto hace que sea imperativo configurar de forma aguda e inteligente el MTU del servidor/cliente VPN.
Saludos.
