Prevention: P16g WiFi Data VLAN 10

Prevention

Short-term

  • All new WiFi EAP-TLS profiles must include mac-address-randomization never and cloned-mac-address permanent

  • Add MAC randomization check to the EAP-TLS deployment runbook pre-flight checklist

  • Document VLAN-to-subnet mapping (which VLANs map to which subnets) in a partial for reference

  • Stop wired autoconnect loop when no carrier: nmcli con modify "Domus-Wired-Mgmt-VLAN100" connection.autoconnect no

Long-term

  • Create an nmcli connection template script that enforces MAC and EAP-TLS settings for all Domus-Secure profiles

  • Document ISE authorization policies: which profiles assign which VLANs under which conditions

  • Add VLAN assignment verification to the 802.1X testing checklist (not just authentication — verify the VLAN attribute in the RADIUS Access-Accept)

Lessons Learned

What Went Well

  • IoT fallback network provided connectivity while troubleshooting

  • Prior RCA (RCA-2026-03-13-001) had already identified MAC randomization as a risk factor — this confirms the pattern

  • Profile comparison immediately surfaced the MAC randomization discrepancy

What Could Be Improved

  • Profile consistency: the Data-VLAN10 profile was created without the MAC hardening that the Mgmt-VLAN100 profile has — no template or checklist enforced consistency

  • Never-connected detection: a profile with timestamp: 0 should be flagged and investigated before it’s needed in production

  • VLAN assignment documentation: it’s unclear whether VLAN 10 assignment is configured in ISE at all for WiFi clients — this should be documented alongside the profiles

Related