802.1X with MAC bypass: dock users land in the guest VLAN

What is actually happening On a port-based 802.1X port, the port is authorized (and assigned a VLAN) as a whole, based on the first authentication result that completes. MAB is a fallback that fires when no EAPoL is seen within the bypass timer - and a dock's USB Ethernet adapter usually does not start relaying the laptop's EAPoL for several seconds while the dock's own NIC is already presenting a MAC.

Sequence on the wire: link-up -> switch sees no EAPoL -> MAB query for the dock MAC -> RADIUS has no policy for that unknown MAC (or a default reject/guest policy) -> fast, successful 'authentication' that resolves to guest -> port is placed in VLAN 200. The laptop's EAP-TLS success 4-8 seconds later is a re-authentication of the same port, and the already-applied guest VLAN is sticky until the session is reset.

Options, with trade-offs

1. Remove MAB from dock ports and rely on EAPoL pass-through (recommended if the dock model relays EAPoL - verify with one unit before rolling out). Cleanest security posture: one supplicant, one identity, one VLAN. Trade-off: any dock that cannot pass EAPoL will not authenticate at all, so test by model.

2. Tune the fallback timing so EAPoL wins the race. Increase the MAC-auth-bypass delay on these ports above the dock's EAPoL relay time. Cheap, but timing-dependent and fragile after firmware changes.

3. Make MAB an acceptance instead of a fallback. Create RADIUS entries for the dock OUIs that return the staff VLAN (or a dock-VLAN that is then re-authorized by EAP-TLS). Works reliably but trusts MAC addresses, which are trivially spoofable - acceptable only for known corporate dock OUIs on physically controlled ports.

4. Separate guest from auth-fail. Guest VLAN should mean 'no credentials offered'; a rejected authentication should go to an auth-fail VLAN with a remediation portal. Conflating them is what makes a MAB miss look like a guest login.

5. MAC-based 802.1X mode authenticates each MAC independently - useful for multi-device ports, but adds operational complexity and per-MAC troubleshooting; not the right first move for a standard desk port.

Root cause to write in the ticket: MAB raced ahead of EAP-TLS on a port-based port and the fallback result was a guest VLAN, not a failure state that the later EAP-TLS success could override.

Diagnosis A port with a MAC limit (often 1, matching a single-desk design) is now seeing the video bar, a laptop, a phone and possibly a wireless dongle - four or more MACs on one port. The switch can either drop frames beyond the limit, shut the port, or send an SNMP trap, depending on the violation action. 'Loses its link every few days' plus a logged violation is consistent with a limit-triggered shutdown, not a hardware fault.

Configuration to apply

• Raise the MAC limit to a number you can defend: count the devices the room genuinely needs - video bar, two laptops, a phone, one spare = 5-6. Not 32 'just in case'.
• Sticky MAC learning on the legitimate devices so the room's known MACs are remembered and anything new counts as an addition against the limit.
• Set the violation action deliberately: shutdown for security-sensitive areas (with an alert so it is investigated rather than silently forgotten); protect/restrict where availability matters more, so only excess frames are dropped and the video bar stays up.
• Storm control and BPDU guard on the port, because an unmanaged switch in a conference room is also a loop risk and a rogue-DHCP risk; port security does not stop loops.
• Trust nothing about the unmanaged switch: it hides topology, cannot be managed, and will happily forward BPDUs it should not.

Justifying the number to the business The MAC limit is a capacity decision, not a security fetish: set it too low and the room breaks (as it just did); set it to unlimited and a single wall port becomes an unmonitored switch that can host a loop, a rogue DHCP server or a user's personal router. A limit of 5-6 with sticky learning gives the room what it needs and still triggers an alert the day someone adds an eighth device.

Longer term: replace the unmanaged switch with a small managed FortiSwitch at the room, managed over FortiLink, so the ports are visible, VLAN-tagged and monitored - the same cost as the support calls this has already generated.

Prove the good state

• Per-port authentication state: every staff port should show 802.1X authenticated with the expected VLAN; phone and printer ports should show MAB success with their assigned VLAN. Sample 20 ports across floors, not one.
• RADIUS accounting on FortiAuthenticator: compare accept/reject counts per day and per NAS. A healthy baseline has almost no rejects on staff ports and a stable number of MAB accepts matching the number of printers and phones.
• VLAN distribution in the MAC table: staff MACs in VLAN 100, phone MACs in VLAN 40, printer MACs in VLAN 60. A dock MAC in VLAN 200 tells you the race is back.
• Switch event logs to FortiAnalyzer: port security violations, port up/down, PoE events - correlate with user tickets so a silent violation does not hide for a week.

Regression signals to alert on

• A rise in guest-VLAN (200) sessions during business hours, especially on desk ports - the dock symptom returning.
• Repeated MAB accepts followed by EAP-TLS accepts on the same port within seconds - classic bypass race, worth a dashboard counter.
• Any port security violation on a non-public port; a steady trickle on conference room ports means the MAC limit is still wrong.
• Re-authentication failures clustered on one switch - points at RADIUS reachability or a switch management path issue, not at users.
• Ports flapping to unauthorized state without a matching RADIUS reject - often a supplicant timeout, not a credential problem.

Test discipline: once per quarter, unplug a laptop, plug in an unknown device, and plug in a printer, and confirm the three outcomes (auth, guest, MAB accept) still match the design. Documented expectations beat a green dashboard that nobody has validated since the last firmware upgrade.