Everything about Web and Network Monitoring

Home > 101 Reasons To Choose Monitis > FreeRadius Server Monitoring

FreeRadius Server Monitoring

Introduction One of the most popular protocols for regulating access to the Internet or any computer network is the Remote Authentication Dial In User Service (Radius). It is based on the AAA protocol and serves three purposes: authenticate users for network access; authorize them for services; and account for their services usage. It is widely used by Internet Service Providers, Mobile Operators, Wi-Fi network providers and VOIP providers. Simply, the operation of the protocol can be described as follows: a client starts a connection via a network access device (Radius Client), then the Radius server checks and authenticates/authorizes the user for service and if the user’s credentials match, the server sends an Access-Accept message back to the Radius Client. After this, the transaction data may be stored and processed in the server for billing purposes. In this article we present a possible solution for monitoring the FreeRadius  server’s health status. Usage approach Monitis provides a great opportunity for IT specialists to build custom monitors via the ‘Monitis Open API’. FRMon is implemented using this approach. The FRMon work scenario can be described as follows: the FRMon, running in a remote host (it is possible to run the monitor on the Radius server’s machine, but in that case the request delay time would lose its actuality), periodically sends a test request to the FreeRadius server and processes the response. It determines the response delay and the server health status from the response, constructs and sends the monitor data to the Monitis server, and the data is then made available to users via the Monitis dashboard (Figure 1). FreeRadius additional configurations To ensure the monitor works properly, you should create a test user for Radius. To do this, you usually need to edit the /etc/raddb/users (or /etc/freeradius/users) file by adding the new user’s credentials. For example: ‘testuser  Cleartext-Password := “123456Aa”’. You will also need to define the client’s IP (the IP of the host machine where the FRMon is going to run). For this edit /etc/raddb/clients.conf (or edit /etc/freeRadius/clients.conf)by adding:

client testuser {
ipaddr = # replace by your client's IP
secret = testing123    # A shared secret to validate communications between client and 
                       # RADIUS server. Replace by your Radius secret.

FRMon customization The application is implemented using Unix Bash Shell. It includes several utility scripts, the Monitis OpenAPI wrapper script (monitis_api.sh), and the processing script (radius_monitor.sh).  The processing script periodically sends authentication requests to the Radius server, processes responses for the health status, determines the response delay, and sends necessary information to the Monitis server. Note that the application uses the FreeRadius ‘radtest’ command to simulate the Radius request, so you need to have installed the FreeRadius client on the monitor host. You also need to tune the application by replacing some parameters (constants) that correspond to your Monitis account and data. These are APIKey, SecretKey, Radius SECRET, HOST (the Radius server’s host machine’s IP), TESTUSER and TESTPASSWORD (for the added user; in our example these values are “testuser” and “123456Aa”). FRMon test For testing purposes we installed and configured the FreeRadius server on an Ubuntu 11.10 64 bit system (Intel core i5 2300 cpu, RAM – 4 GB, kernel Linux 3.0, Bush version  - 4.2.10). After running the application on the remote machine (Ubuntu 11.10 64 bit, Intel core i5 2300 cpu, RAM – 1 GB, kernel Linux 3.0, Bush version – 4.2.10, working on a virtual machine running Windows 7 32 bit) we got the results in our Monitis account as shown in Figure 2 and Figure 2.1. The application tracks the FreeRadius server’s health status by using 2 metrics:

  • ‘status’ – shows the servers current running status.  It may have one of the 3 following values:
    • OK – Access-Accept message received for the test user.
    • NOK – Access-Rejected message received for the test user. This means that the server rejected the test user due to some internal problem (for example you may not have properly performed the FreeRadius additional configuration described above).
    • DEAD – server is down.
  • ‘reqTime’ – shows the response delay in seconds for Radius request.

Figure 2: FreeRadius monitoring results.   Figure 2.1: The graphical representation of the FreeRadius monitoring results.

You can find the link to the monitor at MonitisExchange.

About Arthur Sergeyan

Web & Cloud