Offenes zufälliges Verhalten von Cisco WLC External WebAuth

Unter Cisco 5508 v7.2.103.0 sind einige WLANs konfiguriert. Nennen Sie sie ABC und XYZ für diese Frage. ABC verwendet 802.1X und erhält eine URL für die Weiterleitung von Begrüßungsseiten. XYZ verwendet PSK und verwendet die externe WebAuth-Konfiguration, um eine Umleitungs-URL für Anmeldeseiten zu übertragen. Sowohl die Begrüßungs- als auch die Anmeldeseite werden unter derselben Basis-URL (externer Webserver) bereitgestellt, z. B. http://webauth.example.com/splash.html und /login.html.

WLAN ABC - Splash-Page-Web-Redirect[WPA + WPA2][Auth(802.1X + CCKM)]
WLAN XYZ - Web-Passthrough[WPA2][Auth(PSK)]

Ich sehe ein inkonsistentes Verhalten, wenn die Umleitungs-URLs auf Geräten angezeigt werden, den Webauth / NAC-RUN-Status und die Möglichkeit, tatsächlich auf das Internet zuzugreifen (oder es nicht zu erhalten, wenn ich sollte).

Ich verstehe, dass die Anmeldeseite akzeptiert werden muss (kein Benutzername erforderlich), bevor der Datenverkehr weitergeleitet werden kann, und der WLC muss lediglich glauben, dass die Begrüßungsseite vom Gerät gesehen wurde (Akzeptanz nicht erforderlich), damit der Datenverkehr hier fließen kann.

Ich habe praktisch alle möglichen Bedingungen gesehen , aber die Fälle, in denen Verkehrsströme nicht immer sinnvoll sind.

1. Die Umleitung von Begrüßungs- oder Anmeldeseiten erfolgt, wenn Sie zu einer nicht sicheren URL im Klartext navigieren. webauth zeigt Authentifiziert mit NAC-Status RUN, Verkehrsfluss. Dies wird erwartet, aber nicht oft.
2. Die Umleitung der Begrüßungs- oder Anmeldeseite erfolgt nicht, wenn Sie zu einer nicht sicheren URL im Klartext navigieren. webauth zeigt Authentifiziert mit dem NAC-Status RUN an, Datenverkehr fließt (sollte aber nicht nach dem Entfernen des Clients aus dem WLC erfolgen, um die Webauth-Umleitung zu erzwingen, die nicht angezeigt wurde).
3. Die Umleitung von Begrüßungs- oder Anmeldeseiten erfolgt nicht, wenn Sie zu einer nicht sicheren Nur-Text-URL navigieren. Webauth nicht mit NAC-Status WEBAUTH authentifiziert, Datenverkehr fließt (sollte aber nicht).
4. Die Umleitung von Begrüßungs- oder Anmeldeseiten erfolgt, wenn Sie zu einer nicht sicheren URL im Klartext navigieren. webauth zeigt Nicht authentifiziert mit dem NAC-Status WEBAUTH an, der Datenverkehr fließt nicht (sollte aber, wenn WEBAUTH als bestanden angezeigt wurde).
5. Die Umleitung von Begrüßungs- oder Anmeldeseiten erfolgt nicht, wenn Sie zu einer nicht sicheren Nur-Text-URL navigieren. Webauth nicht mit dem NAC-Status WEBAUTH authentifiziert, Datenverkehr fließt nicht (wie erwartet).

In allen Fällen zeigt das Client-Detail, dass die Umleitungs-URL festgelegt wurde.
In den beiden Fällen, in denen alles wie erwartet funktioniert hat, mit der Umleitung, dem Webauth / Run-Status und dem Verkehrsfluss (entweder erlaubt oder verweigert), denke ich nicht, dass die ACLs das Problem sind. Von ACS wird nichts anderes als die Weiterleitungs-URL heruntergedrückt. Die beiden WLANs sind in verschiedenen VLANs fest codiert.

Könnte dies ein zufälliges Verhalten sein oder spielen meine Augen mir nur einen Streich? Ich habe ein etwas anderes Verhalten bei verschiedenen Geräten gesehen - einige mehr zufällig, andere weniger.

Was ist der beste Ansatz, um dieses Problem einzugrenzen?

Update : DNS ist nicht das Problem. Die allgemeine IP-Erreichbarkeit funktioniert zufällig im Browser. Unabhängig vom Webauth-Status (RUN vs WEBAUTH-REQD) kommt der Browser manchmal durch und manchmal nicht. (Anfängliche Anfragen sind immer HTTP im Klartext.) Ich habe sogar gesehen, dass regelmäßiger Datenverkehr für Nicht-Web-Apps wie SMTP durchkommt, also denke ich wirklich, dass Webauth damit herumfummelt, aber ich sehe nichts offensichtlich Falsches . Ich habe eine Preauth- ACL, die ziemlich liberal ist, und eine Gast- ACL. Ich habe sogar beiden ACLs die Erlaubnis any / any hinzugefügt, die keinen Unterschied machten.

Ich habe in der Vergangenheit zweimal ähnliche Probleme gesehen.

Das erste Mal hatte es mit der DNS-Auflösung zu tun. Ich habe eine DNS-Suche auf einem Client durchgeführt, bei dem Probleme aufgetreten sind, und festgestellt, dass der Client die URL, die ich für die Anmeldeseite übergeben habe, nicht auflösen konnte. Dies lag daran, dass ich einen externen DNS-Server übergeben habe. Überprüfen Sie das zuerst. Ich habe das behoben, indem ich die IP in der URL übergeben habe, obwohl Sie einen c-Namen erstellen konnten, der in 1.1.1.1 aufgelöst wird.

Beim zweiten Mal handelte es sich um ein Zertifikat. Einige Standardbrowser zeigen den Begrüßungsbildschirm nicht an, wenn der Benutzer ein selbstsigniertes Zertifikat akzeptieren muss. Ich würde das testen, indem ich manuell zum Begrüßungsbildschirm oder zur Anmeldeseite eines Clients navigiere, der diese nicht automatisch anzeigt.

Hoffe einer von denen hilft dir weiter. Ich weiß, dass ich bereit war, mir die Haare auszureißen, als ich das zum ersten Mal sah.