Untitled :: The FreeRADIUS project

Enabling RadSec with FreeRADIUS

Our first task is to set up a RadSec server by configuring an instance of FreeRADIUS to accept RADIUS over TLS requests.

The following steps should be performed on the host which will be the RadSec server, we will call it radsecsvr.

You can install FreeRADIUS using the NetworkRADIUS packages by following the instructions provided here:

https://networkradius.com/packages/

Before making any configuration changes, you should stop the radiusd service:

 service radiusd stop

Then, enable the tls virtual server:

cd /etc/raddb/sites-enabled
ln -s ../sites-available/tls

The FreeRADIUS distribution contains an example Certificate Authority that will have generated the necessary CA, server and client certificates and keys during package installation. You can use this CA, or you can use your own CA and certificates.

If the example certificates are not present (for example if FreeRADIUS was installed from source) then FreeRADIUS will fail to start. The files can be regenerated by running make in the /etc/raddb/certs directory.

Edit the tls virtual server configuration, in order to add definitions for the clients by extending the clients radsec {} section:

Example 1. Example radsec client definitions in /etc/raddb/sites-available/tls

clients radsec {
   ...
       # Direct connections from the test client
       client radseccli {
               ipaddr = 172.23.0.2
               proto = tls
               virtual_server = default
       }
       # Connections via HAproxy
       client haproxy {
               ipaddr = 172.23.0.4
               proto = tls
               virtual_server = default
       }
       # Connections via Traefik
       client traefik {
               ipaddr = 172.23.0.5
               proto = tls
               virtual_server = default
       }
}

The client ipaddr configuration item is used to match the source IP address of incoming connections. You must add client definitions for each of the clients which will connect.

For RadSec, you can just list the IP address of the RadSec client. This client definition is used for processing RADIUS packets from the RadSec client.

A secret does not have to be specified for RadSec clients, as the default is radsec. If you specify a secret, then that will be used instead of radsec.

When the PROXY protocol is used, you must also define a client which matches the IP address of the proxy (haproxy, etc). This client is only used to check that the source IP is permitted to connect to the server. Fields other than ipaddr can be specified (and in some cases may be required). However, all other fields will be ignored.

For testing purposes, we want to amend the default virtual server so that it accepts all authentication reqeusts and immediately responds to accounting requests.

Edit the /etc/raddb/sites-enabled/default file so that the beginning of the authorize and preacct sections looks as follows:

Example 2. Example default virtual server modification to unconditionally accept Access-Requests

authorize {
    accept
    ...
}
...
preacct {
    handled
    ...
}

This change makes the authorize section always "accept" the user, and makes the preacct section always say "we handled the accounting request". These changes are only for testing, and should never be used in production.

Start the FreeRADIUS service in the foreground with debugging enabled:

radiusd -fxxl /dev/stdout

Examine the output from FreeRADIUS to ensure that it is now listening for RadSec connection on TCP/2083:

Example 3. Example output from running radiusd -fxxl /dev/stdout

FreeRADIUS Version 3.0.24
Copyright (C) 1999-2021 The FreeRADIUS server project and contributors
...
... : Debug: Listening on auth+acct proto tcp address * port 2083 (TLS) bound to server default
... : Debug: Listening on auth address * port 1812 bound to server default
... : Debug: Listening on acct address * port 1813 bound to server default
... : Debug: Listening on auth address :: port 1812 bound to server default
... : Debug: Listening on acct address :: port 1813 bound to server default
...
... : Info: Ready to process requests

FreeRADIUS is now ready to process RadSec traffic.

For testing, we first test normal RADIUS over UDP functionality, then the RadSec connection using a test client, then introduce a proxy server, and finally we enable PROXY Protocol. Doing the tests in this way ensures that we know that all previous steps work before trying the next step. This process allows us to quickly narrow down problems, and gets us to the final goal faster than just "doing everything all at once".

Testing the RADIUS policy

Before moving on, verify that the FreeRADIUS policy is able to authenticate a local test RADIUS Access-Request over UDP:

echo "User-Name = terry" | radclient 127.0.0.1 auth testing123

Due to the accept we added in the authorize section, the expected output should be an Access-Accept:

Example 4. Expected output from radclient

Sent Access-Request Id 157 from 0.0.0.0:36850 to 127.0.0.1:1812 length 27
Received Access-Accept Id 157 from 127.0.0.1:1812 to 127.0.0.1:36850 length 20

Any other output indicates that there is a problem with the FreeRADIUS configuration which must be solved before testing RadSec. Carefully verify that you have carried out each of the above steps correctly and examine the debug output from FreeRADIUS, which will usually tell you what is wrong.

See [how to read the debug output](http://wiki.freeradius.org/radiusd-X) for instructions on reading amd understanding the debug output.

The next step is to configure FreeRADIUS as a RadSec test client so that we can verify that our RadSec server is working.