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 a transport layer and communicate with a user 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 requests and server response manner as it’s shown below.

1. The 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. The 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 to maintain a unique session identifier.

3. The 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. The server replies with a Accounting-Response message to confirm the new session.

In a RADIUS environment, an additional service for user 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 not being able access to a server network or login into an application, users can’t open a session into a device or being unable to get the authorization to use a right in a business process. To solve that kind of situation, this article aims to setup the environment shown below.

SKUDONET will share the RADIUS protocol messages among all the RADIUS servers, whether they’re in different or local sites. In the following sections, we’re explaining the configuration of this kind of environment, 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 an LSLB farm with an L4xNAT profile at layer 4, ports 1812 and 1813, protocol type UDP and preferred DNAT 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 as ALL protocols 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 successfully configured, we can set the advanced health check for this service.

RADIUS Advanced Health Check Configuration

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

The help of this command can be listed:

root@Skudonet5# /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 SKUDONET):

root@Skudonet5# cd /usr/local/zenloadbalancer/app/libexec/
root@Skudonet5# ./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 SKUDONET 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 SKUDONET 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 SKUDONET it’s required some manual configuration as it’s not integrated yet.

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

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

For this kind of approach, the IANA has created an official entry for RadSec (RADIUS Security) to use the 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 SKUDONET, 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, SKUDONET doesn’t support RADIUS proxy capabilities but it’s planned to be included soon. Look forward to the latest developments!

Enjoy your highly available and scalable network accessing services!