Comportamento aleatório aparente do Cisco WLC WebAuth externo


10

No Cisco 5508 v7.2.103.0, tenho duas WLANs configuradas. Chame-os de ABC e XYZ para o bem desta pergunta. O ABC usa 802.1X e obtém um URL de redirecionamento de página inicial pressionado. O XYZ usa PSK e usa a configuração externa do WebAuth para enviar por push um URL de redirecionamento da página de login. As páginas de abertura e de login são veiculadas na mesma URL base (servidor da Web externo), como http://webauth.example.com/splash.html e /login.html.

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

Vejo o que parece ser um comportamento inconsistente quando os URLs de redirecionamento são exibidos nos dispositivos, o estado webauth / NAC RUN e a capacidade de realmente obter acesso à Internet (ou não quando necessário).

Entendo que a página de login exige aceitação (não é necessário nome de usuário) antes de permitir a passagem do tráfego e o WLC apenas pensa que a página inicial foi vista pelo dispositivo (aceitação não necessária) para que o tráfego flua aqui.

Eu já vi praticamente todas as condições possíveis , mas os casos em que os fluxos de tráfego nem sempre fazem sentido.

  1. O redirecionamento de página inicial ou de splash ocorre ao navegar para um URL de texto simples não seguro; webauth mostra Autenticado com estado NAC RUN, fluxos de tráfego. É o que se espera que aconteça, mas não acontece com frequência.
  2. O redirecionamento de página inicial ou de splash não ocorre ao navegar para um URL de texto sem formatação não seguro; O webauth mostra autenticado com o estado NAC RUN, fluxos de tráfego (mas não deve após a remoção do cliente do WLC para forçar o redirecionamento do webauth que não foi exibido).
  3. O redirecionamento de página inicial ou de respingo não ocorre ao navegar para um URL de texto simples não seguro; webauth não autenticado com o estado WEBAUTH do NAC, fluxos de tráfego (mas não deveria).
  4. O redirecionamento de página inicial ou de splash ocorre ao navegar para um URL de texto simples não seguro; webauth mostra Não autenticado com o estado WEBAUTH do NAC, o tráfego não flui (mas deveria se WEBAUTH foi mostrado como aprovado).
  5. O redirecionamento de página inicial ou de respingo não ocorre ao navegar para um URL de texto simples não seguro; webauth não autenticado com o estado WEBAUTH do NAC, o tráfego não flui (conforme o esperado).

Em todos os casos, os detalhes do cliente mostram que o URL de redirecionamento foi definido.
Nos dois casos em que tudo funcionou como esperado com o redirecionamento, estado de webauth / run e fluxo de tráfego (sendo permitido ou negado), não acho que as ACLs sejam o problema. Nada mais está sendo enviado do ACS para além do URL de redirecionamento. As duas WLANs são codificadas para diferentes VLANs.

Poderia ser um comportamento aleatório ou meus olhos estão apenas brincando comigo? Vi comportamentos ligeiramente diferentes com dispositivos diferentes - alguns mais aleatórios, outros menos.

Qual é a melhor abordagem para diminuir esse problema?

Atualização : o DNS não é o problema. A acessibilidade geral do IP funciona aleatoriamente no navegador. Independentemente do estado do webauth (RUN x WEBAUTH-REQD), algumas vezes o navegador é acessado e outras não. (As solicitações iniciais são sempre HTTP em texto sem formatação.) Vi até mesmo o tráfego regular passar por aplicativos que não são da Web, como SMTP, então estou realmente pensando que o Webauth está mexendo com isso, mas não vejo nada obviamente errado . Eu tenho uma ACL pré - legal que é bastante liberal e uma ACL para convidados . Eu até adicionei permissão any / any para ambas as ACLs que não fizeram a diferença.


Vou dar uma olhada, pois sei que algumas instalações usaram controladores âncora convidados para fazer o que você deseja. Sei também que poucos lugares em que tentei usar a conexão sem fio de maneira semelhante têm os mesmos problemas. Às vezes, não é redirecionado, e às vezes apenas me permite! Eu diria que é um problema comum.
Artanix 21/05

O WLAN ABC é para funcionários e usa 802.1X. Somente o WLAN XYZ é para convidados que usam PSK e atualmente não está ancorado a um controlador convidado. Fiz testes com a ACL pré-aberta e ainda recebo o mesmo comportamento aleatório.
generalnetworkerror

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:


3

Já vi problemas semelhantes duas vezes no passado.

A primeira vez, teve a ver com resolução de DNS. Eu realizei uma pesquisa de DNS em um cliente que estava com problemas e percebi que o cliente não era capaz de resolver o URL que eu estava passando para a página de login. Isso ocorreu porque eu estava passando um servidor DNS externo. Verifique isso primeiro. Eu resolvi isso passando o IP na URL, embora você pudesse criar um cname que resolva para 1.1.1.1.

Na segunda vez, foi um problema de certificado. Alguns navegadores padrão não mostrarão a tela inicial se o usuário precisar aceitar um certificado autoassinado. Eu testaria isso navegando manualmente na tela inicial ou na página de login de um cliente que não a mostra automaticamente.

Espero que um desses ajude você. Eu sei que estava pronto para arrancar meus cabelos quando vi isso pela primeira vez.


Por favor, não use 1.1.1.1. É um espaço de endereço anunciado válido . Sei que a Cisco ainda o usa em seus exemplos, mas quando você o usa, mascara parte do espaço de endereço do Google.
LapTop006

É o comportamento aparentemente aleatório para o mesmo cliente sem nenhuma alteração que está me matando. Concordo com o @ LapTop006 que não devemos usar o 1.1.1.1. Eu usei um nome DNS que mapeia para um endereço / 32 privado.
generalnetworkerror

@JD votou. Eu estou segurando a recompensa. Se ele aceitar uma resposta, eu concederei a recompensa lá. Caso contrário, você receberá a recompensa pelo esforço. : ^)
Craig Constantine
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.