Kurzzusammenfassung
– Eine „return infinite“-Schleife bei Cisco ISE entsteht fast immer durch einen fehlerhaften Redirect-URL-Flow zwischen NAD, ISE und Client – kein ISE-Bug, sondern ein Konfigurations- oder Zertifikatsproblem.
– Die Ursachen lassen sich in drei Kategorien einteilen: ACL/Redirect-Konfiguration am Switch oder WLC, Zertifikats- und Trust-Probleme am ISE-Node, oder ein fehlerhafter CoA-Flow.
– Wer die Schleife systematisch mit Live-Logs, RADIUS-Debugging und Packet-Capture einkreist, hat das Problem in den meisten Fällen in unter 30 Minuten lokalisiert.
Was bedeutet „return infinite“ bei Cisco ISE – und wann tritt es auf?
Der Begriff beschreibt keinen offiziellen ISE-Fehlercode, sondern ein Symptom: Der Client wird nach der Authentifizierung in eine Endlos-Schleife aus Redirects geschickt – er landet immer wieder auf der ISE-Gastportal- oder Posture-Seite, ohne jemals ins Netzwerk durchzukommen. Aus Nutzersicht: Die Captive-Portal-Seite lädt sich endlos neu. Aus Admin-Sicht: Der RADIUS-Flow scheint abzuschließen, aber der Client landet nie im korrekten Authorization-Profil.
Das tritt typischerweise in drei Szenarien auf: beim Web Authentication Flow (WebAuth/CWA), beim Posture Assessment mit dem Cisco AnyConnect Posture-Modul, oder nach einem Change of Authorization (CoA), der nicht korrekt verarbeitet wird. Gemeinsam haben alle drei: Der NAD – also Switch oder Wireless LAN Controller – schickt den Client nach dem Re-Authentifizierungsversuch erneut in den Redirect, obwohl ISE bereits ein finales Authorization-Profil gesendet hat.
Die häufigsten Ursachen für die Redirect-Loop im Überblick
Vor der Diagnose hilft ein schneller Abgleich mit den statistisch häufigsten Ursachen:
Redirect-ACL greift nach CoA weiterhin: Der Switch oder WLC wendet nach dem CoA-Push weiterhin die ursprüngliche Redirect-ACL an, weil der CoA nicht verarbeitet oder verworfen wurde. Ursache dafür ist oft ein falsches CoA-Port-Setting (Standard: UDP 1700) oder eine fehlende CoA-Konfiguration am NAD.
ISE-Zertifikat wird vom Client nicht trusted: Der Client bricht den HTTPS-Handshake zur ISE-Portalseite ab, was je nach Browser und OS zu einer Redirect-Loop statt einer klaren Fehlermeldung führt. Besonders häufig nach Zertifikatserneuerung, wenn das neue Zertifikat noch nicht auf allen PSNs ausgerollt ist.
Falsches Authorization-Profil greift erneut: Eine zu breite oder falsch geordnete Authorization Policy trifft nach dem CoA erneut auf die Redirect-Regel, weil das Differenzierungsmerkmal – etwa ein Session-Attribut oder ein Posture-Status – noch nicht korrekt gesetzt ist.
PSN-Load-Balancing ohne Sticky Sessions: Bei mehreren Policy Service Nodes ohne Session-Persistenz landet der Re-Auth-Request auf einem anderen PSN, der die ursprüngliche Session nicht kennt – und schickt den Client zurück in den initialen Flow.
Schritt-für-Schritt-Diagnose: Wo genau hängt der Request?
Ziel ist es, den Breakpoint im Flow zu lokalisieren – bevor an der Konfiguration etwas geändert wird.
Schritt 1 – ISE Live Logs prüfen:
Operations → RADIUS → Live Logs aufrufen, nach der MAC-Adresse des betroffenen Clients filtern. Entscheidende Frage: Erscheint nach dem CoA ein zweiter Auth-Eintrag – und wenn ja, welches Authorization-Profil greift dabei? Wenn das Redirect-Profil erneut zugewiesen wird, liegt das Problem in der Policy. Wenn kein zweiter Auth-Eintrag erscheint, kommt der CoA nicht am NAD an.
Schritt 2 – CoA-Verarbeitung am NAD verifizieren:
Am Switch: debug radius und debug aaa per-user aktivieren, CoA-Flow beobachten. Am WLC (AireOS): debug aaa events enable. Entscheidend ist, ob der CoA-Disconnect oder CoA-Re-Auth mit einem ACK bestätigt wird. Ein NAK oder Silence bedeutet: Der CoA erreicht den NAD nicht oder wird abgelehnt.
Schritt 3 – Redirect-ACL am NAD prüfen:
show authentication sessions interface [X] detail am Switch zeigt, welches Profil aktuell aktiv ist. Wenn hier nach dem CoA noch immer die Redirect-ACL steht, hat der Switch den CoA nicht umgesetzt – unabhängig davon, was ISE gesendet hat.
Schritt 4 – Zertifikat und Portalaufruf isolieren:
Den Portalaufruf manuell im Browser mit geöffneter Entwicklerkonsole (F12 → Netzwerk) beobachten. Wenn der Browser einen Redirect-Loop meldet (ERR_TOO_MANY_REDIRECTS), aber kein Zertifikatsfehler sichtbar ist, liegt das Problem im Flow. Wenn ein Zertifikatsfehler erscheint, sofort den ISE-PSN-Zertifikatsstand prüfen.
So behebst du die Schleife dauerhaft – nach Ursache geordnet
Ursache: CoA kommt nicht am NAD an
Prüfen, ob am NAD aaa server radius dynamic-author konfiguriert ist und die ISE-IP als Client eingetragen ist. Port UDP 1700 in beiden Richtungen in der Firewall freigeben. CoA-Key zwischen ISE und NAD abgleichen – Case-sensitive, kein Leerzeichen am Ende.
Ursache: Falsche Authorization Policy greift erneut
Die Policy-Reihenfolge in ISE überprüfen. Nach einem Posture-Assessment muss der Posture-Status (Compliant / Non-Compliant) als Bedingung in der finalen Regel greifen – und diese Regel muss vor der Catch-All-Redirect-Regel stehen. Häufiger Fehler: Die Posture-Regel ist korrekt, aber das Posture-Attribut wird erst nach einem zweiten Auth-Zyklus gesetzt, den der Client nicht mehr abwartet.
Ursache: PSN ohne Session-Persistenz
In der Load-Balancer-Konfiguration Sticky Sessions auf Basis der Session-ID oder der Client-MAC aktivieren. Alternativ: In ISE unter Administration → System → Deployment sicherstellen, dass Session-Direktive korrekt auf den initialen PSN zurückrouted.
Ursache: Zertifikatsproblem
Unter Administration → System → Certificates prüfen, ob das Portal-Zertifikat auf allen aktiven PSNs identisch und gültig ist. Wenn das Zertifikat kürzlich erneuert wurde: Neuverteilung auf alle Nodes anstoßen und ISE-Services neu starten (ise restart application).
Häufige Fragen
Kann eine Redirect-Loop auf einen ISE-Software-Bug hinweisen?
Ja, aber das ist selten der primäre Grund. Bekannte Loop-Bugs existieren in bestimmten ISE-Versionen – etwa rund um Posture-Flows in älteren 2.x-Releases. Vor einem Bugfix-Update immer sicherstellen, dass die Konfiguration sauber ist, da viele vermeintliche Bugs bei näherer Analyse Konfigurationsprobleme waren. Die Cisco Bug-Datenbank (tools.cisco.com/bugsearch) mit dem Suchterm „redirect loop“ und der eigenen ISE-Version ist der schnellste Weg zur Verifikation.
Welche ISE-Version ist für CoA-Loops am unauffälligsten?
ISE 3.1 Patch 6 und 3.2 Patch 4 aufwärts gelten aktuell als stabil für WebAuth- und Posture-Flows. Wer noch auf 2.7 oder frühen 3.0-Releases unterwegs ist, hat statistisch mehr Loop-Risiko – sowohl durch Known Bugs als auch durch veränderte Standardkonfigurationen, die nicht mit älteren NAD-Firmwares harmonieren.
Warum tritt die Schleife nur bei bestimmten Clients auf, nicht bei allen?
Das deutet fast immer auf ein gerätespezifisches Problem hin: abweichendes Betriebssystem-Verhalten beim Captive-Portal-Detection-Mechanismus, ein anderer Browser-Cache-Zustand oder ein Client, der CoA-Pakete auf Betriebssystemebene verwirft. Windows, macOS und iOS behandeln Captive-Portal-Redirects unterschiedlich – was bei einem Android-Gerät funktioniert, kann bei iOS in einer Loop enden, wenn der Portal-Hostname nicht korrekt im DNS auflöst.
Schreibe einen Kommentar