Внешнее случайное поведение WebAuth Cisco WLC

На Cisco 5508 v7.2.103.0 у меня настроена пара WLAN. Назовите их ABC и XYZ ради этого вопроса. ABC использует 802.1X и получает URL перенаправления страницы-заставки. XYZ использует PSK и использует внешнюю конфигурацию WebAuth для отправки URL-адреса перенаправления страницы входа. Страницы-заставки и страницы входа обслуживаются по одному и тому же базовому (внешнему веб-серверу) URL-адресу, например http://webauth.example.com/splash.html и /login.html.

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

Я вижу несоответствующее поведение, когда URL-адреса перенаправления отображаются на устройствах, состояние webauth / NAC RUN и возможность фактически получить доступ к Интернету (или не получить его, когда я должен).

Я понимаю, что страница входа требует принятия (имя пользователя не требуется), прежде чем пропустить трафик, и WLC просто должен думать, что устройство увидело заставку (принятие не требуется), чтобы трафик проходил здесь.

Я видел практически все возможные условия , но случаи, когда потоки трафика не всегда имеют смысл.

1. Перенаправление страницы-заставки или входа происходит при переходе по небезопасному текстовому URL; webauth показывает Аутентифицированное с NAC состояние RUN, потоки трафика. Это то, что ожидается, но случается не часто.
2. Перенаправление страницы-заставки или входа не происходит при просмотре незащищенного текстового URL-адреса; webauth показывает Authenticated с состоянием NAC RUN, потоки трафика (но не следует после удаления клиента из WLC для принудительного перенаправления webauth, которое не показывалось).
3. Перенаправление страницы-заставки или входа не происходит при переходе по небезопасному текстовому URL; webauth не аутентифицирован с состоянием NAC WEBAUTH, потоки трафика (но не должны).
4. Перенаправление страницы-заставки или входа происходит при переходе по небезопасному текстовому URL; webauth показывает Неаутентифицированный с состоянием NAC WEBAUTH, трафик не течет (но должен, если WEBAUTH был показан как пройденный).
5. Перенаправление страницы-заставки или входа не происходит при переходе по небезопасному текстовому URL; webauth не аутентифицирован с состоянием NAC WEBAUTH, трафик не передается (как и ожидалось).

Во всех случаях клиент показывает, что URL перенаправления был установлен.
В двух случаях, когда все работало, как ожидалось, с перенаправлением, состоянием webauth / run и потоком трафика (будучи либо разрешенным, либо запрещенным), я не думаю, что ACL являются проблемой. Ничто иное не выталкивается из ACS, кроме URL перенаправления. Две WLAN жестко закодированы для разных VLAN.

Может ли это быть случайным поведением или мои глаза просто обманывают меня? Я видел немного различное поведение на разных устройствах - некоторые более случайные, некоторые менее.

Как лучше всего сузить эту проблему?

Обновление : DNS не проблема. Общая IP-доступность случайным образом работает в браузере. Независимо от состояния webauth (RUN vs WEBAUTH-REQD), иногда браузер проходит, а иногда нет. (Первоначальные запросы всегда представляют собой обычный текстовый HTTP.) Я даже видел регулярный трафик для не-веб-приложений, таких как SMTP, поэтому я действительно думаю, что Webauth с этим не справляется, но я не вижу ничего явно неправильного , У меня достаточно либеральный ACL preauth и ACL для гостей . Я даже добавил разрешение any / any к обоим ACL, которые не имели значения.

Я видел подобные проблемы дважды в прошлом.

В первый раз это было связано с разрешением DNS. Я выполнил поиск DNS на клиенте, у которого были проблемы, и понял, что клиент не может разрешить URL-адрес, который я передавал для страницы входа. Это было потому, что я передавал внешний DNS-сервер. Проверьте это сначала. Я решил это, передав IP в URL, хотя вы могли бы создать имя cname, которое разрешается в 1.1.1.1.

Во второй раз это был выпуск сертификата. Некоторые браузеры по умолчанию не отображают заставку, если пользователь должен принять самозаверяющий сертификат. Я бы проверил это, вручную перейдя на заставку или страницу входа от клиента, который не показывает его автоматически.

Надеюсь, что один из них поможет вам. Я знаю, что был готов вырвать мои волосы, когда увидел это в первый раз.