Wireless Access

Hi There

I have many users with ipad that are having issues with connecting to the captive portal SSID.

When I look in the log, it appears that the ip address asssigned by DHCP to that ipad has been spoofed by an other device. So, this devise is no more able to connect to the wifi. 

The device spoofing the ip address has an age time of 506 days in the user table. why the user table is not cleared?

For instance, this ipad with mac address 64:20:0c:4f:96:18 was unable to connect to the wifi. 

(wifi_local2) #show log user all | include 64:20:0c:4f:96:18
Sep 18 13:54:18 :522027: <WARN> |authmgr| MAC=58:bd:a3:2d:1f:4c IP=172.26.162.66 IP Spoof from MAC=64:20:0c:4f:96:18

(wifi_local2) #show user-table | include 172.26.162.66
172.26.162.66     58:bd:a3:2d:1f:4c     user1    StudentRole  506:08:20   Web

Is there any solution to fix this issue of ip spoofing?

Please advise.

Thanks.

Did you change your AAA timers?  (type show aaa timers)

if you changed your timers, and a user stays in the table, if another user gets that ip address from DHCP, it will be marked as a spoof...

What version of ArubaOS is this?

Hi Joseph,

We did not change the timers. 

User idle timeout = 1800 seconds
Auth Server dead time = 10 minutes
Logon user lifetime = 5 minutes
User Interim stats frequency = 300 seconds

Master-local environment M3 AOS version 6.1.2.4

Last night, I cleared the user table on all my controllers. This morning, I can see only one ip spoof on the log. 

I wont to do this every night to fix the issue of the ip spoofing due to entries not cleared from the user table.

Please advise

It would be painful to troubleshoot this here on the forum.  I suggest you open a support case so that they can examine your setup.

Thonk you, I will do.

I ran into this same problem today.  Someone associated to our guest network, but did not log in.  Shortly after, I believe they disconnected and released their IP.  Then, my iPad associated, obtained the IP that was just released by the guest, and would not show up in the user table.  The user idle time was set to 60 min, which seems to be causing the problem I experienced.

Since the controller sees all user traffic, wouldn't it make sense to delete the entry from the user table if the IP is released rather than wait for the user idle timeout to expire?

---

@thecompnerd wrote:

I ran into this same problem today.  Someone associated to our guest network, but did not log in.  Shortly after, I believe they disconnected and released their IP.  Then, my iPad associated, obtained the IP that was just released by the guest, and would not show up in the user table.  The user idle time was set to 60 min, which seems to be causing the problem I experienced.

 

Since the controller sees all user traffic, wouldn't it make sense to delete the entry from the user table if the IP is released rather than wait for the user idle timeout to expire?

---

Compnerd,

The general rule is that the user idle-timeout needs to be less than the DHCP lease to prevent that from happening.  Extending the user idle-timeout is an alternate reality where Aruba allows a user to stay in the table longer than that user is connected.  It is normally a workaround for Captive Portal so that users do not have to login as often, BUT mac caching deals with that, so there is no real reason to change that global parameter.  New in 6.3 there is also an idle-timeout http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/Captive_Portal/Captive_Portal_Authentic.htm that allows you to change that parameter ONLY for a specific captive portal and not globally.

Long story short, the user idle timeout is a workaround for which a solution exists, so Aruba probably will not attempt to engineer DHCP inspection to deal with extending the timer because it is a workaround.  Removing a user from the user-table upon DHCP release also creates other issues, so why bother?

I'm about to move our guest SSID to ClearPass which has MAC caching enabled, so I suppose at that point the user idle timeout will not be of any use.  Sounds like there isn't any other use for it so I'll probably set it back to the default time.

Please do!!! :)