Wireless Access

Hi,

Im running an Aruba W3400 on AOS 6.1.3.1.

Recently, or at least we noticed recently, we are seeing traffic from our guest VLAN (200) showing up as new user requests on the authmgr. This seems to be generated by the internet browsing of users on the wifi on that VLAN. Internet pages accessed show up as new IP connections from the firewall mac address on which the guest VLAN is physically connected.

We don't use any Wired access on this controller, only Wireless. The huge inflood of users is clogging the authmgr process and making the controller unstable. The fact that they register as wired clients is really confusing.

A dump from the clients list:
User Name Device Type MAC address Client IP User Role Auth Type ESSID AP Name Phy Type Age Roaming Status Forward Mode
00:90:7f:d0:9b:64 8.8.8.8 logon tunnel 1 3 mins Wired tunnel
00:90:7f:d0:9b:64 85.205.221.241 logon tunnel 1 2 mins Wired tunnel
00:90:7f:d0:9b:64 104.16.96.65 logon tunnel 1 2 mins Wired tunnel
00:90:7f:d0:9b:64 17.248.145.138 logon tunnel 1 1 mins Wired tunnel
00:90:7f:d0:9b:64 193.105.33.16 logon tunnel 1 3 mins Wired tunnel
Android 80:22:75:1c:16:ac 172.16.4.4 gasten@eduvier-cp_prof gasten@eduvier apaurum002 802.11g-HT 2 hrs Wireless tunnel
c.sen Android c0:ee:fb:35:75:4c 10.150.162.194 guest-logon Captive Portal gasten@eduvier APAURUM006 802.11a-HT 1 hrs 12 mins Wireless tunnel

The traffic from mac 00:90:7f:d0:9b:64 on Wired is the unexpected internet traffic showing up as users.

Excerpt from the process log showing the incoming sessions:

Apr 1 10:27:01 authmgr[1583]: <522026> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=104.70.5.52 User miss: ingress=0x1081, VLAN=200
Apr 1 10:27:01 authmgr[1583]: <522006> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=104.70.5.52 User entry added: reason=Sibtye
Apr 1 10:27:01 authmgr[1583]: <522049> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=104.70.5.52 User role updated, existing Role=none/logon, new Role=none/logon, reason=User not authenticated for inheriting attributes
Apr 1 10:27:01 authmgr[1583]: <522050> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=104.70.5.52 User data downloaded to datapath, new Role=logon/1, bw Contract=0/0,reason=New user IP processing
Apr 1 10:27:01 authmgr[1583]: <522026> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=88.221.144.136 User miss: ingress=0x1081, VLAN=200
Apr 1 10:27:01 authmgr[1583]: <522006> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=88.221.144.136 User entry added: reason=Sibtye
Apr 1 10:27:01 authmgr[1583]: <522049> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=88.221.144.136 User role updated, existing Role=none/logon, new Role=none/logon, reason=User not authenticated for inheriting attributes
Apr 1 10:27:01 authmgr[1583]: <522050> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=88.221.144.136 User data downloaded to datapath, new Role=logon/1, bw Contract=0/0,reason=New user IP processing
Apr 1 10:27:01 authmgr[1583]: <522026> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=88.221.144.136 User miss: ingress=0x1081, VLAN=200
Apr 1 10:27:01 authmgr[1583]: <522050> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=88.221.144.136 User data downloaded to datapath, new Role=logon/1, bw Contract=0/0,reason=New user IP processing
Apr 1 10:27:01 authmgr[1583]: <522026> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=95.101.78.209 User miss: ingress=0x1081, VLAN=200
Apr 1 10:27:01 authmgr[1583]: <522006> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64 IP=95.101.78.209 User entry added: reason=Sibtye
Apr 1 10:27:01 authmgr[1583]: <522049> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=95.101.78.209 User role updated, existing Role=none/logon, new Role=none/logon, reason=User not authenticated for inheriting attributes
Apr 1 10:27:01 authmgr[1583]: <522050> <INFO> |authmgr| MAC=00:90:7f:d0:9b:64,IP=95.101.78.209 User data downloaded to datapath, new Role=logon/1, bw Contract=0/0,reason=New user IP processing

For now I have set the logon lifetime to max 2 minutes to help minimize the amount of registered clients. I have also disabled the associated SSID's on most of the locations, except in the IT office for testing purposes.

How would I go about preventing this traffic from generating client connections, instead of trying to patch it with a limited logon lifetime?

kind regards,

Raymond Brettschneider

make interface tunnel 1 trusted.

config t

interface tunnel 1

trusted

The tunnel already appears to be trusted. I checked first with show interface tunnel 1 and it has the same output as after doing the suggested action.

Here is the show interface tunnel 1 output:

(svschans014) (config) #show interface tunnel 1

Tunnel 1 is up line protocol is down
Description: Tunnel Interface
Source 192.168.50.19
Destination unconfigured
Tunnel mtu is set to 1500
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Trusted
Inter Tunnel Flooding is enabled
Tunnel keepalive is disabled
tunnel vlan 1,200-201

 What are you doing with that tunnel?

Excellent question, I really wish I could answer it. I 'inherited' the controller from a predecessor who configured the wireless network, but did not document it too extensively. I'm not really sure what the purpose of the GRE tunnel is.

I can tell you that vlan 1 is our default corporate network vlan. Vlan 200 and 201 are the separated vlan's for guests and student access. The 192.168.50.19 is the IP address of the controller. The only internet traffic that is being registered as new users is coming from vlan 200 and 201, vlan 1 is not generating these errors.

I believe I tried shutting down tunnel 1 last night and losing all network connectivity to the controller forcing me to re-enable it using the CLI on a serial cable.

Is it a single controller, or multiple controllers?

It's a single controller

If you PM me your email address, I can send you a link so you can send me your logs.tar

I am seeing this exact problem, we are utilizing aguest anchor controller for our guest network. We have clustered MDC's.

When I check tunnel interfaces on the guest anchor I see those are "untrusted" per your reply these should be set to "trusted" correct?

Please see below from the anchor

Tunnel 10 is up line protocol is up
Description: Tunnel Interface
Source 10.128.64.246 (Vlan 64)
Destination 10.17.1.19
Tunnel mtu is set to 1400
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Untrusted
Inter Tunnel Flooding is disabled
Tunnel keepalive is enabled
Keepalive type is Default
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 603835, Heartbeats lost 235
Tunnel is down 6 times
tunnel vlan 306

Tunnel 11 is up line protocol is up
Description: Tunnel Interface
Source 10.128.64.246 (Vlan 64)
Destination 10.17.1.18
Tunnel mtu is set to 1400
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Untrusted
Inter Tunnel Flooding is disabled
Tunnel keepalive is enabled
Keepalive type is Default
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 603835, Heartbeats lost 254
Tunnel is down 10 times
tunnel vlan 306

Tunnel 12 is up line protocol is up
Description: Tunnel Interface
Source 10.128.64.246 (Vlan 64)
Destination 10.32.1.18
Tunnel mtu is set to 1400
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Untrusted
Inter Tunnel Flooding is disabled
Tunnel keepalive is enabled
Keepalive type is Default
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 603835, Heartbeats lost 36
Tunnel is down 3 times
tunnel vlan 306

Tunnel 13 is up line protocol is up
Description: Tunnel Interface
Source 10.128.64.246 (Vlan 64)
Destination 10.32.1.19
Tunnel mtu is set to 1400
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Untrusted
Inter Tunnel Flooding is disabled
Tunnel keepalive is enabled
Keepalive type is Default
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 603835, Heartbeats lost 28
Tunnel is down 2 times
tunnel vlan 306

Tunnel 14 is up line protocol is up
Description: Tunnel Interface
Source 10.128.64.246 (Vlan 64)
Destination 10.32.1.20
Tunnel mtu is set to 1400
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Untrusted
Inter Tunnel Flooding is disabled
Tunnel keepalive is enabled
Keepalive type is Default
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 603835, Heartbeats lost 26
Tunnel is down 2 times
tunnel vlan 306

Tunnel 15 is up line protocol is down
Description: homearmc03
Source 10.128.64.246 (Vlan 64)
Destination 10.17.1.21
Tunnel mtu is set to 1400
Tunnel is a Layer2 GRE TUNNEL
Tunnel is Untrusted
Inter Tunnel Flooding is disabled
Tunnel keepalive is enabled
Keepalive type is Default
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 603835, Heartbeats lost 558128
Tunnel is down 14 times
tunnel vlan 306

Root cause has been found and corrected.

A comment in the following thread led me to the cause:

http://community.arubanetworks.com/t5/Wireless-Access/How-to-I-set-ACL-s-on-a-particular-vlan-to-block-all-management/td-p/159094

Turns out, we have a portchannel on which one of the ports was represented as trusted in the webgui, which was in fact no longer trusted. It could not be corrected using the webinterface, but I was able to manually set the port to trusted using the CLI.

Having set the port to trusted all unwanted users disappeared from the user table and so far they have not returned either.

I would like to give my special thanks to Colin Joseph for the time and effort he put in finding the root cause for this. I hope the information gathered and the logs will still be of use to you.

Kinds regards,

Raymond