Cisco WLC Zewnętrzne pozorne przypadkowe zachowanie WebAuth

W Cisco 5508 v7.2.103.0 mam skonfigurowanych kilka sieci WLAN. Nazwij je ABC i XYZ ze względu na to pytanie. ABC korzysta ze standardu 802.1X i pobiera adres URL przekierowania strony powitalnej. XYZ używa PSK i zewnętrznej konfiguracji WebAuth do wypychania adresu URL przekierowania strony logowania. Zarówno strona startowa, jak i strona logowania są obsługiwane pod tym samym podstawowym adresem URL (zewnętrzny serwer WWW), takim jak http://webauth.example.com/splash.html i /login.html.

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

Widzę, co wydaje się niespójne, gdy adresy URL przekierowań wyświetlają się na urządzeniach, stan RUN webauth / NAC RUN i możliwość faktycznego uzyskania dostępu do Internetu (lub nie uzyskania go, kiedy powinienem).

Rozumiem, że strona logowania wymaga akceptacji (nie wymaga nazwy użytkownika) przed zezwoleniem na ruch, a WLC musi jedynie pomyśleć, że urządzenie zobaczyło stronę powitalną (akceptacja nie jest wymagana), aby ruch mógł się tutaj odbywać.

Widziałem praktycznie wszystkie możliwe warunki , ale przypadki, w których ruch uliczny nie zawsze ma sens.

1. Podczas przeglądania pod niezabezpieczonym, czystym adresem URL następuje przekierowanie lub przekierowanie strony logowania; webauth pokazuje Uwierzytelniony ze stanem NAC RUN, przepływy ruchu. Tak się dzieje, ale nie zdarza się często.
2. Przekierowanie strony powitania lub logowania nie występuje podczas przeglądania do niezabezpieczonego, jawnego adresu URL; webauth pokazuje Uwierzytelniony ze stanem NAC RUN, przepływy ruchu (ale nie powinien po usunięciu klienta z WLC, aby wymusić przekierowanie webauth, które się nie pokazało).
3. Przekierowanie strony powitania lub logowania nie występuje podczas przeglądania do niezabezpieczonego, jawnego adresu URL; webauth nie jest uwierzytelniony ze stanem NAC WEBAUTH, ruch odbywa się (ale nie powinien).
4. Podczas przeglądania pod niezabezpieczonym, czystym adresem URL następuje przekierowanie lub przekierowanie strony logowania; webauth pokazuje Nieuwierzytelniony ze stanem NAC WEBAUTH, ruch nie płynie (ale powinien, jeśli WEBAUTH został pokazany jako przekazany).
5. Przekierowanie strony powitania lub logowania nie występuje podczas przeglądania do niezabezpieczonego, jawnego adresu URL; webauth nie jest uwierzytelniony w stanie NAC WEBAUTH, ruch nie przepływa (zgodnie z oczekiwaniami).

We wszystkich przypadkach szczegóły klienta wskazują, że adres URL przekierowania został ustawiony.
W dwóch przypadkach, w których wszystko działało zgodnie z oczekiwaniami z przekierowaniem, stanem Webauth / run i przepływem ruchu (zarówno dozwolonym, jak i odrzucanym), nie sądzę, aby listy ACL były problemem. Nic więcej nie jest wypychane z ACS poza adresem URL przekierowania. Dwie sieci WLAN są zakodowane na stałe w różnych sieciach VLAN.

Czy to może być przypadkowe zachowanie, czy moje oczy mogą po prostu grać na mnie? Widziałem nieco inne zachowanie z różnymi urządzeniami - niektóre bardziej losowe, inne mniej.

Jakie jest najlepsze podejście do zawężenia tego problemu?

Aktualizacja : DNS nie jest problemem. Ogólna dostępność adresów IP losowo działa w przeglądarce. Niezależnie od stanu webauth (RUN vs WEBAUTH-REQD), czasami przeglądarka przechodzi, a czasem nie. (Początkowe żądania są zawsze zwykłym tekstem HTTP.) Widziałem nawet regularny ruch w aplikacjach innych niż sieci Web, takich jak SMTP, więc naprawdę myślę, że Webauth się tym zajmuje, ale nie widzę nic oczywistego źle . Mam preauth ACL, która jest dość liberalna i gości ACL. Dodałem nawet zezwolenie na dowolne / dowolne z obu list ACL, które nie miały znaczenia.

W przeszłości widziałem podobne problemy dwa razy.

Za pierwszym razem miało to związek z rozpoznawaniem DNS. Przeprowadziłem wyszukiwanie DNS na kliencie, który miał problemy, i zdałem sobie sprawę, że klient nie był w stanie rozwiązać adresu URL, który przekazałem dla strony logowania. Stało się tak, ponieważ mijałem zewnętrzny serwer DNS. Sprawdź to najpierw. Rozwiązałem ten problem, przekazując adres IP w adresie URL, chociaż można utworzyć nazwę, która jest rozwiązywana do wersji 1.1.1.1.

Za drugim razem było to wydanie certyfikatu. Niektóre domyślne przeglądarki nie wyświetlają ekranu powitalnego, jeśli użytkownik musi zaakceptować samopodpisany certyfikat. Sprawdziłbym to, ręcznie przeglądając ekran powitalny lub stronę logowania od klienta, który nie wyświetla go automatycznie.

Mam nadzieję, że jedna z nich ci pomoże. Wiem, że byłem gotowy wyciągnąć włosy, kiedy zobaczyłem to po raz pierwszy.