ArubaOS and Controllers

Aruba Employee

How to perform legal interception


In some countries, it is required for those who provide hotspot services to keep track of some information for some time. While the type of information that is required may vary, in most cases it can be summarized to

- User that access the resource
- IP of the resource
- Date
- Type of the traffic (UDP, TCP, etc...)

The Aruba can be configured to generate this kind of information to a backend server. However, it is not designed to operate as a stand alone machine since it wouldn't have the disk capacity to store this kind of information over large period of times (typically 1 year).

Using the "log" option in the firewall rules for any type of traffic, we can log the IP addresses of the servers visited. However, there are several limitations:

- We can only log IP addresses and not host names. For servers running as virtual servers (where several servers are hosted under the same public IP address), we won't know which actual server the client has accessed. Typically for HTTP/HTTPS, if you want to achieve this, I'd recommend setting up a proxy (like squid) possibly in transparent mode.
- Before AOS 3.4, we didn't log the username but only its source IP address. This means that if we need to search the actual user name that was using this specific IP address, we'll have to perform a lookup. While it is not natively doable on our GUI, a simple perl script can do the job. See below.

With AOS 3.4, we now include in each log entry both the username and its source IP. This means that even in case where WiFi clients are being SRC-NAT by the Aruba controller, we can still correlate the traffic to each individual user. See below for more information

Sometimes it's important to log the mapping that an Aruba controller uses between an internal IP/Port to an external IP/Port combination when doing source NAT.

Since AOS v3.3, we have supported logging this information, simply by adding the "log" flag to an ACL that includes the src-nat action. The log item looks like this:

Oct 25 21:04:23 2008 authmgr: <124006> |authmgr| {4693} TCP srcip= srcport=54569 dstip= dstport=80, action=src-nat pool test-pool, role=test-nat, policy=test-src-nat

It does not however include the username, nor the location where this nat occured.

From AOS 3.4 onwards, username will be logged in an authentication message like this-
Oct 29 14:57:47 :522008: |authmgr| User authenticated: Name=test MAC=00:14:a5:49:f0:95 IP= method=802.1x server=Internal role=pre-employee

Prior to v3.4, this same message exists, but does not include the username. For versions prior to this, you can use this same log message to get the users MAC address and correlate this with the de-authentication message that _does_ include the username:

Oct 24 13:51:30 2008 authmgr: <522010> |authmgr| MAC=00:0d:88:57:79:36 IP= User de-authenticated: name=giles, cause=unknown

To get the location that the user is at, you can use the association log message for the users mac address:
Oct 30 10:07:41 2008 stm: <501100> |stm| Assoc success: 00:0d:88:57:79:36: AP

We have created a small perl script that can be run after a log rotation on the controllers output log that will parse these messages and generate a simple HTML output that combines all this information together into one page.

We are assuming that given a date, time and external IP address and external port, they want to find out who sent it and from where.

You setup the syslog server to rotate every week and after rotation, run our script and dump the output to a directory with a web server looking at it. That way, you would end up with a web directory full of weekly files like this say-


Based on the date of the request, the operator would click on the correct week and then would quickly search using the browsers search function for about the right time, or the right external IP address / port. The appropriate line would then quickly give the operator the username and the ap-name.

Note that the time is never going to be exact because this log entry is generated by the _first_ packet of a flow that can last a long time (15 minutes is the default timeout for TCP).

Example screencapture below...
Search Airheads
Showing results for 
Search instead for 
Did you mean: