User-based tunneling

User-based tunneling uses GRE to tunnel ingress traffic on a switch interface to a mobility controller for further processing. User-based tunneling enables a mobility controller to provide a centralized security policy, using per-user authentication and access control to ensure consistent access and permissions.

Applications of user-based tunneling include:

  • Traffic segmentation: Enables splitting of traffic based on user credentials, rather than the physical port to which a user is connected. For example, guests on a corporate network can be assigned to a specific VLAN with access and firewall policies defined to protect the network. Traffic from computers/laptops can be tunneled, while allowing VoIP traffic to move freely through the wired network.
  • Authentication of PoE devices: Many devices that require power over Ethernet (PoE) and network access, such as security cameras, payment card readers, and medical devices, do not have built-in security software. As a result, these devices can pose a risk to networks. User-based tunneling can authenticate these devices and tunnel their traffic to a mobility controller, harnessing the firewall and policy capabilities to secure the network.

At the most basic level User-Based Tunneling has two components:

  • User-Roles refers to the ability to assign roles, on the fly, to a wired device/user, based on such things as the access method of a client. When leveraging ClearPass, additional context can be added, such as time-of-day and type-of-machine. As a result, IT staff no longer must pre-configure an access-port to VLAN and uplinks.
  • Tunneling is the ability to tunnel traffic back to an Aruba Mobility Controller (previously known as tunneled-node).

User-based tunneling supports two types of controller deployments:

  • Standalone Controller Support
  • Clustered Controller Support

The recommended controller version for user-based tunneling is 8.5 or greater.

Components of user-based tunneling

Clients and devices

Traditionally, ports were labeled with a color and a color was assigned to a specific device. With colorless ports, all ports on an access switch are set to authenticate with both 802.1X and MAC Authentication. When a device connects to the network it is authenticated using either MAC Authentication or 802.1X and triggers an enforcement policy from ClearPass, which contains an enforcement profile with a user role configuration.

Access switches

Access switches authenticate users connected to the switch. Once a device or user is authenticated, a role is applied to the device or user. A role is a set of attributes and policies that is applied to the device or user. This user role can exist locally on an access switch or on ClearPass as part of an enforcement profile.

Mobility controller cluster

The Aruba Mobility Controller has many built-in security and application capabilities tailored specifically to wireless traffic. However, this can be extended as well to wired traffic. This is the main reason to tunnel traffic from an Aruba access switch to a controller, so the wired, tunneled traffic can take advantage of the controller’s firewall capabilities and client applications.

Aruba ClearPass Policy Manager

ClearPass assigns enforcement policies and profiles containing user role information based on profiled devices or authenticated user information.

How it works

When first configuring the switch, the tunneling profile must be configured first. This is done using the command ubt zone. Within this context, the primary controller IP address can be configured, which should be the physical IP of one of the cluster members. Once the controller information is known on the switch and the UBT service is enabled, the switch then performs a handshake with the controller to determine its reachability and to discover the version information.

When reachability is confirmed, the switch executes a switch bootstrap, and sends a bootstrap message to the controller, similar to an AP Hello between an AP and a controller. This bootstrap control packet contains user role information. Once the controller receives the message, it replies with an acknowledge message. When acknowledged, the switch updates its local data structures with a bucket map and controller node list, which is used for mapping users to controllers and client load balancing.

After the bucket map list is downloaded to the switch, a GRE heartbeat is then started between the switch and the controller, forming a tunnel. A regular heartbeat, using GRE, is exchanged with the controller, which then serves as the switch anchor controller (SAC). This is the primary-controller ip in the ubt zone command. A secondary heartbeat is also established with a standby controller, acting as a secondary switch anchor controller (s-SAC).

When a user connects to a secure port, the authentication sub-system on the switch sends a RADIUS request to the RADIUS server (for example, ClearPass Policy Manager), which authenticates the user and returns a user role to the switch in the form of a local user role (LUR), downloadable user role (DUR) or venfor-specific attribute (VSA).


For a downloadable user role, the entire role itself is downloaded to the switch containing the user role via a VSA.

Aruba utilizes the concept of a user role which contains user policy and access to the network based on the role. A user-role can contain ACL/QoS policy, captive portal, VLAN information (used for locally switched traffic), and device attributes. When the user role VSA, received from the RADIUS server, is applied to the user, a command to redirect traffic to a controller can be included within the user role. This is defined with the gateway zone command which causes tunneling to be enabled. The authentication sub-system notifies the tunneling subsystem on the switch, providing a gateway or secondary role. The gateway or secondary role is the user role on the controller where policy will generally exist for tunneled users, and where firewall and security policies are applied. This can also be the same role used for wireless users and can be reused for wired users, if feasible.

The gateway role information sent to the switch tunneling subsystem is an indication to the controller that it has to enforce additional policies on the user’s traffic based on the policy configuration associated with the secondary role and the tunnel. This secondary role can be downloaded directly to the controller. When the primary controller or cluster is not reachable, the SAC tunnel is formed with the backup controller and the clients are tunneled to the backup.

Points to remember

  • UBT Mode: Local VLAN

    • UBT is supported only on the default VRF.

    • Source interface is specified using command ip source-interface.

    • VLAN is specified using command ubt-client-vlan.

    • No feature should be configured on ubt-client-vlan.

    • Client IP tracker is not supported for UBT clients.

    • UBT does not support tagged clients.

    • UBT clients and non-UBT clients on same VLAN and same port is not supported.

    • Source interface change: Disable UBT, change the source-interface, enable UBT.

  • UBT Mode: VLAN extend
    • UBT is supported only on the default VRF.

    • Source interface is specified using command ip source-interface.

    • UBT client vlan is defined under role.

    • DHCP snooping and ND-snooping should not enabled on a UBT client assigned VLAN.

    • IGMP snooping should not be enabled on a UBT client assigned VLAN.

    • Client IP tracker is not supported for UBT clients.

    • The VLAN on which UBT clients are placed should not be configured on the switch uplink.

    • UBT clients and non-UBT clients on the same VLAN on the same switch is not supported.

    • Source interface change: Disable UBT, change the source-interface, enable UBT.

  • PC behind an IP phone

    You should not have a PC and phone on the same VLAN on the same port when the PC is a UBT client and the phone is a non-UBT client. If you do, UBT clients broadcast/multicast packets will return to the same port and corrupt the phone MAC table.

  • Clients behind an L2 switch on the same VLAN

    You should not have clients behind an L2 switch in a UBT environment. If UBT and non-UBT clients are behind an L2 switch on the same VLAN, this will cause duplicate packets. Broadcast/multicast packets will be copied to the tunnel and locally, causing the client to receive duplicate packets and network instability.


    Its recommended to connect the client directly into switch ports or behind VoIP.

Comparison between UBT modes

UBT Mode: Local VLAN UBT Mode: VLAN extend
Switch unaware of UBT user VLAN Switch is aware of user VLAN
Colorless ports: No UBT user VLAN config at switch Colorless ports: UBT User VLAN config is required on switch
VLAN assignment by controller VLAN assignment by switch
Supports only untagged UBT users Supports both tagged/untagged UBT users
Controller replicates the broadcast/multicast traffic (converting bcast/mcast to unicast) and sends it to every UBT client Single dedicated multicast GRE tunnel will be established between the controller and switch for Broadcast/Multicast traffic
Controller forwards all broadcast/multicast traffic to the UBT clients which are part of the same VLAN Switch will forward the broadcast/multicast traffic to the UBT clients which are part of the same VLAN
The unicast/multicast/broadcast traffic from controller to switch is sent to the clients via the same UAC tunnel The unicast traffic from controller to switch is sent through the UAC tunnel and multicast/broadcast traffic via Multicast GRE tunnel
Multicast traffic will be sent to the client which send join Multicast traffic will be sent to all UBT clients on the same VLAN