The mistake that costs every new Aruba engineer a day
Here's how it usually goes. Sneha, fresh onto the wireless team at Infosys, gets her first ticket: "Stand up a new Corp-WiFi SSID on the third floor." She opens Aruba Central, finds the SSID settings, types the name, sets a WPA3 password, hits save. The SSID appears. Laptops connect. She closes the ticket.
Two hours later: a flood of complaints. Everyone on Corp-WiFi can reach each other's machines, the finance VLAN, and the printers in another building. Sneha configured the radio. She never configured who the clients become once they join. That second half — the user role — is where real WLAN design lives.
This lesson fixes Sneha's mental model permanently. We'll stack the three profiles that make an SSID, pick the right WPA3 mode, then master the role-derivation order — the single most-tested, most-misunderstood topic on the wireless side of the HPE6-A85 blueprint.
① The Profile Stack — three profiles, one SSID
An Aruba SSID is never a single object. It's a stack. The top of the stack is the Virtual AP (VAP) profile. Think of the VAP as the assembly line: it points at one SSID profile and one AAA profile, and only then does the AP start beaconing.
By default a new VAP is wired to the default SSID, AAA, 802.11k and Hotspot profiles. You override the two that matter — SSID and AAA — and leave the rest alone until you need them.
The parent container. It binds one SSID profile + one AAA profile and is what an AP group actually advertises. No VAP = no SSID on air.
The radio half: essid name, opmode (WPA mode), band, SSID-hide, max-clients. Decides how the client encrypts — not who it is.
The identity half: initial role, default role per auth method, derivation rules, and the RADIUS server group. Decides who the client becomes.
A named bundle of firewall ACLs + VLAN + bandwidth contract. This is your real segmentation boundary — it follows the client across APs.
Here's the same stack as CLI. On a controller-managed AOS deployment the profiles are explicit objects you chain together; in Aruba Central the wizard hides the names but creates the identical objects underneath.
wlan ssid-profile "Corp-WiFi-ssid" essid "Corp-WiFi" opmode wpa3-aes-ccm-128 aaa profile "Corp-WiFi-aaa" initial-role "logon" authentication-dot1x "default" dot1x-default-role "corp" auth-server-group "CPPM-Servers" wlan virtual-ap "Corp-WiFi-vap" ssid-profile "Corp-WiFi-ssid" aaa-profile "Corp-WiFi-aaa" vlan 30
show wlan virtual-ap "Corp-WiFi-vap" Virtual AP profile "Corp-WiFi-vap" ---------------------------------- Parameter Value --------- ----- SSID Profile Corp-WiFi-ssid AAA Profile Corp-WiFi-aaa Virtual AP enable Enabled VLAN 30 Forward mode tunnel
dot1x-default-role to a locked-down corp role that denies client-to-client traffic. The radio never changed; the laptops never re-associated. Only the role flipped. Complaints stop.
A colleague says "just make a second SSID for the IoT cameras." You only need different authentication and a different VLAN — same encryption. Do you need a new SSID profile, a new AAA profile, or both?
essid) and a separate AAA profile (MAC-auth instead of 802.1X, different default role). The VLAN lives on the VAP. One thing you should not do: pile a 5th and 6th SSID onto every radio — each beacon costs airtime.In ArubaOS, which profile object does an access point actually advertise on its radio to put an SSID on the air?
② WPA3, Enterprise modes & Enhanced Open
The opmode line in the SSID profile is your encryption decision. Get it wrong and you either lock out half your clients or leave the door cracked. Aruba gives you a precise set of keywords — here are the four you'll actually type.
WPA3-Personal. SAE replaces the WPA2 PSK handshake. Same one password, but un-crackable offline. Needs a pre-shared key.
WPA3-Enterprise, widest compat. 128-bit; with transition mode it still admits WPA2-Enterprise clients. The everyday corporate 802.1X choice.
WPA3-Enterprise, GCMP-256. Admits only WPA3 clients that support GCMP-256. Step toward CNSA (192-bit) for high-assurance / government.
Enhanced Open / OWE (RFC 8110). Open guest Wi-Fi, no password — but every client gets per-session encryption. Replaces naked open SSIDs.
The transition-mode trap
To support old laptops, engineers flip on transition mode: one SSID advertises both WPA2-PSK and WPA3-SAE. Everyone connects — and that's the problem. An attacker forces the weak WPA2 path, captures the 4-way handshake, and cracks your PSK offline with Hashcat. WPA3's protection is bypassed by the very fallback you enabled. Worse, PMF is only optional in transition mode.
▶ Watch a client join and earn its role
Click Play. Each stage lights up as the client moves from radio association through WPA3 to a final user role.
You switched the SSID from WPA2 straight to wpa3-aes-gcm-256 or pure wpa3-sae-aes with transition mode off. Cause: legacy phones, printers and IoT that only speak WPA2 (or can't do GCMP-256 / PMF-required) silently fail to associate. Fix: either run a short transition window with a cutover date, or carve those devices onto a separate WPA3-Personal or dedicated IoT SSID rather than forcing the strictest cipher on everyone.
A cafe wants guest Wi-Fi with no password but still wants each customer's traffic encrypted over the air. Which Aruba opmode is correct?
open sends everything in clear text. SAE and CNSA both require a credential, so they can't be "passwordless" guest Wi-Fi.③ User Roles & the 5-level derivation order
Authentication answers "are you allowed in?" A role answers "now that you're in, what can you touch?" On Aruba a client can be assigned a role from up to five different sources at once — and they don't all carry equal weight. This precedence order is the single most-tested wireless concept, and the one that wastes the most production hours.
From lowest to highest precedence: initial role → user-derived role → default role (per auth method) → server-derived role → VSA-derived role. The higher one always overrides the lower one. So an Aruba VSA from RADIUS beats everything you configured locally.
dot1x-default-role corp and swears it's right — yet contractors keep landing in a wide-open role. The cause: ClearPass returns an Aruba-User-Role VSA for the contractor group. That VSA (rung 5) beats his local default (rung 3). His CLI was never wrong; the override lived on the RADIUS side. He fixes it in ClearPass, not on the controller.
A user-derived rule matches an IoT camera by MAC OUI and assigns role iot-locked. The same camera then passes MAC-auth, whose default role is iot-open. Which role does the camera end up in?
iot-open — the default role wins. User-derived roles (rung 2) are applied before authentication; the per-method default role (rung 3) is applied on successful auth and sits higher on the ladder. So once MAC-auth succeeds, its default role overrides the earlier user-derived role. If you wanted iot-locked to stick, you'd return it as a server rule or VSA instead.The initial (logon) role — don't leave it open
Before 802.1X finishes, the client lives in the initial role (commonly named logon). A client whose auth fails or stalls stays there. If that role is permissive, a failing device can still reach the LAN — a quiet but real hole. Lock the initial role to DHCP, DNS and the RADIUS path only.
show user-table mac a4:83:e7:11:22:33
IP MAC Name Role Age Auth Profile ---------- ----------------- ------ ---- --- ---- ------- 10.30.0.57 a4:83:e7:11:22:33 rahul.k corp 00:03 802.1x Corp-WiFi-aaa Role derived from: VSA (Aruba-User-Role) VLAN: 30 ACL: corp-acl
That one line ends 80% of role arguments. It tells you whether the role came from a VSA, a server rule, the method default, a user-derived rule, or the initial role. If it says VSA and you didn't expect one, your fix is on RADIUS/ClearPass — not the SSID, not the VAP, not the controller config you've been staring at.
A client gets a server-derived role of staff AND an Aruba VSA returning admin in the same Access-Accept. Which role is applied?
④ Troubleshoot — "auth passed but no internet"
The most common wireless ticket isn't "can't connect" — it's "connected, authenticated, but nothing works." Almost always it's a role or VLAN problem, not an auth problem. Here's the 4-rung ladder.
show user-table mac <mac>. Confirm the role + VLAN actually applied, and read the "Role derived from" line. This finds the wrong-role bug instantly.
Dump the ACLs the role enforces. A client stuck with no internet often has a role whose firewall policy permits DHCP/DNS but denies the rest.
Right role, wrong VLAN? The VSA or server rule may push a VLAN your upstream switch trunk doesn't carry. Verify the VLAN exists end-to-end.
Live auth trace for one MAC. Shows the full 802.1X exchange and exactly which RADIUS attribute/VSA came back. The ground truth.
show user-table and sees the role never moves past logon. The captive-portal role that should follow login was never returned — ClearPass needed valid credentials on the first attempt to hand back the post-portal role. The radio, the SSID profile, the WPA mode: all fine. The fix lived entirely in the role-return logic, which she'll wire up properly in the ClearPass lesson next.
The CVE you should know this month
Keep firmware current. In late 2025 HPE disclosed CVE-2025-37165 (CVSS 7.5) — an unauthenticated VLAN-configuration information-disclosure on Aruba APs in router mode — alongside CVE-2025-37166, a crafted-packet DoS that can wedge an AP until a hardware reset. Both are fixed in the patched AP firmware HPE pushed in December 2025. There's also a critical AOS-CX auth-bypass (CVE-2026-23813, CVSS 9.1) on the switching side. WLAN design is wasted if the platform under it is exploitable — patch, then design.
The whole lifecycle on one timeline
Zoom out. Every concept in this lesson maps onto one client's life — from beacon to forwarded traffic. Keep this timeline as your cheat-sheet: when a ticket lands, you know exactly which stage owns the symptom.
A user reports "Wi-Fi shows connected and authenticated, but no app works." Using the timeline above, is this an auth problem or a role/VLAN problem — and which side of the orange dot do you investigate?
show user-table mac <mac> to read the applied role and VLAN, then show rights <role>. Don't waste time re-checking the password or RADIUS reachability — those are left of the dot.A user complains: "Wi-Fi connects, shows authenticated, but no website loads." Which single command tells you the role and VLAN the client actually received, and how the role was derived?
show user-table mac <mac> shows the live client's applied role, VLAN, auth method, and the all-important "Role derived from" line. show ap database lists APs, show wlan ssid-profile shows static config, and show running-config is a haystack — none tell you what role a specific live client got.🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from HPE Aruba TechDocs + Airheads community Q&A. For complex prod issues, paste your show user-table + show auth-tracebuf output into chat.techclick.in.
📝 Wrap-up — six more
You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 Explain it back (60 seconds)
In your own words: a teammate says "the SSID profile and the AAA profile do the same thing." Type the one-line correction you'd give them — then imagine saying it out loud to a friend. Teaching it is how it sticks.
📬 Lock it in — get a 3-day recall nudge
We'll email you 3 quick recall questions on this lesson in 3 days. Spaced repetition is the cheapest way to turn "I read it" into "I know it."
📖 Glossary — the terms that show up in tickets
- VAP
- Virtual AP profile — the broadcast container that ties an SSID profile to an AAA profile. One VAP = one SSID on air.
- SSID profile
- The radio/encryption half:
essid,opmode(WPA mode), band, hide, max-clients. - AAA profile
- The identity half: initial role, default roles per auth method, derivation rules, RADIUS server group.
- User role
- A named bundle of firewall ACLs + VLAN + bandwidth applied to a client after it connects. Your real segmentation boundary.
- SAE
- Simultaneous Authentication of Equals — WPA3-Personal's password handshake; resists offline cracking.
- OWE
- Opportunistic Wireless Encryption (RFC 8110) — encrypts open Wi-Fi with no password. Aruba opmode
enhanced-open. - PMF
- Protected Management Frames (802.11w) — blocks deauth/disassoc spoofing. Mandatory in WPA3, optional in transition mode.
- VSA
- Vendor-Specific Attribute — Aruba-User-Role is the famous one; a role it returns beats every locally configured role.
- Transition mode
- One SSID advertising both WPA2 and WPA3 for compatibility — convenient, but opens an offline-cracking path.
📚 Sources
- HPE Aruba Networking TechDocs — Virtual AP Profiles & Configuring WLAN Properties on AOS-10 APs. arubanetworking.hpe.com
- HPE Aruba Networking TechDocs — wlan ssid-profile (opmode keywords) & Configuring WPA3 Encryption. arubanetworking.hpe.com / CLI-Bank
- HPE Aruba Networking TechDocs — User Roles & Assigning User Roles (derivation precedence). arubanetworking.hpe.com (AOS 8.x & Central)
- HPE Aruba Networking — WPA3 and Enhanced Open 101 Technical Note + #ArubaAirheads WPA3/OWE TechTalk Live.
- TrustedSec — The Dangers of Transition Mode (WPA3 downgrade / PMF-optional risk). trustedsec.com
- Airheads Community — Guests stuck in logon role & 802.1x to captive portal threads. community.arubanetworks.com
- HPE Security Advisory — CVE-2025-37165 / CVE-2025-37166 (Aruba AP info-disclosure + DoS) and CSA advisory CVE-2026-23813 (AOS-CX auth bypass).
- HPE Certification — HPE6-A85 ACA Campus Access exam blueprint (WLAN domain ≈ 18%).
What's next?
You've seen how a VSA from RADIUS quietly overrides every local role. Next we open the box that sends that VSA — ClearPass Policy Manager: RADIUS service flow, role-mapping and enforcement policies, device posture and OnGuard health checks, and exactly why guests get "stuck in the logon role."