RADIUS

RADIUS, the Remote Authentication Dial-In User Service, is a client-server protocol that provides centralized authentication, authorization and accounting for users and devices that connect to a network. In network security, it lets access points, switches, VPN gateways and firewalls delegate the decision about who may connect to one central policy server.

RADIUS is defined mainly in RFC 2865 for authentication and RFC 2866 for accounting. It remains the standard back end for WPA2-Enterprise and WPA3-Enterprise Wi-Fi, wired 802.1X port control and many VPN deployments, even though its original design dates from dial-up modems.

How RADIUS authenticates a connection

RADIUS involves three parties. The supplicant is the user device, the network access server (NAS) is the access point, switch or VPN gateway, and the RADIUS server holds the policy and checks credentials, often against a directory such as LDAP or Active Directory. The NAS acts as the RADIUS client, not the user device.

The NAS sends an Access-Request over UDP to the server. The server answers with Access-Accept, Access-Reject or Access-Challenge when more exchanges are needed, as in EAP methods. An Accept message can carry authorization attributes, such as a VLAN ID, a session timeout or a filter name, which the NAS then enforces.

The table shows the main RADIUS message types and their role.

Ports, shared secrets and transport

RADIUS runs over UDP port 1812 for authentication and UDP port 1813 for accounting. Older equipment may still use 1645 and 1646. Dynamic authorization messages, known as Change of Authorization, use UDP port 3799.

Each NAS and server pair shares a shared secret. It is used to authenticate responses and to obscure the user password attribute with an MD5-based scheme. The rest of the packet, including the username and attributes, travels in clear text, which is the main weakness of classic RADIUS.

The Blast-RADIUS vulnerability disclosed in 2024 showed that an attacker in the path could forge Access-Accept responses against MD5-based integrity. The recommended response is to require the Message-Authenticator attribute on all packets and to move to RadSec where possible.

RADIUS with 802.1X and EAP

In enterprise Wi-Fi and wired port security, RADIUS carries EAP messages between the device and the server. The NAS only relays them, so credentials never terminate on the access point. The EAP method decides how the user proves its identity.

The most frequent configuration mistake is a client that does not validate the server certificate. A rogue access point with its own RADIUS server can then capture password hashes from PEAP. Certificate validation on every client is therefore not optional.

RADIUS compared with related access protocols

RADIUS is one of several AAA protocols, and choosing among them depends on whether the goal is network access or administrative access to devices.

RADIUS also differs from a VPN or IPsec: those protect traffic, while RADIUS only decides whether a session may begin and under which policy. In practice, a VPN gateway often uses RADIUS to check credentials and assign per-user network segmentation.

Deployment practices and pitfalls

A reliable RADIUS design focuses on redundancy, strong secrets and clear policy. Because every connection depends on the server, an outage blocks new logins across the whole network.

• Deploy at least two RADIUS servers and configure every NAS with both, with timeouts of a few seconds and two or three retries.
• Use long random shared secrets, unique per NAS or per site, rather than one short secret reused everywhere.
• Return VLAN or role attributes from RADIUS to apply network segmentation dynamically instead of hard-coding ports.
• Watch accounting data for session durations, data volumes and repeated rejects, which reveal misconfigured or compromised clients.
• Keep clocks synchronized and certificates current; an expired server certificate silently breaks EAP for every client.

Timeout values deserve particular attention. EAP-TLS exchanges need several round trips, often ten or more packets, so a high-latency path to a cloud RADIUS service can push total authentication time beyond the NAS timer. Placing a local RADIUS proxy near the access layer, or raising the NAS timeout to five or more seconds, prevents failures that look random to users.

Finally, fallback behavior must be decided in advance. Some switches can grant a restricted critical VLAN when no RADIUS server answers, which keeps phones and printers working during an outage. Others simply deny access. Neither choice is wrong, but an undocumented default usually surprises the operations team at the worst moment.

Explained without jargon

RADIUS works like a central reception desk for a building with many doors. Each door, such as a Wi-Fi access point or a network socket in the wall, does not keep its own list of who may enter. It simply asks the reception desk.

The desk checks the visitor and says yes or no. It can also say which floors the visitor may use and for how long. Every entry and exit is written in a log. One desk, one set of rules, many doors is the whole idea.

A typical use case

A university with 400 access points across its campus replaces a shared Wi-Fi password with WPA2-Enterprise. Every access point is configured as a RADIUS client of two redundant servers, which check student and staff credentials against the central directory.

Based on group membership, the RADIUS server returns a VLAN attribute: staff land in VLAN 20, students in VLAN 30 and laboratory devices with client certificates in VLAN 40. When a student graduates and the account is disabled, the next login attempt is rejected everywhere at once. The result is per-user access control without touching a single access point, plus accounting records that the security team uses to trace an incident to a specific account and time.