I85PREP
⌘ K
Aruba Campus Access Architect (HPE7-A11) study materials
Aruba Campus Access Architect (HPE7-A11) study resources

Guest Wi-Fi Bleeding Into Clinical VLANs

Aruba Campus Access Architect (HPE7-A11) · Put your knowledge to work in context.

All case studies

Guest Wi-Fi Bleeding Into Clinical VLANs

A regional clinic rolled out a new guest SSID and a new clinical-device SSID in the same week. Within days, the security team reports that a guest laptop received an address in the clinical server subnet and could reach a medical imaging server on TCP 104. The guest SSID is tunneled to a controller; the clinical SSID is bridged locally at the access point. Both SSIDs use the same RADIUS server for authentication, and the guest SSID uses a captive portal with MAC caching. The clinic has 40 access points across 6 floors and no change-control records for the rollout.

1. Describe a structured troubleshooting path to find the root cause, and name the most likely failure classes.

Read the worked answer

Work from the symptom backward, in layers, and do not change anything until you have captured current state.

Capture first:

  • Client MAC, IP, subnet mask, gateway, and the SSID/VLAN it believes it is on.
  • Controller/AP association records for that client, including the VLAN or tunnel assignment actually applied.
  • DHCP server lease record and which relay/interface delivered it.
  • ARP and MAC tables on the gateway for the clinical server subnet.

Troubleshooting sequence:

  1. Client layer: Confirm the client is on the guest SSID and not silently falling back to another profile.
  2. Policy layer: Check the role/VLAN assignment the controller or AP applied. A guest role mapping to the clinical VLAN is the highest-probability cause given the timing.
  3. Transport layer: For the bridged clinical SSID, confirm the local VLAN mapping on the AP uplink. For the tunneled guest SSID, confirm the tunnel termination VLAN.
  4. DHCP layer: Identify which relay/interface handed out the clinical-subnet lease. This pinpoints where the misassignment occurred.
  5. Enforcement layer: Check ACLs and firewall rules between the guest role and the server subnet. TCP 104 succeeding implies no effective policy between them.

Likely failure classes:

  • Role/VLAN misconfiguration on the guest SSID (wrong VLAN or role mapping).
  • MAC caching granting a stale or over-broad role to a returning device.
  • Shared RADIUS attributes returning a VLAN that overrides the intended guest policy.
  • Missing or misordered ACL between guest and server subnets.
  • Bridged SSID on an AP trunked to a VLAN that also carries clinical traffic.

2. Given the evidence, what containment do you apply immediately, and what is the correct long-term segmentation model?

Read the worked answer

Immediate containment (in order):

  1. Disable the guest SSID or apply a deny-all egress policy to the guest role, so no further guest traffic reaches internal subnets.
  2. Add an explicit deny between the guest subnet/role and all clinical and server subnets, placed above any permit rules.
  3. Audit active leases for guest clients that received clinical-subnet addresses and revoke/remediate them.
  4. Preserve logs and configuration snapshots for the incident record before making further changes.

Long-term segmentation model:

  • Guest is untrusted by default: guest traffic terminates in a dedicated DMZ-like segment with only internet-bound egress. No route to internal subnets except through an explicit, logged policy.
  • Separate policy from transport: assign roles by identity (RADIUS attributes, device posture), and make the role the enforcement point rather than the VLAN alone. VLANs remain the transport, but the role drives the ACL.
  • Clinical devices on their own segment with an allow-list of required flows to imaging and EHR servers, default deny.
  • MAC caching scoped tightly: short cache lifetime, re-authentication on role change, and cache invalidation on device or user change.
  • Reconcile the two SSIDs' policy paths: the tunneled guest and bridged clinical SSIDs should not share a RADIUS attribute set that can cross-assign VLANs.

Verify: attempt the same guest-to-imaging flow from a test client and confirm it is denied and logged.

3. The clinic has no change-control records. What process and technical controls do you recommend to prevent recurrence?

Read the worked answer

Process controls:

  • Require a change record for every SSID, role, VLAN, and ACL change, with a named approver and a rollback plan.
  • Pair changes: a guest SSID change and a clinical SSID change in the same window should be reviewed together, since they share a RADIUS path.
  • Post-change verification step: a documented test that a guest client cannot reach an internal subnet, and that a clinical device can reach its allow-listed servers.

Technical controls:

  • Policy as configuration with review: keep SSID/role/ACL definitions in version control so diffs are visible.
  • Default-deny between segments: new segments should be isolated until a policy is explicitly written, so a misassignment fails closed.
  • Automated validation: a scheduled synthetic check that a guest-profile client is denied access to a canary internal host, alerting on any permit.
  • Configuration drift detection: compare running configuration against a known-good baseline and alert on VLAN/role/ACL drift.
  • Role-change logging: log every role and VLAN assignment decision with the identity and attribute set that produced it, so a recurrence is traceable in minutes.

Governance: assign an owner for guest and clinical segmentation, and review the policy quarterly against the allow-lists.