Roles

• 1: Fundamentals
• 2: Management and configuration
• 3: Bridge forwarding
• 4: Tunnel forwarding
• 5: User-Based Tunneling

1 - Fundamentals

Roles are policy and configuration containers that are assigned to client devices connected to HPE Aruba Networking access points (APs), gateways, and access layer switches. Usage of roles is mandatory for APs and gateways but optional for access layer switches except when User-Based Tunneling (UBT) is deployed.

Roles are a differentiating foundational architectural element supported by HPE Aruba Networking infrastructure devices. They can be used to implement dynamic segmentation and policy enforcement between different sets of client devices and may optionally include other attributes for assignment. Initially introduced for use on wireless controllers and controllerless APs (AOS-8), roles are now supported by all current infrastructure devicesincluding APs, gateways, and switches.

Role uses

Roles are used to apply network access policies and other attributes to client devices or user identities. The policy language and supported attributes are network infrastructure device type specific and vary between APs, gateways, and switches. The available policy options and attributes being limited by the capabilities and supported features for each device type.

In AOS-10, roles contain policy language used to determine host, network, and application permissions. They may optionally include other configuration attributes such as VLAN assignment, captive portal configuration or bandwidth contracts. Global client roles applied to gateways also include group policy identifiers (GPIDs) used by gateways and switches for role-to-role policy enforcement.

On switches, roles are used to dynamically apply configuration to access ports when port-access security is enabled. When a wired client device or user successfully authenticates, the RADIUS authentication server or Central NAC service can return a role name that determines the port’s operation mode, forwarding behavior, switchport mode, and access or trunk VLAN assignments. If UBT is enabled, the assigned role will also determine the cluster (zone) where traffic is tunneled to, and the role assigned on the gateways.

Role assignment

Roles can be assigned to client devices or user identities on APs, gateways, or access layer switches at the point each client device connects to the network. When traffic is tunneled from an AP or UBT access layer switch to gateways, a role is assigned on the tunnelingdevice where the client is attached in addition to the gateways.

APs

Roles are assigned to each wired and wireless client device (unique MAC) that connects to an AP regardless of the forwarding mode configured in the profile. This includes:

• Wired devices connected to downlink port.

• Wireless devices connected to WLANs.

Each client device is assigned a default role or a user defined role from a RADIUS authentication server, Central NAC service, or role assignment rule. If no role is dynamically assigned or the assigned role does not exist, a default role is assigned. As wireless clients are nomadic, the assigned role will follow each client as they roam between APs within a roaming domain,the assigned role being cached and automatically distributed by services within Central to neighboring APs.

Gateways

When a wired or wireless client on an AP or a wired client connected to a UBT switch is tunneled to a gateway cluster, two roles are assigned:

• A role is assigned at the AP where the wired or wireless client device is attached.

• A role is assigned on the UBT switch where the wired client device is attached.

Within a cluster, each tunneled client device (unique MAC address) is assigned an active and standby User Designated Gateway (UDG) via the published bucket map for the cluster (see Cluster Roles). Each client’s assigned UDG gateway is the anchor point for all traffic and is persistent. The only time a tunneled client’s UDG gateway assignment is changed is if a gateway is added or removed from a cluster, a failover to a secondary cluster occurs, or the wireless client roams to an AP that is tunneling to a different cluster.

A role may also be assigned to wired client devices that are serviced by a switchport on a gateway. When a port or VLAN is untrusted, each wired device can be optionally authenticated where a user defined role can be dynamically provided by a RADIUS server or Central NAC service. For non-authenticated ports or VLANs, a user defined role may be statically assigned.

Access layer switches

When port-access security is configured on an access layer switch, a role can be dynamically assigned to wired devices from a RADIUS authentication server or Central NAC service. The attributes in each role determine the configuration that is applied to the switchport and if user based tunneling (UBT) is activated for forwarding.

When a wired UBT client is tunneled to a gateway cluster, two roles are assigned:

• A role is assigned on the access layer switch where the wired client device is attached.

• A role is assigned on the user designated gateway (UDG) for each UBT client.

For UBT to function, a user defined role is assigned on the access layer switch that includes attributes that specifies the cluster (zone) the UBT client’s traffic is tunneled to and the user defined role that is assigned on each UDG gateway. For flexibility, the role mapping configured for each role permits the same role name to be assigned on both the access layer switches and gateways or different role names to be assigned. Additionally, CX access layer switches implement zones allowing UBT clients traffic to be terminated on different clusters within the network.

Role types

AOS-10 APs and gateways support default roles, user defined roles, and global client roles. Default roles are applied to wired or wireless client devices when no user defined role is assigned while user defined roles and global client roles are assigned by either an authentication server or role derivation rule.

Default roles

Default roles are automatically created for each downlink port profile and WLAN profile that are configured within an AP configuration group. Each default role has the same name as its parent profile and is assigned to client devices when no user defined role is assigned.

Default roles are either created within an AP configuration group or both AP and gateway configuration groups depending on the forwarding mode of the profile:

• Bridge forwarding – The default role is created in the AP configuration group only.

• Mixed / tunnel forwarding – The default role is created in both the AP and gateway configuration groups. When both a primary and secondary cluster are assigned, they are created in both the primary and secondary gateway configuration groups.

Default roles are mandatory and must exist on the AP for each profile. They can be used to apply security policies to client devices as well as assign other attributes such as VLANs, captive portal configuration, or bandwidth contracts. They may be used exclusively when no dynamic role assignment is required or be employed as a fall-through/catchall role when no dynamic user defined role is assigned.

While a default role can be dynamically assigned to client devices or user identities connected to other profiles, this is not recommended as default roles are deleted when their parent profile is deleted. If a role needs to be assigned to multiple profiles, a user defined role should be used. A default role should only be used within the context of the parent profile.

User defined roles

User defined roles are configured and named by the administrator. They can be independently configured per AP or gateway configuration group or be orchestrated by Central to the necessary configuration groups by a profile creation workflow. They are assigned to client devices or users either by a RADIUS authentication server, Central NAC service, or role derivation rule. A default user role is assigned to client devices when no user defined role is dynamically assigned or if a dynamically assigned role does not exist on the AP or gateway.

When user defined user roles are added or modified using a profile creation workflow, the roles and associated policies are either created in the AP configuration group or both the AP and gateway configuration groups depending on the forwarding mode of the profile:

• Bridge forwarding – User defined roles are created in the AP configuration group only.

• Tunnel forwarding – User defined roles are created in the respective gateway configuration groups. When both primary and secondary clusters are assigned, they are created in both the primary and secondary gateway configuration groups.

• Mixed forwarding - User defined roles are created in both the AP and gateway configuration groups.

If no user defined roles are configured using the profile creation workflow, they must be manually created in the respective AP and gateway configuration groups by the admin. Only roles added or modified using a profile creation workflow are automatically orchestrated between AP and gateway configuration groups. When a profile creation workflow is used, policies, attributes and derivation rules are also orchestrated between AP and gateway configuration groups. The orchestrated roles can be used across profiles as needed.

For most AOS-10 deployments, user defined roles will either be created in their respective AP or gateway configuration groups as the profiles on the APs will implement either a bridged or tunnel forwarding mode. User defined roles will only need to be created in both AP and gateway configuration groups if the AP is simultaneously bridging and tunneling user traffic and the same user defined role is assigned to client devices or user identities for both forwarding modes. For example, an employee role is assigned to tunneled wireless clients in addition to bridged wired clients connected to wall-plate APs. In this scenario the employee role would be assigned to both AP and the respective gateway configuration groups.

Global client roles

Global client roles are configured and managed in Central then propagated to CX switches or gateways but are not supported on APs or AOS-S switches. Unlike user defined roles which are configured and managed per configuration group, global client roles are centrally configured and managed in Central then propagated to the CX switches, branch gateways, and mobility gateways.

When propagated to branch or mobility gateways, each global client role will be listed in the roles table in each applicable gateway configuration group and are identified with a ‘Yes’ flag in the global column. Each global client role must have a unique name and cannotoverlap with existing default or user defined roles.

A global client role can be assigned to tunneled client devices terminating on a gateway cluster in addition to wired client devices that are connected to an untrusted port or VLAN on a gateway. They can be used the same way as user defined roles and can include IP-based policies and attributes.

Unlike default and user defined roles, global client roles do not contain any IP-based network access permissions by default, and these must be assigned post propagation by the admin. If used in an unmodified state, client devices will be unable to obtain IP addressing or be able to communicate over the intermediate IP network. For each propagated role, the admin must assign one or more session access control lists (SACLs) that allows basic network services such as Dynamic Host Configuration Protocol (DHCP) and Domain Name Services (DNS) in addition to the necessary destination host and network permissions.

Global client roles may also be used to apply role-to-role group-based policy enforcement with a NetConductor solution in addition to role-to-role enforcement across gateways as detailed in theVSG.

2 - Management and configuration

Role management and configuration in Central is separated into two management functions. The first management function involves role creation or removal which can be performed in different areas within the Central UI depending on the role type:

• Default roles – Are supported on APs and gateways. They are added or removed to AP and gateway configuration groups with their parent profile. Default roles cannot be manually created or removed.

• User defined roles – Are supported on APs and gateways. They are added or removed using either the profile creation workflow or are manually added or removed directly within each AP or gateway configuration group.

• Global client role – Are added or removed globally within a Central instance then propagated to gateways and switches.

As roles are policy and configuration containers, the second management function involves adding, removing, or modifying network access policies and attributes for each role. For default and user defined roles, the forwarding mode selected for a profile will influence where role management can be performed:

• Bridge forwarding – Network access policies and attributes can be configured and managed using the profile creation workflow or by directly modifying each role within an AP configuration group.

• Mixed or tunnel forwarding – Network access policies and attributes are configured and managed directly per AP and gateway configuration group. This recent change permits different network access policies and attributes to be assigned to a role on APs and gateways.

Role to role permission management and group policy identifier configuration for global client roles is performed globally within each Central instance. For global client roles that are propagated to mobility gateways, additional network access policies and attributes are configured and managed directly within each gateway configuration group.

Profile creation workflow

The profile creation workflow provides a convenient way to configure default and user defined roles as part of an intuitive workflow. Roles can be added and removed without requiring the admin to exit the profile workflow. The access slider in the workflow determines the level of role configuration that is exposed:

• Unrestricted – No role configuration is exposed within the workflow.

• Network Based – Network access permissions and attributes can be configured and modified for the default role only.

• Role Based – Full role configuration is exposed.

For bridge forwarding profiles, roles can be added, removed, and configured using the workflow. When Role Based access is selected, adding, editing, or removing user defined roles is possible.

For mixed and tunnel forwarding profiles, roles can be added and removed using the profile creation workflow, but policies cannot be configured. User defined roles added or removed using the workflow are added or removed from their respective AP and gateway configuration groups. Note that network access policies and attributes are no longer configurable using the profile creation workflow for mixed and tunnel forwarding profiles and must be manually configured in the respective AP and gateway configuration groups. A warning is displayed in theconfiguration workflow advising of this requirement.

Configuration groups

User defined roles can be added, removed, and configured directly per AP and gateway configuration group using the Central UI. The admin can configure network access permissions and attributes for existing roles or add, delete, and configure user defined roles. The UI also offers a convenient way to pre-configure user defined roles, network access permissions and attributes prior to creating profiles.

For AP configuration groups, default and user defined roles can be configured and managed under Security > Roles. User defined roles can be added, removed, or configured, but default roles can only be configured and not removed. Default roles can only be removed by removing the parent profile.

Each role is configured by selecting a role from the list which presents the network access policies and attributes that are configured for the selected role. An example of role management within an AP configuration group is depicted below.

For gateway configuration groups, default and user defined roles can be configured and managed under Security > Roles. The role table lists all the roles configured in the gateway configuration group which includes predefined roles, default roles, user defined roles, and global client roles. Global client roles are identified with a Global “Yes” flag.

Each role is configured by selecting a role in the table which displays an additional table that presents the network access policies and attributes that are assigned to the selected role.

3 - Bridge forwarding

Please refer to the Forwarding Modes of Operation for a detailed overview of bridge forwarding.

Supported role types

For bridge forwarding, the AP makes the role assignment decision. Bridged clients can be assigned a default role or user defined role but not a global role. A bridged client is either assigned a default role or user defined role depending on if a user defined role is dynamically assigned from an authentication server or role derivation rule.

Role derivation and assignment

For bridge forwarding, the APs operate as authenticators and make the role assignment decision. When a client device attaches to an AP or a device/user identity is authenticated, a default or user defined role is assigned:

• Default role – Is assigned when no user defined role is dynamically assigned, or the dynamically assigned role is not present on the AP.

• User defined role – Is dynamically assigned from a RADIUS authentication server, Central NAC service or role assignment rule.

A user defined role may also be assigned post-authentication using a DHCP role assignment rule. DHCP role assignment rules are evaluated post authentication as a DHCP message exchange must occur. A default or user defined role may also be changed post-authentication by an authentication server that sends a change of authorization (CoA) message.

Default role

A default role is created for every bridge profile with a default role assignment rule that cannot be modified. The default role assignment for a profile can be viewed in the profile creation workflow when Role Based access is selected. An example of a default role assignment for a profile named BridgeProfile is depicted below.

A default role is assigned to client devices or user identities when no role is dynamically assigned from a RADIUS authentication server, Central NAC service or role assignment rule. They are also assigned if a dynamically assigned role is not present in the AP configuration.

Assignment rules

User defined roles can be dynamically assigned to client sessions by creating role assignment rules within the profile creation workflow. They are optional and permit dynamic user defined role assignment based on admin defined rules that include an attribute, operator, string value, and the resulting role assignment. They operate like security access control lists (ACLs) where rules are evaluated in order (top down). The first assignment rule that is matched is applied. Assignment rules may also be re-ordered at any time.

Role assignment rules are often implemented during migrations to HPE Aruba Networking by allowing role assignments to be made using the attribute value pairs (AVP) from existing RADIUS server policies that implement IETF or vendor specific attributes (VSA).

As an example, a third-party RADIUS server is configured with policies that return the IETF Filter-Id AVP that provides unique string values that can be used by the APs to assign a user defined role. Each condition in the UDR includes a match condition and user defined role assignment.

Assignment rules can also be used for dynamic role assignment for non-authenticated sessions. For example, assignment rules can be created to dynamically assign user defined roles based on MAC OUI or DHCP options. This can be useful if dynamic VLAN assignments or unique network access policies need to be applied to sets of headless devices that do not support 802.1X or for profiles that do not have 802.1X or MAC authentication enabled.

DHCP option-based rules are evaluated post authentication and are only applicable once a VLAN assignment has been made as the assignment rules operate by matching option fields exchanged in DHCP discover and request messages. DHCP optional-based rules are not applicable for profiles with Captive Portal enabled and should not be used to assign user defined roles that result in a VLAN assignment change.

RADIUS assigned

Clients connected to WLANs or downlink ports requiring MAC or 802.1X authentication can be directly assigned a user defined role from a RADIUS authentication server or Central NAC service that return the HPE Aruba Networking Aruba-User-Role vendor-specific AVP. Policies on the RADIUS authentication server or Central NAC service can be configured to directly return a user defined role name based on the authenticating device/user identity, user identity store attributes such as department, or other contextual conditions such as date or time, location, or posture.

APs performing MAC or 802.1X authentication will accept the Aruba-User-Role AVP from a RADIUS Server or Central NAC with no additional configuration being required. If the user defined role is present on the AP and no role assignment rule is matched, the role name provided by the Aruba-User-Role AVP is assigned.

A role assignment rule can be configured to use a specific role based on the received role name if required. For example, if the Aruba-User-Role is returned with the value Employees, a role assignment rule can be configured to match the received role name and apply a different role. This can be a useful tool for migrations and troubleshooting.

Assignment order

When multiple role assignment outcomes are possible for a client device or user identity, an assignment priority is followed by the AP. As a rule, a user defined role that is derived from a role assignment rule will take precedence over a user defined role received from the Aruba-User-Role AVP. If no user defined role is derived or the derived role does not exist on the AP, a default role is assigned.

User defined roles can also be dynamically assigned post authentication which is not captured in the above assignment flow. A user defined role change can occur as the result of a DHCP assignment rule during attachment or change of authorization (CoA) message received from a RADIUS authentication server or the Central NAC service. User defined roles assigned from a DHCP assignment rule or CoA will take precedence over a previously assigned default or user defined role post authentication.

For example, if an 802.1X client device is assigned a user role using the Aruba-User-Role AVP and a DHCP assignment rule is matched that assigns a different role, the role derived from the DHCP assignment rule will take precedence.

Policy enforcement

When bridge forwarding is selected in a profile, the APs operate as the sole policy enforcement point. The APs inspect all user traffic and can make forwarding and drop decisions based on each client device’s role assignment and the network access policies that are configured in each role.

Each AP has a deep packet inspection (DPI) capable firewall that can permit or deny traffic flows based on available information contained within IP headers. When application visibility or unified communications (UCC) is enabled, the APs can also identify applications and real-time application flows by leveraging deep packet inspection (DPI), application layer gateways (ALGs) and advanced heuristics.

Each AP is fully capable of inspecting traffic received from attached client devices and making a forward or drop decision based on the network access rules that are configured within each assigned role. All north / south and east / west traffic flows are inspected and can be acted on by the firewall. Client devices can either be assigned a default role or be dynamically assigned a user defined role. When dynamic role assignment is used, individual clients connected to a WLAN or downlink port can be assigned separate roles each with the necessary network access policies assigned.

Scaling considerations

When configuring user defined roles within an AP configuration group, scaling must be considered as each AP can only support a specific number of default and user defined roles which is dependent on the version of AOS-10 in use.

Each wired-port profile and WLAN profile includes a default role that counts against the maximum number of roles supported by the APs. This also includes the 2x default wired-port profiles that are present on each AP and cannot be removed.

To determine the number of user defined roles that can be configured in an AP group, you must subtract the total number of wired-port and WLAN profiles that are present on the AP from the maximum number of roles that are supported. For example, an AP running 10.6 that has a total of 6 wired-port + WLAN profiles configured in the group can support a total of 122 user defined roles (128 – 6 = 122).

4 - Tunnel forwarding

Please refer to the Forwarding Modes of Operation for a detailed overview of tunnel forwarding.

Supported role types

When mixed or tunnel forwarding mode is enabled in a profile, the gateway determines the role assignment. That role assignment is done at both the AP and the gateway:

• AP – A default or user defined role

• Gateway – A default, user defined, or global role.

Split role assignment

Tunneled clients can be assigned the same or different roles on the AP and gateway. A default role is assigned on both the AP and gateway if no role is dynamically assigned from an authentication server, Central NAC service, server derivation rule (SDR), or user derivation rule (UDR). Additionally, an AP will assign a default role to a tunneled client if a dynamically assigned role is not present on the AP. As global client roles are not supported by APs, an AP can only assign a default or user defined role to a tunneled client.

The following combinations of role assignments are supported for tunnel forwarding:

• Default role – Assigned on both APs and gateways if no dynamic role assignment is made.

• User defined role – Assigned on both APs and gateways if a dynamic role assignment is made and the role is present in both the AP and gateway configuration groups.

• Separate roles – A default role is assigned on the APs and a user defined or global role is assigned on the gateways.

Separate roles can only be assigned on the AP and gateway when a dynamically assigned role is not present on the AP. When a role is dynamically assigned to a tunneled client device or user identity that is not present on the AP, the gateway will assign the dynamically assigned role while the AP will assign the default role. For most deployments, the default role on the AP will only contain the default network access policy (allow all) while the user defined or global role on the gateway will contain more restrictive network access rules and attributes.

Role derivation and assignment

For mixed and tunnel forwarding, the gateway operates as the authenticator and makes the role assignment decision. When a client device attaches to an AP or a device/user identity is authenticated, a role is assigned on both the AP and the gateway.

Default role

A default role is created for every mixed or tunnel mode profile. The default role assignment for a profile can be viewed in the profile creation workflow when Role Based access is selected. The default assignment rule cannot currently be modified.

A default role is assigned to client devices or user identities when no role is dynamically assigned from a RADIUS authentication server, Central NAC service or derivation rule. They are also assigned if a dynamically assigned role is not present on the AP or gateway.

Assignment rules

User defined and global client roles can be dynamically assigned to client devices or user identities by creating role assignment rules. Gateways supports two types of role assignment rules:

• Server derivation rules (SDR) – Can assign roles based on rules that match IETF or vendor-specific RADIUS attributes and values that are returned from a RADIUS server or Central NAC service.

• User derivation rules (UDR) – Can assign roles based on rules that match MAC OUIs or DHCP options.

SDR and UDR assignment rules are optional and permit dynamic user defined role or global role assignment based on admin defined rules that include an attribute, operator, string value and the resulting role assignment. They operate like security access control lists (ACLs) where rules are evaluated in order (top down). The first assignment rule that is matched is applied. Assignment rules may also be re-ordered at any time.

Server derivation rules

SDR rules can be either configured within a profile creation workflow or directly within each gateway configuration group. They can be implemented for profiles that use MAC or 802.1X authentication.

SDR rules configured using a profile creation workflow are automatically orchestrated on the respective primary/secondary gateway cluster configuration groups. Each mixed or tunnel mode profile includes a corresponding authentication server group for the profile in the primary/secondary cluster gateway configuration groups. SDR rules configured in workflow are automatically added as server rules in the respective tunnel profile authentication server groups.

When both a primary and secondary gateway cluster are assigned to the profile, the server derivation rules should be managed directly in the mixed or tunnel mode profile. This ensures that the derivation rules are the same for each cluster by modifying the authentication server group configurations in both locations automatically. If SDR rules are defined directly within each gateway configuration group, additional care must be taken to ensure the rules are the same in both authentication server groups else unpredictable role assignments will occur.

User derivation rules

UDR rules are configured per gateway configuration group and can be used to dynamically assign user defined or global client roles to tunneled client devices based on MAC address or DHCP signatures. Each UDR ruleset can contain multiple rules that are evaluated in order (top-down). The first rule that is matched is applied.

UDR rules are configured per gateway configuration group by selecting Security > Advanced > Local User Derivation Rules. Each ruleset has a unique name and can contain multiple rules in order of priority. Existing rules can be re-ordered at any time by selecting a rule and moving it above or below another rule.

A ruleset must be assigned to an orchestrated AAA profile by selecting Security > Role Assignment (AAA Profiles). Each mixed or tunnel mode forwarding profile will have a corresponding AAA profile orchestrated on the applicable gateway configuration groups. Only one UDR ruleset can be applied per orchestrated AAA profile.

DHCP option-based rules are evaluated post authentication and are only applicable once a VLAN assignment has been made as DHCP assignment rules operate by matching option fields transmitted by client devices in DHCP discover and request messages. DHCP option based rules should not be used to assign user defined roles or global client roles that result in a VLAN assignment change and are not applicable for profiles with Captive Portal enabled.

RADIUS assigned

Clients connected to mixed or tunnel mode forwarding WLANs or downlink ports requiring MAC or 802.1X authentication can be directly assigned a user defined or global role from a RADIUS authentication server or Central NAC service configured to return the Aruba-User-Role AVP.

APs forward RADIUS access requests to their assigned designated device gateway (DDG) which is proxied to the configured external RADIUS server or the Central NAC service. The gateways will accept the Aruba-User-Role AVP from a RADIUS Server or Central NAC with no additional configuration being required in the profile. If the user defined role is present on the gateway, the role name supplied by the Aruba-User-Role AVP is assigned.

A role assignment rule can be configured to change the received role name if required. For example, if the Aruba-User-Role is returned with the value Employees, a role assignment rule can be configured to match the received role name and apply a different role name such as employee-role. This can be a useful tool for migrations and troubleshooting.

Assignment order

When multiple role assignment outcomes are possible for a client device or user identity, an assignment priority is followed by the gateway. As a rule, a user defined role received in the Aruba-User-Role AVP, or an SDR will take precedence over a user defined role assigned from a UDR. If no user defined role is derived or the derived role does not exist on the AP or gateway, a default role is assigned.

User defined roles can also be dynamically assigned post authentication which is not captured in the above assignment order. A user defined role change can occur as the result of a DHCP UDR assignment rule during attachment or change of authorization (CoA) message received from a RADIUS authentication server or the Central NAC service. User defined roles assigned from a DHCP UDR assignment rule or CoA will take precedence over a previously assigned default or user defined role post authentication.

For example, if an 802.1X client device is assigned a user role using the Aruba-User-Role AVP and a DHCP UDR assignment rule is matched that assigns a different role, the role derived from the DHCP assignment rule will take precedence.

Policy enforcement

When tunnel forwarding is enabled in a profile, the APs and gateways can both operate as policy enforcement points. Both can inspect user traffic and make forwarding and drop decisions based on the network access policies defined within each assigned role.

The network access policies included in the role assigned at the AP and gateway determines which device inspects the traffic and makes the drop or forwarding decision. For most tunneled deployments, the client device or user identity will be assigned a default role on the AP and a user defined role on the gateway. The default role on the AP includes a default allow-all rule that permits all traffic to be forwarded while the user defined role on the gateway includes more restrictive network access policies and provides enforcement.

For mixed forwarding, the enforcement point depends on the forwarding mode utilized for each client device or user identity.

Ultimately the network access policies assigned to the default and user defined roles determine if the AP, gateway, or both perform the packet inspection and enforcement. As a general recommendation, use the AP as the enforcement point for bridged forwarding and the gateway as the enforcement point for tunnel forwarding.

While the roles on both AP and gateway can each contain separate network access policies, this should be avoided as doing so will result in a more complex policy deployment model as the firewall functions are distributed between the two devices. If network access rules must be implemented on both AP and gateway for tunneled traffic, the less restrictive policies should be applied at the AP with the more restrictive or complex policies at the gateway.

5 - User-Based Tunneling

This section provides an overview of how user defined roles are implemented on AOS-10 gateways and AOS-CX access layer switches for User-Based Tunneling (UBT) deployments. This section covers the role types that are supported on gateways and switches and how the roles are configured and managed. This section also provides details for how roles are assigned and where network access permissions are enforced.

Role types

UBT deployments implement user defined roles on the access layer switches and gateways which are independently configured and managed by the administrator. The access layer switches may optionally implement downloadable user roles (DUR) from a ClearPass Policy Manager (CPPM) server if needed where user defined roles are dynamically downloaded and installed on the access layer switches upon successful authentication and authorization.

User defined roles

User defined roles are configured and named by the administrator and must be configured per gateway and switch configuration group. They may also be directly configured per access layer switches that are not managed by Central.

User defined roles are assigned to UBT client devices or user identities either by a RADIUS authentication server or Central NAC service. As theaccess layer switch is the authenticator, the user defined role cannot be assigned by gateways using role derivation rules.

The user defined role assigned on the access layer switch and gateway can be the same role name or a different role name. Each user defined role on the access layer switch that is used for UBT includes specific attributes that determines the cluster UBT traffic is tunneled to and the gateway role that is assigned.

As gateways and switches are often managed and configured by separate IT teams, the gateway role mapping allows for discrepancies between role names. For example, a VoIP phone can be assigned a user defined role named ip_phone on the access layer switch and a role named voip-role on the gateway. The same role name may also be assigned on both.

Role configuration and management

User defined roles must be configured and managed separately per gateway and switch configuration group. For access layer switches, UBT configuration, user defined roles and gateway mappings can be applied either using configuration templates or the MultiEdit configuration editor. For gateways, user defined roles, attributes, and network access permissions are configured per gateway configuration group using the Central UI.

Access layer switches

User defined roles can be added, removed, and configured directly per switch configuration group using either templates or the MultiEdit configuration editor. Template groups allow for configuration to be applied to all CX switches within a configuration group or different configurations to be applied to groups of switches based on model and version. The UBT zone configuration, user defined roles and gateway role mappings being defined in each respective template.

The MultiEdit configuration editor allows for configuration to be applied to multiple CX switches simultaneously or individual switches based on selection with the Central UI. The MultiEdit configuration editor allows for UBT zone configuration, user defined roles and gateway role mappings to be added, removed or modified by selecting one or more CX access layer switches, editing the configuration then adding the necessary CLI commands all within a single intuitive workflow within the Central UI. Syntax checking is provided within the workflow.

Gateways

User defined roles can be added, removed, and configured directly per gateway configuration group using the Central UI. The admin can configure network access permissions and attributes for existing roles or add, delete, and configure user defined roles.

For gateway configuration groups, default and user defined roles can be configured and managed under Security > Roles. The role table lists all the roles configured in the gateway configuration group which includes all the roles including predefined roles, default roles, user defined roles and global client roles.

Each role is configured by selecting a role in the table which displays an additional table that presents the network access policies and attributes that are assigned to the selected role. An example of role management within a gateway configuration group is depicted below. In this example a role named contractor-role is selected and the network access policies displayed.

Each user defined role on the gateway that is used for UBT must include a VLAN assignment which is defined as an attribute within each user defined role. Each role can be assigned a VLAN ID or VLAN Name defined within the configuration group using a dropdown selection within the More option for each role. The VLAN ID or VLAN Name must be configured and present within the configuration group.

An example of VLAN assignment for a user defined role named contractor-role a is depicted below. In this example UBT clients will be assigned to VLAN ID 82 within the cluster.

Role derivation and assignment

When User-Based Tunneling (UBT) is deployed, a user defined role configured on the access layer switch initiates the user based tunneling session to a cluster of gateways. For a typical deployment, the UBT ports are configured with MAC and/or 802.1X port-access security where each wired device (unique MAC) is authenticated against a RADIUS server or Central NAC service. Upon successful authentication, the RADIUS authentication server or Central NAC service returns the Aruba-User-Role AVP that determines the user defined role assignment.

Each user defined role used for UBT includes additional attributes that specifies a UBT zone and gateway role:

• UBT zone – References configuration within the access layer switch that determines the primary and optionally secondary cluster that traffic is tunneled to. Each role supports one zone assignment.

• Gateway role – Determines the role that is assigned on the gateway.

The user defined role assigned to the UBT client device or user identity must include both the UBT zone and gateway role attributes as they determine the primary or secondary cluster the traffic is tunneled to in addition to the role assigned within the cluster. The assigned role on the cluster determines the network access policies that are applied in addition to the VLAN assignment within the cluster.

When a wired client device or user identity is authenticated by the access layer switch and user defined role with UBT attributes is assigned, the traffic is tunneled to the respective primary or secondary cluster. Each UBT client is anchored to a user designated gateway (UDG) node within the cluster based on the published bucket map. The configured gateway role determines the user defined role that is assigned to the UBT session on the UDG in addition to the VLAN assignment. Each UBT session can be assigned the same role name on the access layer switch and UDG, or separate roles names if required.

Policy enforcement

For UBT, the access layer switches and gateways can both operate as policy enforcement points, however the traffic inspection capabilities of both devices are quite different. The access layer switches do not implement a stateful packet inspection firewall and only support stateless access control lists (ACLs) which can be applied to ingress or egress traffic. Gateways implement a deep packet inspection (DPI) firewall that is stateful and application aware. Traffic is inspected on ingress.

For most UBT deployments, the network access policies will be defined within the user defined roles on the gateways and all north / south and east / west traffic flows can be inspected and enforced by the gateways. Gateway enforcement also allows for the same user defined roles, network access policies and attributes to be applied to both wireless and UBT clients, but the different client types should be assigned separate VLANs.