802.1X Wired NAC with RADIUS: Authenticating the Edge

The wired network is the soft underbelly of most enterprises. Wi-Fi gets WPA2-Enterprise and everyone feels secure, while any visitor who finds an empty wall jack in a meeting room lands straight on the corporate VLAN. Wired 802.1X closes that door: a port stays dead until whatever plugs in proves who it is.

The technology is old and well-understood. What trips people up is the operational design — what happens to printers that cannot do 802.1X, and what happens to the whole floor when RADIUS is down.

The Three Players

[Supplicant]──EAP over LAN──[Authenticator]──RADIUS──[RADIUS server]
(laptop) (switch port) (FreeRADIUS)
  • Supplicant — the device, running an 802.1X client.
  • Authenticator — the switch port, which relays EAP to RADIUS and enforces the result.
  • RADIUS server — decides allow/deny and which VLAN the device lands in.

Switch Configuration

Global AAA and RADIUS first (Cisco IOS-XE):

Terminal window
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
dot1x system-auth-control
radius server NAC
address ipv4 10.0.0.10 auth-port 1812 acct-port 1813
key S3cretRadiusKey

The access port — 802.1X with MAB (MAC Authentication Bypass) as fallback:

Terminal window
interface GigabitEthernet1/0/10
switchport mode access
authentication host-mode multi-auth
authentication port-control auto
authentication order dot1x mab
authentication priority dot1x mab
mab
dot1x pae authenticator
dot1x timeout tx-period 7
spanning-tree portfast
spanning-tree bpduguard enable

authentication order dot1x mab tries real 802.1X first; if the device never responds to EAP (a printer, a camera), it falls back to MAB, authenticating by MAC address. MAB is weak — MACs are spoofable — but it is the pragmatic answer for the long tail of devices that cannot do 802.1X, and you confine them to a restricted VLAN.

Dynamic VLAN Assignment

The point of NAC is not just allow/deny — it is putting each device where it belongs. RADIUS returns the VLAN with three attributes:

Tunnel-Type = VLAN (13)
Tunnel-Medium-Type = IEEE-802 (6)
Tunnel-Private-Group-Id = "20"

A FreeRADIUS users entry for a corporate laptop (EAP) and a printer (MAB):

Terminal window
# Corporate user via EAP — lands in VLAN 20
alice Cleartext-Password := "..."
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "20"
# Printer by MAC (MAB) — restricted VLAN 50
00aabbccddee Cleartext-Password := "00aabbccddee"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "50"

The same physical port now serves a laptop on VLAN 20 and a printer on VLAN 50, decided by identity, not by which jack someone used. In production, drive these from a group lookup (LDAP/AD) rather than flat files — but the attributes RADIUS returns are identical.

The Part Everyone Gets Wrong: Fail-Open

Here is the scenario that turns a security project into a career-limiting outage: RADIUS server reboots for patching, and every 802.1X port on every switch stops authenticating. The entire building drops off the network. Now NAC is the thing that took down the company.

The fix is inaccessible authentication bypass — when RADIUS is unreachable, put ports into a designated VLAN instead of denying them:

Terminal window
! global: send EAPOL-Success to clients authorized into the critical VLAN
dot1x critical eapol
! the dead/alive actions are interface-level
interface GigabitEthernet1/0/10
authentication event server dead action authorize vlan 20
authentication event server dead action authorize voice
authentication event server alive action reinitialize

When RADIUS comes back (server alive), ports re-authenticate. The design decision is what the “critical VLAN” is: the corporate VLAN (maximize uptime, minimize security during the outage) or a limited one (the reverse). For most enterprises, the honest answer is the corporate VLAN — a RADIUS outage should not stop the business, and the exposure window is short and monitored.

Verification

Terminal window
# Per-session state on a port
show authentication sessions interface Gi1/0/10 details
# Status should be "Authorized", with the assigned VLAN and method (dot1x/mab)
# RADIUS reachability and dead-server detection
show aaa servers | include host|state
# Live test from FreeRADIUS side
radtest alice password 10.0.0.10 0 S3cretRadiusKey

On the FreeRADIUS host, run it in debug for the first rollout — it shows the exact attributes returned and why a request was rejected:

Terminal window
freeradius -X

Troubleshooting a Stuck Port

When a port will not authorize, the session table tells you which phase failed before you touch RADIUS at all:

Terminal window
show authentication sessions interface Gi1/0/10 details

Read the Method status list and Acct session ID. Three failure shapes recur:

  • Authc Failed on dot1x — the supplicant tried EAP and RADIUS rejected it. The cause is on the RADIUS side: bad credentials, an EAP method mismatch (device wants PEAP, server offers only EAP-TLS), or an untrusted server cert. Confirm with freeradius -X on the server.
  • Authc Failed on dot1x, then Authz Success on mab — normal for a non-supplicant device. The 802.1X attempt times out, MAB takes over. If MAB also fails, the MAC has no users entry.
  • Session never appears — the port is not running 802.1X. Check dot1x pae authenticator is on the interface and dot1x system-auth-control is on globally.

The single most common false alarm is the tx-period timeout. With dot1x timeout tx-period 7 and the default max-reauth-req of 2, a real non-supplicant device waits roughly tx-period × (max-reauth-req + 1) seconds — about 21 — before MAB even starts. Operators watch a printer sit dark for twenty seconds and assume NAC is broken. It is not; it is counting down to the MAB fallback. Lower tx-period to speed the fallback, but not so low that a slow-booting supplicant loses its race against MAB:

Terminal window
interface GigabitEthernet1/0/10
dot1x timeout tx-period 5
dot1x max-reauth-req 2

Verify the RADIUS path independently of any switch with radtest, and watch the server in debug to see the exact Access-Accept attributes — if Tunnel-Private-Group-Id is missing or names a VLAN that does not exist on the switch, the port authorizes and then lands nowhere.

Change of Authorization: Reacting Without a Reboot

Static VLAN assignment at login is half the picture. A device that is healthy at 9 a.m. and compromised at noon should not keep its access until the next reauth. RADIUS CoA (RFC 5176) lets the server push a change to an already-authorized session — bounce the port, re-auth, or apply a new policy — without anyone touching the switch.

Enable the dynamic-author server on IOS-XE:

Terminal window
aaa server radius dynamic-author
client 10.0.0.10 server-key S3cretRadiusKey
auth-type all

Now a posture or NAC engine can send a CoA-Request to quarantine a session, and a periodic reauthentication backstops it for anything CoA misses:

Terminal window
interface GigabitEthernet1/0/10
authentication periodic
authentication timer reauthenticate server

authentication timer reauthenticate server takes the reauth interval from the RADIUS Session-Timeout attribute, so you tune reauth frequency centrally instead of per-switch. The trade-off is load: aggressive reauth on thousands of ports is real RADIUS traffic, so size the server and its replicas for the steady-state reauth rate, not just the morning login storm.

Rollout Without Locking Yourself Out

Never flip a whole switch to port-control auto on day one. Stage it:

  1. Monitor modeauthentication open plus port-control auto. Ports authenticate and log, but traffic is allowed regardless. You collect who would pass or fail without breaking anyone.
  2. Fix the failures — find the devices with no supplicant and no MAB entry, and decide: supplicant, MAB, or exception.
  3. Low-impact mode — keep authentication open but apply a restrictive ACL to unauthenticated traffic.
  4. Closed mode — remove authentication open. Now unauthenticated means no access.

Skipping monitor mode is how you discover, in production, that the CEO’s docking station does not do 802.1X. Run it open for a couple of weeks, read the logs, and only close ports once the exception list is empty.

802.1X is not hard to configure. It is the design around the edges — MAB for the un-authenticatable, fail-open for the RADIUS outage, monitor mode for the rollout — that decides whether wired NAC is a quiet win or the reason the building lost network on a Tuesday.