10

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.

  1. 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.
  2. 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).
  3. 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).
  4. 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).
  5. 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.

Improve this question
2
  • I'll have a look into it, as I know that a few installs have used guest anchor controllers to do what you want. I also know that few places I've tried to use wireless in a similar way have the same issues. Sometimes it doesn't redirect, and sometimes it just lets me on! I'd say its a common issue though.
    – user275
    May 21, 2013 at 9:04
  • WLAN ABC is for employees and uses 802.1X. Only WLAN XYZ is for guests using PSK and isn't currently anchored to a guest controller. I've done tests with the preauth ACL wide open and still get the same random behavior.
    – generalnetworkerror
    May 22, 2013 at 6:55

1 Answer 1

Reset to default
3
+50

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.

Improve this answer
3
  • Please don't use 1.1.1.1. It's valid advertised address space. I know Cisco still use it in their examples, but when you use it you're masking some of Google's address space.
    – LapTop006
    May 22, 2013 at 3:10
  • It's the apparently random behavior for the same client without any changes that's killing me. I agree with @LapTop006 that we shouldn't use 1.1.1.1. I used a DNS name that maps to a private /32 addr.
    – generalnetworkerror
    May 22, 2013 at 5:45
  • @JD upvoted. I'm holding the bounty. If he accepts an answer I'll award the bounty there. Otherwise you'll get the bounty for the effort. :^)
    – Craig Constantine
    May 22, 2013 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.