User Based Tunneling Design

User-Based Tunneling (UBT) extends centralized policy enforcement to wired clients, applying role-based access controls through Mobility Gateway clusters. The gateway delivers flexible, high-performance traffic filtering, ensuring consistent security and segmentation. UBT operates over a Layer 2 or Layer 3 underlay, with switches establishing GRE tunnels to the gateway cluster, similar to tunneled WLAN deployments. Client traffic is mapped to assigned roles and placed into a Layer 2 VLAN on the gateway, which terminates at the service aggregation switch pair.

While tunneled WLAN is not technically part of UBT, it is often considered alongside UBT in network design discussions. Since both architectures rely on Mobility Gateway clusters for role-based policy enforcement and traffic tunneling, this chapter references wireless components when relevant to provide full context.

This chapter focuses on UBT design for campus networks, UBT also is widely deployed in branch environments. For details on branch deployments, refer to the SD-Branch Design VSG. Additional UBT documentation is available in the AOS-10 Fundamentals Guide.

The following sections outline key design considerations for deploying UBT.

Gateway Design and Scaling

When designing a gateway cluster for UBT, it is essential to assess both capacity and redundancy requirements.

Many customers initially size their gateway clusters based on their wireless deployment needs, ensuring sufficient capacity for AP tunneling and wireless client traffic. However, as organizations expand their network segmentation strategy, they often introduce UBT to extend role-based access control to switches. A common oversight in this transition is failing to reassess the scale of the existing gateway cluster.

Each cluster’s capacity is determined by the gateway model, the number of nodes, and the specific needs for client and device tunneling. For instance, each Access Point and UBT switch or stack establishes tunnels to the cluster, and each wired or wireless client device consumes resources within the cluster. These specifications, along with considerations such as uplink types and aggregate bandwidth, guide the selection of an appropriate gateway model.

After establishing base capacity, it is important to determine the number of additional nodes required to provide redundancy during maintenance events or unexpected failures. Notably, these additional nodes are active during normal operations, contributing to user traffic capacity.

Use the AOS 10 Cluster Scale Calculator to guide cluster design and determine the optimal number of nodes to meet capacity and redundancy requirements. By carefully planning and maximizing available resources, organizations can design a resilient and efficient UBT deployment. For a detailed guide on planning a gateway cluster, please refer to the AOS-10 Gateway Planning documentation.

Multizone Considerations

Multizone is an important design consideration in a UBT deployment when organizations require segmentation across multiple administrative domains or need to maintain separate policy enforcement zones within a single network. HPE Aruba Networking multizone architecture allows APs and switches to terminate tunnels to multiple Mobility Gateways simultaneously, enabling distinct security policies, traffic handling, and user segmentation per zone.

In a UBT deployment, multizone is particularly useful when there is a need to separate traffic based on business units, regulatory requirements, or operational roles. For example, an enterprise might deploy multizone to isolate corporate and guest traffic, ensuring that guest users terminate in a DMZ while corporate users are tunneled to an internal gateway. Similarly, educational institutions may use multizone to enforce distinct network policies for students, faculty, and research groups while keeping their data paths separate.

Evaluate the intended use-cases and confirm the requirements align to multizone capabilities related to independent policy control across different network segments. If UBT traffic is managed under a single administrative domain with uniform policy enforcement, multizone may not be necessary. However, for environments requiring strong policy isolation, regulatory compliance, or multi-tenant architectures, multizone is a powerful tool that enhances the flexibility of a UBT deployment. When designing a UBT deployment with multizone, ensure that APs and switches have reachability to all gateway clusters.

Underlay Requirements

A well-designed underlay is critical for a successful UBT deployment, ensuring reliable reachability between infrastructure components. The primary requirement is connectivity between the management and loopback interfaces of APs and switches and the system IPs of the gateways in a cluster.

UBT operates over a Layer 2, Layer 3, or mixed underlay. The illustration above depicts a traditional underlay design, where Layer 3 links are configured above the access layer, and the access layer is configured as Layer 2.

AP-to-Gateway Reachability For tunneled WLAN, each AP establishes tunnels to the gateway cluster. This requires consistent IP reachability between the AP’s management IP and the system IP of the gateway. Any routing or firewall policies in the underlay must allow this communication.

Switch-to-Gateway Reachability For UBT, each switch or switch stack builds tunnels to the gateway. These tunnels rely on the switch’s loopback address reaching the gateway’s system IP. The loopback ensures stability and avoids disruptions caused by physical interface changes. Proper routing, typically through an IGP like OSPF or a static route, is necessary to maintain reachability across the network.

Jumbo MTU Support Since UBT relies on GRE encapsulation, the underlay network must support a jumbo MTU to prevent fragmentation. The minimum reccommened MTU is at least 1600 bytes, accommodating GRE overhead while ensuring efficient packet forwarding. Without proper MTU configuration, fragmentation can lead to performance issues, increased latency, and degraded user experience. HPE Aruba Networking recommends using an MTU value of 9198 on the AOS-10 gateways and AOS-CX switches.

When designing the underlay, validate these considerations through path testing, proper routing configurations, and ensuring that all intermediate devices (switches, firewalls, and routers) support the required MTU.

Reserved vs. Extended Client VLAN

When designing a User Based Tunneling VLAN, the VLAN can be configured as a Reserved VLAN (default) or an Extended VLAN. The choice between these configurations affects the distribution and replication of BUM (Broadcast, Unknown Unicast, and Multicast) traffic within the network.

• Reserved VLAN: In this configuration, the VLAN is deployed exclusively to the gateway, which handles all BUM traffic replication and forwards it to the necessary clients. This approach is the recommended design for most deployments due to its simplicity and efficiency.
• Extended VLAN: When configured as Extended, the Layer 2 VLAN must be present on both the gateway and the switches, though it does not require trunking between them. In this setup, BUM traffic is forwarded to the switches, which then handle the replication internally.

For most deployments, the Reserved VLAN approach is recommended because it simplifies traffic management. Extended VLAN configurations should be considered only when supporting high volumes of BUM traffic that require the local replication capabilities of the switches.

Note: If the deployment contains IP multicast, consult an HPE Aruba Networking account team for design assistance.

User-Defined Roles

A user-defined role is a configurable set of policies and attributes that determine network access privileges for client devices connected to APs, gateways, and access layer switches. These roles determine policy enforcement points, security policies, and operational parameters for users and devices in the network.

UBT

In a UBT deployment, user-defined roles facilitate traffic redirection to the appropriate gateway zone and enforce policy at the gateway. These roles are assigned to UBT client devices or users based on authentication results from a RADIUS server, such as Central NAC or ClearPass Policy Manager.

User-defined roles can be created, modified, and applied per switch configuration group using templates or the MultiEdit configuration editor.The UBT zone configuration, user-defined roles, and gateway role mappings are defined within these templates.

The access layer switch serves as the authenticator and applies role assignments. Each user-defined role on the switch includes attributes that define the destination gateway cluster for UBT traffic and the gateway role assigned to the session. The switch role directs traffic to the appropriate gateway zone but does not enforce policy. All policy enforcement occurs at the AOS-10 gateway cluster based on the role definition.

port-access role EMPLOYEE
 auth-mode client-mode
 gateway-zone zone default gateway-role EMPLOYEE

The configuration snippet illustrates the role configuration on an access switch, which will redirect the traffic to the default gateway zone and apply the EMPLOYEE role on the gateway. The screenshot illustrates the EMPLOYEE role configured on the gateway with an associated policy that the traffic will be subjected to.

Role names are case-sensitive and must match exactly as configured on the reference device. To simplify operations and minimize configuration overhead, role names should remain consistent across switches and gateways when possible, though unique role names can be used if required.

Tunneled WLAN

In a tunneled WLAN deployment, APs forward RADIUS authentication requests to their assigned gateway cluster, which then proxies the request to the configured RADIUS server. The RADIUS server returns the Aruba-User-Role attribute.

Both APs and gateways can serve as policy enforcement points, inspecting traffic and making forwarding or drop decisions based on the network access policies associated with each assigned role. The enforcement location depends on the policies defined within the assigned roles. In most tunneled deployments, the AP assigns a default role with an allow-all policy, permitting traffic forwarding, while the user-defined role on the gateway enforces network access policies.