IKEv2 mit RADIUS klingt nach Standard. Nach einer Firewall-Migration hat uns genau diese Kombination mehr Zeit gekostet als jedes andere Einzelthema. Dieser Beitrag fasst zehn Stolperfallen, ihre Lösungen und unsere Checkliste vor dem Go-live zusammen, damit Sie diese Erfahrungen nicht selbst machen müssen.
Von Marcel Beckeherm, Senior Consultant bei der mosaic IT GmbH
Warum dieser Beitrag
Es gibt heute moderne Ansätze wie Zero Trust Network Access (ZTNA), etwa WatchGuard FireCloud. Klassische VPNs haben trotzdem weiterhin ihre Daseinsberechtigung: Sie sind in vielen Unternehmen fest etabliert, laufen mit den Bordmitteln der Betriebssysteme und sind bei der Migration bestehender Umgebungen oft die pragmatische Wahl.
In unserem Fall lief der VPN-Tunnel selbst am Abend des Umstellungstages: Zertifikat, IKE-Aushandlung, Adresspool, Routen und Regelwerk waren nachgewiesen. Gescheitert ist allein die Anmeldung.
Der Hintergrund war ein Wechsel der Plattform. Die alte Firewall hat MS-CHAPv2 selbst terminiert und Benutzer direkt gegen das Active Directory geprüft. Die neue WatchGuard Firebox braucht für Mobile VPN with IKEv2 mit Benutzername und Kennwort zwingend einen RADIUS-Server. Damit kommt ein Glied in die Kette, und an genau diesem Glied sind alle Störungen aufgetreten.
Am Ende standen fünf unabhängige Ursachen in der Authentifizierung und drei Befunde auf Client-Seite. Jede einzelne hätte die Anmeldung für sich allein verhindert. Weil alle dasselbe Fehlerbild erzeugten, nämlich „Anmeldung abgewiesen“, wurde die nächste Ursache immer erst sichtbar, wenn die vorige behoben war.
So spielen IKEv2, EAP und RADIUS zusammen
Die Kette ist eine Station länger als bei Firewalls, die selbst gegen das Verzeichnis prüfen:
Client → Firebox (IKEv2/EAP) → RADIUS-Server → Active Directory
Der Client authentifiziert sich per EAP-MS-CHAPv2 gegenüber der Firebox. Die Firebox terminiert EAP jedoch selbst und reicht die Anmeldung als klassisches MS-CHAPv2 in herstellerspezifischen Attributen an den RADIUS-Server weiter. Das ist der wichtigste Punkt für die Konfiguration des RADIUS-Servers: Er sieht kein EAP, sondern MS-CHAPv2.
Die integrierte LDAP-Anbindung der Firebox hilft hier nicht, denn für IKEv2 mit Benutzername und Kennwort ist sie nicht nutzbar. Als RADIUS-Server kommt etwa Windows NPS in Frage.
Gruppen kommen per Attribut zurück: Der RADIUS-Server liefert im Access-Accept das Attribut Filter-Id (11) mit dem Gruppennamen. Die Firebox ordnet den Benutzer damit ihren Gruppen und Regeln zu.
Die Stolperfallen und wie wir sie gelöst haben
1. Die 15-Zeichen-Grenze, in die der Servername hineinzählt
Das war die eigentliche Hauptursache, und sie war ein Produktfehler, keine Fehlkonfiguration. Fireware begrenzt bei der RADIUS-Anmeldung das Benutzernamenfeld auf 15 Zeichen und rechnet den Namen des Authentifizierungsservers mit ein. Hieß der Servereintrag nach der vollen Domäne, wurde aus firma.example.com\benutzer schon auf der Firebox etwas wie firma.example. Der eigentliche Benutzername ging verloren, bevor überhaupt ein RADIUS-Paket entstand.
Tückisch daran: Die Kürzung wird nirgends protokolliert, weder auf der Firebox noch am RADIUS-Server. Das Fehlerbild sieht aus wie ein falsches Kennwort. Einzelne Konten funktionierten zufällig, weil ihr gekürzter Name noch eindeutig war. Das führte uns zeitweise auf die falsche Fährte veralteter Kennwort-Hashes.
Lösung: Den Servereintrag kurz benennen. Umbenennen kann Fireware nicht, eine Korrektur heißt also löschen und neu anlegen. Wählen Sie den Namen nicht zu kurz und nicht beliebig: Windows stellt den Namen des Authentifizierungsservers dem Benutzernamen voran und nutzt diese Kombination auch für weitere Anmeldungen, etwa an SMB-Freigaben. Bewährt hat sich der NetBIOS-Domänenname. Er ist kurz genug und für Windows verwertbar.
2. Kein Reject, sondern Stille: das Shared Secret
Nach einem Wechsel des RADIUS-Servers meldete die Firebox nur „Recv timeout“. Die Server-IP war geändert, das Shared Secret aber aus dem alten Eintrag übernommen. Ein falsches Secret führt bei NPS zum stillen Verwerfen, nicht zu einem Access-Reject.
Lösung: Das Secret auf beiden Seiten frisch eintippen, nicht kopieren. Nachgestellte Leerzeichen sind ein Klassiker. Danach den NPS-Dienst (IAS) neu starten, weil Änderungen am RADIUS-Client nicht immer sofort greifen.
3. Die falschen Authentifizierungsmethoden
NPS lehnte mit Ursachencode 66 ab: In der Netzwerkrichtlinie war nur EAP-MS-CHAPv2 freigegeben. Weil die Firebox EAP selbst terminiert und klassisches MS-CHAPv2 weiterreicht, genügt das nicht.
Lösung: MS-CHAPv2 (klassisch) zusätzlich zu EAP-MS-CHAPv2 in der Netzwerkrichtlinie freigeben.
4. NTLM-Härtung auf dem NPS-Host
Ein Mitschnitt direkt auf dem RADIUS-Server zeigte den MS-CHAP-Fehler E=691 („falscher Benutzername oder Kennwort“) bei nachweislich korrekten Daten. Ursache war eine Gruppenrichtlinie, die NTLMv1 abschaltet und LmCompatibilityLevel auf 5 setzt. MS-CHAPv2 über RADIUS braucht eine niedrigere Stufe.
Lösung: Stufe 3 auf dem NPS-Host, und zwar als Ausnahme per Gruppenrichtlinie. Eine lokale Einstellung fällt beim nächsten Richtlinienabgleich zurück. Am Rande: Die Herstellerdokumentation ist hier in sich widersprüchlich und empfiehlt sinngemäß genau die Stufe, die das Problem auslöst.
5. Blind ohne Protokoll
Im Sicherheitsprotokoll des NPS fehlten die Ereignisse 6272 und 6273 komplett, im Textprotokoll fehlte der Richtlinienname. Tagelang war die Analyse damit blind. Die Audit-Unterkategorie „Network Policy Server“ war nicht aktiv, und die Domänenrichtlinie überschrieb jeden lokalen Versuch.
Lösung: Die Unterkategorie per Gruppenrichtlinie auf der OU des NPS-Hosts aktivieren, und zwar vor dem Go-live. Prüfen Sie anschließend die Wirkung.
6. Gruppen per Filter-Id: Anmeldung ist nicht Berechtigung
Über RADIUS gemeldete Gruppen existieren nicht in der Benutzerdatenbank der Firebox. Der einzige Ort, an dem eine Gruppe als VPN-berechtigt gilt, ist die Gruppenliste in der Mobile-VPN-Konfiguration selbst. Fehlt dort das Häkchen, läuft die per Filter-Id gemeldete Gruppe ins Leere. Lokale Firebox-Benutzer sind davon nicht betroffen. Daher entsteht der irreführende Eindruck, das Häkchen sei unnötig.
Dieselbe Liste ist zugleich der Berechtigungsfilter: Nur dort angehakte Gruppen dürfen IKEv2 nutzen. Auf der Firebox muss das Group Attribute auf 11 stehen, damit Filter-Id ausgewertet wird.
7. Leere globale DNS-Einstellungen
iOS-Clients hatten IP-Verbindung, aber keine Namensauflösung. Die globalen DNS- und Domänen-Einstellungen der Firebox waren leer, also schickte sie im CFG_REPLY keinen DNS-Server mit. iOS-Profile können für IKEv2 keinen DNS-Server selbst setzen. Das ist ein klassischer blinder Fleck bei Migrationen, der auch das Verhalten von WPAD und Proxy durcheinanderbringt.
Lösung: Vor dem Go-live Domänennamen und interne DNS-Server in den globalen Einstellungen eintragen.
8. iOS hat eigene Regeln
- Leerer LocalIdentifier: Das von der Firebox erzeugte .mobileconfig-Profil enthält ein leeres LocalIdentifier-Feld. iOS sendet eine leere Identität, die abgelehnt wird (WatchGuard KB 000031210). Als Workaround tragen Sie einen beliebigen alphanumerischen Wert ein. Ein korrigiertes Profil reicht für alle Benutzer.
- Abbruch nach der ersten DNS-Anfrage: Ab iOS 17.3 trennt die Firebox eine IKEv2-Split-Tunnel-Verbindung kurz nach dem Aufbau, bei uns nach rund 21 Sekunden. Das ist der bestätigte Herstellerfehler FBX-26342, ein Fix steht aus. Für iOS-Geräte sollten Sie bis dahin einen alternativen Zugang einplanen.
9. MFA: über IKEv2 und RADIUS nur Push
Weil die Kette MS-CHAPv2 transportiert, gibt es keinen Platz für ein zusätzliches Einmalkennwort. Mit IKEv2 und RADIUS ist damit nur Push-MFA möglich, kein OTP. Das ist eine Eigenschaft des Protokolls, nicht von WatchGuard. Wer OTP braucht, sollte das vor der Entscheidung für IKEv2 klären.
10. Die Arbeitsweise, die uns gerettet hat
- Eine Änderung, ein Test, ein Protokolleintrag. Bei fünf überlagerten Ursachen ist das der einzige Weg, Variablen auseinanderzuhalten.
- Mitschnitt auf dem RADIUS-Server, nicht nur auf der Firewall. Erst dort wurde E=691 sichtbar.
- Lokale Firebox-Konten als Brücke. Kritische Benutzer arbeiteten damit durchgehend weiter. Zugleich trennten diese Konten Tunnel-Probleme von Problemen in der Authentifizierung.
- Client-Seite rechnerisch ausschließen. Ein kleines Skript bestätigte die MS-CHAPv2-Challenge-Response als korrekt. Damit war klar, dass die Ursache serverseitig liegt.
- Zeitstempel mit Vorsicht korrelieren. Zeitzonen und Uhrabweichungen zwischen Geräten machen naive Vergleiche wertlos.
Checkliste vor dem Go-live
Diese Punkte haben wir für alle weiteren Standorte zur Pflicht gemacht. Wer sie vor der Umstellung abarbeitet, spart sich den Großteil des oben beschriebenen Aufwands.
- RADIUS-Servereintrag auf der Firebox von Anfang an kurz benennen (NetBIOS-Domänenname) und prüfen, dass Name plus Benutzername unter 15 Zeichen bleiben
- Shared Secret auf beiden Seiten von Hand eintippen, NPS-Dienst danach neu starten
- Am RADIUS-Server MS-CHAPv2 klassisch zusätzlich zu EAP-MS-CHAPv2 freigeben
- Bei NPS: NTLM-Kompatibilitätsstufe klären und die Ausnahme für den NPS-Host dauerhaft per Gruppenrichtlinie setzen
- NPS-Protokollierung (Audit-Unterkategorie) per Gruppenrichtlinie aktivieren und die Ereignisse 6272 und 6273 testen
- Globale DNS- und Domänen-Einstellungen der Firebox füllen
- Filter-Id (11) als Group Attribute auf der Firebox setzen und die VPN-Gruppen in der Mobile-VPN-Konfiguration anhaken
- iOS-Profil vor der Verteilung um den LocalIdentifier ergänzen und für iOS ab 17.3 einen alternativen Zugang einplanen
- Gruppenzuordnung mit Testbenutzern aus mindestens drei Gruppen prüfen, einschließlich Mehrfachmitgliedschaft
- MFA-Anforderung klären: Reicht Push, oder wird OTP gebraucht?
- Lokale Notfallkonten auf der Firebox als Rückfallebene anlegen und nach der Abnahme zurückbauen
Fazit
IKEv2 mit RADIUS funktioniert, aber nur, wenn jedes Glied der Kette stimmt. Keines davon meldet sich deutlich, wenn es nicht stimmt. Die teuerste Erkenntnis war ein stiller Produktfehler: ein abgeschnittener Benutzername, den kein Log zeigt.
Der wichtigste Rat ist deshalb weniger technisch als methodisch: Logging zuerst, dann eine Änderung nach der anderen, und Mitschnitte dort, wo die Entscheidung fällt. Wer heute plant, sollte außerdem zwei Fragen an den Anfang stellen: Wird OTP gebraucht, und wie viele iOS-Geräte sind im Spiel? Beides spricht gegen IKEv2 über RADIUS als alleinigen Zugangsweg.
Die Angaben zu Produktverhalten und Herstellerfehlern geben unseren Stand aus dem Projekt im November 2026 wieder. Prüfen Sie vor der Umsetzung die aktuellen Hinweise des Herstellers.
Sie stehen vor einer ähnlichen Migration? Sprechen Sie uns an. Diese Fehler müssen Sie nicht noch einmal machen.