> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/es/otro/troubleshooting/fallos-de-autenticacion-eap-tls-sobre-cgnat-y-enlaces-celulares.md). # Fallos de autenticación EAP-TLS sobre CGNAT y enlaces celulares En seguridad de redes, la Unidad Máxima de Transmisión (MTU) es un parámetro de red crítico que define el tamaño máximo de paquete que puede transmitirse por un enlace de red sin fragmentarse. Aunque la mayoría de los usuarios no necesita pensar en la MTU, se convierte en un factor importante de resolución de problemas en escenarios específicos, especialmente con autenticación RADIUS y EAP-TLS. Un síntoma típico es que la autenticación funciona sobre la conexión principal a Internet, pero falla sobre un enlace de respaldo celular o satelital. Este artículo explica cómo la MTU afecta a RADIUS, especialmente cuando intervienen cargas útiles grandes como certificados EAP-TLS, por qué esto puede provocar fallos de autenticación y cómo evitarlos con RADIUSaaS. *** #### Introducción a la MTU y la fragmentación La MTU es el tamaño máximo de paquete que una red puede manejar sin dividirlo en partes más pequeñas. La MTU estándar para la mayoría de las redes Ethernet es de 1500 bytes. Cuando un paquete es demasiado grande para un enlace de red, debe descartarse o dividirse en partes más pequeñas, un proceso llamado fragmentación IP. El host de destino es responsable de reensamblar todos los fragmentos en el paquete original. Enlaces como 4G/5G y las conexiones satelitales suelen tener una MTU efectiva menor que una conexión fija típica, porque el operador añade su propia sobrecarga de túnel. Por lo tanto, los paquetes que pasan sin cambios por una línea fija pueden fragmentarse en estos enlaces. *** #### EAP frente a fragmentación IP: por qué importa esta distinción La distinción entre EAP y la fragmentación IP es crucial para entender los problemas de autenticación. La fragmentación IP ocurre en la capa de red. Un router o host divide un único datagrama UDP en varios paquetes IP más pequeños. Esto sucede por debajo de la aplicación RADIUS, que desconoce que su paquete se fragmentó. La fragmentación EAP ocurre en la capa de aplicación. El protocolo EAP en sí no admite fragmentación, pero métodos EAP individuales como EAP-TLS implementan la suya propia. Cuando un mensaje grande de EAP-TLS, como un certificado, es demasiado grande, se divide en múltiples fragmentos EAP, y cada fragmento se transporta en su propio paquete RADIUS. La diferencia clave es que la fragmentación IP depende de que la red entregue cada fragmento para que el paquete pueda reensamblarse, lo que a menudo falla. La fragmentación EAP es gestionada por los dos extremos EAP, el cliente y el servidor RADIUS, y evita esos problemas a nivel de red. *** #### Framed-MTU frente a tamaño de fragmentación EAP El atributo Framed-MTU a menudo se confunde con la fragmentación EAP, en parte porque se usa de dos maneras distintas. En un Access-Accept, Framed-MTU indica al cliente RADIUS qué MTU debe configurar para la sesión del usuario después de la autenticación. No tiene ningún efecto sobre el propio intercambio de autenticación. En un Access-Request, sí importa para EAP. La RFC 3579, sección 2.4, explica que un servidor RADIUS no puede usar el descubrimiento de MTU para conocer la MTU del enlace, por lo que el autenticador puede incluir Framed-MTU en un Access-Request que contenga EAP para darle al servidor esta información. Un servidor que lo recibe "NO DEBE enviar ningún paquete posterior en esta conversación EAP" cuyas EAP-Message concatenadas superen el tamaño anunciado, teniendo en cuenta el tipo de enlace. Para IEEE 802.11, por ejemplo, el servidor puede enviar un paquete EAP de hasta Framed-MTU menos cuatro octetos, teniendo en cuenta los campos de cabecera de 802.1X. Por lo tanto, Framed-MTU en un Access-Request es la forma estándar de que un autenticador limite el tamaño de los paquetes EAP que envía el servidor. Sin embargo, describe el enlace entre el autenticador y el cliente, no la ruta de red entre el autenticador y el servidor RADIUS. Puede reducir el tamaño de los paquetes RADIUS en esa ruta como efecto secundario, pero no garantiza evitar la fragmentación IP en enlaces con una MTU reducida. Referencia: [RFC 3579, sección 2.4 – Fragmentación](https://www.rfc-editor.org/rfc/rfc3579#section-2.4) *** #### Por qué la fragmentación EAP por sí sola no basta En principio, la fragmentación EAP mantiene cada paquete RADIUS lo suficientemente pequeño como para cruzar la red sin fragmentarse por IP. Por eso reducir el tamaño del fragmento EAP es una recomendación habitual para los servidores RADIUS autoalojados. En la práctica, el tamaño del fragmento en cada dirección lo establecen los dos extremos EAP: el supplicant en el lado del cliente y el servidor RADIUS en el otro. El autenticador actúa como un simple paso a través y no refragmenta los mensajes EAP-TLS. Los ajustes EAP en conmutadores y puntos de acceso, como los que ofrecen Cisco, Aruba o Juniper, gobiernan principalmente el enlace entre el autenticador y el cliente. No controlan directamente el tamaño de los paquetes que el servidor RADIUS devuelve. Algunas plataformas, como Meraki, no exponen este ajuste en absoluto. El mensaje más grande en un intercambio EAP-TLS suele viajar del servidor al autenticador: el Access-Challenge que transporta la cadena de certificados del servidor. Eso hace que el tamaño del fragmento en el lado del servidor sea el factor decisivo. Con RADIUSaaS, este valor lo gestiona el servicio y no puede ajustarse por cliente, así que afinar la fragmentación EAP solo en sus dispositivos no evitará de forma fiable la fragmentación IP en enlaces con una MTU reducida. Bajar la MTU de toda la interfaz WAN tampoco es una buena solución. Afecta a todo el tráfico de ese enlace y, por sí sola, no impide que los paquetes RADIUS UDP se fragmenten. El enfoque más robusto es cambiar cómo se transporta el tráfico RADIUS, como se describe a continuación. *** #### Por qué falla la fragmentación con CGNAT La fragmentación IP es una causa común de fallos de autenticación, especialmente en redes que usan NAT de grado de operador (CGNAT), como la mayoría de las conexiones 4G/5G y Starlink. Muchos firewalls y dispositivos CGNAT no están diseñados para manejar paquetes fragmentados. Solo el primer fragmento lleva los números de puerto UDP que NAT usa para seguir una conexión, por lo que los fragmentos restantes suelen descartarse, ya sea deliberadamente por motivos de seguridad o porque el dispositivo no puede asociarlos a una sesión. Si se pierde incluso un fragmento, el datagrama UDP original no puede reensamblarse. UDP no tiene un mecanismo de retransmisión para la parte faltante, así que se pierde todo el paquete y la autenticación finalmente vence por tiempo de espera. Esto afecta a ambas direcciones, pero en EAP-TLS suele golpear la respuesta del servidor. El Access-Challenge que transporta la cadena de certificados del servidor suele ser el paquete más grande del intercambio. Si se descartan sus fragmentos, el autenticador nunca recibe el challenge y la autenticación falla. *** #### Solución: usar RadSec o evitar que RADIUS UDP pase por rutas CGNAT Con RADIUSaaS, el tamaño del fragmento EAP en el lado del servidor lo gestionamos nosotros y no puede cambiarse por cliente. Por tanto, la solución más fiable es evitar que los paquetes de autenticación grandes se fragmenten por IP en rutas que no pueden manejar fragmentos. La opción preferida es conectar su autenticador a RADIUSaaS usando RadSec en lugar del RADIUS clásico sobre UDP. RadSec transporta RADIUS sobre TLS en el puerto TCP 2083, por lo que paquetes grandes como la cadena de certificados del servidor se dividen en segmentos TCP adaptados a la ruta en lugar de fragmentos IP. Los firewalls y los dispositivos CGNAT los manejan como cualquier otro tráfico TCP y el problema desaparece. Muchas plataformas actuales admiten RadSec de forma nativa. Si su dispositivo se conecta por un enlace con MTU reducida, como un respaldo celular o satelital, asegúrese también de que el MSS de TCP coincida con la MTU real de la ruta. Puede hacerlo configurando una MTU más baja en esa interfaz WAN, de modo que los segmentos TLS grandes no se descarten silenciosamente. Si su autenticador no admite RadSec, evite enviar RADIUS UDP directamente a través de enlaces CGNAT como 4G/5G o Starlink. Una opción es enrutar el tráfico RADIUS a través de una VPN de sitio a sitio existente hacia una ubicación con una conexión fija a Internet, y enviarlo desde allí al proxy de RADIUSaaS. Dentro del túnel VPN, los fragmentos se encapsulan y el NAT del operador ya no los descarta. Otra opción es ejecutar un pequeño proxy RadSec en las instalaciones. Este acepta RADIUS UDP de sus dispositivos en la red local y lo reenvía a RADIUSaaS mediante RadSec. *** #### Conclusión Los mensajes EAP-TLS grandes, en particular la cadena de certificados del servidor RADIUS enviada durante el intercambio, pueden superar la MTU de algunas rutas de red. Cuando eso ocurre sobre UDP, los paquetes se fragmentan por IP. Los firewalls y los dispositivos CGNAT a menudo descartan esos fragmentos, lo que provoca tiempos de espera de autenticación que normalmente solo aparecen en ciertos enlaces, como una conexión de respaldo celular. Dado que el tamaño del fragmento en el servidor de RADIUSaaS no puede ajustarse por cliente, la solución más robusta es usar RadSec siempre que sea posible, ya que elimina por completo la fragmentación IP. Donde RadSec no esté disponible, mantenga RADIUS UDP fuera de rutas CGNAT encapsulándolo en un túnel o usando un proxy RadSec local. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/es/otro/troubleshooting/fallos-de-autenticacion-eap-tls-sobre-cgnat-y-enlaces-celulares.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.