Apple iOS CNA issues with Guest Portals on ISE

[Jason Salmans]

I'm attempting to set up a Dual-SSID flow on a test deployment of ISE.  I initially tried a Single-SSID flow but ran into a chicken or the egg issue with Android and certificates (want to do a long private cert but then Android wants a public one for the initial PEAP connection and seems to be in the process of removing the "Do Not Validate" cert options).

I believe the Dual-SSID flow is working for Android now via signing in to a guest portal that only allows AD logins and then presents the BYOD pages to get the certificate onboarding done.

However, I'm running into issues with the iPad I'm testing and the CNA/mini browser.

When using a portal I created in ISE, when I get redirected (which doesn't seem to always happen when I try in succession), I can log in with my AD credentials but the next page stays on "Cancel" and never presents the "Done" message.  I've attempted adding either of the javascript options found here but with no improvement (added to Optional Content 2 on the Apple Mini Browser page in the portal) :

https://community.cisco.com/t5/network-access-control/cisco-ise-3-1-sponsor-guest-flow-and-apple-cna-issue-cancel/m-p/4500187#M570961

I believe I have the ACLs set correctly on the 9800-CL.. the initial one is set up to trigger the redirect and then the second one should get switched to when it detects the Apple Mini Browser flow (deny ip any to 1.1.1.1 and then a permit ip any to any).

I found another solution that recommended using the ISE portal builder.  I created a test portal, uploaded it to ISE, and set up the basic options.  Testing this with my iPad gets stuck even earlier...  I enter my credentials and then click Sign On and nothing happens.  It never proceeds to the next page.  ISE radius logs seem to show an active session with my username though.

I'm using ISE 3.1 with patch 5 currently and I've tried 15.7 and updating to 16.3 on my iPad.

I'm starting to wonder if maybe the javascript doesn't work on the CNA at all now?  Or is something still possibly messed up with the ACLs I'm using?

[ahollifield]

Why not configure Captive Network Assistance bypass on the 9800?  Also BYOD on mobile devices is a much better user and management experience if you use an MDM.

[Jason Salmans]

Hi @ahollifield and thanks for the reply!

We're not using an MDM.  My original goal was to provide some additional security options for true BYOD (so personally owned staff, faculty, and student devices).  Currently we use PEAP/MsCHAPv2 with our main SSID but that presents several issues:

• Less secure
• Users have to update devices every time they change their password (currently must occur every 120 days or so)
• Changes with Windows for domain-joined machines are going to prohibit using username/password credentials to log in to wifi automatically if they're the same credentials used to log into the machine

To solve these, I wanted to allow the SSID to also support EAP-TLS and give users an option to onboard their devices or choose to stick with PEAP and the associated password changes.  Domain-joined university owned machines would be moved up to EAP-TLS.  To prevent users from having to onboard or update their cert multiple times, I want to use a certificate we generated from our internal PKI and then issue certs to the client devices with lifespans of something like 5 years (for most students, this means just one onboarding per device during their time at the university).

I started looking at Single-SSID first but ran into the issues with Android not trusting the internal PKI certificate (as expected) but, unlike iOS, Mac, and Windows it doesn't even give the user the option to use it.  On my Android phone, I can select "Do Not Validate" for the certificate and that works but I've read that it may be removed in the future (might already be removed for Pixel.. not sure).

My concern with CNA bypass is won't users have to try opening a page in Safari or something to get redirected at that point?  We've done that in the past with a more traditional hotspot setup and the issue was that users think they're connected and try to use an app that doesn't redirect (Facebook or something) and then it just seems like the wifi doesn't work.

I'm considering writing instructions just to have the iOS users connect to the 802.1x SSID directly, sign in to PEAP, and then maybe give them a link to a BYOD portal so that they can choose which security option to use but I hate having to give divergent instructions for different device types.

[ahollifield]

Yes they would but that is the only option here; IIRC BYOD is not supported on the embedded browser.  

Does it make sense from a security prospective to deploy certificates for an internal PKI to unmanaged devices though?  Why not just use a guest flow for this?

[Jason Salmans]

I would use a public PKI but I've heard that isn't a great security practice either and I don't believe I can do a certificate from a public entity that is longer than a year anymore or that can itself sign certificates.  I've put in a feature request with Cisco to allow for multiple EAP certs so that even a yearly public one can be offered on the PEAP authentication and then our internal one can be offered for EAP-TLS signing/negotiation.

At least with the portals I created on the portal builder tool, I am already essentially using a guest portal (even though I have the BYOD features turned on instead of allowing guest registration) as it is required with the Dual-SSID setup and I can't even get the Apple device to get past the Sign On page.  I feel like there has to be something I'm missing here like the CNA no longer executes javascript on the page or my ACL is incorrect on the 9800 or something.

Another reason for more security may be things such as Eduroam.  We've talked about implementing this a few times already and the research I'm doing now on these non-production/trial ISE and WLC instances is helping me map this out.  With our own SSID, or with Eduroam, PEAP is less recommended because of the security issues (I believe the same reason Microsoft wants to prevent you using it automatically with your credentials you signed into the machine with).  EAP-TLS seems to be the preference.

[Jason Salmans]

I figured this out and wanted to post what I found.

First and most importantly, I did indeed have my redirect ACL incorrect on the WLC.  The initial ACL to redirect to the Guest portal was fine, but the one designed to handle the Apple CNA browser post-login was backwards on the permit/deny.  The 9800 is reversed from the older AireOS WLC (which is what the available instructions online show).  I had remembered this previously but, when I was testing and it didn't work before, I made it match the instructions.  Whatever the reason it wasn't working before has apparently been revolved as putting it back to the correct way for an IOS-XE WLC now works.  I came to this conclusion when seeing traffic that should have been blocked/redirect for 1.1.1.1 hitting our firewall.

Apple CNA ACL for the 9800 is:
1 - Permit IP protocol from any to host 1.1.1.1
2 - Deny IP protocol from any to any

The above ACL solved the issue with the Cancel button never changing to Done.  It now changes to Done almost immediately.

The next issue was, after it changes to Done and you click the link, it would prompt to open in Safari.  Doing this then showed it trying to reach 192.0.2.123 with a session ID.  Looking this up, I thought I could fix this by changing the Retry URL setting in ISE but nothing I did there would ever seem to impact it and the iPad continued to try to load that IP.  Finally, I just added another line to the Apple CNA ACL to include that IP as a redirect.  So the updated ACL now looks like:

1 - Permit IP protocol from any to host 1.1.1.1
2 - Permit IP protocol from any to host 192.0.2.123
3 - Deny IP protocol from any to any

This then worked to redirect the iPad Safari browser to resume the BYOD segment.  The OS was incorrectly identified as Mac but I changed it to iPad, added a device name, and then was able to proceed through the certificate profile downloads/installs and then connect via EAP-TLS to the test 802.1x SSID.

Next I probably need to investigate session timeouts on this Onboarding SSID as I think it currently gives virtually full access after they authenticate in the guest portal and until the session expires or is terminated.

[ahollifield]

1.1.1.1 should no longer be used, it’s now owned by CloudFlare. 192.0.2.1 is a suitable replacement.

[Jason Salmans]

Out of curiosity, what is the trigger for that part (the 1.1.1.1 or the 192.0.2.1)?  Is the Apple device pre-programmed as part of the CNA to reach out to these which triggers the redirect based on the ACL?  I remember 1.1.1.1 used to be a default virtual IP for at least the AireOS controllers and that it was recommended to change that but I guess I'm a bit unclear on how the device knows to request it and, therefore, trigger the redirect ACL.

Also, is it beneficial to use the DHCP option 114 with this either side-by-side or a replacement?  

[ahollifield]

If you are using CWA redirection, the local controller virtual IP (192.0.2.1) would never be used in this case.

[Jason Salmans]

I'm redirecting via an ACL on the WLC which is set by the ISE authorization policy per most instructions for the BYOD setup.

[hslai]

In the redirect access-list

1 2 3

Permit IP protocol from any to host 1.1.1.1 Permit IP protocol from any to host 192.0.2.123 Deny IP protocol from any to any

Lines 1 and 2 are to trigger web redirect when accessing the two destination IP addresses, and Line 3 is to not redirect the rest so permit the traffic through.

In our dCloud demo ISE Enterprise and Security, we have been using the combinations of a web-redirect ACL and a DACL even though DACL is only recently vetted officially with IOS-XE 17.10.1, such that a web-redirect ACL is only for redirect and a DACL is to use for what to allow. For example, consider the following:

A. Redirect-ACL ACL_WEBAUTH_REDIRECT

1 2 3

ip access-list extended ACL_WEBAUTH_REDIRECT 10 permit tcp any any eq www 40 deny icmp any any

Line 2 is to trigger URL redirect on any hit to HTTP (TCP/80) and Line 3 is to allow ICMP through for network ping tests.

B. Downloadable ACL ISE_PROVISION_ACCESS

1 2 3 4 5 6

permit udp any host 198.18.133.1 eq domain permit tcp any host 198.18.133.27 eq 8443 permit tcp any host 198.18.133.27 eq 8905 permit tcp any host 198.18.133.27 eq 8084 permit icmp any any deny ip any any

Line 1 is to allow DNS queries; Lines 2 ~ 4 are for the connections to ISE during provisioning phrase; Line 5 is for ICMP networking testing.

[j656]

So, I am seeing where the Apple browser is getting redirect to CloudFlare (1.1.1.1).  Sometimes it happens and sometimes not.  I guest just depends on the version of the device.  I know I can change that address (to 192.0.2.1) in the Guest Portal > Portal Page Customization > Apple Mini Browser page in the html code, is that the correct way to change that?  I also added the address (192.0.2.1) to the ACL on the anchor WLC.  What else needs to change for the devices to use that address to open the portal using the new 192.0.2.1?  Do I need to add the address to the global Web Auth policy on the 9800 WLC anchor.

[hslai]

On WLC. See Cisco Catalyst 9800 Series Configuration Best Practices / Network Controller settings / Virtual IP address