Wireless Access

Hello everyone,

I noticed recently that the IDS field in my records AMP various daily alarms "IP spoofing" which in my view are false positives. Our controllers are layer 2 being the only one who is Master Layer 3 and serves as a DHCP relay to our external DHCP. What I see is that at one point two distinct MAC user with the same IP and take the controller alarm as IP spoofing. I read some threads here in the forum but nothing to help me isolate the problem, like before opening a TAC to see if anyone knows any solution.

ArubaOS: 6.3.1.8

DHCP server lease time: 2 hours
User idle timeout: 1 hour (already tested with 5 minutes)
Here some screens attached
Thank you

You need to look at the history of both the attacker and target to understand what is going on.  We do not have enough information about your infrastructure to know.  There could be a device with a static ip address..

It looks like you have some clients that are getting more than one IP address.  We have seen this happen on Androids because they sometimes manage to accidentally run more than one dhcpclient instance on their WiFi adaptor.  Because of the way they behave, when they get this way they start getting addresses, abandoning them, and then getting new addresses pretty frequently.  Likely if you look at your core router's ARP table for these MAC addresses they will have several more IPs associated than what you see on the controllers.  There may be an additional problem with exactly how the controller is handling this situation, but the root of the problem is client-side and there is a solution on the server side.  You have two options:

1) If you can get your production DHCP servers to verson 4.3 (assuming they are isc-dhcpd) then you can apply the ignore-client-uids option to prevent two clients on the same machine from being assigned different addresses.  Most networks do not need to allow this to happen, and it can also help in general with the seperate clients run by bootp/boostrap/os.

2) If you have to wait for 4.3 to make it into your approved distros, then you can periodically put static lease reservations for  the clients you find with more than one IP address in Airwave.  The easiest way I found to do this is to build a view that show you just the MAC and IP fields in Airwave and then you can cut and paste that into a script to generate stanzas.  You don't have to get all of them just most of them to keep the amount of this activity low.

Thanks for the replies.

I think that if you explained fits since the client to make the request directly to the DHCP and not the parent as is the case here. The controller acts as the DHCP relay.
All vlans are layer 2 in the local controllers and only the Master has for DHCP relay.
There is a configurable field in the parent that I can send to my DHCP lease one releasing the client IP in DHCP?
This problem is a bit confusing to understand, since the DHCP will not deliver an IP that is already being used, it seems that most of the confusion is a master controller or location.
Our environment consists of 14 controllers, these, only 6 have this false positive, the other not. If settings are global AAA I could be forgetting to check other parameters in the other?
Attached put an approximate design of our topology, but I think it will not help to clarify much.
Another perhaps not very important thing, this false positive occurs in two VLANs with different scopes and different authentication types as well, with one another with 802.1x and captive portal. Our is balanced in two DHCP servers, each of which delivers a half scope, for example:

DHCP 1: Delivery 172.27.32.X the 172.27.39.Y and the other,
DHCP 2: Delivery 172.27.40.X the 172.27.47.Y

Thanks for your help.

@Rafap wrote:

All vlans are layer 2 in the local controllers and only the Master has for DHCP relay.
There is a configurable field in the parent that I can send to my DHCP lease one releasing the client IP in DHCP?

---

That would be consistent with our setup; we also have redundant live DHCP servers and they may be necessary for this problem to occur.

Not sure what you are asking, could you rephrase?

This is a timing-sensitive glitch so if there is a difference between the latency of one set of clients versus others, that could explain the difference between controllers.  Also the magnitude of the problem is version-dependent on the Android side -- it happens more often on older versions of Android.

When this happens the DHCP servers may expunge leases that the client still thinks it owns, if they have "deny duplicates" set, and they become pingable orphaned addresses for a while.