Wireless Access

Is there a way to delete a DHCP lease from the controller, either through the web UI or the CLI?

 

When users authenticate against the SSID it pulls their Windows credentials and the controller uses that info to determine what VLAN to assign the user into. Each VLAN has it's own scope.

 

The issue is that if you sign in as a user that authenticates on one VLAN, they get a DHCP lease in that VLAN. When that user signs out and another of a different VLAN signs in, it's still pulling / using the DHCP lease that actually belongs to the other VLAN - even though the controller recognizes the correct role for the user.

The solution for this is to not change user VLANs and instead use firewall policies restrict access when in machine auth role vs user role. Many clients will not re-DHCP on a role change.

Are you using ClearPass? You could issue a change of authorization which will *usually* force the client to re-DHCP.

We actually are using firewall policies that do accurately detect access based on user, even though they still get an IP assignment in the wrong VLAN. Everything works as we expect since the firewall policies look at user and not machine.

 

The (small) issue is that since the client doesn't get a new DHCP lease in the correct VLAN, it ends up getting passed to the firewall on the wrong VLAN interface - so in the set of firewall policies for a particular vlan we actually have to have role based polciies for users who shouldn't be in that vlan in the first place, only because the aruba controller isn't switching the user into the correct vlan when they get their role assignment from the controller. (I hope that explanation makes sense - at least as far as trying to articulate what's happening.)

 

Forgive my ignorance - is ClearPass something in the aruba controller?

 

And still for my orignial question: is there a way to remove a DHCP lease so that the client is then forced to renew?

 

(I honestly can't remember why we have two separate vlans on our one wireless SSID - since the firewall can do role / user-based filtering I'm not sure why the vlans were originally implemented.)

After talking with my colleague, we finally recalled why the VLAN assignments by the aruba were necessary (it was an authentication issue with Android tablet devices). We actually don't need it to do that anymore, so we could conceivably eliminate the issue as you suggest by dumping the vlans and relying strictly on our firewall policies (which are working properly).

 

Since that's not something I can do overnight without potential severe impact on the organization, I still want to know whether I can kill a DHCP lease for a client. If the aruba controller is to stay as the DHCP server for all my 800+ wireless clients then I have to be able to kill a lease, not just disconnect the user.

Couple of things

 

- I would highly recommend you move DHCP off of the controller. The internal DHCP server is meant for small environments and guest networks.

- There is no automated way to kill a DHCP lease when the client changes VLANs.

- You can only manually clear all DHCP leases, not a single lease.

- There is a setting in the Windows dot1X supplicant that you could try. See below. You can update this via Group Policy.

 

>>- You can only manually clear all DHCP leases, not a single lease.

 

on controller ? how i can delete all leases while it's not possible to delete single leases , any idea? 

 

thanks

ben

quickndirty, lets delete DHCP config, that should wipe shortly the leases ;-) 

 

(WH-Aruba3400) #show ip dhcp statistics

DHCPv4 enabled; DHCPv6 disabled

DHCP Pools
----------
Network Name        Type  Active  Configured leases  Active leases  Free leases  Expired leases  Abandoned leases
------------        ----  ------  -----------------  -------------  -----------  --------------  ----------------
AP-Netz             v4    Yes     28                 5              23           0               0
WH-Gastnetz         v4    Yes     99                 26             73           0               0
WH-INTERN           v4    Yes     125                8              117          0               0
WH-INTERN-AUTH_MAC  v4    Yes     61                 0              61           0               0

Current leases          313
Total leases            512

 

I'd disagree that policy-only configurations are "the solution" for such problems.  There is a lot to be said for the advantages of VLAN-based switching, such as allowing local host policies on servers to be written against known IP ranges.

 

That said, Androids and many linux-based tablets have the horrible property that they do not retry DHCP after being bumped off the controller and forced to re-associate.  Many linux laptops are also not correctly configured to retry DHCP at appropriate times.  In a mostly Windows or OSX environment this is not so much of a problem -- but there is one small AAA problem you have to deal with if you are using fast reauthentication to ensure that fast-reauths do not return cached VLANs during a VLAN change because window's contorted idea of a manual reset of a wifi connection is to perform a fast-reauth.

 

You have to know this limitation and be prepared to deal with it and not get too fancy, but this solution does work, and is architecturally more solid than trying to distribute policy across a heterogeneous network infrastructure.

 

I agree with you re: those advantages of VLAN.

 

Aruba support gave me this as a solution to fully removing a client and the corresponding DHCP lease: use the CLI with the command

 

aaa user delete mac X

 

where X is the mac address of the device in question.

 

There are other switches you can use with delete, such as the user, role, or all users.

 

This is the band-aid I was looking for just to immediately troubleshoot a different issue that's VLAN related. Long term I think we're looking at what cappalli suggested (drop the role-based vlans and move dhcp out of the controller). We know recall why we had to go this route initially.

 

Thanks again guys for pitching in your two pesos on the question.

This comes up fairly regularly on the ISC DHCP server mailing list.  The short answer is no, you can't reliably force a renew, and this is because of the underlying protocol spec, not any particular vendor's implementation.

 

When a DHCP server issues a lease to a client, it's making a promise to the client that the IP address handed out in the lease will be owned solely by that client for the duration of the lease.  This means that the client is under no particular obligation to stop using that IP address until the lease runs out.  Most clients will do functional optimizations, like renewing or discovering on link change or SSID change, on the assumption that they're moving to a different subnet, but this is by no means a hard requirement.  As Tim said, you can do certain tricks that will typically encourage most clients to renew/discover, but there's nothing in the standards that says they have to.  You're far, far better off focusing on dynamically applying the relevant firewall polices to their curent address in the long run.