> 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/de/andere/troubleshooting/fehler-bei-der-eap-tls-authentifizierung-uber-cgnat-und-mobilfunkverbindungen.md). # Fehler bei der EAP-TLS-Authentifizierung über CGNAT- und Mobilfunkverbindungen In der Netzwerksicherheit ist die Maximum Transmission Unit (MTU) ein kritischer Netzwerkparameter, der die größte Paketgröße definiert, die über eine Netzwerkverbindung übertragen werden kann, ohne fragmentiert zu werden. Während die meisten Benutzer sich nicht mit der MTU beschäftigen müssen, wird sie in bestimmten Szenarien zu einem wichtigen Faktor bei der Fehlersuche, insbesondere bei RADIUS- und EAP-TLS-Authentifizierung. Ein typisches Symptom ist, dass die Authentifizierung über die primäre Internetverbindung funktioniert, aber über eine mobile oder satellitengestützte Backup-Verbindung fehlschlägt. Dieser Artikel erklärt, wie sich die MTU auf RADIUS auswirkt, insbesondere wenn große Nutzdaten wie EAP-TLS-Zertifikate beteiligt sind, warum dies zu Authentifizierungsfehlern führen kann und wie man diese mit RADIUSaaS vermeidet. *** #### Einführung in MTU und Fragmentierung Die MTU ist die größte Paketgröße, die ein Netzwerk verarbeiten kann, ohne sie in kleinere Teile zu zerlegen. Die Standard-MTU für die meisten Ethernet-Netzwerke beträgt 1500 Bytes. Wenn ein Paket für eine Netzwerkverbindung zu groß ist, muss es entweder verworfen oder in kleinere Teile zerlegt werden; dieser Vorgang wird IP-Fragmentierung genannt. Der Zielhost ist dafür verantwortlich, alle Fragmente wieder zum ursprünglichen Paket zusammenzusetzen. Verbindungen wie 4G/5G und Satellitenverbindungen haben oft eine kleinere effektive MTU als eine typische Festnetzverbindung, da der Anbieter seinen eigenen Tunnel-Overhead hinzufügt. Pakete, die auf einer Festnetzverbindung unverändert durchgehen, können daher auf diesen Verbindungen fragmentiert werden. *** #### EAP vs. IP-Fragmentierung: Warum dieser Unterschied wichtig ist Der Unterschied zwischen EAP- und IP-Fragmentierung ist entscheidend für das Verständnis von Authentifizierungsproblemen. IP-Fragmentierung findet auf der Netzwerkschicht statt. Ein Router oder Host zerlegt ein einzelnes UDP-Datagramm in mehrere kleinere IP-Pakete. Dies geschieht unterhalb der RADIUS-Anwendung, die nicht merkt, dass ihr Paket fragmentiert wurde. EAP-Fragmentierung findet auf der Anwendungsschicht statt. Das EAP-Protokoll selbst unterstützt keine Fragmentierung, aber einzelne EAP-Methoden wie EAP-TLS implementieren ihre eigene. Wenn eine große EAP-TLS-Nachricht, etwa ein Zertifikat, zu groß ist, wird sie in mehrere EAP-Fragmente aufgeteilt, und jedes Fragment wird in einem eigenen RADIUS-Paket übertragen. Der entscheidende Unterschied besteht darin, dass die IP-Fragmentierung darauf angewiesen ist, dass das Netzwerk jedes Fragment liefert, damit das Paket wieder zusammengesetzt werden kann, was oft fehlschlägt. Die EAP-Fragmentierung wird von den beiden EAP-Endpunkten, dem Client und dem RADIUS-Server, verarbeitet und vermeidet diese Probleme auf Netzwerkebene. *** #### Framed-MTU vs. EAP-Fragmentierungsgröße Das Attribut Framed-MTU wird oft mit EAP-Fragmentierung verwechselt, teilweise weil es auf zwei verschiedene Arten verwendet wird. In einem Access-Accept teilt Framed-MTU dem RADIUS-Client mit, welche MTU für die Sitzung des Benutzers nach der Authentifizierung konfiguriert werden soll. Es hat keinen Einfluss auf den eigentlichen Authentifizierungshandshake. In einem Access-Request ist es für EAP jedoch relevant. RFC 3579, Abschnitt 2.4, erklärt, dass ein RADIUS-Server MTU-Discovery nicht verwenden kann, um die Link-MTU zu ermitteln, sodass der Authenticator Framed-MTU in einen Access-Request mit EAP aufnehmen kann, um dem Server diese Information zu geben. Ein Server, der dies empfängt, "MUST NOT send any subsequent packet in this EAP conversation", dessen zusammengefügte EAP-Message-Attribute die angegebene Größe überschreiten, wobei der Verbindungstyp berücksichtigt wird. Für IEEE 802.11 kann der Server beispielsweise ein EAP-Paket bis zu Framed-MTU minus vier Oktette senden und damit die 802.1X-Headerfelder berücksichtigen. Framed-MTU in einem Access-Request ist daher der Standardweg für einen Authenticator, die Größe der EAP-Pakete zu begrenzen, die der Server sendet. Es beschreibt jedoch die Verbindung zwischen dem Authenticator und dem Client, nicht den Netzwerkpfad zwischen dem Authenticator und dem RADIUS-Server. Es kann die Größe der RADIUS-Pakete auf diesem Pfad als Nebeneffekt verringern, ist aber keine Garantie gegen IP-Fragmentierung auf Verbindungen mit reduzierter MTU. Referenz: [RFC 3579, Abschnitt 2.4 – Fragmentierung](https://www.rfc-editor.org/rfc/rfc3579#section-2.4) *** #### Warum EAP-Fragmentierung allein nicht ausreicht Grundsätzlich sorgt EAP-Fragmentierung dafür, dass jedes RADIUS-Paket klein genug bleibt, um das Netzwerk ohne IP-Fragmentierung zu durchqueren. Deshalb ist die Verringerung der EAP-Fragmentgröße eine gängige Empfehlung für selbst gehostete RADIUS-Server. In der Praxis wird die Fragmentgröße in jede Richtung von den beiden EAP-Endpunkten festgelegt: dem Supplicant auf der Client-Seite und dem RADIUS-Server auf der anderen Seite. Der Authenticator fungiert als Durchreiche und fragmentiert EAP-TLS-Nachrichten nicht erneut. EAP-Einstellungen auf Switches und Access Points, wie sie etwa von Cisco, Aruba oder Juniper angeboten werden, steuern hauptsächlich die Verbindung zwischen dem Authenticator und dem Client. Sie steuern nicht direkt die Größe der Pakete, die der RADIUS-Server zurücksendet. Einige Plattformen, wie Meraki, stellen diese Einstellung überhaupt nicht bereit. Die größte Nachricht in einem EAP-TLS-Austausch wird in der Regel vom Server zum Authenticator übertragen: der Access-Challenge, der die Zertifikatskette des Servers enthält. Damit ist die serverseitige Fragmentgröße der entscheidende Faktor. Bei RADIUSaaS wird dieser Wert vom Dienst verwaltet und kann nicht pro Kunde angepasst werden, sodass das Feintuning der EAP-Fragmentierung nur auf Ihren Geräten IP-Fragmentierung auf Verbindungen mit reduzierter MTU nicht zuverlässig verhindert. Auch das Herabsetzen der MTU der gesamten WAN-Schnittstelle ist keine gute Lösung. Es betrifft den gesamten Verkehr auf dieser Verbindung, und allein dadurch werden UDP-RADIUS-Pakete nicht vor Fragmentierung bewahrt. Der robustere Ansatz besteht darin, zu ändern, wie der RADIUS-Verkehr transportiert wird, wie unten beschrieben. *** #### Warum Fragmentierung mit CGNAT fehlschlägt IP-Fragmentierung ist eine häufige Ursache für Authentifizierungsfehler, insbesondere in Netzwerken mit Carrier-Grade NAT (CGNAT), wie bei den meisten 4G/5G-Verbindungen und Starlink. Viele Firewalls und CGNAT-Geräte sind nicht dafür ausgelegt, fragmentierte Pakete zu verarbeiten. Nur das erste Fragment enthält die UDP-Portnummern, die NAT zur Verfolgung einer Verbindung verwendet, daher werden die übrigen Fragmente oft verworfen, entweder absichtlich aus Sicherheitsgründen oder weil das Gerät sie keiner Sitzung zuordnen kann. Wenn auch nur ein Fragment verloren geht, kann das ursprüngliche UDP-Datagramm nicht wieder zusammengesetzt werden. UDP verfügt nicht über einen Mechanismus zur erneuten Übertragung des fehlenden Teils, sodass das gesamte Paket verloren geht und die Authentifizierung schließlich abläuft. Dies betrifft beide Richtungen, trifft bei EAP-TLS jedoch meist die Antwort des Servers. Der Access-Challenge mit der Zertifikatskette des Servers ist normalerweise das größte Paket im Austausch. Wenn seine Fragmente verworfen werden, empfängt der Authenticator den Challenge nie, und die Authentifizierung schlägt fehl. *** #### Lösung: RadSec verwenden oder UDP-RADIUS von CGNAT-Pfaden fernhalten Bei RADIUSaaS wird die EAP-Fragmentgröße auf der Serverseite von uns verwaltet und kann nicht pro Kunde geändert werden. Die zuverlässigste Lösung besteht daher darin, zu verhindern, dass die großen Authentifizierungspakete auf Pfaden, die keine Fragmente verarbeiten können, IP-fragmentiert werden. Die bevorzugte Option besteht darin, Ihren Authenticator über RadSec statt klassischem RADIUS über UDP mit RADIUSaaS zu verbinden. RadSec transportiert RADIUS über TLS auf TCP-Port 2083, sodass große Pakete wie die Zertifikatskette des Servers in TCP-Segmente aufgeteilt werden, die für den Pfad passend sind, anstatt in IP-Fragmente. Firewalls und CGNAT-Geräte behandeln diese wie jeden anderen TCP-Verkehr, und das Problem verschwindet. Viele aktuelle Plattformen unterstützen RadSec nativ. Wenn Ihr Gerät über eine Verbindung mit reduzierter MTU verbunden ist, etwa eine mobile oder satellitengestützte Backup-Verbindung, stellen Sie außerdem sicher, dass die TCP MSS der tatsächlichen Pfad-MTU entspricht. Sie können dies erreichen, indem Sie auf dieser WAN-Schnittstelle eine niedrigere MTU festlegen, damit große TLS-Segmente nicht stillschweigend verworfen werden. Wenn Ihr Authenticator RadSec nicht unterstützt, vermeiden Sie es, UDP-RADIUS direkt über CGNAT-Verbindungen wie 4G/5G oder Starlink zu senden. Eine Möglichkeit besteht darin, den RADIUS-Verkehr über ein vorhandenes site-to-site VPN zu einem Standort mit einer Festnetz-Internetverbindung zu leiten und ihn von dort an den RADIUSaaS-Proxy weiterzuleiten. Innerhalb des VPN-Tunnels werden Fragmente gekapselt und nicht mehr vom NAT des Anbieters verworfen. Eine andere Möglichkeit ist, einen kleinen RadSec-Proxy vor Ort zu betreiben. Er nimmt UDP-RADIUS von Ihren Geräten im lokalen Netzwerk entgegen und leitet es über RadSec an RADIUSaaS weiter. *** #### Fazit Große EAP-TLS-Nachrichten, insbesondere die während des Handshakes gesendete Zertifikatskette des RADIUS-Servers, können die MTU mancher Netzwerkpfade überschreiten. Wenn das über UDP geschieht, werden die Pakete IP-fragmentiert. Firewalls und CGNAT-Geräte verwerfen diese Fragmente oft, was zu Authentifizierungs-Timeouts führt, die typischerweise nur auf bestimmten Verbindungen auftreten, etwa auf einer mobilen Backup-Verbindung. Da die serverseitige EAP-Fragmentgröße bei RADIUSaaS nicht pro Kunde angepasst werden kann, ist die robusteste Lösung, möglichst überall RadSec zu verwenden, wodurch IP-Fragmentierung vollständig entfällt. Wo RadSec nicht verfügbar ist, halten Sie UDP-RADIUS von CGNAT-Pfaden fern, indem Sie es tunneln oder einen lokalen RadSec-Proxy verwenden. --- # 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/de/andere/troubleshooting/fehler-bei-der-eap-tls-authentifizierung-uber-cgnat-und-mobilfunkverbindungen.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.