Buenas @juanfmg
A ver, me he explicado a lo mejor mal o quizás pueda hacerlo mejor, hay varias cosas aquí que producen dicho comportamiento o error si lo quieres ver así. Que diga que está en vuestra parte es debido a como actualmente se basan las conexiones de Movistar en general, si quieres usar o configurar un servicio X, tienes que atenerte a lo bueno y a lo malo, pero que pueda cumplir con los requerimientos si lo quieres ver así.
En última instancia, a día de hoy usamos frames Ethernet para transportar los datos, que a su vez se ponen en la red del ISP, y los frames Ethernet tienen un tamaño máximo de payload de 1500Bytes, excluyendo los JumboFrames. Esto significa que todos los datos se van a enviar (mientras estén en frames ethernet) se hacen en como mucho bloques de 1500Bytes.
Pero esos 1500Bytes son máximos. Los protocolos que encontramos a lo largo del modelo OSI son jerárquicos, uno encima de otros. Ethernet es un protocolo de Capa física (capa 1), así que encima de este por así decirlo encontramos otros, y todos ellos tienen que "entrar" en esos 1500Bytes. Movistar usa PPPoE, y PPP es a su vez un protocolo de enlace de datos (capa 2), por cierto, igual que muchos de los protocolos VPN. Y en Capa 3 tendríamos por ejemplo el protocolo IP, y en capa 4 TCP... Cada uno de los protocolos por lo general tienen sus propias cabeceras que los configuran/identifican, y esas cabeceras consumen Bytes. PPPoE, tiene una cabecera de 8Bytes, con lo que cualquier paquete Ethernet que salga que use PPPoE ya no podrá tener 1500Bytes de payload, como mucho 1492. Y por supuesto hay no se acaba la cosa, porque el protocolo IP se lleva también lo suyo etc etc. El MTU define la unidad máxima de transmisión dentro del propio Frame, 1492 para conexiones PPPoE, mientras que el MSS por contra sería el tamaño máximo de los datos que puede acarrear un paquete TCP bajo PPPoE: 1500- 8PPPoE - 20 IP - 20 TCP = 1452
Las stacks TCP/IP de los equipos del mundo saben perfectamente el tamaño de los frames, pero si no se indica otra cosa, se presupone que como es natural el frame son 1500. Cuando se envían paquetes pequeños no es problema, porque esos 1452 no se alcanzan nunca. No obstante, el problema aparece si un equipo empieza a establecer la conexión, y como es lógico presupone un MTU de 1500, lo que le da un MSS de 1460, así que informa de ello y como tiene que enviar 1MB de datos por TCP los parte en bloques de 1460. La aplicación del equipo envía 1460 Bytes de datos, a los cuales se les suma los 20 de cabecera de TCP, otros 20 de IP, lo que hacen 1500... pero faltan otros 8 de PPPoE, los cuales sin duda se añaden, conformando un frame al final de 1508. Por intentar, el Router los puede intentar lanzar fuera, pero el juniper que estará posiblemente después cogerá el frame y lo eliminará. Y eso es sólo mitad del problema, porque sin otro mecanismo, el equipo que inició la conexión hacia el exterior indicó que usaba un MTU de 1500, así que en el caso de que los datos llegasen del origen al destino porque fuesen pequeños datos, el servidor destino podría enviar de vuelta paquetes completos, que a su vez no podrían ser recibidos porque Movistar en algún momento le añadiría la cabecera PPPoE y excedería de nuevo los 1500.
Esto se evita de muchos modos. Lo ideal es que cada usuario configure todos sus equipos correctamente, con el MTU que requieren. Pero... te imaginas a todos los clientes tener que andar modificando el MTU de sus dispositivos?? No es factible, además todos los OS usan como es natural un MTU base de 1500.
Si, se establece el MTU en el Router, pero eso no impide a que otros equipos de la red puedan "anunciar" a los servidores remotos un MTU mayor. Esto se soluciona a día de hoy con un "truco". Se añade a los Router residenciales una regla en iptables bien conocida:
# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Esto hace que cualquier petición de cualquier equipo detrás de dicho Router hacia el exterior, el MSS que anuncia (por defecto sería 1460) sea modificado a 1452. Es decir el Router modifica la cabecera de los paquetes TCP SYN para que con independencia de como fuesen enviados en su origen, el MSS se establezca a 1452. Así el servidor destino lee que se está negociando un MSS de 1452, y el enviará entonces los paquetes a ese tamaño. Si los enviase a 1460 tendríamos problemas.
Este sistema no es perfecto. En primer lugar, porque esto sólo se aplica a conexiones TCP, que sí, son las más problemáticas, pero... que pasa con protocolos superiores?? Que pasa con VPN?? GRE/L2TP... son protocolos de niveles superiores, que a su vez encapsulan tráfico IP, desde luego, pero todo lo dicho anteriormente no se aplica a ellos. Así que son estos protocolos los que tienen que saber gestionar el MTU de forma correcta. El servidor VPN puede presuponer que estás usando un MTU 1500 que es digamos "la base", pero al final pasa lo mismo, puesto que al final al componer el frame ethernet completo, excede los 1500 y problema.
El problema está en tu lado en tanto y cuanto es tu servidor VPN el que tiene que configurarse correctamente con este tipo de cuestiones en la mesa. Eso no significa que en muchos escenarios aun sin modificar el MTU en los servidores VPN no vaya a funcionar, pues depende de muuuuchos factores, hay muchos intermediarios que pueden desde modificar el MTU, hasta fragmentar los paquetes de modo no convencional para permitirlo... así como otros pueden simplemnte descartarlos, otros pueden... pero al final todo es comportamiento fuera de lo normal. Es decir, que pueda o no funcionar bien es otra cuestión, pero la esencia es la misma: Movistar = PPPoE -> MTU Máximo = 1492. Y a partir de ese número tienes que contar, da igual el protocolo que se use dentro, lo máximo que puede usar serán 1492.
La mayoría de conexiones VPN o móviles se hacen con MTUs mas bajos, con lo que no son problema, porque aun sumando los 8 de PPPoE no exceden los 1492. Pero si se usan de origen datos digamos que van justo, al sumar los 8 Bytes... Puedes comprobarlo, accede a:
http://www.speedguide.net:8080/
desde diferentes conexiones, verás como dependiendo de, el MTU/MSS variará. Y esto es importante, porque aquí hay dos partes involucradas, origen y destino. Tan importante es que tus datos salgan en un tamaño dado, como lo es que los otros te los envíen a ti, y también es diferente los datos que te mandan a ti cuando has iniciado tu la conexión como los que te mandan ellos a ti cuando la inician ellos, porque el MSS los negocia quien inicia la conexión, y es el destino quien dependiendo de lo que el origen le manda, lo establece a un número igual o inferior.
Dependiendo del sistema de "control" que cada extremo use para acomodarse al MTU, así como el MTU que use el OS en origen o como esté configurado, determina como interaccionen los dos extremos entre ellos. Pero al final es sencillo... un frame Ethernet pude tener máximo 1500 Bytes, y si uno envía a otro un frame mayor aunque sea porque en algún momento de todo el camino este crece, problemas. Y si uno envía a otro igualmente paquetes más grandes de los que el otro es capaz de recibir, aun cuando cupiesen en un frame ethernet, problemas también. De ahí a que exista la fragmentación, la anunciación del MSS... etc etc etc.
A todo eso, por supuesto, no se excluye problemas que pueda existir (y tenemos de ejemplo una ONT en particular que los ha causado) de añadir por la cara, literalmente un par de Bytes adicionales al frame debido a la cola FCS. Pero al margen de esto, lo otro no se invalida, es la causa principal a estos problemas.
Espero a ver aclarado un poco el asunto...
Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
