User-based tunneling

User-based tunneling uses GRE to tunnel ingress traffic on a switch interface to a mobility gateway for further processing. User-based tunneling enables a mobility gateway 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 gateway, 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 Gateway (previously known as tunneled-node).

User-based tunneling supports two types of gateway deployments:

• Standalone Gateway Support
• Clustered Gateway Support

The following commands are required to configure UBT:

• ip source-interface
• ubt
• ubt-client-vlan

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 gateway cluster

The Aruba Mobility Gateway 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 gateway, so the wired, tunneled traffic can take advantage of the gateway’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 gateway IP address can be configured, which should be the physical IP of one of the cluster members. Once the gateway information is known on the switch and the UBT service is enabled, the switch then performs a handshake with the gateway 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 gateway, similar to an AP Hello between an AP and a gateway. This bootstrap control packet contains user role information. Once the gateway receives the message, it replies with an acknowledge message. When acknowledged, the switch updates its local data structures with a bucket map and gateway node list, which is used for mapping users to gateways 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 gateway, forming a tunnel. A regular heartbeat, using GRE, is exchanged with the gateway, which then serves as the switch anchor gateway (SAC). This is the primary-gateway ip in the ubt zone command. A secondary heartbeat is also established with a standby gateway, acting as a secondary switch anchor gateway (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 vendor-specific attribute (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 gateway 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 gateway 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 gateway 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 gateway. When the primary gateway or cluster is not reachable, the SAC tunnel is formed with the backup gateway and the clients are tunneled to the backup.

Multi-zone in UBT

The multizone feature allows a switch to host users whose traffic is tunneled to different gateway clusters. Each UBT zone corresponds to a unique Gateway cluster or a standalone gateway. Each UBT zone is mapped to VRF on a switch/stack. The zone configuration is local to the switch and it provides isolation of user traffic across different gateway clusters.

Multizone is supported for both UBT modes (local VLAN and VLAN extend). The maximum number of UBT zones that can be configured is eight per switch/stack. All UBT zones configured on a switch/stack will either be in local VLAN or VLAN extend mode. Mixed mode is not supported across zones on the same switch/stack. Multiple UBT zones per single VRF on a switch/stack is also supported.

Points to remember

• UBT Mode: Local VLAN
  • UBT is supported on the default VRF and non-default VRF.
  • Source interface is specified using command ip source-interface.
  • VLAN is specified using command ubt-client-vlan.
  • ubt-client-vlan should not be used on any other feature on the switch except for the client IP address tracking feature.
  • 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 on the default VRF and non-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.
  • 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.
• Gateway DUR
  • Downloadable gateway role is supported with switch VSA only. Mixed mode role configuration is supported ((switch LUR + gateway radius VSA) + gateway DUR). Switch mixed role is used to send other role attributes along with VSA.
    • Use aaa authentication port-access radius-overide enable to enable.
  • CPPM server FQDN/hostname configuration is supported.

For information on IP Client Tracker, refer to the IP Client Tracker chapter in the Fundamentals Guide.

• Multi-zone
  • Total number of UBT zones supported on switch/stack is 8.
  • Multiple UBT zones per single VRF is also supported.
  • The total number of supported UBT users across different zones on a switch/stack is 1017.
  • Overlapping user role VLAN(s) should not be present across UBT zones on a switch.

  This will lead to one zone traffic (multicast and broadcast) reaching other zone(s) on the same switch.

• 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.

 

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 gateway	VLAN assignment by switch
Supports only untagged UBT users	Supports both tagged/untagged UBT users
Gateway 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 gateway and switch for Broadcast/Multicast traffic
Gateway 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 gateway to switch is sent to the clients via the same UAC tunnel	The unicast traffic from gateway 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