Wireless Access

We have a SSID/profile setup for our corp and byod networks, corp using 802.1x Eap-TLS and byod using EAP-PEAP. We have two different DHCP scopes for each network. The BYOD network is dedicated for handheld devices and personal devices. 

We are getting (mainly android) devices that when they roam between AP's, they get a "obtaining IP address" and no connectivity. They authenticate fine in ClearPass, but can't connect or get an IP. 

Thought it was the DHCP server/scope so we threw it on the controller itself. I just enabled "Enforce DHCP" for the SSID/Profile and will see if that makes a difference. We have another SSID for PSK authentication with a DHCP scope on another router....have no issues with that.

 

I also noted that when the clients roam they are re-authenticating over and over again...and possibly this could be leading to this issue. Any thoughts?

- When did this start happening?

- Do you have the VLAN hardcoded into the role?

 

 

Thanks Colin for the response. 

Yes, there is a vlan hardcoded in role. We have clearpass passing the user role and within the user role/policy we have a vlan hardcoded to place users on.

We stood up this test SSID a few weeks ago. We had one user in the beginning who had this problem and chalked it up as to his phone. Then yesterday and today I experienced it as well as others. It now is across android and iOS. It happens only when moving around between AP's it seems.

What you should do is, instead of hardcoding the VLAN in the role, you should return the VLAN (the Aruba-User-Vlan attribute), instead in the radius response along with the role.  Having it in the role could possibly result in what you are seeing.

Thanks for the information. I have put the role on Clearpass to pass to the controller and took off the vlan assignment on the controller for that role. I will see how it plays out tomorrow when people are in. Thanks for the help!

Thanks for the information. I have put the role on Clearpass to pass to the controller and took off the vlan assignment on the controller for that role. I will see how it plays out tomorrow when people are in. Thanks for the help!

So taking the hardcoding of the vlan off of the role didn't work. We are still experiencing issues.

It is very strange. We are trying to do debugs on the controller to find out what's going on. But the user gets authenticated, but the phone shows "obtaining IP address." The DHCP server is on the controller and should be getting it fine. We enabled "enforce DHCP" on the profile/role as well.

We also disabled 3/4G on the phones and same issue. We saw once that a host was actually getting a 100.109.x.x IP....which isn't in our scope at all.

 

We are trying to look at show commands and debugs but nothing noteworthy happening.

Are the roles completely open? (allowall)

The role in question that's having issues isn't allow all. However, we have allow DNS and DHCP, block all internal IP's, then allow all. So trying to allow only the needed protocols/IP's and allow everything else.

Do you have the output of "show rights <role>"?

Thanks again for your help! This ended up leading us to the exact cause. After opening up the ACL on the controller to allow all, we had consistent successes. We added each access-list entry to the ACL and found out that I'm a dummy. 

I was allowing DHCP services to only the DHCP server. I'm not a DHCP expert, but the clients have no idea who the server is; they just send out broadcasts. So there is no unicast/single host I can allow DHCP requests to....I have to allow DCHP services to any host, which once I did, it worked. 

 

I'm assuming it worked sometimes was that at some point the ACL was non existent or not applied and hosts were pulling an IP just fine. While some users weren't on the WiFi during this point and then after applying the ACL they weren't able to pull an IP.

Thanks again for the help!!!