How it works

The functionality of User-Based Tunneling starts with the tunneled-node server information being discovered on the Aruba switch. User-Based Tunneling module exchanges information with the tunneled-node server to determine its reachability and discover the version details. Once the reachability is confirmed, the user-based tunneling module in the Aruba switch sends a bootstrap message to the tunneled-node server, which replies with an acknowledge message.

Creating a Tunnel

A GRE heartbeat is initiated between the Aruba switch and the managed device creating a tunnel. A GRE heartbeat is exchanged with the managed device, which is the switch anchor controller (SAC). This is the controller-IP in the tunneled-nodeserver command. A secondary heartbeat is also established with the standby managed device and acts as a secondary switch anchor controller (s-SAC).

Authenticating the User

As a user connects to a secure port, the Aruba switch sends a request to the RADIUS server (in this case, ClearPass), which authenticates the user and returns a user role attribute to the Aruba switch. Once the attribute containing information on which user role the user will be placed in is received by the Aruba switch, the user role that is configured locally on the Aruba switch or downloaded from the ClearPass.

Aruba User Role

A user role can contain policy, captive portal, and VLAN information. When the user role that is returned from the RADIUS server is applied to the user, the tunneled-node-server-redirect command to redirect traffic to a managed device can be included within the user role. When this command is executed and the user-based tunneling feature status is up, the authentication sub system notifies the user-based tunnel node module, providing a secondary role. The secondary role is the user role on the managed device where policy generally exists for tunneled users. This is where the firewall and security will be applied. This secondary-role information is an indication to the managed device that it has to enforce additional policies to the user traffic based on policy configuration associated with the secondary role and then from the tunnel.

Tunneling to a Controller Cluster

To ensure high availability, customers can tunnel traffic to a Controller Cluster instead of just to a standalone controller. If users are tunneled to a controller cluster, the bucket map containing the mapping between a bucket of clients to the active UAC and s-UAC is populated in the controller. A value based on the client MAC address is assigned when a user is redirected to a controller. This value is then used to look up the bucket map and the client device is then anchored to that particular controller node. This secondary role information is an indication to the controller that it has to enforce additional policies to user traffic based on policy configuration associated with the secondary role. After this process, the per user tunneled node module creates a tunnel to this UAC, if not already created, and forward user traffic to that UAC. If a user role does not contain an attribute to redirect traffic to a controller, then the switch will forward the traffic locally.

Once user tunnels are established to the user anchor controllers, a PAPI (Process Application Programming Interface)-based keepalive packet is exchanged with the controllers that have users anchored to them.