XYZ使用PSK并使用WebAuth外部配置来推送登录页面重定向URL。
初始页面和登录页面均在同一目录下提供基本（外部Web服务器）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)]
I查看当重定向
URL在设备上显示时，webauth / NAC RUN状态以及
实际获得Internet访问（或在我应有的时候无法获得）的功能时，似乎不一致的行为。 br />
我了解登录页面需要接受（无需用户名）才能允许流量通过，并且WLC只需认为启动页面已被设备看到（无需接受）即可访问流量在这里流动。
我已经看到了几乎所有可能的情况，但是交通流量并不总是有意义。
启动或登录页面浏览到非-安全的纯文本网址； webauth显示NAC状态为“已认证”，流量通过。这是预期会发生的，但不会经常发生。
浏览到非安全的纯文本URL时，不会发生启动或登录页面重定向； webauth显示已通过NAC状态RUN进行身份验证，流量流动（但在从WLC删除客户端以强制未显示的webauth重定向后不应该如此）。
浏览到非安全的纯文本URL；浏览器未通过NAC状态WEBAUTH进行身份验证时，流量会（但不应）通过。
浏览到非安全的纯文本URL时会发生启动或登录页面重定向； webauth显示NAC状态为WEBAUTH的未经身份验证，流量不会流动（但如果WEBAUTH显示为已通过，则流量应该会流动）。
浏览到非安全的纯文本URL时，不会发生启动或登录页面重定向；未通过NAC状态WEBAUTH对webauth进行身份验证，流量没有按预期方式流动。在重定向，webauth /运行状态和流量（被允许或拒绝）方面按预期工作，我认为ACL并不是问题。除了重定向URL，没有其他任何东西可以从ACS下推。这两个WLAN被硬编码到不同的VLAN。
这是随机行为还是我的眼睛在骗我？我看到不同设备的行为略有不同-有些随机，有些更少。
缩小此问题的最佳方法是什么？
更新：DNS不是问题。常规IP可达性在浏览器中随机起作用。无论webauth状态（RUN与WEBAUTH-REQD）如何，有时浏览器都能通过，有时却无法通过。 （初始请求始终是纯文本HTTP。）我什至看到非SMTP等非Web应用程序的正常流量都可以通过，因此我真的以为Webauth对此感到不满，但是我看不到任何明显错误的地方。我有一个相当宽松的预认证ACL和一个来宾ACL。我什至在两个ACL中都添加了允许任何/任何内容，这没有什么不同。
#1 楼
我过去曾两次看到类似的问题。第一次，它与DNS解析有关。我在有问题的客户端上执行了DNS查找，并意识到该客户端无法解析我为登录页面传递的URL。这是因为我正在传递外部DNS服务器。首先检查。我可以通过在URL中传递IP来解决此问题，尽管您可以创建一个解析为1.1.1.1的cname。
第二次，这是证书问题。如果用户必须接受自签名证书，则某些默认浏览器将不会显示初始屏幕。我会通过从不会自动显示该客户端的客户端手动浏览至启动屏幕或登录页面来进行测试。
希望其中之一可以帮助您。我知道当我第一次看到这个时我已经准备好拔头发了。
评论
请不要使用1.1.1.1。这是有效的广告地址空间。我知道Cisco在他们的示例中仍然使用它，但是当您使用它时，您将掩盖Google的某些地址空间。
–LapTop006
13年5月22日在3:10
对于相同的客户端，显然是随机的行为，没有任何变化使我丧命。我同意@ LapTop006，我们不应使用1.1.1.1。我使用了一个DNS名称，该名称映射到私有/ 32地址。
–generalnetworkerror
13年5月22日在5:45
@JD赞成。我拿着赏金。如果他接受答案，我将在那里奖励。否则，您会得到努力的赏金。 ：^）
–克雷格·康斯坦丁（Craig Constantine）
13年5月22日在13:55
评论
我将对其进行研究，因为我知道一些安装已使用来宾锚控制器来完成您想要的操作。我也知道，我尝试以类似方式使用无线的地方很少有相同的问题。有时它不会重定向，有时它会让我继续前进！我会说这是一个普遍的问题。WLAN ABC适用于员工，并使用802.1X。仅WLAN XYZ适用于使用PSK的来宾，当前尚未锚定到来宾控制器。我已经使用完全开放的preauth ACL进行了测试，但仍然得到相同的随机行为。