Wireless Access

Hello,

We're seeing a strange phenomenon happening with our 6000 controller (virtual applicance running 6.3.1.9) where an end point/user will show two entries in the user table. One will have a valid DHCP provided IP address and one will have a mysterious. See output below from the controller and from the endpoint (windows device):

Controller output
(ArubaMaster) # show user | include packerd
10.0.0.21 50:1a:c5:e9:1b:3f packerd Employee_Internet_Only 00:05:15 802.1x Conf_room_N3_IS:a9:13 Wireless NRUCFC-Corp/d8:c7:c8:ea:91:38/a-HT NRUCFC-Corp-aaa_prof tunnel Win 8
192.168.101.99 50:1a:c5:e9:1b:3f packerd Employee_Internet_Only 00:05:15 802.1x Conf_room_N3_IS:a9:13 Wireless NRUCFC-Corp/d8:c7:c8:ea:91:38/a-HT NRUCFC-Corp-aaa_prof tunnel Win 8

Endpoint output
C:\Users\Daniel>ipconfig

Windows IP Configuration

Ethernet adapter Bluetooth Network Connection:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Local Area Connection* 2:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . : ad.nrucfc.org
Link-local IPv6 Address . . . . . : fe80::609b:3b3b:9840:2186%3
IPv4 Address. . . . . . . . . . . : 192.168.101.99
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.101.1

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:79fb:3828:1dc8:3f57:9a9c
Link-local IPv6 Address . . . . . : fe80::3828:1dc8:3f57:9a9c%8
Default Gateway . . . . . . . . . : ::

Tunnel adapter isatap.ad.nrucfc.org:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : ad.nrucfc.org

C:\Users\Daniel>netstat

Active Connections

Proto Local Address Foreign Address State
TCP 127.0.0.1:19872 Alpha:49501 ESTABLISHED
TCP 127.0.0.1:49501 Alpha:19872 ESTABLISHED
TCP 127.0.0.1:49876 Alpha:49881 ESTABLISHED
TCP 127.0.0.1:49876 Alpha:49882 ESTABLISHED
TCP 127.0.0.1:49881 Alpha:49876 ESTABLISHED
TCP 127.0.0.1:49882 Alpha:49876 ESTABLISHED
TCP 127.0.0.1:51246 Alpha:51247 ESTABLISHED
TCP 127.0.0.1:51247 Alpha:51246 ESTABLISHED
TCP 192.168.101.99:49163 bn1wns2011804:https ESTABLISHED
TCP 192.168.101.99:49176 64.233.171.109:imaps ESTABLISHED
TCP 192.168.101.99:49179 bay402-m:https ESTABLISHED
TCP 192.168.101.99:51137 r-064-042-234-077:http ESTABLISHED
TCP 192.168.101.99:51195 64.233.171.188:5228 ESTABLISHED
TCP 192.168.101.99:51213 ash-rc1-3b:http ESTABLISHED
TCP 192.168.101.99:51215 iad23s23-in-f21:https ESTABLISHED
TCP 192.168.101.99:51224 qg-in-f189:https ESTABLISHED
TCP 192.168.101.99:51249 viewext:https ESTABLISHED
TCP 192.168.101.99:51250 viewext:https CLOSE_WAIT
TCP 192.168.101.99:51251 viewext:https CLOSE_WAIT
TCP 192.168.101.99:51285 iad23s23-in-f6:https ESTABLISHED
TCP 192.168.101.99:51288 iad23s23-in-f5:https ESTABLISHED
TCP 192.168.101.99:51289 64.233.171.113:https ESTABLISHED
TCP 192.168.101.99:51292 qg-in-f147:https ESTABLISHED
TCP 192.168.101.99:51294 65.55.163.222:https TIME_WAIT

 

 

The problem is the 10 net address. As you can see it is not configured anywhere on the windows client. But that 10 net address happens to be a server on our network that is in no way assoicated to aruba at all. 

 

Has anyone else seen this before?

Thanks,

Josh

Please configure "Enforce DHCP" in your aaa profile to deal with this issue.  Please see more about this configuration knob here:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/What-does-enforce-dhcp-option-in-aaa-profile-do/ta-p/180226

 

 

In addition to the enforce DHCP as mentioned by Colin, if you have a pefng license, you can also solve this by using validuser ACL to only allow specific subnets (i.e. your DHCP scope) into the user table. It's also good practise to use the validuser ACL to deny important Ips from entering the usertable (radius, default g/w etc.).

 

These IP addresses come from various places, including windows machines bridging packets, stale DHCP leases, smart phones leaking their carrier side IP address into wifi, multinetted interfaces on non windows devices, VM installations etc.  It's quite common and not necessarily a problem until one of these addresses overlaps with something important (hence why validuser ACL should be setup in two parts, allow valid subnets and protect valid hosts)

 

regards

-jeff

 

 

 

Thanks Jeff. Is a pefng license the same as "Policy Enforcement Firewall"? If so it looks like we have that (see below).

 

Also, do you know what the affect would be of checking the "Enforce DHCP" option during production? Would clients be dropped and forced to re-authenticate?

 

 

joshsg,

 

"Enforce DHCP" only has affect on new clients that join after you enable it.

 

You can also optionally use the "aaa user fast-age" command to age out those "ghost" ip addresses :  http://community.arubanetworks.com/t5/Command-of-the-Day/COTD-aaa-user-fast-age/m-p/4098/highlight/true#M170

 

 

I have seen the same behaviour on our wifi clients, they had their legit ip address from the wifi vlan issued from local dhcp server (as expected), and next to that they had external ip adresses from places in the US. Seemed more than strange to have your local wifi clients showing up external adresses in Aruba 3200 controller monitoring screen. Then this post came up that seemed to match the problem seen. Applied the setting as suggested "aaa profile default = enforce dhcp" because it made sense and when it says that " this option ensures only the clients that gets the an IP address from a DHCP server will be allowed in the controller user-table..." its just what one needs on the face of it.

Controller rebooted and after that became inaccessible on the local network, off the air as well.

How inconvenient that can be? No one had wifi on college campus. Conroller power cycled but this did not help. Eventually had to connect via serial console cable and use cli to revert to original setting without "enforce-dhcp" option to bring it back on line.

Why would this happeen I have no idea but someone on the forum might?

 

 

Why did the controller reboot?  Enforce DHCP is not related to controller rebooting. 

---

@cjoseph wrote:

Why did the controller reboot?  Enforce DHCP is not related to controller rebooting. 

---

After saving configuration change controller was rebooted after hours intentionally, so that client ip addresses can be checked again in monitoring screen, in other words to confim that configuration change produced results.

It is possible that you did not save the configuration and the controller reverted to what it was before the last time you saved it? Since the controller was rebooted, there is little evidence of what could have happened.

As I said in my original post after rebooting the controller, I had to connect via serial cable and use cli to change the configuration back to original setting, without the "dhcp-enforce" and then it worked fine. Why is it that this setting upsets the controller I have no idea.

If you want to get to the bottom of it, you should probably open a support case. I cannot think of any reason why changing that setting would create your specific issue.

Reading your statement again, you said you put "Enforce DHCP" on the default AAA profile.  Very rarely is the default AAA profile used for wireless users.  It is entirely possible that you have the default AAA profile attached to a physical port on the controller (untrusted port maybe) which could create the issue you mentioned if you turned on "Enforce DHCP"

 

If you type "show user-table verbose", the profile column will tell you what AAA profile you should apply "Enforce DHCP" to.

Thanks, it is indeed the Wired profile having Auth profile=default. Other profiles exist for wireless that can be modified for this setting. Should have known that before.