Comportement aléatoire apparent de WebAuth externe de Cisco WLC

Sur Cisco 5508 v7.2.103.0, j'ai un couple de WLAN configurés. Appelez-les ABC et XYZ pour cette question. ABC utilise 802.1X et obtient une URL de redirection de page de démarrage poussée vers le bas. XYZ utilise PSK et utilise la configuration externe WebAuth pour envoyer une URL de redirection de page de connexion. Les pages de démarrage et de connexion sont servies sous la même URL de base (serveur Web externe) telle que http://webauth.example.com/splash.html et /login.html.

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

Je vois ce qui semble être un comportement incohérent lorsque les URL de redirection s'affichent sur les appareils, l'état Webauth / NAC RUN et la possibilité d'accéder réellement à Internet (ou de ne pas l'obtenir quand je le devrais).

Je comprends que la page de connexion nécessite une acceptation (aucun nom d'utilisateur requis) avant de laisser passer le trafic et le WLC doit simplement penser que la page de démarrage a été vue par l'appareil (acceptation non nécessaire) pour que le trafic circule ici.

J'ai vu pratiquement toutes les conditions possibles , mais les cas où les flux de trafic n'ont pas toujours de sens.

1. La redirection vers la page de démarrage ou de connexion se produit lors de la navigation vers une URL en texte brut non sécurisée; webauth affiche Authentifié avec l'état NAC RUN, les flux de trafic. C'est ce qui devrait arriver, mais cela n'arrive pas souvent.
2. La redirection vers la page de démarrage ou de connexion ne se produit pas lors de la navigation vers une URL en texte brut non sécurisée; webauth affiche Authentifié avec l'état NAC RUN, les flux de trafic (mais ne devraient pas après la suppression du client de WLC pour forcer la redirection webauth qui ne s'affichait pas).
3. La redirection vers la page de démarrage ou de connexion ne se produit pas lors de la navigation vers une URL en texte brut non sécurisée; webauth non authentifié avec l'état NAC WEBAUTH, les flux de trafic (mais ne devraient pas).
4. La redirection vers la page de démarrage ou de connexion se produit lors de la navigation vers une URL en texte brut non sécurisée; webauth affiche Non authentifié avec l'état NAC WEBAUTH, le trafic ne circule pas (mais devrait si WEBAUTH a été affiché comme transmis).
5. La redirection vers la page de démarrage ou de connexion ne se produit pas lors de la navigation vers une URL en texte brut non sécurisée; webauth non authentifié avec l'état NAC WEBAUTH, le trafic ne circule pas (comme prévu).

Dans tous les cas, le détail du client indique que l'URL de redirection a été définie.
Dans les deux cas où tout fonctionnait comme prévu avec la redirection, l'état webauth / run et le flux de trafic (étant autorisé ou refusé), je ne pense pas que les ACL soient le problème. Rien d'autre n'est poussé vers le bas à partir d'ACS autre que l'URL de redirection. Les deux WLAN sont codés en dur sur différents VLAN.

Serait-ce un comportement aléatoire ou mes yeux me jouent-ils un tour? J'ai vu un comportement légèrement différent avec différents appareils - certains plus aléatoires, d'autres moins.

Quelle est la meilleure approche pour réduire ce problème?

Mise à jour : DNS n'est pas le problème. L'accessibilité IP générale fonctionne de manière aléatoire dans le navigateur. Quel que soit l'état de Webauth (RUN vs WEBAUTH-REQD), parfois le navigateur passe et parfois non. (Les demandes initiales sont toujours en texte clair HTTP.) J'ai même vu du trafic régulier passer pour des applications non Web telles que SMTP, donc je pense vraiment que Webauth est en train de foutre ça, mais je ne vois rien de mal à l'évidence . J'ai une ACL de pré - autorisation qui est assez libérale et une ACL d' invités . J'ai même ajouté le permis any / any aux deux listes de contrôle d'accès qui n'ont pas fait de différence.

J'ai vu deux fois des problèmes similaires par le passé.

La première fois, cela avait à voir avec la résolution DNS. J'ai effectué une recherche DNS sur un client qui rencontrait des problèmes et j'ai réalisé que le client n'était pas capable de résoudre l'URL que je transmettais pour la page de connexion. C'est parce que je passais devant un serveur DNS externe. Vérifiez d'abord. J'ai résolu cela en passant l'IP dans l'URL, bien que vous puissiez créer un cname qui résout 1.1.1.1.

La deuxième fois, c'était un problème de certificat. Certains navigateurs par défaut n'afficheront pas l'écran de démarrage si l'utilisateur doit accepter un certificat auto-signé. Je testerais cela en parcourant manuellement l'écran de démarrage ou la page de connexion à partir d'un client qui ne l'affiche pas automatiquement.

J'espère que l'un d'eux vous aidera. Je sais que j'étais prêt à arracher mes cheveux quand j'ai vu ça la première fois.