The RADIUS (Remote Authentication Dial-In User Service) protocol ensures safer authentication and authorization for users attempting to access remote networks. Additionally, it helps facilitate secure connectivity between machines — allowing for data exchanges over the network while following the familiar client-server model.
Livingston Enterprises developed the RADIUS protocol in 1991 to help centralize user authentication and remote access procedures. Supported by Merit Network and the National Science Foundation (NSF), Livingston's early RADIUS implementation has since evolved into an IETF standard process that runs on Windows, Linux, and Unix.
RADIUS 1.1 is the current version of RADIUS and defined under RFC 9765. The latest RADIUS extensions, management, and accounting standards — which enable auditing — are separately defined under RFC 6929.
How does RADIUS work?
RADIUS clients often run on network access servers (NASes), wireless access points, and physical LAN-supported switches. RADIUS servers are typically centralized machines (including personal computers) with essential access to separate user, client, and dictionary databases. These databases store many essential details, including:
Credentials (usernames, passwords, and client IP addresses)
Protocol information
Shared keys
RADIUS-specific attributes and their values
Administrators can use RADIUS to prevent unwanted network access. The protocol also oversees each user session by tracking packet transmission, bytes in and out, and total session time. Known as accounting, this visibility helps teams better spot suspicious user behavior regardless of their geolocation and prevent abuse.
RADIUS runs atop the UDP protocol to help route clients to secondary servers, when initial authentication fails at the primary server. UDP supports retransmission timers, lengthier authentication processes, stateless sessions, and laxer acknowledgement requirements characteristic of RADIUS. It uses UDP port 1812 for authentication and UDP port 1813 for accounting.
RADIUS clients kick off communication using the following steps:
The client (which can be one of many device types) sends a request to the NAS. A supplicant program helps transfer information to the NAS — including user credentials and network address.
The NAS polls the RADIUS server for access. This requires the NAS to send along any relevant user data and performs a lookup to ensure the client IP is legitimate according to the RADIUS server's records.
The RADIUS server either accepts, rejects, or challenges the request. The challenge asks the NAS for additional information before granting access or denying the request. If accepted, RBAC and similar measures ensure that a user can only perform actions — or access resources — according to their permissions. The server will dictate the user's session length, active protocol, and IP address while the connection is alive.
Overall, RADIUS provides reliable authentication and remote access with enhanced scalability. By tightly controlling which users can send requests to given servers within a pool, administrators can keep services online without locking out trusted users.
You’ve mastered one topic, but why stop there?
Our blog delivers the expert insights, industry analysis, and helpful tips you need to build resilient, high-performance services.
Does HAProxy support RADIUS?
Yes! HAProxy One provides fast and reliable load balancing for UDP, QUIC, and TCP/HTTP traffic with one powerful solution. This solution is designed to successfully handle massive RADIUS request volumes for internal systems while providing unmatched quality of service (QoS).
To learn more about RADIUS support in HAProxy, check out our UDP solution or our blog, Load Balancing RADIUS With HAProxy Enterprise UDP Module.