iOS Devices CWP not auto-closing

  • 1
  • Question
  • Updated 4 years ago
  • Answered
Hi. We have enabled CWP on our SSIDs and have discovered that when the Apple Captive Network Wizard opens to allow users to authenticate it won't close automatically and forces us to wait about 40 seconds for the cancel button in the top right corner to change to 'Done'. If we tap cancel before this changes to done we are disconnected from the SSID.

We're using an Open SSID and the CWP uses radius authentication from our windows servers. The SSID is configured to redirect back to the original requested page after 5 seconds (which seems to be the minimum) and the iPad displays the apple success page. But Apple CNW still doesn't close. If we set CWP not to redirect, or redirect it to a specific Internet address we get the same behaviour and are forced to wait around 40 seconds before being able to tap done and browse normally.

Our APs are using firmware 5.1r5 (as recommended by Support for another issue we faced with the 4ghz spectrum).

The SSID user profile application is: mac auth -> CWP -> SSID (as another forum post I've read recommended)

Any suggestions would be gratefully received.

Regards
Ryan
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes

Posted 4 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I know there were changes to the behaviour here in iOS 7. What version of iOS are you testing with, 7.1?

My hunch is that this may be caused by a compatibility issue in the older HiveOS releases with iOS 7.

For testing purposes, can you reproduce the issue with HiveOS 6.1r3?

Nick


(Edited)
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Hi Nick,

Thanks for the reply.  Unfortunately at the moment we're not in a position to change the Firmware on our APs due to an active support case being logged that has required us to down grade the firmware as part of a resolution / workaround.

Is there anything else we could try to do that doesn't involve firmware?  For reference a video we have just made demonstrates the problem: https://dl.dropboxusercontent.com/u/7242110/IMG_0223.MOV  (yes I know the username and password can be seen but this is a locked down test user with heavy restrictions placed on the account)

Thanks,
Ryan
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
just added redirect after successful login to an external site

and got a pop up saying it could not validate the self generated Aerohive ip address

clicked continue and it took me to the external site and the cancel button changed to done, but it did not close on it's own.

(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
So you are suggesting that it might be a certificate issue here? Cool! That would not be Apple's problem if that is the case.

Clearly, a valid and trusted certificate must be used for a CWP otherwise it is highly security vulnerable after redirection has occurred. (And all CWPs must use HTTPS to protect credentials.)

For public access networks, this means a certificate from a commercial CA must be used on the domain for the address that you redirect to.

You must, of course, never redirect to an IP address where HTTPS in use.
(Edited)
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
I am just relaying what I am seeing. I actually have a valid wildcard cert installed for the captive portal.

the redirect is to the logical interface
  • wifi0.1 — 1.1.1.1/24
  • wifi0.2 — 1.1.2.1/24
  • wifi0.3 — 1.1.3.1/24
  • wifi1.1 — 1.1.101.1/24
  • wifi1.2 — 1.1.102.1/24
  • wifi1.3 — 1.1.103.1/24


Photo of Steven Bateman

Steven Bateman

  • 65 Posts
  • 12 Reply Likes
I'm seeing the same behavior as Andrew on a CWP I'm administering. I can't seem to find a magic combination that works.

-Redirecting to an external website or to the initially requested site gives a cert hostname mismatch error on both a wildcard and explicit CN cert. Expected hostname is the domain name or CN and the actual redirect (as Andrew said) is the interface's IP, causing the mismatch error.

-Not redirecting or attempting to show the success page will just change the "Cancel" button to "Done"

Does anyone have this working in a way that's acceptable?


Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
Hi Steve

I just ordered a cert with a SAN that defines the different virtual IPs for the SSIDs. I have to wait awhile for our purchasing process before I get the cert. I am hopeful that it will fix the weirdness. I will update you once I get the cert installed.

A
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I meant temporarily, purely for testing purposes, on one AP to confirm or disprove it making a difference to the issue that you are observing. You could then downgrade the firmware back again.

What is the issue that required you to downgrade the firmware with 5 GHz clients?

Nick
(Edited)
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I feel you pain.  We have a number of sites that have had issues with iOS devices and captive portals.  Unfortunately Apple makes the rules up as it goes along and if you try to get support from them they advise you that iOS devices are not designed for enterprise networks.

At one of our sites, which run an Aruba wireless network, we had to upgrade the firmware twice (including creating an outage, advising everybody, checking that everybody was logged out, etc.) to keep up with the changes Apple were making without advising anybody.  From iOS 6.1 to 7.1 there have been three changes to the way iOS devices handle captive portals.

I migrated one of our Aerohive deployments from a captive portal design to a PPSK design as it was just getting too difficult making continual changes to accommodate the iOS devices.  The Android devices (except the 2.x devices, which should be removed from any network) just kept working.  
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Ryan,

Are you redirecting to a HTTPS URL that has a valid certificate from a trusted CA? (Normally always commercial.)

Nick
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Hi guys,

Thanks for all the comments.  We're pretty much using the default AeroHive settings whilst we're still in the testing phase of this particular SSID deployment.

The CWP is the default AeroHive one but this does pass authentication requests via radius to one of our radius servers (this server is using a certificate signed by our own internal CA.**) Following successful authentication the user is displayed the usual AeroHive success page and after 5 seconds is redirected back to the original request URL (which in Apple's case is one of the usual 200 or so random URLs that host the success.html page).  The Apple success page itself I believe is accessed via http and not https but the CNW makes it difficult to verify this as the full URL isn't displayed.


** I did try using a properly signed cert for our Radius requests between AeroHive and our servers but could never get this to be trusted by end devices.  I believe this was because the device had to authenticate to gain internet access and so therefore at the point of certificate exchange the device couldn't verify the cert against the CA - in this case GoDaddy.


Thanks
Ryan
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Hi All,

After a couple of months of testing and reading how other (and in my opinion better) wireless providers have worked around the iOS CNA issue I'm happy to report I have a viable solution for this on AeroHive.  The following appears to be working for us (although at the moment with limited testing)...

In the CWP settings page select Walled Garden under Optional Advanced Config.

Add the following hostnames into the Walled Garden (I selected Web protocol just to help lock this down slightly more)  Please see my attached screenshot if required:
  • appleiphonecell.com
  • www.appleiphonecell.com
  • apple.com
  • www.itools.info
  • www.ibook.info
  • www.thinkdifferent.us
  • apple.com.edgekey.net
  • akamaiedge.net
  • akamaitechnologies.com
  • www.airport.uk
  • captive.apple.com
  • *.apple.comWEB

This list was taken from a forum post on the Cisco Support Community so may not be complete, but you can add additional URLs to this list when and as you discover them.  Another possible solution would be to unblock the entire 17.0.0.0/8 IP range (or a subnet of) which is Apple's public address range.  Please also note that although I have added some wild card entries to this, I have yet to see proof that AeroHive supports this so these may not be being used.

With the above configured, Apple CNA no longer loads, but when a user attempts to web browse after connection to the SSID they are then prompted for credentials before being allowed full web access.

Any way, this seems to go some way to mitigating the CNA / CWP disaster.  Hope it helps you too.

Regards,
Ryan
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
Hi Ryan

Thanks for this. It seems that the walled garden could be improved a bit for white-listing sites for devices.

I created an IP object based on the following, but they are not options one can select in the Walled Garden.

Apple CNA:
http://www.apple.com/library/test/success.html
Kindle Fire CNA:
http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html
Google Play (aka Android Market)
android.clients.google.com - google play access
.ggpht.com - download app from google play store
Amazon Market
amzdigitaldownloads.edgesuite.net



I think an option should be added to allow the use of web page ip objects for the specific urls that these CNAs use.



Cheers
A
Photo of Patience

Patience

  • 61 Posts
  • 0 Reply Likes
It is helpful.
Thank you!
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I identified the cause of the original behaviour reported in this post a couple of months ago (it is caused by a combination of a timing issue at the AP end and a somewhat strange, to put it politely, retry behaviour at the iOS end) and escalated to Aerohive.

A fix has been provided in 6.1r6 and from my initial testing the original problem of CNA not changing the "Cancel" button to "Done" is resolved by this fix.

I would hope that in future Aerohive will be a little more proactive in testing iOS beta releases and fixing these inevitable interop quirks before they become a problem for end users.
Photo of Patience

Patience

  • 61 Posts
  • 0 Reply Likes
I totally agree with you that Aerohive should be more proactive in testing their releases.