No Wireless Guest After ISE 2.4 Upgrade

[tcebak]

I'll try to keep this short but include as much as I can.

We have ISE2.0 installed and stood up 2.4(patch 5) ISE severs. We slowly switching everything over from 2.0 to 2.4.
Everything pretty much stayed the same and all wired 802.1x and MAB have no issues.
Wireless 802.1x and MAB have no issues
However we do have an issue with Wireless Guest (using MAB). In WLC, we can switch back to ISE 2.0 and it works but with 2.4 it does not.

We only have 1 WLC 5520 running 8.2.166.
I'll followed "ISE Guest Prescriptive Deployment Guide" just to double check if something was added or needed to be changed from 2.0 to 2.4. Which is attached.

From ISE the client on the guestnet authenticates and is allowed.
-ISE is also sending all the correct info, redirect to the WLC (debug capture)

From the Client they try to connect and then it just fails to join the WAP.
-Because the client never establishes a connection wireshark produces no data
-We have tried 3 client laptops, running windows 7 and 10

From the WLC, which I'm pretty sure is the issue
-Running debug client MAC, it shows the url redirect never occurs
-It's like the WLC gets the information from ISE and then just ignores it and since the client's MAC is not allowed, it's rejected.
-I notice on the failed connection it tries "Apply WLAN Policy over PMIPv6 Client Mobility Type, Tunnel User - 0" not really sure why it's doing that.

-The settings are exactly the same, it just fails when we switch to the new AAA servers and yes i've updated the WLC ACL to include the new ISE servers IP's instead of the old ones. 

I've attached the WLC client debug, working is using ISE 2.0 and failed is using ISE 2.4 with all the same policy sets, profiles, and anything else i can think of.

Any suggestions or clues?

[Arne Bier]

If as you say, ISE is performing the MAB authZ policy and sending back URL redirect to the correct WLC then you should also validate that via a debug aaa event enable, and also, aaa packet enable. Failing that WLC debug, run tcpdump on ise to validate that the WLC sends MAB requ and ISE responds with URL redirect.

Have you tried creating a new WLAN profile instead of using existing one in case WLC config got corrupted? You can disable old one and create new one. Same SSID of course. 

[tcebak]

Thanks Arne,

I do happen to have the ISE tcp dump and it shows the WLC doing a Access-Request, then ISE sends a Access-Accept. Looks like the WLC does not send a ACK because WLC returns with another Access-Request and ISE responds with another Access-Acept. They do that a total of 5 times. 

Any clues why the WLC wouldn't ACK? 

I have not created a new WLAN profile, currently we have a vistor who is using the guestnet (currently pointed to ISE 2.0) but once they leave i'll try that. Normally, i would try to make some argument about if the WLC config is messed up why would it work on old ise but not the new ise servers, but i've seen some weird issues like inside CUCM and know better now!

I'll also try the debug aaa event and see what's happening. To me, i would assume everything would be talking since the other two WLANs are working correctly. But I'll double check! 

Thanks again

[tcebak]

So I tried a new WLAN and still the same issue. 

I ran the aaa debug on the WLC and it says:

24:77:03:d1:c4:24 Invalid RADIUS message authenticator for mobile 24:77:03:d1:c4:24
24:77:03:d1:c4:24 RADIUS message verification failed from server X.X.X.X(qid:4) with pktId=41. Possible secret mismatch for mobile 24:77:03:d1:c4:24
24:77:03:d1:c4:24 Returning AAA Error 'Authentication Failed' (-4) for mobile 24:77:03:d1:c4:24

I want to say the secret is correct because the other 2 WLANs are using the same settings and they are successful.

[Arne Bier · Accepted solution]

Regarding the five access requests and access accepts ... is it just plain access accept and no URL? 5 in a row doesn’t sound right. Should only need one. And there is no ack (I made a typo in my initial reply about ack - if you saw that reply please ignore my comments)

invalid Authenticator would indicate wrong shared secret. You are right that if other wlan is using same radius servers successfully then this open SSID wlan should be able to use same radius creds. Weird. Are you sure the other wlans are indeed using the same PSN?

Does your guest wlan setting use ISE NAC Mode under the advanced tab?

i think you need to chase down the invalid Message Authenticator - you won’t get the URL redirect until that is sorted. 

[tcebak]

In the contents of the ISE tcp dump it shows:

WLC -> ISE  Contains: ssid, it's name, client MAC an audit session id

ISE -> WLC contains: The url-redirect-acl and the url-redirect 

That exchange occurs 5 times before it stops. not other messages between the WLC & ISE occur. 

I've doubled check becasue on the WLC and i've updated the secert and key wrap. Then the WLAN is using the two new ISE servers and that's across all the WLANs. ISE has the WLC and under network devices, it has the correct secret and key wrap.

The guest WLAN and actally all the other WLANs are using the ISE NAC Mode. 

Such a weird issue, becasue ISE in the radius live logs says it's good. the WLC has no issue with the other WLANs, but yet with the guess it seemed like it was ignoring ISE on the access accept, but maybe there is some setting to change. I don't see much to change on ISE nor the WLC. And then i say to my self, well ISE is getting the message from the WLC and it can read it, so why can't the WLC read the response from ISE. Shouldn't it be a two way street if the key is messed up?

Thanks for looking at it!

[tcebak]

Sooo... I deleted the Radius servers and re added them with the same secret/keys, rebooted the WLC and now it's working like a charm. Thanks for bouncing back and forth with me!!!

[Arne Bier]

well done. When things get weird, then rebuild and reboot are required :-)