802.1X — Port-Based Network Access Control

Mental model

Port security locks a port by MAC address — works, but a MAC is easily spoofed. 802.1X is the proper answer: a device must authenticate (with credentials, a certificate, or a token) before the switch port will pass any traffic.

The switch port has two virtual states:

• Uncontrolled — only 802.1X authentication traffic (EAPOL) is allowed
• Controlled — opens once authentication succeeds. Normal traffic flows.

Plug in an unauthorized device → the port stays uncontrolled → no DHCP, no anything. Plug in an authorized device → it authenticates → the port opens.

That’s the whole concept. The rest is the protocol mechanics.

Three roles

The authenticator is just the gatekeeper — it relays messages but never sees the actual password. This is important for security: an attacker compromising a switch can’t extract user credentials from it.

The protocols at each link

Supplicant  ←EAPOL→  Authenticator  ←RADIUS→  Auth Server
   (laptop)             (switch)            (FreeRADIUS)

• EAPOL (EAP over LAN) — between the device and the switch. Layer 2 only.
• RADIUS — between the switch and the auth server. Layer 3 (UDP).

The switch acts as a translator: takes EAPOL frames from the supplicant, repackages the contents into RADIUS messages for the server, and reverses on the way back.

EAP methods you’ll see

EAP is a framework that supports many authentication methods. Common ones:

For a Windows / Active Directory environment, the standard combo is PEAP-MSCHAPv2 — domain credentials authenticate, all carried over a TLS tunnel that the supplicant verifies via the server’s certificate.

Commands — wired 802.1X on a Cisco switch

! Enable AAA and point to RADIUS
SW1(config)# aaa new-model
SW1(config)# radius server CORP-RAD
SW1(config-radius-server)# address ipv4 10.0.99.5 auth-port 1812 acct-port 1813
SW1(config-radius-server)# key supersecret123

SW1(config)# aaa group server radius RADGROUP
SW1(config-sg-radius)# server name CORP-RAD

SW1(config)# aaa authentication dot1x default group RADGROUP
SW1(config)# aaa authorization network default group RADGROUP

! Globally enable 802.1X
SW1(config)# dot1x system-auth-control

! On each access port
SW1(config)# interface GigabitEthernet0/5
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10              ! the "authorized" VLAN
SW1(config-if)# authentication port-control auto       ! the magic line
SW1(config-if)# dot1x pae authenticator

authentication port-control auto means: start in unauthorized state, only let the device in after successful 802.1X auth.

Three port-control modes

Verification

SW1# show authentication sessions
SW1# show authentication sessions interface GigabitEthernet0/5
SW1# show dot1x interface GigabitEthernet0/5
SW1# debug dot1x events                  ! while troubleshooting only

show authentication sessions lists every authenticated device on every port — user, MAC, VLAN, auth method, session ID. The big picture in one command.

Guest / failure handling

What if 802.1X fails (no supplicant, wrong creds, RADIUS server down)? Three common options:

! Guest VLAN — fall through to a restricted VLAN if no supplicant responds
SW1(config-if)# authentication event no-response action authorize vlan 99

! Auth-fail VLAN — different VLAN for devices that try and fail
SW1(config-if)# authentication event fail action authorize vlan 100

! Critical auth — if RADIUS server unreachable, allow the device into a fallback VLAN
SW1(config-if)# authentication event server dead action authorize vlan 50

Use these carefully — they’re escape hatches. An attacker who knows about the guest VLAN can simply not respond and get network access.

Common mistakes

1. Forgetting aaa new-model. Without it, none of the 802.1X commands work.

2. No RADIUS server, then enabling 802.1X. Devices try to authenticate, can’t, get nothing. Always test RADIUS reachability before enabling on production ports.

3. Forgetting to set the port to access mode. 802.1X works on access ports. Trunk ports use other mechanisms.

4. Locking yourself out of management. Don’t enable 802.1X on management VLANs without a way back in. Always keep a console / OOB management path during rollout.

5. No fallback for non-supplicant devices. Older printers and IoT devices can’t speak 802.1X. Use MAB (MAC Authentication Bypass) as a fallback — the switch sends the MAC to the RADIUS server, which whitelists it. Less secure than 802.1X but works for devices that can’t authenticate.

6. Using EAP-MD5 in production. Trivially broken. Always pick PEAP, EAP-TLS, or EAP-FAST.

7. Skipping the certificate validation step on PEAP clients. Without server cert validation, a man-in-the-middle attacker can spoof the RADIUS server and harvest credentials. Always deploy the correct CA cert to clients.

Lab to try tonight

1. Set up FreeRADIUS with one test user.
2. On a Cisco switch, configure AAA + RADIUS pointing to your FreeRADIUS server.
3. Enable dot1x system-auth-control globally + authentication port-control auto on one access port.
4. On a Windows / Linux laptop, configure an 802.1X supplicant with PEAP + your test credentials.
5. Plug in. Watch show authentication sessions show the device move from “Authenticating” to “Authorized.”
6. Try with wrong credentials → port stays unauthorized.
7. Try with no supplicant configured → port stays unauthorized.
8. Bonus: add MAB fallback for non-supplicant devices: authentication order dot1x mab. Verify a non-802.1X device authenticates by MAC.

Cheat strip