ISE BYOD - Prolem with Android Device Network Setup Assistant not connecting to ISE

Simon Parlsjo · ‎05-22-2015

Hi,

I'm evaluating a BYOD setup using ISE, vWLC and some diferent enddevices such as android, IOS, Mac OSX and windows. At the moment I’m testing the single SSID deployment.

I'm experiencing problems with Android and the Network Setup Assistant.

1. First of all it seems hopelessly hard to configure a good redirect ACL that allows users to download the app but without permitting access to all of google. Do you guys have any suggestions? I read something about narrowing the ACL to only Android devices with some sort of new authZ rule, it had something to do with session==android or something like that. Can anyone clarify this to me?

2. Point 1 is of lesser concern. At the moment my real problem is pushing the profile to android clients. The app keeps telling me that it is unable to contact the ISE and asking if I'm connected to the guest portal. Looking into the spw.log it seems that everything is in order but I'm not sure. I've read somewere about the app making a http connection against the GW but it seems that thats not the problem. It works flawless on an apple iPad so I know that the configuration is correct. It seems that I'm missing something.

Some info about the environment:

vWCL and ISE and clients all on the same subnet (this is a lab environment).

spw.log and ACL rules are attached.

I've followed the BYOD CVD guide as well as some of the videos on labminutes.com.

Cisco Unified Access (UA) and Bring Your Own
Device (BYOD) CVD" - See more at: https://supportforums.cisco.com/discussion/12420826/ise-byod-android-impossible-launch-network-setup-assistant#sthash.ZWNmD50c.dpuf

nspasov · ‎05-22-2015

For #1:

- What version of code are you running on the WLC? With version 7.6 and later you can add "DNS ACL" entries to your ACLs. So instead of IPs you can say permit everything to www.play.google.com

- You should also have a separate on-boarding/BYOD process rule that is for Android devices only. For this, you can leverage the profiling functionality of ISE. The rule should sit above the standard "device registration" rule

For #2:

- So are you saying that you are able to download the network setup assistant but then the on-boarding fails after?

- For your ACL, what are the IPs of ISE and your DNS server

- Post screenshots of your AAA policies and your Client Provisioning rules.

Thank you for rating helpful posts!

Simon Parlsjo · ‎05-22-2015

1:

I'm running the very latest 8.1.102.0. My WLANS are local switched so I'm using flexconnect ACL and then DNS is not support. I could howerver change this to central switching. This is as I said a lab environment but it would be nice to have this feature in an flexconnect environment as well.

I actually did try to use DNS ACLs but it didnt work perhapse I used the wrong DNS names. Do you have the correct ones to use? Also when using DNS ACLs is it enough to open to ISE, DNS, DHCP and then block everything else, will the DNS option take care of everything else.

Update: I tried adding the Session:Device-OS EQUALS Android to a new rule above the BYOD_NOREG but it dosent seem to work. For some reason my android device dosent match that rule. Is there something additional I have to configure for it to work. If I check the endpoint mac adress I see thats its profiled as an Android device. Any suggestions?

2: I actually downloaded the app over 3g/4g prior to connect. During the onboarding when I reach the Google Play link I manually start the app. There I'm presented with the "Unable to download profile (Have you logged in to the quest portal?)" error. Looking in the spw log it seems that I discover the ISE without problem but then something happens.

ISE=10.0.0.31

DNS=10.0.0.20

Can it be a certificate trust issue?

I'm using the internal CA. I've acquired a public signed wildcard cert from startcom startssl (they are free) and there have been som issues with devices not having there root CA in there trusted store. But I think I have seen confiurations example with self-signed certificates so this should not be a problem but I'm not sure.

I also tried blocking the default gw and enroll.cisco.com in the redirect acl but that didnt help.

Do you have any other idea?

So are you saying that you are able to download the network setup assistant but then the on-boarding fails after?

- For your ACL, what are the IPs of ISE and your DNS server

- Post screenshots of your AAA policies and your Client Provisioning rules.

- See more at: https://supportforums.cisco.com/discussion/12514491/ise-byod-prolem-android-device-network-setup-assistant-not-connecting-ise#sthash.TQVtQRrK.dpuf

Simon Parlsjo · ‎05-24-2015

Update:

There seems to be som issue with Andorid 5.X Lollipop. I tried with 3 diffrent models all running Lollipop (Oneplus One, Sony Z3 Compact and LG G2) and all failed. Then I tried with an older Samsung S2 and then the Network Setup Assistant worked flawless!

However I'm still not matching the new rule with Session:DeviceOs==Android and I'm still not sure how the DNS-ACL rule should look like.

nspasov · ‎05-26-2015

I have tested this in my lab with Galaxy S5 running Lollipop (5.0) and did not have any issues. My rules are:

1. If: RegisteredDevices AND EapAuthentication = EAP-TLS THEN Full Access

2. If: RegisteredDevices AND AD1:ExternalGroup = Ise-provision AND EapAuthentication = MSCHAPv2 AND EndPoints: LogicalProfile = Android_Device THEN NSP_Android

3. If: AD1:ExternalGroup = Ise-provision AND EapAuthentication = MSCHAP THEN NSP_Standard

4. Default = DenyAccess

The DNS ACL allows you to add DNS entries so you won't have to have a wide open (to the internet) ACL. For instance, you can provide an entry for play.google.com

Thank you for rating helpful posts!

mscottini · ‎06-16-2015

I'm not matching the new rule with Session:DeviceOs=Android too. You created a rule based in LogicalProfile and Witch profilies you put in? I have a Samgung Android Smartphone and the profile is samsung-device for example.

nspasov · ‎06-22-2015

My logical profile contains any Android devices. You should be getting that information along with the device OS via profiling. Can you confirm with me what you have configured for:

1. Device profiling > Under the advanced tab on the WLC WLAN?

2. Profiling Probes > In ISE

3. CoA Setting > In ISE under System > Settings > Profiling

Thank you for rating helpful posts!

mscottini · ‎06-22-2015

1.
Radius Client > only HTTP (because DHCP Addr. Assignment is disable)
Local Client > HTTP and DHCP

2.
DHCP / HTTP / RADIUS / SNMPQUERY

3.
No CoA

The first time the device hit ISE, the profile is unknow, after the AAA success, than the ISE can profile the device. But the OS device session never match the policy...

Is it necessary ip helper-address point to ISE in the WLC's interface?

nspasov · ‎06-23-2015

1. Unless you have static DHCP assigned devices then you should be OK to enable the DHCP profiler in your WLC.

2. That looks good

3. I would change the CoA to "Re-Auth". Also, in the same section, do you have the "EndPoint Attribute Filter" enabled?

Thank you for rating helpful posts!

mscottini · ‎06-23-2015

What's the difference between CoA to Re-Auth?

No, I don't have the "EndPoint Attribute Filter" enabled.

nspasov · ‎06-23-2015

The re-auth CoA setting will force the device to re-auth each time it gets profiled to a different device. For instance, a device first tries to authenticate and it is uknown but gets profiled as Cisco device. ISE will issue a CoA re-auth and now the device will try to authenticate again. If during that process the device gets profiled to let's say Cisco-IP-Phone then a re-auth will be issued again. During that process the device gets profiled as a Cisco-IP-Phone-7940 a re-auth will happen again...this will continue until the device is profiled at its final stage.

Thank you for rating helpful posts!

mscottini · ‎06-23-2015

Nice, I will try it. And the option "EndPoint Attribute Filter", Is it necessary be enabled?

nspasov · ‎06-23-2015

Sounds good. Let me know if this helps. At this point I would keep the Attribute Filter disabled.

Simon Parlsjo · ‎10-08-2015

Hoping to bring this thread alive again!

I need your input Neno.

After a long parental leave I'm back and still facing some problems with Android devices.

I've configured the logical profile: Android but I'm having difficulties matching the correct rule. At the moment I'm using a singel-ssid onboarding procedure and when an Android device connects it skips the rule with the logical profile and goes direct to the generic rule. During this time I se that the device eventually gets profiled as an Android device but I do not see any COA. If the clients just idles then about 10 minutes later I do see that it matches the Android rule but that’s not fast enough.

Profiling settings is set to REAUTH but it seems that this doesn’t happen fast enough.

Also I've tried the URL-filter in WLC but it dosn't seem to work.