You must add a rule that lets a role reach a finance app on HTTPS but blocks everything else to RFC1918. In what order do the rules belong in the session ACL?

Correct: a. First match wins, so the specific finance permit must sit above the broad RFC1918 deny — otherwise the deny would also block the finance app (which is inside RFC1918). Option b blocks the finance app; c is false; d disables the whole policy.

After a ClearPass change, show user-table shows clients in the default logon role instead of FINANCE , even though auth succeeds. What is the most likely cause?

Correct: b. Auth succeeded (so it's not the cable or a down link), but the device fell back to its default role — classic sign the returned role attribute is wrong or the named role doesn't exist locally. Check the ClearPass Access Tracker to see exactly what was returned. MTU/PEF-disable are red herrings here.

A bank wants wired-camera traffic enforced at a single, auditable point and is fine with traffic flowing to a gateway. A hyperscale campus wants to avoid trombonning all wired traffic to a gateway. Which models fit?

Correct: c. Centralized UBT gives one place to write/audit policy (the gateway) — perfect for the bank's auditability need. Distributed VXLAN enforces on the switches and avoids hauling all traffic to a gateway — perfect for the hyperscale campus. The two models can even co-exist.

All UBT users on one switch suddenly drop to the default role at the same instant, while ClearPass logs still show successful authentications. What do you check FIRST?

Correct: d. Auth still works (ClearPass is fine), and the failure is simultaneous and switch-wide — that points squarely at the shared GRE tunnel to the gateway, not at individual clients or ClearPass. show ubt state shows tunnel + bootstrap status in one line. a/b/c are expensive non-fixes.

A team proposes deploying Dynamic Segmentation but skipping the PEF licence "to save money, since ClearPass already returns roles." Evaluate.

Correct: c. ClearPass is the decision-maker; PEF is the enforcer that sits in the data path on the gateway/AP. Without the firewall, a returned role is just a label with no teeth — the segmentation you "deployed" doesn't actually restrict traffic. The proposal misunderstands the split between policy decision and policy enforcement.

An auditor says "Dynamic Segmentation makes the network secure, so we can deprioritise patching the gateways and APs." Evaluate this claim against the 2024 ArubaOS advisories.

Correct: b. Segmentation is enforced by the gateway/AP — if that device is remotely compromised via the PAPI RCE chain, the attacker can rewrite or bypass the very policy you trust. Strong segmentation and disciplined patching are complementary, not substitutes. Always patch and restrict UDP/8211.

Aruba Dynamic Segmentation & PEF — Roles, Tunnels & Policy in 11 Minutes

Q: In Aruba Dynamic Segmentation, what decides which network resources a connected device can reach?

Correct: a. The whole point of Dynamic Segmentation is that the role — derived from identity/device type — carries the policy. The port is "colorless"; access follows the user, not the cable. Options b/c/d are the legacy port-centric thinking Dynamic Segmentation replaces.

Q: Priya writes a session ACL with user any any permit as line 1, then user alias hr-app any deny as line 2. HR-bound traffic still flows. Why?

Correct: b. Session ACLs are first-match. The broad permit on line 1 catches everything, including HR-bound packets, and evaluation stops there. Move the specific hr-app deny above the catch-all permit and the deny takes effect. This is PQ2 in action.

Q: Your campus has 280 ArubaOS-CX switches. Security asks you to add one new deny rule to the FINANCE role everywhere. Which approach makes that a single change?

Correct: a. That is the whole reason DUR exists — the role definition lives centrally in ClearPass and is downloaded to the device after authentication. Option b is the LUR pain DUR removes; c and d don't change the policy at all.

Q: In the centralized (UBT) model, on which device is the PEF firewall policy actually enforced for a tunneled wired client?

Correct: b. UBT (centralized) tunnels the client's traffic to the gateway, which creates the user entry and runs the PEF session ACL on the inner packet. ClearPass only chooses the role; it never inspects data-plane traffic. That single enforcement point is the appeal of the centralized model.

Identity / role (royal) Data path / tunnel (electric) Permitted / healthy (green) Watch-out / fallback (amber) Denied / broken (red)

① Dynamic Segmentation — the role follows the user

Picture a campus. A finance laptop, an IP camera, a printer, and a guest phone all plug into identical switchports. The old way: you hand-cut a VLAN and an ACL onto each port and pray nobody moves a cable. The Aruba way is Dynamic Segmentation: the device authenticates, gets a role, and that role decides what it can reach — on any port, wired or wireless.

The role is the unit of trust. PEF (the firewall) lives inside the role. ClearPass decides which role. And the traffic is either enforced right at the switch/AP or tunneled to a gateway. Memorise this one line: "Identity decides the role, the role carries the firewall, the firewall is enforced at the edge or in a tunnel."

Scenario · Sneha, L1, Infosys Pune

Sneha's manager keeps "fixing" access by re-cutting VLANs every time someone hot-desks. She enables Dynamic Segmentation: the finance role is defined once, ClearPass returns it on login, and now the same person gets the same access whether they sit in Pune or visit Bengaluru — no per-port edits. Her ticket queue drops by half.

Big picture — the cable is just a door; ClearPass hands out the badge (role), and the PEF firewall inside the role decides which destinations open.

🪪

User Role

tap to flip

The container of trust. It points at one or more session ACLs, a VLAN, bandwidth and captive-portal settings. Everything a client is allowed to do hangs off its role.

🔥

PEF

tap to flip

Policy Enforcement Firewall — Aruba's stateful, identity-aware firewall. The session ACLs inside a role ARE the PEF. Needs the PEFNG/PEF licence to enforce app-aware rules.

☁️

ClearPass

tap to flip

The brain. It authenticates (802.1X / MAC-auth), profiles the device, and returns the role name — or the whole role definition (DUR) — to the access device via RADIUS.

🎨

Colorless port

tap to flip

A switchport with no pre-assigned VLAN/role. After auth, the role+VLAN drop in dynamically. Any device on any port lands in the right segment — no per-port config.

Recap: role = unit of trust, PEF = the firewall inside the role, ClearPass = who picks the role, colorless port = any port works. PQ1 answered: no — when access is role-based, moving the laptop changes nothing; the role re-applies on the new port automatically.

Pause & Predict 1

A camera that can never run an 802.1X supplicant still needs a role. How does Dynamic Segmentation give it one?

MAC authentication. The switch sends the camera's MAC to ClearPass, which profiles it (OUI, DHCP fingerprint, behaviour) and returns an iot-camera role with a tight session ACL — camera → NVR only. No supplicant required. This agentless reach is exactly why role-based beats hand-cut VLANs for IoT.

Quick check · Q1 of 10

In Aruba Dynamic Segmentation, what decides which network resources a connected device can reach?

a) The user role assigned after authentication (and the PEF policy inside it) b) The physical switchport number the cable is plugged into c) The order the device was powered on d) Whichever VLAN has the lowest ID

Correct: a. The whole point of Dynamic Segmentation is that the role — derived from identity/device type — carries the policy. The port is "colorless"; access follows the user, not the cable. Options b/c/d are the legacy port-centric thinking Dynamic Segmentation replaces.

② The Policy Enforcement Firewall — session ACLs, first match wins

A PEF policy is just an ordered list of rules called a session ACL. You build it with ip access-list session, then attach it to a user-role. The golden rule: rules are evaluated top to bottom, and the first match terminates the search. So you put specific permits/denies at the top and the broad catch-all at the bottom.

Here's a finance role on an ArubaOS gateway. The source user means "this client's own IP," and alias finance-app is a netdestination object pointing at 10.50.20.0/24.

ArubaOS — build the PEF policy and attach it to a role

ip access-list session POL-FINANCE
  user alias finance-app svc-https permit
  user alias dns-servers svc-dns  permit
  user network 172.16.0.0 255.240.0.0 deny      # block all other RFC1918
  user any any permit                            # internet OK, last
!
user-role FINANCE
  access-list session POL-FINANCE
  vlan 120

Expected output — show rights FINANCE

Derivation Rules: implicit role

Role Entries:
 priority  position  src  dst            service    action
 ----      1         user finance-app    svc-https  permit
 ----      2         user dns-servers    svc-dns    permit
 ----      3         user 172.16.0.0/12  any        deny
 ----      4         user any            any        permit
Captive Portal profile: N/A    Bandwidth contract: N/A

Scenario · Rahul, L2, TCS Bengaluru

Rahul pastes a fresh user any any permit at the top of the role to "quickly test." Suddenly finance laptops can reach the HR subnet. The first-match engine hit his permit at position 1 and never read the deny below it. He moves it to the bottom — order restored. This is the single most common PEF mistake.

First-match flow — the packet stops at rule 1. A broad any any permit placed at the top would silently hide every deny beneath it.

The #1 PEF trap — rule order

Symptom you see: a role you carefully locked down suddenly lets traffic through that should be denied. Cause: a broad permit sits above your specific deny. First match wins, so the engine never reaches the deny. Always order specific → broad, and keep the catch-all user any any rule dead last.

Pause & Predict 2

Your colleague says "PEF is just like a router ACL." Predict the one big behavioural difference before reading on.

PEF is stateful and identity-aware; a router ACL is neither. PEF tracks the session, so the return traffic is allowed automatically — you don't write a mirror rule. It also matches on user (the authenticated identity) and on applications (App-aware), not just IP/port. A router ACL is stateless and IP-only.

Quick check · Q2 of 10

Priya writes a session ACL with user any any permit as line 1, then user alias hr-app any deny as line 2. HR-bound traffic still flows. Why?

a) PEF only enforces deny rules at reboot b) First match wins — line 1 (any any permit) matches first, so the deny on line 2 is never evaluated c) Deny rules require a separate licence d) The HR alias must be an IPv6 object

Correct: b. Session ACLs are first-match. The broad permit on line 1 catches everything, including HR-bound packets, and evaluation stops there. Move the specific hr-app deny above the catch-all permit and the deny takes effect. This is PQ2 in action.

③ ClearPass & Downloadable User Roles — define once, push everywhere

You can build a role two ways. A Local User Role (LUR) lives on the device — ClearPass just sends the name and the device already has the definition. A Downloadable User Role (DUR) is defined centrally in ClearPass; after auth, ClearPass pushes the whole definition down. Change it once, every device gets it.

ClearPass ships a special enforcement profile template — Aruba Downloadable Role Enforcement — that targets ArubaOS-Switch, Mobility Access Switch and the gateway/controller. It returns the role via VSAs such as Aruba-User-Role. For UBT users it can also carry Aruba-UBT-Gateway-Role.

▶ Watch a client get a Downloadable User Role

Click Play. Each stage lights up as the auth + role download happens.

① CONNECT Sneha's laptop plugs into a colorless port g1/0/14. No VLAN/role yet.

▼

② 802.1X Switch 10.10.10.2 relays EAP to ClearPass 10.50.30.10 over RADIUS.

▼

③ CLEARPASS Identity = sneha@infosys, AD group = Finance → ClearPass selects role FINANCE.

▼

④ ACCESS-ACCEPT VSA Aruba-User-Role = FINANCE + the downloadable role definition (PEF + VLAN 120).

▼

⑤ APPLY Switch installs role FINANCE on the port. Session ACL POL-FINANCE now active.

▼

⑥ ENFORCED Laptop reaches finance-app:443; HR subnet is denied. Role follows Sneha to any port.

Press Play to step through auth → role download → enforcement. Each press of Next advances one stage.

LUR vs DUR — the difference between editing a role on 300 switches by hand (amber) and editing it once in ClearPass and having it pushed everywhere (green).

Quick check · Q3 of 10

Your campus has 280 ArubaOS-CX switches. Security asks you to add one new deny rule to the FINANCE role everywhere. Which approach makes that a single change?

a) Define FINANCE as a Downloadable User Role in ClearPass — edit it once, it's pushed to every device on next auth b) SSH into all 280 switches and edit the Local User Role on each c) Reboot every switch so the rule auto-appears d) Change the VLAN ID on each port

Correct: a. That is the whole reason DUR exists — the role definition lives centrally in ClearPass and is downloaded to the device after authentication. Option b is the LUR pain DUR removes; c and d don't change the policy at all.

④ Tunnels, colorless ports & the troubleshooting playbook

Dynamic Segmentation has two enforcement models that can co-exist. Centralized uses user-based tunneling (UBT): the CX switch wraps the client's traffic in a GRE tunnel to an AOS 10 gateway cluster, which runs the PEF. Distributed keeps enforcement on the switches using an EVPN-VXLAN fabric and Group-Based Policy. Centralized = simpler policy, one place to look; distributed = no traffic "trombone" to the gateway, but more fabric to run.

AOS-CX — point a switch at the UBT gateway cluster (centralized)

ubt-client-vlan 4000
ubt zone HQ vrf default
  primary-controller ip 10.50.40.5
  backup-controller  ip 10.50.40.6
  sac-heartbeat-interval 1
!
port-access role TUNNEL-FINANCE
  gateway-zone zone HQ gateway-role FINANCE

Expected output — show ubt state

UBT Zone : HQ            VRF : default
 SAC     : 10.50.40.5    state : Registered
 UAC     : 10.50.40.6    state : Standby
 Tunnel  : GRE           status : up
 Bootstrap: complete     users : 42

Scenario · Karthik, network ops, HCL Noida

Karthik's UBT users all dropped to the default role at 2 a.m. show ubt state showed Tunnel: GRE status: down. The gateway's data interface had been marked untrusted after a config push, so the GRE tunnel never came up and the secondary (gateway) role never activated. He set the gateway port trusted, the tunnel registered, and roles re-applied. Lesson: when UBT roles vanish, check the tunnel before you touch ClearPass.

▶ UBT data path — client to gateway over GRE

Centralized enforcement: the switch tunnels the client, the gateway runs the PEF.

① CLIENT Finance laptop authenticated, assigned tunneled role on CX switch.

▼

② ENCAP Switch 10.10.10.2 wraps the frame in GRE → gateway 10.50.40.5.

▼

③ BOOTSTRAP Gateway creates the user entry, applies role FINANCE + VLAN sent by the switch.

▼

④ PEF On the gateway, session ACL POL-FINANCE evaluates the inner packet (first match).

▼

⑤ FORWARD Permitted → gateway de-encapsulates and forwards to finance-app. Denied → dropped centrally.

▼

⑥ RETURN Reply comes back through the same GRE tunnel — symmetric, stateful, enforced once.

Notice the firewall runs at the gateway, not the switch. That is what "centralized" means — one place to write and audit policy.

The diagnosis ladder — work top to bottom. Most "role not applied" tickets die at step 1 (wrong attribute) or step 4 (GRE tunnel down).

①

show user-table

tap

On the gateway/controller: shows each client's IP, MAC, and the role actually applied. If it says the default role, ClearPass returned the wrong thing.

②

show rights ROLE

tap

Dumps the role's session ACL in order. This is where you spot a broad permit shadowing a deny — the #1 PEF bug.

③

show ubt state

tap

On the CX switch: GRE tunnel status, SAC/UAC registration, bootstrap. down here = roles fall back to default.

④

show datapath session

tap

On the gateway: the live session table + which ACL action hit. Confirms whether PEF permitted or dropped a specific flow.

CLI — confirm the role a live client actually got

(gw-cluster) #show user-table | include 10.10.10.50

Expected output

IP             MAC                Name           Role      Age   Auth
-------------  -----------------  -------------  --------  ----  --------
10.10.10.50    a4:bb:6d:11:22:33  sneha          FINANCE   00:14 802.1x
10.10.10.61    00:1a:1e:aa:bb:cc  cam-lobby-3    IOT-CAM   01:02 MAC
10.10.10.77    f0:9f:c2:44:55:66  guest-7421     GUEST     00:03 captive

Common mistake — forgetting the security patch lane

Symptom you see: the segmentation works, but a pen-test flags your gateways/APs. Cause: unpatched ArubaOS exposed to the PAPI management protocol on UDP/8211. The 2024 advisory chain (CVE-2024-26305, CVE-2024-42509, CVE-2024-47460) let unauthenticated attackers run commands via crafted PAPI packets. Fix: patch ArubaOS, and block UDP/8211 from untrusted networks. Segmentation is only as trustworthy as the box enforcing it.

Pro tips that separate L1 from L2

1. Keep gateway clusters below ~50% load so failover is hitless; ~80% is the practical ceiling. 2. Start centralized (UBT) for simplicity; move to distributed VXLAN only when the traffic-trombone to the gateway hurts. 3. Use DUR so a role edit is one change, not 300. 4. Always end every session ACL with an explicit, intentional catch-all — don't rely on implicit behaviour you can't see in show rights.

Pause & Predict 3

A UBT switch loses its GRE tunnel to the gateway cluster. Predict what role the affected clients end up with.

They fall back to the local default / reject role on the switch — they do NOT keep the gateway-enforced role. The secondary (gateway) role only activates while the tunnel is up and bootstrap is complete. That's why UBT troubleshooting always starts at show ubt state: a down tunnel silently downgrades everyone. This is PQ3.

Quick check · Q4 of 10

In the centralized (UBT) model, on which device is the PEF firewall policy actually enforced for a tunneled wired client?

a) On the client laptop's local firewall b) On the AOS 10 gateway cluster at the far end of the GRE tunnel c) On the ClearPass server d) Nowhere — UBT disables the firewall

Correct: b. UBT (centralized) tunnels the client's traffic to the gateway, which creates the user entry and runs the PEF session ACL on the inner packet. ClearPass only chooses the role; it never inspects data-plane traffic. That single enforcement point is the appeal of the centralized model.

🤖 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 ubt state output into chat.techclick.in.

Make it stick — three 30-second moves

Self-explanation: In your own words (type it or say it out loud) — a laptop plugs into a colorless port. Walk through every step that chooses its role, then every step that enforces that role, and name which device does each. If you can do it without scrolling up, you own this lesson.

Teach a friend: Explain it to a junior in 30 seconds — "Aruba Dynamic Segmentation is a smart office building. The wall cable is just a door anyone can plug into. The security desk (ClearPass) checks your ID and hands you a colour-coded badge (the role). The badge has the rules baked in (PEF) — and the doors you can open depend on the badge, not the door you walked up to. Move desks, same badge, same access." Send that to one teammate today.

🔁 Spaced recall: drop your email and we'll resurface the 3 hardest questions from this lesson in 3 days — first-match rule order, LUR-vs-DUR, and the GRE-down fallback. Spaced recall is how this sticks past the interview.

✓ Locked in. We'll resurface the 3 hardest questions in 3 days.

📖 Glossary

Dynamic Segmentation: Assigning a role + policy based on who/what connects, then enforcing it at the edge or in a tunnel — access follows the user, not the cable.
User Role: The unit of trust on ArubaOS — points at session ACLs, a VLAN, bandwidth and captive-portal settings.
PEF (Policy Enforcement Firewall): Aruba's stateful, identity-aware firewall; the session ACLs inside a role are the PEF. Needs the PEFNG/PEF licence.
Session ACL: An ordered firewall policy built with ip access-list session; evaluated top-to-bottom, first match wins.
ClearPass: Aruba's AAA + policy engine — authenticates clients and returns the role to enforce.
DUR (Downloadable User Role): A role defined centrally in ClearPass and pushed to the device after auth via VSAs — edit once, apply everywhere.
LUR (Local User Role): A role defined on the device itself; ClearPass sends only the name.
UBT (User-Based Tunneling): The centralized model — a switch tunnels a client over GRE to an AOS 10 gateway cluster that runs the PEF.
Colorless port: A switchport with no pre-set VLAN/role; the role + VLAN drop in dynamically after authentication.
Gateway cluster: A group of AOS 10 gateways sharing client state; keep below ~50% load for hitless failover.

📚 Sources

HPE Aruba Networking — Policy Enforcement Firewall (PEF) product page & What is Dynamic Segmentation? glossary. arubanetworking.hpe.com / hpe.com
HPE Aruba TechDocs — ip access-list session (CLI Bank) and Configuring Firewall Policies (ArubaOS 8.x WebHelp). arubanetworking.hpe.com
HPE Aruba TechDocs — User-Based Tunneling (AOS 10 design) & Aruba Downloadable Role Enforcement Profile (ClearPass 6.11). arubanetworking.hpe.com
HPE Aruba — Validated Solution Guide: Policy Design & Segmentation Design (TME-updated 2025/2026; centralized UBT vs distributed EVPN-VXLAN, colorless ports, cluster sizing). arubanetworking.hpe.com/techdocs/VSG
Aruba Airheads Community — Tunneled-node / GRE tunnel troubleshooting threads (Wired Intelligent Edge & Wireless Access). community.arubanetworks.com
2024 ArubaOS Security Advisories — CVE-2024-26305 / -42509 / -47460 (PAPI UDP/8211 RCE chain). HPE support bulletins / BleepingComputer.
HPE/Aruba Certification — ACP-NS (HPE7-A02) Network Security & ACMP / ACCP blueprints (roles, firewall policies, Dynamic Segmentation, ClearPass).

What's next?

You can decide WHO gets in and WHAT they can reach. Next we make the Wi-Fi itself fast and seamless: how a client roams between APs without dropping a call, using 802.11r/k/v, OKC and AP clustering.

Lesson 7 · Aruba Mobility & Fast Roaming → ← Recap Architecture & Central

Aruba Dynamic Segmentation & PEF — Role Follows the User, Not the VLAN

Pick your path — jump straight to it

Roles & Segmentation

The PEF Firewall

ClearPass & DUR

Tunnels & Troubleshoot

① Dynamic Segmentation — the role follows the user

② The Policy Enforcement Firewall — session ACLs, first match wins

③ ClearPass & Downloadable User Roles — define once, push everywhere

▶ Watch a client get a Downloadable User Role

④ Tunnels, colorless ports & the troubleshooting playbook

▶ UBT data path — client to gateway over GRE

🤖 Ask the AI Tutor

📝 Wrap-up — six more

📖 Glossary

📚 Sources

What's next?