How RADIUS Authentication Actually Works

RADIUS is one of those protocols that quietly runs an enormous amount of the world — enterprise WiFi, VPNs, ISP access, switch and router logins — and yet most people who depend on it every day have never seen how it works. It’s old (early 1990s), it’s simple in outline, and once you understand its handful of moving parts, a whole category of “why did my login fail” questions becomes answerable. So here’s the honest mechanical tour.

The cast: supplicant, NAS, and RADIUS server

Three parties, and getting them straight is half the battle:

• The supplicant — the thing trying to get on the network: your laptop, phone, the VPN client. It usually never talks to the RADIUS server directly.
• The NAS (Network Access Server) — the device controlling access at the edge: the WiFi access point or controller, the VPN concentrator, the switch. The NAS is the RADIUS client. This naming trips everyone up: the client of the RADIUS server is the network gear, not your laptop.
• The RADIUS server — the central brain that says yes or no, holds (or looks up) the credentials and policy, and hands back the answer plus any settings.

The supplicant presents credentials to the NAS; the NAS packages them into a RADIUS request and asks the server; the server decides; the NAS enforces. Your device is the subject of the conversation, not a participant in it.

Four messages and a shared secret

The core protocol is a request/response with essentially four message types:

• Access-Request — the NAS asks: here’s who’s trying to connect and their credentials.
• Access-Accept — the server says yes, and includes attributes telling the NAS how to set up the session (which VLAN, what bandwidth, session timeout, and so on).
• Access-Reject — the server says no.
• Access-Challenge — the server says “not done yet, ask them this” — the hook that makes multi-step and EAP-based authentication possible.

Between the NAS and the server sits a shared secret — a password the two of them both know, configured on each side. It’s not encrypting the whole conversation (classic RADIUS runs over UDP and only obscures the password field), but it’s used to sign responses so the NAS can trust that an Accept really came from the server. Get that shared secret wrong on one side and you get the maddening symptom where everything looks configured but every request silently fails or is ignored — because the two ends can’t prove anything to each other. It’s the same “both ends must agree on a secret” trust dependency I keep running into elsewhere.

Attributes: the protocol is mostly soup

A RADIUS packet is a small header plus a pile of attributes — key/value pairs carrying everything the protocol conveys: User-Name, User-Password, Called-Station-Id (often the access point’s MAC and the network name), Calling-Station-Id (your device’s MAC), NAS-IP, and on the reply side the session settings. Vendors define their own vendor-specific attributes for anything the standard doesn’t cover.

Those attributes are defined in a dictionary both ends must share — and if the NAS sends a vendor attribute the server doesn’t have in its dictionary, the server silently ignores it. That “unknown attribute vanishes without a word” behavior is its own debugging trap, and it’s exactly the shared-dictionary problem: the bytes arrive fine, but meaning lives in a definition file each side loaded separately.

Where EAP and the Challenge come in

Plain username/password barely covers modern network auth. Enterprise WiFi uses EAP (Extensible Authentication Protocol) — EAP-TLS with certificates, PEAP, EAP-TTLS, and friends — and RADIUS carries it. This is what the Access-Challenge is for: EAP is a multi-round-trip conversation (negotiate a method, build a TLS tunnel, exchange credentials inside it), and each round trip is the server sending a Challenge and the NAS relaying the supplicant’s answer back in the next Access-Request. So a single “connect to WiFi” can be a half-dozen RADIUS exchanges, with the server picking an EAP method based on who’s connecting and what the policy allows. RADIUS is the envelope; EAP is the letter inside.

Proxying: RADIUS forwards to whoever owns the identity

RADIUS servers can also be proxies. When a request comes in for an identity that belongs to someone else — a roaming partner, another realm — the server forwards it to their RADIUS server and relays the answer back. Routing is usually by realm, the user@domain part of the identity. This is how roaming and federation work: your home server vouches for you even when you’re on someone else’s network. It also means an authentication can traverse several servers before an Accept comes back, which is why I think of auth as a relay race — each hop has to hand off cleanly or the whole thing fails at a seam you can’t see from either end.

Accounting and mid-session changes

Two companions round it out. RADIUS accounting is a separate message flow (Start / Interim / Stop) the NAS sends to record that a session began, is ongoing, and ended — the basis for usage tracking and billing. And Change of Authorization (CoA) and Disconnect let the server reach back to the NAS mid-session to change a live session’s settings or kick it off — the reverse direction from the usual “NAS asks, server answers.” That reverse channel is how a back-office system boots a device or re-authorizes it without waiting for the next login.

Why knowing this pays off

Once the mechanics are in your head, the failures get legible. “It just won’t authenticate” splits into real questions: is the shared secret right on both ends? Is the NAS even reaching the server (it’s UDP — a dropped packet just looks like silence)? Is the identity’s realm routing to the right server? Is an EAP method mismatch causing the challenge dance to break down? Is a vendor attribute being dropped because a dictionary is missing? RADIUS isn’t magic and it isn’t modern, but it’s knowable, and knowing it turns network-auth debugging from guesswork into a checklist. If you’ve untangled a gnarly RADIUS failure, I’d enjoy hearing which part bit you.