On Cisco 5508 v7.2.103.0, I have a couple of WLANs configured. Call them ABC and XYZ for the sake of this question. ABC uses 802.1X and gets a splash page redirect URL pushed down.
XYZ uses PSK and uses the WebAuth external config to push a login page redirect URL.
Both the splash and login pages are served under the same base (external web server) URL such as http://webauth.example.com/splash.html and /login.html.
WLAN ABC - Splash-Page-Web-Redirect[WPA + WPA2][Auth(802.1X + CCKM)]
WLAN XYZ - Web-Passthrough[WPA2][Auth(PSK)]
I see what appears to be inconsistent behavior on when the redirect
URLs show on devices, the webauth/NAC RUN state, and the ability to
actually get Internet access (or not get it when I should).
I understand the login page requires acceptance (no username required) before allowing traffic to pass and the WLC merely has to think the splash page was seen by the device (acceptance not necessary) for traffic to flow here.
I've seen virtually all conditions possible, but the cases where traffic flows don't always make sense.
- Splash or Login page redirect occurs when browsing to a non-secure, plain-text URL; webauth shows Authenticated with NAC state RUN, traffic flows. This is what's expected to happen, but doesn't happen often.
- Splash or Login page redirect does not occur when browsing to a non-secure, plain-text URL; webauth shows Authenticated with NAC state RUN, traffic flows (but shouldn't after removing client from WLC to force webauth redirect which didn't show).
- Splash or Login page redirect doesn't occur when browsing to a non-secure, plain-text URL; webauth not authenticated with NAC state WEBAUTH, traffic flows (but shouldn't).
- Splash or Login page redirect occurs when browsing to a non-secure, plain-text URL; webauth shows Unauthenticated with NAC state WEBAUTH, traffic doesn't flow (but should if WEBAUTH was shown as passed).
- Splash or Login page redirect doesn't occur when browsing to a non-secure, plain-text URL; webauth not authenticated with NAC state WEBAUTH, traffic doesn't flow (as expected).
In all cases, the client detail shows the redirect URL was set.
In the two cases where everything worked as expected with the redirect, webauth/run state, and traffic flow (being either allowed or denied), I don't think the ACLs are the issue. Nothing else is being pushed down from ACS other than the redirect URL. The two WLANs are hardcoded to different VLANs.
Could this be random behavior or are my eyes just playing a trick on me? I seen slightly different behavior with different devices — some more random, some less.
What's the best approach to narrow this problem down?
Update: DNS is not the issue. General IP reachability randomly works in browser. Regardless of the webauth state (RUN vs WEBAUTH-REQD), sometimes the browser gets through and sometimes does not. (Initial requests are always plain-text HTTP.) I've even seen regular traffic get through for non-web apps such as SMTP, so I'm really thinking Webauth is mucking with this, but I don't see anything obviously wrong. I have a preauth ACL that's fairly liberal and a guests ACL. I've even added permit any/any to both ACLs that didn't make a difference.
Best Answer
I've seen similar issues twice in the past.
The first time, it had to do with DNS resolution. I performed a DNS lookup on a client that was having issues, and realized that the client wasn't capable of resolving the URL that I was passing for the login page. This was because I was passing an external DNS server. Check that first. I resolved that by passing the IP in the URL, although you could create a cname that resolves to 1.1.1.1.
The second time, it was a certificate issue. Some default browsers won't show the splash screen if the user must accept a self-signed certificate. I would test that by manually browsing to the splash screen or login page from a client that does not automatically show it.
Hope one of those helps you out. I know that I was ready to pull my hair out when I saw this the first time.