> 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/fr/autre/troubleshooting/echecs-dauthentification-eap-tls-via-cgnat-et-liaisons-cellulaires.md). # Échecs d'authentification EAP-TLS via CGNAT et liaisons cellulaires En sécurité réseau, l’Unité de transmission maximale (MTU) est un paramètre réseau essentiel qui définit la taille maximale d’un paquet pouvant être transmis sur un lien réseau sans être fragmenté. Bien que la plupart des utilisateurs n’aient pas besoin de se soucier de la MTU, elle devient un facteur de dépannage important dans certains scénarios, en particulier avec l’authentification RADIUS et EAP-TLS. Un symptôme typique est que l’authentification fonctionne via la connexion Internet principale, mais échoue via un lien de secours cellulaire ou satellite. Cet article explique comment la MTU affecte RADIUS, surtout lorsque de grandes charges utiles telles que des certificats EAP-TLS sont impliquées, pourquoi cela peut entraîner des échecs d’authentification, et comment les éviter avec RADIUSaaS. *** #### Introduction à la MTU et à la fragmentation La MTU est la plus grande taille de paquet qu’un réseau peut traiter sans le découper en morceaux plus petits. La MTU standard de la plupart des réseaux Ethernet est de 1500 octets. Lorsqu’un paquet est trop grand pour un lien réseau, il doit soit être abandonné, soit être découpé en morceaux plus petits, un processus appelé fragmentation IP. L’hôte de destination est chargé de réassembler tous les fragments pour reformer le paquet d’origine. Les liens tels que les connexions 4G/5G et satellite ont souvent une MTU effective plus faible qu’une connexion filaire classique, car l’opérateur ajoute sa propre surcharge de tunnellisation. Les paquets qui passent inchangés sur une liaison filaire peuvent donc être fragmentés sur ces liens. *** #### Fragmentation EAP vs. fragmentation IP : pourquoi cette distinction est importante La distinction entre la fragmentation EAP et la fragmentation IP est cruciale pour comprendre les problèmes d’authentification. La fragmentation IP se produit au niveau réseau. Un routeur ou un hôte découpe un seul datagramme UDP en plusieurs paquets IP plus petits. Cela se produit en dessous de l’application RADIUS, qui n’a pas conscience que son paquet a été fragmenté. La fragmentation EAP se produit au niveau applicatif. Le protocole EAP lui-même ne prend pas en charge la fragmentation, mais les méthodes EAP individuelles, comme EAP-TLS, implémentent la leur. Lorsqu’un grand message EAP-TLS, tel qu’un certificat, est trop volumineux, il est divisé en plusieurs fragments EAP, et chaque fragment est transporté dans son propre paquet RADIUS. La différence clé est que la fragmentation IP repose sur le fait que le réseau livre chaque fragment afin que le paquet puisse être réassemblé, ce qui échoue souvent. La fragmentation EAP est gérée par les deux extrémités EAP, le client et le serveur RADIUS, et évite ces problèmes au niveau réseau. *** #### Framed-MTU vs. taille de fragmentation EAP L’attribut Framed-MTU est souvent confondu avec la fragmentation EAP, en partie parce qu’il est utilisé de deux façons différentes. Dans un Access-Accept, Framed-MTU indique au client RADIUS quelle MTU configurer pour la session de l’utilisateur après l’authentification. Il n’a aucun effet sur la phase d’échange d’authentification elle-même. Dans un Access-Request, il a en revanche une importance pour EAP. La RFC 3579, section 2.4, explique qu’un serveur RADIUS ne peut pas utiliser la découverte de MTU pour connaître la MTU du lien, de sorte que l’authentificateur peut inclure Framed-MTU dans une demande Access-Request contenant EAP afin de fournir cette information au serveur. Un serveur qui le reçoit « MUST NOT send any subsequent packet in this EAP conversation » dont les attributs EAP-Message concaténés dépassent la taille annoncée, en tenant compte du type de lien. Pour IEEE 802.11, par exemple, le serveur peut envoyer un paquet EAP allant jusqu’à Framed-MTU moins quatre octets, en tenant compte des champs d’en-tête 802.1X. Framed-MTU dans un Access-Request est donc la manière standard pour un authentificateur de limiter la taille des paquets EAP envoyés par le serveur. Il décrit toutefois le lien entre l’authentificateur et le client, et non le chemin réseau entre l’authentificateur et le serveur RADIUS. Il peut réduire la taille des paquets RADIUS sur ce chemin comme effet secondaire, mais ce n’est pas une garantie contre la fragmentation IP sur des liens à MTU réduite. Référence : [RFC 3579, section 2.4 – Fragmentation](https://www.rfc-editor.org/rfc/rfc3579#section-2.4) *** #### Pourquoi la fragmentation EAP seule ne suffit pas En théorie, la fragmentation EAP permet de garder chaque paquet RADIUS suffisamment petit pour traverser le réseau sans fragmentation IP. C’est pourquoi la réduction de la taille des fragments EAP est une recommandation courante pour les serveurs RADIUS auto-hébergés. En pratique, la taille des fragments dans chaque direction est déterminée par les deux extrémités EAP : le supplicant côté client et le serveur RADIUS de l’autre côté. L’authentificateur agit comme un relais et ne re-fragmente pas les messages EAP-TLS. Les paramètres EAP sur les commutateurs et les points d’accès, tels que ceux proposés par Cisco, Aruba ou Juniper, régissent principalement le lien entre l’authentificateur et le client. Ils ne contrôlent pas directement la taille des paquets renvoyés par le serveur RADIUS. Certaines plateformes, comme Meraki, n’exposent pas du tout ce paramètre. Le plus grand message dans un échange EAP-TLS circule généralement du serveur vers l’authentificateur : le Access-Challenge transportant la chaîne de certificats du serveur. Cela fait de la taille des fragments côté serveur le facteur décisif. Avec RADIUSaaS, cette valeur est gérée par le service et ne peut pas être ajustée par client, donc régler la fragmentation EAP sur vos appareils ne suffira pas de manière fiable à empêcher la fragmentation IP sur des liens à MTU réduite. Réduire la MTU de toute l’interface WAN n’est pas non plus une bonne solution. Cela affecte tout le trafic sur ce lien, et à lui seul cela n’empêche pas les paquets UDP RADIUS d’être fragmentés. L’approche la plus robuste consiste à modifier la manière dont le trafic RADIUS est transporté, comme expliqué ci-dessous. *** #### Pourquoi la fragmentation échoue avec le CGNAT La fragmentation IP est une cause fréquente d’échecs d’authentification, en particulier sur les réseaux utilisant du Carrier-Grade NAT (CGNAT), comme la plupart des connexions 4G/5G et Starlink. De nombreux pare-feu et dispositifs CGNAT ne sont pas conçus pour gérer les paquets fragmentés. Seul le premier fragment contient les numéros de port UDP que le NAT utilise pour suivre une connexion, si bien que les fragments restants sont souvent abandonnés, soit délibérément pour des raisons de sécurité, soit parce que l’appareil ne peut pas les associer à une session. Si ne serait-ce qu’un fragment est perdu, le datagramme UDP d’origine ne peut pas être réassemblé. UDP ne dispose d’aucun mécanisme de retransmission pour la partie manquante, donc tout le paquet est perdu et l’authentification finit par expirer. Cela affecte les deux sens, mais en EAP-TLS, cela touche le plus souvent la réponse du serveur. Le Access-Challenge transportant la chaîne de certificats du serveur est généralement le plus gros paquet de l’échange. Si ses fragments sont abandonnés, l’authentificateur ne reçoit jamais le challenge et l’authentification échoue. *** #### Solution : utiliser RadSec, ou éviter que le RADIUS UDP passe par des chemins CGNAT Avec RADIUSaaS, la taille des fragments EAP côté serveur est gérée par nous et ne peut pas être modifiée par client. La solution la plus fiable consiste donc à éviter que les gros paquets d’authentification soient fragmentés en IP sur des chemins qui ne gèrent pas les fragments. L’option privilégiée consiste à connecter votre authentificateur à RADIUSaaS en utilisant RadSec plutôt que le RADIUS classique sur UDP. RadSec transporte RADIUS sur TLS via le port TCP 2083, de sorte que les grands paquets, comme la chaîne de certificats du serveur, sont découpés en segments TCP adaptés au chemin plutôt qu’en fragments IP. Les pare-feu et les dispositifs CGNAT traitent cela comme n’importe quel autre trafic TCP, et le problème disparaît. De nombreuses plateformes actuelles prennent en charge RadSec nativement. Si votre appareil se connecte via un lien à MTU réduite, comme un secours cellulaire ou satellite, assurez-vous également que le MSS TCP correspond à la vraie MTU du chemin. Vous pouvez le faire en définissant une MTU plus faible sur cette interface WAN, afin que les grands segments TLS ne soient pas silencieusement abandonnés. Si votre authentificateur ne prend pas en charge RadSec, évitez d’envoyer du RADIUS UDP directement sur des liens CGNAT tels que 4G/5G ou Starlink. Une option consiste à acheminer le trafic RADIUS via un VPN site à site existant vers un emplacement disposant d’une connexion Internet fixe, puis de l’envoyer ensuite vers le proxy RADIUSaaS depuis cet emplacement. À l’intérieur du tunnel VPN, les fragments sont encapsulés et ne sont plus supprimés par le NAT de l’opérateur. Une autre option consiste à exécuter un petit proxy RadSec sur site. Il accepte le RADIUS UDP de vos appareils sur le réseau local et le transfère vers RADIUSaaS via RadSec. *** #### Conclusion Les grands messages EAP-TLS, en particulier la chaîne de certificats du serveur RADIUS envoyée pendant la poignée de main, peuvent dépasser la MTU de certains chemins réseau. Lorsque cela se produit en UDP, les paquets sont fragmentés en IP. Les pare-feu et les dispositifs CGNAT abandonnent souvent ces fragments, ce qui provoque des expirations d’authentification qui n’apparaissent généralement que sur certains liens, comme une connexion de secours cellulaire. Comme la taille des fragments côté serveur de RADIUSaaS ne peut pas être ajustée par client, la solution la plus robuste consiste à utiliser RadSec dès que possible, ce qui supprime entièrement la fragmentation IP. Là où RadSec n’est pas disponible, évitez que le RADIUS UDP passe par des chemins CGNAT en le tunnellisant ou en utilisant 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/fr/autre/troubleshooting/echecs-dauthentification-eap-tls-via-cgnat-et-liaisons-cellulaires.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.