Android and ISE supplicant provisioning

I’ve been working in my lab on the cert and supplicant provisioning process in ISE for iOS, Android, OSX, and Win platforms.  There are various docs out and about but they all seem to have gaps.  Maybe at some point I’ll write one or do a video tutorial.  Anyway, one of the challenges has been related to getting Android devices to provision properly.  In the process, I’ve been stuck a few times.

The first obstacle is related to getting the Cisco Network Setup Assistant downloaded so the provisioning process can take place.  A typical webauth ACL is going to redirect everything but dns and access to the ISE server.  Since the app you’re looking for has to be downloaded from the Google Play Store, you also have to allow access to that.  I’m really hoping there is a better way than what I’ve found to work around this.  Google could at any time change the IP (group of IPs) that resolve play.google.com.  This presents a bit of a problem when setting up your ACL.  For now, what I’ve found is that I just do an nslookup from my machine for play.google.com and use the results to populate my ACL.  In my lab, I’m just using a /24 of the first three octets from the results since, so far, they’ve been identical.  You could, of course, put each of the 6 addresses in /32 format individually.

The second obstacle I’ve run into is an error when trying to download the app. Sometimes the Cisco Network Setup Assistant just doesn’t complete the download. It will say “Error – package file is invalid.”  So, here’s what I did to overcome that.  Go to Settings->Applications->Manage Applications->All->Google Play Store and then click the Clear Data and Clear Cache buttons.  I rebooted and then tried again with success.

Remember, if you have to, you can download the Cisco Network Setup Assistant via 3G/4G, then connect to the proper wifi network and launch the application.  It’s not the way you’re supposed to have to do it for sure, but it is a little workaround until this gets a bit more fluid (or I come to a better understanding of how to do this right :)).  So, you could download the app before you try to associate to the device registration network.  Then, as you step through the process and the time comes for the app to download, you can just launch the app.

If you see any errors, or know of a better way to do something, please share!

Advertisements

14 thoughts on “Android and ISE supplicant provisioning

  1. Having the same issue. For some reason i am suspecting the acl.. In my acl i am allowing all google plays ip addresses and also allowing port 5228 to any any.. Im a bit stumped as to what the issue could be. I also downloaded the app from google play via 3g/4g and try again only to get – unable to detect server

    😦

    1. Toby, thanks for your comment. I haven’t had time to do more work on this, except to ask a few TAC engineers and fellow ISE engineers that I know. I haven’t heard an answer yet that satisfies this concern completely. Depending on the Android device’s config, the user may be prompted for either Internet or Play Store options. The ports change based on this decision. If they choose the Google Play option, both 5228 and 8889 (UDP & TCP) should be opened. But, it has also been noticed that port 8880 may also need to be opened for some devices. And, like I mentioned in my post, an nslookup on play.google.com provides varied ip resolution results. My original ACL had something like 74.137.0.0/16 (don’t remember exactly) but nslookup today shows that it needs to be 74.125.0.0/16. I’ve also seen reference to 173.194.0.0/16. It’s a nightmare to keep up with all of that. Also, if the Internet Option is selected, I’m seeing that UDP 5228 and TCP all ports need to be opened. Sigh…

      If anyone reading this post finds a truly workable solution, please share!

      1. Ted, the main issue centers around opening a hole in the ACL to allow access to play.google.com. The older NAC solution allows ACLs with dns names from what I understand, but ISE does not…yet. Be looking for updates from Cisco regarding new features in upcoming releases.

  2. 1) dns based acls are on road map for WLC 8.0.
    2) In the mean time, I would recommend to have two acls-groups on WLC.
    * Redirect-ACL : Allow access only to ISE. So that all the traffic is redirected to ISE.
    * IntraNet-ACL. Here you allow outside but deny to your intranet.

    Write an extra authz policy like this
    Session.OS equals Android.

    When the user hits register button on self registration page, a CoA-reauth is triggered that will hit the rule which allows everything and denys traffic to intranet. In this state when the browser is redirected to google play it wlll have access to it to download the app.

    1. Thanks for your input Vamshi. Do you know when dns based acls are on the roadmap for ISE? WLC 8.0 will also support dACLs so that will be the method of choice I would imagine for getting ACLs to the WLC.

  3. For the first obstacle we also had to open ports 80 and 443 for each /16 at Google otherwise we would receive an “Error 923” from the Play store. This means that all Google webpages work before authorization which is not desirable. Hopefully DNS based ACLs are soon. Could you get it to work with just the two ports in the documentation (5228 and 8889)?

    For the second obstacle clearing DNS/Cache did not resolve this for us. We ran a packet capture and found that during the download there was a DNS query that returned an IP of an additional server that the device needed to communicate with to complete installation. The DNS query was for r6.sn-ufuxaxjvh-v53e.c.android.clients.google.com which resolved to 206.169.145.209. We added an ACL line to allow destination port 80 to this address and the “Error – package file is invalid” message was no more and the application installed successfully. Who knows how long that will last though.

    1. Hi Greg, thanks for your comment. I’ve been so swamped on projects, my time has been too limited to give this blog the attention it needs/deserves so my apologies!

      I could not get it to work by opening up the two documented ports. The resolution of play.google.com (and other google hosts) varies too widely to keep track – and like you said, it is very undesirable to open up all possible google blocks of adresses. For those of us deploying ISE in various regions, it is a compounding headache! There is a release of WLC code in the 7.3 train that allows DNS based ACLs – can’t remember which release but I’m not sure it is readily available via CCO though (might require requesting it from TAC).

      At some point, I’ll downgrade my WLC from beta 7.5 (yes, 7.5 is released now, but I haven’t loaded that yet) to the BYOD release of 7.3 and try it out. I’ve had to move on to ISE 1.2 for the last few months because I had one early deployment in June for 1.2 and several designs for projects that I’m working now that have taken up my time.

  4. Found that the Apps are downloaded from:
    77.214.52.141
    Ive added 77.214.0.0/16 in my ACLs so it adds up to:
    4 lines in the config:
    74.125.0.0
    173.194.0.0
    80.239.0.0
    77.214.0.0
    ALL /16 and dont forget to permit the returning traffic.

    1. Thanks for your post, Ove. This is the current workaround – large ranges in an ACL. Unfortunately, this also opens up access to google in general and tends to defeat the purpose of a redirect ACL. Also, if the user has google.com as their home page, the user experience isn’t too good since they will not get redirected when opening up their browser. There is a new version of WLC code coming that will allow for fqdn’s in ACLs. That will be a good thing when it finally arrives!

      Update: As you may know, 7.6 WLC code is out and does have URL based ACLs – you can add a URL (like play.google.com) to a standard ACL. You have to mouse-over the little blue icon at the far right of the ACL name to access the fly-out menu. I have retested an Android phone in my lab after adding the play.google.com URL and it seems to work very well.

      1. Hi
        I did try with 7.6.100 code using the url name along with the redirect acl, but it didn’t work. what exact version of 7.6 you tried working?

        Thanks
        Ted

      2. Hi Ted, I don’t recall the exact version as I sometimes run beta code. But, I’m pretty sure I was using 7.6.100.0 like you. I would recommend moving up to 7.6 MR2 (7.6.120.0) in any case.

  5. I ran into this problem as well. Depending on the version of Android the client is using the behavior seems to be different. I saw a number of inconsistencies when bouncing back and forth between two GS5’s and a GS3. Seems like the newer OS uses a couple more URLs that all resolve back to either 74.125.0.0/16 or 173.194.0.0/16

    I ended up adding the DNS/URL based ACLs listed below to an ACL_REDIRECT on our 8510 and it worked 95% of the time. If I canceled the play store prompt that comes after device registration (Processing…) and went directly to the Google Play Store app, searched for Cisco Network Assistant, it worked every time. Using the prompt from inside the central web auth, opened the play store as part of the browsing session/app. The 5% failure (retry screen and/or failed download) seemed to be caused by a web request actually calling a specific IP address in the URL(173.194.115.96 in my case). I don’t know if that is somehow cached inside ISE (not as likely), my device(s) (even though I cleared cache and rebooted before each test), or if the Play Store is actually using IPs and not DNS names part of the time. Either way, clicking retry over and over seemed to get past that.

    1. Hi Daniel, thanks for adding your experience to the story here. I’m sure it will help other viewers. After getting past the opening of the right set of subnets for the Google Play Store, most of the troubleshooting I seem to do these days with NSP is trust related. After adding the dns url to the ACL (unless flexconnect is being used), it seems that iOS and Android have different eccentricities :). For iOS, they don’t seem to like cross-chain certs (Entrust is famous for this). Android seems more tolerant of that one (although ice cream sandwich works differently at times than kitkat, which works differently than lollipop…). The errors I see on Android devices during NSP often have to do with an underlying trust issue, although the error message you see doesn’t always point directly to a trust issue. There are the typical things like needing to clear the play store and deleting certs, but often the breakdown occurs when the process moves to https and the device simply doesn’t trust the certificate ISE is presenting to identify itself.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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