ISE WebAuth with iOS Devices

In my lab, I try to explore scenarios that either I have come across in my design meetings or ones that I feel will be useful in future designs.  Since ISE has been around for a bit now, many engineers have already hit the issue where an Apple iPad (or iPhone, iPod Touch) doesn’t quite get to the ISE redirection page.  Instead, you end up with a (for the most part) blank page.  Apple implemented their Captive Network Assistant (CNA) which basically senses when a captive portal (like the WebAuth page) is being presented.  To detect this behavior, the Apple device sends a request to to see if it gets a response.  If it does, it knows a captive portal isn’t being used.  If it does not get a response, it assume a captive portal is in use and CNA auto-launches a broswer window so as to get a leg-up on the portal login – trying to make sure the user doesn’t get stuck trying to use an app but not realizing they have to login to the captive portal first.  Sounds like a fair plan but this ends up causing a “controlled window” to pop up that ends up blank.

There are a couple of workarounds that I know about, but only one that is really feasible.

1) You can disable auto-login under WLAN settings on the Apple device.  This of course requires a user to know how to do that – or a call to the help desk for assistance.

2) On the Cisco WLC (Wireless LAN Controller), there is a CLI only command that will bypass this “controlled windows” behavior on the Apple device.

(Controller)> config network web-auth captive-bypass enable

With solution #2, you can now see the WebAuth redirect page in the Apple device’s browser.

If you find errors, have a better solution, or just some comments, please add to the knowledge!


**Update:  I hear that iOS 7 is going to change the behavior of Apple’s CNA.  So, if you have the above solution in place, iOS 7’s CNA will work differently.  Cisco is going to put out WLC 7.4 MR2 code sometime this month (hopefully) that will work with the new CNA.  Be looking for that release.


13 thoughts on “ISE WebAuth with iOS Devices

  1. Hi, thank’s for the information.
    Due to CNA and the special window pop up, I will run into trouble with usage of safari feature “remenber username and password”. Because it will not work anymore. The actual username and password will be stored, but can not be changed. Unfortunately “remenber username and password” will be used very often by our users to remember the portal password for the next few weeks until it gets changed periodically.
    So they have to remember the password for each login. Thats really bad, because it’s still another user/password than usually being used.

    1. Hi Alois, I’m not familiar enough with the intricacies of Safari, but do these users have AD credentials or are they truly guests? If they have AD credentials, you could allow them to use those instead. They would still apparently need to login with the issue you are citing (I haven’t seen/noticed that issue), but at least it would be credentials they already know.

  2. I battled with the iphone not displaying the redirect to the ise guestportal for a couple of days. I had read this may be an issue before I started, so I enabled captive bypass on the WLC (7.4) but it would not work. I ended up getting it working by disabling captive bypass and using L3 security on the WLC to redirect to ISE guest portal. When I did this, the iphone did display the ISE redirected page in its captive portal.

    1. Hi Hroyd, did you notice this with a number of iOS devices consistently or just one or two? Also, what iPhone and iOS version were you testing? When you had the captive portal bypass enabled, what was the behavior on the client? Also, what was the Radius NAC State for that client on the WLC when you saw this behavior? You can see that by going to Monitor->Clients and click on the MAC address of the client in question. Another item I’ve found that generally helps the iOS family of devices is to enable Fast SSID change on the WLC (Controller->General). The purpose of the feature is pretty self-explanatory, but it can affect some not-so-obvious behaviors. Those of us consulting in the enterprise wireless space understand that iOS devices will almost always prefer an open network without security. I’ve seen them jump very quickly from one to the other and cause issues. With Fast SSID Change enabled, the obvious issue tends to go away (purposely changing SSIDs on the client, but the session seems to lock up), but some not-so-obvious issues may go away too. It is the same issue of course, but the behavior can show itself a bit differently at times so it is not so obviously the culprit.

      1. Hi ts

        I think i tried pretty much everything before resorting to turning off captive bypass, including fast SSID change. I altered session timers, flipped the NAC state between none and RADIUS etc. my set up was ISE 1.2, WLC with 7.4, an older 1262 access point, tested on two iphones running IOS 6.1.3. Initially I was sending the redirect URL in a RADIUS AV pair to the client. I could see from ISE that this was happening as I expected it to. The behaviour was that the phone would jump immediately to a 404 error, and would not display anything. If i typed in the URL into the phone, I would be able to get to the guestportal page. I know it isn’t the greatest of tests, but this was just a lab set up. My other test machine was a windows 8 laptop which had no problem with the initial set up and redirected to the guestportal just fine.

      2. I should have pointed out that the 404 was for the web page I opened in the browser, not the redirect. It was like the phones were not seeing or ignoring the redirect. As I said though, the laptop was being redirected to the guestportal

  3. I have this issue, all devices are fine, only apple devices cant be redirected to ISE CWA, image, IOS version 8.x
    i used bypass command you wrote nothing happened

    1. Hi stemagor,

      I have seen this a number of times, this morning even. Apple iOS devices often require manual navigation to a site that hasn’t recently been visited to get the redirect to function. Be sure to navigate to a site that doesn’t require https.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s