Aruba Network Security Professional study materials
Aruba Network Security Professional study resources

Contractor VLAN Assignment Conflict

Aruba Network Security Professional · Put your knowledge to work in context.

All case studies

Contractor VLAN Assignment Conflict

A manufacturer uses Aruba CX switches with downloadable user roles via ClearPass. Contractors connect to wired ports in a lab. The enforcement profile assigns role 'contractor-lab' with an ACL permitting only 10.20.5.0/24. A new contractor laptop authenticates successfully via 802.1X (PEAP-MSCHAPv2) and Access Tracker shows the correct role returned. However, the laptop can reach the corporate file server at 10.20.9.15. Investigation shows the port is a member of a VLAN where a static 'permit any' ACL is applied at the SVI, and the switch is running an older AOS-CX firmware where downloadable role ACLs are applied as port ACLs. The contractor's traffic to 10.20.9.15 is permitted.

1. Explain why the contractor reached the file server despite the correct role being returned.

Read the worked answer

Role assignment succeeded, but enforcement is layered. The downloadable role ACL is applied as a port ACL (ingress on the contractor's port), while the SVI has a static 'permit any' ACL applied to all traffic in that VLAN. Port ACLs and VLAN/SVI ACLs are evaluated in sequence; if the SVI ACL permits and the port ACL does not explicitly deny the destination, traffic can pass depending on ACL direction and ordering. The core issue is that the role ACL permitted only 10.20.5.0/24 but did not include an explicit deny for everything else, and the SVI ACL overrode or supplemented it. Best practice: downloadable role ACLs should end with an implicit or explicit deny, and VLAN-level ACLs must not contradict role intent. Verify with 'show access-list' hit counters on both the port and SVI.

2. What configuration changes and validation steps would you recommend?

Read the worked answer

Changes: (1) Add an explicit 'deny any any' (or log-and-deny) at the end of the contractor role ACL. (2) Audit the SVI ACL so it does not blanket-permit traffic that role policy intends to restrict - scope it or remove it. (3) Consider upgrading AOS-CX firmware so role ACLs enforce at the intended point. Validation: clear ACL counters, generate test traffic from the contractor laptop to 10.20.9.15 and to an allowed 10.20.5.x host, and confirm permit/deny counters increment as expected. Confirm Access Tracker still shows the role and that re-authentication reapplies the role cleanly.