Overview #

RADIUS or Remote Authentication Dial-In User Service is a network protocol that provides Authentication, Authorization and Accounting of users and devices centralized management. It’s widely used by Internet Service Providers and enterprises to control the access to Internet, local services, wireless networks through WiFi access points, etc.

The RADIUS protocol is implemented in the application layer with a client-server architecture that could use TCP or UDP as transport layer and are communicated with a users database like Active Directory, LDAP service or Linux accounting system. The most popular RADIUS solutions are FreeRadius or Microsoft NPS Radius Server.

RADIUS Messaging Protocol #

The protocol messaging is based on client request and server response manner as it’s shown below.

1. Client sends an Access-Request to the server for each user or device to be authenticated to the server port TCP/UDP 1812 (older server versions would use 1645 for authentication as well).
2. Server replies according to the policy Access-Accept if the authentication is allowed, Access-Reject if the access is not allowed or Access-Challenge if the server requires more information in order to determine the access (like a second validation: PIN, password, certificate, etc.)

Optionally, the client and server could exchange messages of accounting like Accounting-Request and Accounting-Response in order to maintain a unique session identifier.

3. Client sends an Accounting-Request to the server through the port TCP/UDP 1813 for accounting session management (older server versions would use 1646 for authentication as well).
4. Server replies with a Accounting-Response message in order to confirm the new session.

In a RADIUS environment, an additional service for users database management will be required and important to be considered in high availability, which will be treated in other specific article.

RADIUS load balancing and high availability environment #

The problem if a RADIUS service is down could produce the risk of users can’t access to a servers network, or login into an application, users can’t open a session into a device or unable to get the authorization to use a right in a business process. In order to solve that kind of situations, the aim of this article is to setup the environment shown below.

RELIANOID will share the RADIUS protocol messages among all the RADIUS servers, either they’re in different or local sites. In the following sections we’re explaining the configuration of this kind of environments, the advanced health checks for RADIUS services and the security challenges of this protocol.

RADIUS Virtual Service Configuration #

The RADIUS protocol nature is based on UDP packets, so the configuration of a reliable RADIUS environment is built with a LSLB farm with L4xNAT profile at layer 4, ports 1812 and 1813, protocol type UDP and preferred DNAT in order to have transparency and get the client IP at the backend side (although NAT should work perfectly as well).

In the Services, no persistence is needed by default unless some stickiness between the client-radius server is required.

If RADIUS is used through TCP instead of UDP, it could be changed in the protocol type field. It could be set as well ALL protocols in order to allow both TCP and UDP at the same time from the same virtual IP.

Finally, configure the backends with no ports configured (as it’ll use the destination port of the client connection) and test the connection. Once the RADIUS virtual service is sucessfully configured, we can set the advanced health check for this service.

RADIUS Advanced Health Check Configuration #

An advanced check is included in RELIANOID with name check_radius under the default folder /usr/local/zenloadbalancer/app/libexec/.

The help of this command can be listed:

root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help
Tests to see if a RADIUS server is accepting connections.

Usage:
check_radius -H host -F config_file -u username -p password
			[-P port] [-t timeout] [-r retries] [-e expect]
			[-n nas-id] [-N nas-ip-addr]

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 --extra-opts=[section][@file]
    Read options from an ini file. See
    https://www.monitoring-plugins.org/doc/extra-opts.html
    for usage and examples.
 -H, --hostname=ADDRESS
    Host name, IP Address, or unix socket (must be an absolute path)
 -P, --port=INTEGER
    Port number (default: 1645)
 -u, --username=STRING
    The user to authenticate
 -p, --password=STRING
    Password for autentication (SECURITY RISK)
 -n, --nas-id=STRING
    NAS identifier
 -N, --nas-ip-address=STRING
    NAS IP Address
 -F, --filename=STRING
    Configuration file
 -e, --expect=STRING
    Response string to expect from the server
 -r, --retries=INTEGER
    Number of times to retry a failed connection
 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)

This plugin tests a RADIUS server to see if it is accepting connections.
The server to test must be specified in the invocation, as well as a user
name and password. A configuration file may also be present. The format of
the configuration file is described in the radiusclient library sources.
The password option presents a substantial security issue because the
password can possibly be determined by careful watching of the command line
in a process listing. This risk is exacerbated because the plugin will
typically be executed at regular predictable intervals. Please be sure that
the password used does not allow access to sensitive system resources.

Firstly, let’s check if it’s working properly by executing the following example command (please use your own radius client configuration parameters from RELIANOID):

root@noid5# cd /usr/local/zenloadbalancer/app/libexec/
root@noid5# ./check_radius -H <RADIUS_SERVER_IP> -P <RADIUS_SERVER_PORT> -u <DUMMY_USER_NAME> -p <DUMMY_USER_PASSWD> -F <RADIUS_CLIENT_CONFIG_FILE>

The test will be done from RELIANOID appliance to one certain RADIUS server with a dummy user validation and, optionally, a client configuration file for specific client parameters. Let’s test the command, and then, when we get the OK from the server and the FAILURE when it’s down we can configure the advanced health check in the Services section of our just created virtual service.

Don’t forget to use the HOST token when configuring the advanced health checks in RELIANOID as per below.

check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg

See below the Services section configuration.

RADIUS Security Options #

The RADIUS protocol has traditionally used MD5 algorithms for per-packet authentication and integrity checks over UDP. As these two don’t provide any security encryption and protection several approaches have been studied.

Deployments of RADIUS over IPsec or Internet Protocol Security have been widely deployed but there are some difficulties of this option as the application layer is not aware of the security policies, as it’s implicit in the network layer. To use this approach with RELIANOID it’s required some manual configuration as it’s not integrated yet.

The specification of DTLS or Datagram Transport Layer Security allows to provide encryption, monitor and control the security policies of such traffic.

Another option would be RADIUS over TLS that provides TCP capabilities of reliability and in-order transport layer.

For these kind of approaches, the IANA has created an official entry for RadSec (RADIUS Security) to use UDP 2083 port for RADIUS/TLS implementations.

Another option would be to enhance the digest and authorization layer with EAP (Extensible Authentication Protocol) that is not used in the link establishment layer but during the connection authentication phase, avoiding the use of MD5 weak digests.

In addition, with RELIANOID, the RADIUS services can be protected with the IPDS module against malicious packets and hosts, DoS attacks, brute force attempts and much more.

RADIUS Proxy capabilities #

If several RADIUS servers are deployed across different sites, it’d be interesting to forward the client connection to the site that manages their authentication, authorization and accounting data. Currently, RELIANOID doesn’t support RADIUS proxy capabilities but it’s planned to be included soon. Look forward to the latest developments!

Enjoy your high available and scalable network accessing services!