User gets/keeps wrong IP

[januslh]

Hello all, not sure if its relevent here, but i'll try my luck.

So, we have recently setup SDA network and 802.1x in our network, and are currently in the process of testing 802.1x on wireless SSID. When a client joins our 802.1x wireless SSID there is a chance that, if they have used their pc at home, that it will keep their home IP network. Usually a reauth will help with the IP problem.

Here we have an user identified correctly, who has also experienced the same problem before.

This is our ISE Policy setup:

^ This is a condition we have made called BLANK_PEAP_OR_EAP-TLS_Test

^ This is the Authorization Policy Flow

My Question is, why does this behavior happen? Is it the ISE policy set's fault? Is it the WLC's fault? Can we automate/prevent this? Our user's can't use the network when this happens, and having to keep reauthing people is a hassle.

[MHM Cisco World]

can you share WLC config 

MHM

[januslh]

Hello MHM,

I've tried pulling a show run with some redacted stuff, where it says either what it is or just IP, or something along those lines. I hoep its useful.

If you needed something different I hope you can explain excatly what, and if I can redact stuff from it.

[MHM Cisco World]

Hi Friend 
I send you PM 

thanks 

MHM

[januslh]

I've replied

[Gaurav Kansal]

Hi,

In your case please check network drivers are up to date. Also if client is configuring static IP to their WiFi adapter to connect there home WiFi then they need too shift to DHCP setting. Normally if DHCP is set in WiFi adapter, Each authentication will proceed with fresh DHCP request. I suggest you to investigate more and conclude your problem area. Please check your issue while keeping all above.

Regards
Gaurav Kansal

[januslh]

We have had problems both with devices that doesn't have the newest network drivers, and devices that has the newest network drivers. All the devices that has experienced this has been running DHCP, but they have been used at home before, so I might assume they haven't closed their PC, only put to sleep and somehow kept the IP.

[Flavio Miranda]

@januslh 

On the WLC, enable "IPv4 DHCP Required option"

This Will force clients to request DHCP to connect

[januslh]

I will look into enabling this, I can't find it currently, and will have to talk with my colleagues about enabling.

[JPavonM]

But remmeber that enabling DHCP Required option could make your real-time conversation to break when roaming if the OS does not finish the DHCP process in a timely manner.

I used to use it some time ago but now I'm not a friend of these vendor features because of the noise that it introduces when troublehoosting roaming issues (and there are lot due to drivers, OS'es and AP codes)

[januslh]

Hmmm, thank you very much for the response, we do have a lot of roaming, so this might not be the ideal solution.

[Rich R]

Which is the wireless profile policy applied to your problem SSID?
It looks like all your wireless profile policy already have "ipv4 dhcp required" configured.
Are you sure you don't have a rogue DHCP server on the local VLAN?
Next time you see the problem on the WLC:
show wireless client mac <client mac> detail
and on Windows command prompt:
ipconfig /all
to get more detail about where that IP address has come from.

[januslh]

It should be using the wireless profile called RUNet_Profile, and I can see that ipv4 dhcp required is on. I will try to execute the command on the WLC next time i see the problem. The ipconfig /all shows a correct IP, it seems to be only ISE (Maybe WLC) that has the wrong IP, and not the PC itself, and the DHCP server also has the correct one registered.

[januslh · Accepted solution]

More or less got the expectation that this is just a bug and it might or might not be fixed. Good luck everybody else

[Rich R]

You might also want to try enabling ARP proxy on the WLAN policy profile (as per best practices recommendation) because you currently do not have it enabled according to your config:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/technical-reference/c9800-best-practices.html#AddressResolutionProtocolARPproxy