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

10

На 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, которые не имели значения.

generalnetworkerror
источник
Я посмотрю на это, так как знаю, что в нескольких установках гостевые якорные контроллеры использовали то, что вы хотите. Я также знаю, что в нескольких местах, где я пытался использовать беспроводную связь подобным образом, были такие же проблемы. Иногда это не перенаправляет, а иногда просто позволяет мне! Я бы сказал, что это общая проблема.
Artanix
WLAN ABC для сотрудников и использует 802.1X. Только WLAN XYZ предназначен для гостей, использующих PSK, и в настоящее время не привязан к гостевому контроллеру. Я провел тесты с широко открытым списком ACL, и все равно получаю то же случайное поведение.
generalnetworkerror
Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.
Рон Мопин

Ответы:

3

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

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

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

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

Джонатан Дэвис
источник
Пожалуйста, не используйте 1.1.1.1. Это действительное рекламное адресное пространство. Я знаю, что Cisco все еще использует его в своих примерах, но когда вы используете его, вы маскируете часть адресного пространства Google.
LapTop006
Это очевидно случайное поведение для того же клиента без каких-либо изменений, которое убивает меня. Я согласен с @ LapTop006, что мы не должны использовать 1.1.1.1. Я использовал DNS-имя, которое отображается на частный / 32 адрес.
generalnetworkerror
@JD проголосовал. Я держу награду. Если он примет ответ, я присуду награду там. В противном случае вы получите награду за усилия. : ^)
Крейг Константин