problema conexión fibra con https, vpn

juanfmg
Usuario Senior
problema conexión fibra con https, vpn
Buenas tardes, hace tiempo el usuario "Huexxx" publicó una incidencia con el mismo problema que estamos enfrentando varias empresas. este es el hilo: https://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Problemas-con-conexi%C3%B... Me gustaría saber si hay algún tipo de solución o respuesta por parte de la comunida de movistar. gracias de antemano
Etiquetas (6)
Mensaje 1 de 10
1.506 Visitas
9 RESPUESTAS 9
Theliel
Colaborador-Creador

Buenas @juanfmg

 

Si tu caso es el mismo, haz una prueba sencilla...

 

Desde uno de esos lugares que tienes problemas de conexión y no puedes acceder, que es de suponer que es una línea de Movistar, disminuye el MTU de la conexión a 1452 por ejemplo, y prueba si la conexión funciona bien o no. Análogamente y con independencia de ello, prueba también a disminuir el MTU en el Router de la empresa a lo mismo, por defecto tanto una conexión como otra deberían de estar en 1492



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 2 de 10
1.458 Visitas
MiguelG-Movistar
Antiguo Moderador

Buenos días:

 

Necesito sus datos para poder comprobarlo:
 

-   Nombre del titular

 

-   NIF del titular

 

-   Número de teléfono del ADSL / Fibra

 

-   Móvil de contacto, nombre del contacto y horario habitual de contacto

 

Traten de infromar de algún dato del destino, el número de ADSL por ejemplo.

 


Pásemelos por un mensaje privado picando en “Enviar mensaje privado a MiguelG



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 3 de 10
1.457 Visitas
juanfmg
Usuario Senior

Hola Theliel

Muchas gracias por la respuesta  a mi post. Decirte que modificando ese parámetro lo hemos solucionado y accedemos por dos líneas que antes no podíamos.

 

Ahora tenemos que hacer una pruebas más con vpn sobre ssl para ver si también se soluciona.

 

Espero que sea de más a ayuda a técnicos que tengan el mismo problema.

 

Como he dicho antes, muchas gracias!!

Mensaje 4 de 10
1.448 Visitas
juanfmg
Usuario Senior

Hola Miguel,

 

Gracias por la respuesta. Lo hemos solucionado reduciendo el mtu en nuestro cortafuego.

Queremos ver si funciona ahora correctamente con unas vpn sobre ssl y estaría solucionado.

 

Gracias igualmente por responder

 

Un saludo

 

Mensaje 5 de 10
1.444 Visitas
Theliel
Colaborador-Creador

Buenas @juanfmg

 

Son fallos... "comunes" dentro de servidores líneas y otros. Cada ISP usa tecnologías de conexión diferentes, y cada una de ellas usan valores MTU diferentes. Si a eso le sumamos posibles fallos en las firmwres, los Juniper que hay en medio, hardware viejo que no se asegura que el MTU es correcto... el resultado es ese.

 

Si reduciendo el MTU en el FW lo soluciona, el problema estaba por tanto en vuestra parte. Movistar usa conexiones PPPoE lo cual reduce los 1500 a 1492 por los 8 bytes de sobrecarga. Esto no es nunca un problema porque tanto sus Routers usan 1492 como MTU, como las reglas internas en el FW de estos Routers usan clamp para fijar el MTU de cualquier conexión a dicho valor. Pero si usas un dispositivo externo, en este caso un servidor VPN, un FW...estos pueden estar fijándolo en otros valores... como al final sí o sí se tienen que sumar a todo el recuento los 8 Bytes de PPPoE, si el frame termina excediendo los 1500... problema

 

De cualquier modo, me alegro que esté arreglado 🙂



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 6 de 10
1.440 Visitas
MiguelG-Movistar
Antiguo Moderador

Gracias a usted,, dejamos el hilo abierto por si acaso hasta el lunes  y si no hay más problemas lo cerraremos.

 

Muchas gracias también a @Theliel  por su acertada aportación.

 

 

            Saludos.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 7 de 10
1.432 Visitas
juanfmg
Usuario Senior

Thetiel,

Permíteme que ponga en duda tu ultimo post cuando dices "el problema estaba por tanto en vuestra parte" porque para llegar a poner este post, realizamos muchísimas pruebas antes. Y una muy clara es que este mismo firewall ( Zywall 310) lo conectamos a una FTTH de Telefónica en otro lugar diferente y no tuvimos esos problemas. Solo nos encontrábamos con este problema cuando lo poníamos en un cliente específico con dos FTTH de Telefónica. He comprobado ahora el MTU de 6 FW´s  conectados a FTTH por ppoe  y todos tienen el MTU a 1492 sin dar problemas en absoluto. 

 

Yo me inclinaría más a un problema de los nodos de enrutamiento previos a este dispositivo nuestro por X causa. 

Pero bueno, aunque hemos perdido un pelín de BW estamos satisfechos con la solución proporcionada.

 

Muchas gracias otra vez!

Un saludo

Juan

Mensaje 8 de 10
1.414 Visitas
Theliel
Colaborador-Creador

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"
Mensaje 9 de 10
1.407 Visitas
juanfmg
Usuario Senior

Gracias por la aclaración e información Thetiel. Nos has aportado mucho.

 

No obstante, igual no sé si yo no me expliqué del todo bien. El 90% de nuestros clientes trabajan ya con FTTH de telefónica. La mayoría de ellos haciendo una marcación pppoe y queda la línea administrada 100% por el firewall de la marca que instalemos.

 

El parámetro del MTU viene por defecto en 1492 y nunca lo he cambiado con esta tecnología FTTH. Solo en este caso y como solución lo he modificado. 

 

Por eso te comentaba, que si de todos los firewalls que tengo conectados por pppoe a ftth,SOLO en uno he tenido que modificar esto, sigo pensando que le problema no esta en nuestro firewall.

 

Igualmente gracias por todo!

 

Un saludo

 

 

 

Mensaje 10 de 10
1.378 Visitas