Blog

Every packet a wireless client sends through an Aruba controller is checked against the client’s user role. The role is the unit of policy on the platform: it decides what a client may reach, how fast, at what QoS priority, and in which VLAN. This post takes the role apart — the stateful firewall behind it, the ACL language, how a client ends up in a particular role, and how ClearPass drives roles dynamically.

The Policy Enforcement Firewall

The Policy Enforcement Firewall (PEF) is a stateful firewall built into every controller’s datapath. Unlike a perimeter firewall that filters by interface and subnet, PEF knows which user owns each flow, because the controller authenticated that user. Every user — wireless, tunnelled wired, or on an untrusted controller port — appears in the user table with a MAC address, IP address(es), username, role, VLAN and AP.

Full PEF functionality (custom roles and policies, AppRF application rules) requires the PEF licence described in Part 2. Without it, the controller can only use predefined roles.

Because PEF is stateful, policy is written from the client’s point of view. A rule permitting user to any on HTTPS automatically permits the return traffic; there is no need for mirrored inbound rules. Inbound flows initiated from the network toward a client must be permitted explicitly in the client’s role (for example, a help-desk subnet reaching laptops for remote support).

Anatomy of a User Role

A user role bundles policy and attributes:

user-role employee
    access-list session ALLOW-DHCP-DNS
    access-list session EMPLOYEE-ACL
    vlan 20                              ! optional: override the VAP's VLAN
    bw-contract EMP-50M per-user downstream
    qos-profile EMPLOYEE-QOS
    reauthentication-interval 1440
    max-sessions 4096

Predefined roles exist and are referenced by default profiles: logon (the default initial role), authenticated, guest, guest-logon, voice, denyall and system roles used by APs. Treat them as read-only references and create named roles for real policy.

Session ACL Syntax

A session ACL line has four mandatory fields and optional extended actions:

<source>  <destination>  <service>  <action>  [extended actions]

Aliases

Aliases make ACLs readable and maintainable. A netdestination is a named set of hosts, networks and ranges; a netservice is a named protocol/port set. Many service aliases are predefined (svc-dhcp, svc-dns, svc-http, svc-https, svc-ssh, svc-icmp, svc-ntp, svc-sip-udp…).

netdestination INTERNAL
    network 10.0.0.0 255.0.0.0
    network 172.16.0.0 255.240.0.0
    network 192.168.0.0 255.255.0.0
!
netdestination DC-SERVERS
    network 10.1.0.0 255.255.0.0
!
netdestination PRINTERS
    range 10.30.0.10 10.30.0.60
!
netservice svc-rdp tcp 3389
netservice svc-ipp tcp 631

Example Policies

! Shared building block: every role needs DHCP and DNS
ip access-list session ALLOW-DHCP-DNS
    user any svc-dhcp permit
    user any svc-dns permit

! Employees: anything internal and the internet, but no RDP into the DC from Wi-Fi
ip access-list session EMPLOYEE-ACL
    user alias DC-SERVERS svc-rdp deny log
    user any any permit

! Contractors: web to the internet, one application server, printers; nothing else internal
ip access-list session CONTRACTOR-ACL
    user host 10.1.20.15 svc-https permit
    user alias PRINTERS svc-ipp permit
    user alias INTERNAL any deny
    user any svc-http permit
    user any svc-https permit

! Voice: prioritize SIP and RTP, mark DSCP EF for media
ip access-list session VOICE-ACL
    user any svc-sip-udp permit queue high tos 24
    user any udp 16384 32767 permit queue high tos 46 disable-scanning
    user alias INTERNAL any deny

! Quarantine: only remediation servers
ip access-list session QUARANTINE-ACL
    user host 10.1.5.20 svc-https permit
    user any any deny log
!
user-role contractor
    access-list session ALLOW-DHCP-DNS
    access-list session CONTRACTOR-ACL
!
user-role quarantine
    access-list session ALLOW-DHCP-DNS
    access-list session QUARANTINE-ACL
    reauthentication-interval 30

Rules are evaluated top to bottom across all ACLs in the role, in the order the ACLs were added, and the first match wins. An implicit deny ends every role. The ordering of the ACLs in the role therefore matters as much as the ordering of lines inside each ACL — a permissive ACL listed first shadows everything after it.

Global Rules and the validuser ACL

Two special policies affect every user:

• Global rules (the global session ACL, edited in the WebUI under Roles & Policies › Global Rules) are evaluated before any role’s own ACLs. They are the place for organization-wide blocks — for example, denying known-malicious destinations for everyone.
• The validuser ACL defines which source addresses may be learned as legitimate user IPs. Denying, for instance, 169.254.0.0/16 (link-local) there stops clients with self-assigned addresses from being entered into the user table — a simple anti-spoofing measure.

Application Awareness: AppRF and Web Content Classification

With deep packet inspection enabled and a PEF licence, ACLs can match applications and application categories rather than ports — useful because most modern applications all look like HTTPS on TCP 443:

ip access-list session GUEST-APPS
    user any appcategory peer-to-peer deny
    user any app bittorrent deny
    user any any permit
!
aaa bandwidth-contract VIDEO-2M mbits 2
!
user-role GUEST
    access-list session GUEST-APPS
    bw-contract appcategory streaming VIDEO-2M downstream

Web Content Classification (WebCC, a subscription) adds URL categories and reputation scores (web-cc-category, web-cc-reputation) so a role can block, for example, high-risk sites. AppRF dashboards on the Conductor show which applications each role is actually using — often the most useful input for writing realistic policy in the first place.

Bandwidth Contracts

aaa bandwidth-contract EMP-50M mbits 50
aaa bandwidth-contract GUEST-ROLE-200M mbits 200
!
user-role employee
    bw-contract EMP-50M per-user downstream       ! each employee individually
user-role GUEST
    bw-contract GUEST-ROLE-200M upstream          ! without per-user: shared by all guests in the role

The difference between per-user and a shared contract is easy to miss and matters: 200 Mbps shared by every guest behaves very differently from 200 Mbps each.

How a Client Gets Its Role

A client’s role is decided in stages. Each stage that applies to the WLAN replaces the role assigned by the stage before it:

1. Initial role — from the AAA profile (initial-role); the client holds it from association until authentication completes. For a PSK or open WLAN without further authentication, it is the final role.
2. User-derivation rules (UDR) — rules evaluated on attributes known before authentication: MAC address or OUI, ESSID, BSSID, encryption type, DHCP options (including DHCP fingerprints). Useful for classifying devices that cannot authenticate.
3. MAC authentication — the MAC-auth default role, or a role returned by the server for the MAC-auth request.
4. 802.1X — the 802.1X default role, or the server-derived role.
5. Layer 3 authentication — the captive portal’s default role (or server-derived role) after a web login.

Within a stage, a server-derived role always beats the default role. And at any time, a RADIUS Change of Authorization can replace the role in place.

User-Derivation Rules

aaa derivation-rules user DEVICE-UDR
    set role condition macaddr starts-with "00:1b:4f" set-value phones
    set role condition dhcp-option starts-with "370103060f77fc" set-value macos-devices
    set vlan condition essid equals "Corp-IoT" set-value 41
!
aaa profile IOT-AAA
    user-derivation-rules DEVICE-UDR

UDRs are a lightweight form of device classification on the controller. Matching on OUI is trivially spoofable, so UDR-assigned roles should grant little more than a default role would. For real device profiling, ClearPass is the better tool.

Server-Derived Roles

The RADIUS server can tell the controller which role to apply in three ways:

1. Aruba VSA — the Access-Accept carries Aruba-User-Role (Aruba vendor ID 14823, attribute 1) containing the role name. The simplest and most common method with ClearPass.
2. Server-derivation rules — rules in the server group map any returned attribute to a role. This is how standard RADIUS servers (Windows NPS, FreeRADIUS) or LDAP group membership drive Aruba roles without Aruba-specific attributes:

   aaa server-group CORP-SG
       auth-server CPPM1
       auth-server CPPM2
       set role condition Filter-Id equals "staff" set-value employee
       set role condition Filter-Id equals "contractors" set-value contractor
       set vlan condition Class contains "engineering" set-value 30

3. Downloadable user role (DUR) — ClearPass returns not just a role name but the role definition itself, which the controller downloads over HTTPS and installs dynamically. Policy then lives entirely in ClearPass. DUR requires the controller to trust ClearPass’s HTTPS certificate (its issuing CA installed as a trusted CA on the controller), ClearPass API credentials on the RADIUS server profile, and download-role enabled in the AAA profile.

The most common role problem on an Aruba network: ClearPass returns a role name that does not exist on the controller (a typo, different capitalization, or the role was created at a different node of the Conductor hierarchy). The controller cannot apply a non-existent role and falls back to the default role for that authentication method — the user connects but gets the wrong access, and nothing obviously fails. show user-table and show auth-tracebuf reveal the mismatch.

How a Client Gets Its VLAN

VLAN assignment follows a similar layered logic — the more specific and later source wins:

1. The VAP’s default VLAN (or VLAN pool).
2. A VLAN from a user-derivation rule.
3. A VLAN configured in the role the client is placed in (for example, the 802.1X default role).
4. A VLAN derived from the RADIUS response — through a server-derivation rule, the Aruba-User-Vlan (numeric) or Aruba-Named-User-Vlan (name) VSAs, or the standard IETF tunnel attributes (Tunnel-Type = VLAN, Tunnel-Medium-Type = 802, Tunnel-Private-Group-ID = VLAN ID).

A server-supplied VLAN therefore beats anything configured locally. In practice, most Aruba designs use few VLANs and differentiate users by role; VLAN steering is reserved for cases where the wired network must also see the separation (for example, a separate VRF for contractors).

Change of Authorization (CoA)

RADIUS is normally request/response: the controller asks, the server answers. Dynamic Authorization (RFC 3576, updated by RFC 5176) lets the server send an unsolicited CoA-Request (change the user’s role or attributes) or Disconnect-Request (kick the user off) to the controller on UDP 3799. This makes policy dynamic: a device that fails a posture check minutes after connecting, or whose profile changes from “unknown” to “IP camera”, can be moved to a different role without the user doing anything.

aaa rfc-3576-server 10.1.1.51
    key R4diusS3cret!
aaa rfc-3576-server 10.1.1.52
    key R4diusS3cret!
!
aaa profile CORP-AAA
    rfc-3576-server 10.1.1.51
    rfc-3576-server 10.1.1.52

In a controller cluster, CoA must reach the controller that currently anchors the user (the UAC); the cluster’s per-controller VRRP addresses exist precisely for this, as Part 6 explains.

MAC Authentication and MAC Caching

Devices that cannot run 802.1X can be authenticated by MAC address — the controller sends a RADIUS request with the MAC address as username and password. MAC auth is not strong security (MAC addresses are easy to spoof) but it is a useful classifier, especially combined with ClearPass profiling.

A common guest pattern combines MAC auth with a captive portal: the first visit goes through the portal, ClearPass records the device’s MAC as registered, and subsequent visits pass MAC authentication silently and go straight to the guest role (“MAC caching”):

aaa authentication mac GUEST-MAC
!
aaa profile GUEST-AAA
    initial-role GUEST-LOGON            ! portal role if MAC auth fails
    authentication-mac GUEST-MAC
    mac-server-group CORP-SG
    mac-default-role GUEST              ! returning, known devices skip the portal
    l2-auth-fail-through                ! continue to L3 (portal) if MAC auth fails

Integrating ClearPass Policy Manager

On ClearPass

1. Network devices — add every controller (or its RADIUS source address) with vendor Aruba, the shared secret, and CoA enabled on port 3799.
2. Authentication sources — join Active Directory (or add LDAP, SQL, a local database).
3. Service — for example from the 802.1X Wireless template: match on the SSID (the controller sends Aruba-Essid-Name) and NAS type, select allowed EAP methods and the authentication source.
4. Role mapping — map AD groups, device profiles, time of day and other conditions to ClearPass roles (internal labels).
5. Enforcement policy — map ClearPass roles to enforcement profiles; an Aruba RADIUS Enforcement profile returns Aruba-User-Role = employee, while an Aruba Downloadable Role profile returns a full role definition.
6. Profiling — have the default gateway relay DHCP to ClearPass as well as to the DHCP server (an extra ip helper-address), so ClearPass sees DHCP fingerprints and can classify devices; the controller can also forward device information when device-type classification is enabled in the AAA profile.

On the Controller

1. RADIUS servers, server group and AAA profile as built in Part 4, plus accounting and the RFC 3576 servers above.
2. Every role name ClearPass might return must exist (unless using downloadable roles).
3. For downloadable roles: the ClearPass CA certificate installed as a trusted CA, API credentials on the RADIUS server profile, download-role in the AAA profile.
4. For an external guest portal, a captive portal profile pointing at ClearPass Guest, with ClearPass allowed in the pre-authentication role:

   netdestination CPPM
       host 10.1.1.51
       host 10.1.1.52
   !
   aaa authentication captive-portal CPPM-GUEST-CP
       login-page https://cppm.corp.example/guest/guest_login.php
       white-list CPPM
       server-group CORP-SG
       default-role GUEST
   !
   user-role GUEST-LOGON
       captive-portal CPPM-GUEST-CP
       access-list session logon-control
       access-list session captiveportal

Verifying Roles and Policy

(HQ-MC1) #show user-table                         ! all users: IP, MAC, name, role, VLAN, AP, auth method
(HQ-MC1) #show user-table verbose                 ! adds derivation details and more columns
(HQ-MC1) #show user ip 10.20.0.55                 ! one user, everything the controller knows
(HQ-MC1) #show rights employee                    ! the role's effective ACLs, contracts and attributes
(HQ-MC1) #show datapath session table 10.20.0.55  ! live firewall sessions and the action applied
(HQ-MC1) #show acl hits                           ! hit counters per ACL line
(HQ-MC1) #show auth-tracebuf mac 3c:22:fb:11:22:33 count 50   ! authentication exchange, step by step
(HQ-MC1) #aaa user delete mac 3c:22:fb:11:22:33   ! force the client to re-authenticate

Reading show datapath session table output is a core skill: each line is one flow, with flags indicating whether it was permitted, denied, NATed or redirected. When a user says “application X does not work”, finding the user’s IP, opening this table while they retry, and looking for flows marked as denied pinpoints the rule responsible in seconds.

Design Guidance

• Design roles around people and device classes (employee, contractor, guest, voice, printer, camera, quarantine), not around SSIDs or VLANs.
• Keep a small set of reusable ACLs (DHCP/DNS, deny-internal, web-only) and compose roles from them.
• Put organization-wide blocks in global rules, not in every role.
• Prefer server-derived roles over default roles; make the default role for each method deliberately restrictive so that a policy failure fails safe.
• Name roles identically on ClearPass and on the controller and define them high enough in the Conductor hierarchy that every controller has them — or use downloadable roles and remove the problem entirely.
• Use max-sessions and blacklist actions to contain misbehaving clients automatically.
• Enable accounting and CoA so ClearPass can see sessions and change them.

Exercises

1. A role has two ACLs, added in this order: ALLOW-ALL (user any any permit) and BLOCK-SSH (user any svc-ssh deny). Can users in this role SSH to servers? How should it be fixed?

2. ClearPass’s Access Tracker shows a successful authentication returning Aruba-User-Role = Contractor, but on the controller the user appears in the authenticated role. What happened?

3. Write an ACL for a “printer” role: printers may receive IPP (TCP 631) and raw printing (TCP 9100) from the employee subnet 10.20.0.0/16, may reach the print server 10.1.30.5 on any port, and nothing else. Remember the direction of stateful rules.

netdestination EMP-NETS
    network 10.20.0.0 255.255.0.0
netservice svc-ipp tcp 631
netservice svc-raw-print tcp 9100
!
ip access-list session PRINTER-ACL
    user any svc-dhcp permit
    user any svc-dns permit
    alias EMP-NETS user svc-ipp permit
    alias EMP-NETS user svc-raw-print permit
    user host 10.1.30.5 any permit
    user any any deny
!
user-role printer
    access-list session PRINTER-ACL

4. A laptop authenticates via 802.1X and receives the employee role. Ten minutes later its endpoint agent reports disabled antivirus to ClearPass. Describe what should happen next, end to end, and which controller configuration makes it possible.

5. A network uses Windows NPS instead of ClearPass. How can members of the AD group “Finance” receive the finance role and VLAN 50 without any Aruba-specific attributes on NPS?

Summary

The user role is the unit of policy on an Aruba network. It carries stateful session ACLs — evaluated first-match, top to bottom across the role’s ACLs, after global rules — plus VLAN, bandwidth contracts, QoS and other attributes. A client’s role is derived in stages (initial role, UDR, MAC auth, 802.1X, captive portal), with server-derived roles beating defaults and CoA able to change the role at any time. RADIUS servers drive roles through the Aruba-User-Role VSA, server-derivation rules on standard attributes, or downloadable roles from ClearPass. ClearPass decides and the controller enforces; the integration needs matching role names (or DUR), accounting, CoA and profiling data.

Next: Part 6 makes all of this highly available — controller clustering with AP and user anchor controllers, hitless failover, roaming, and Live Upgrade.