== 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:

[source,shell]
----
 service radiusd stop
----

Then, enable the `tls` virtual server:

[source,shell]
----
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.

[TIP]
====
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 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.

[NOTE]
====
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 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:

[source,shell]
----
radiusd -fxxl /dev/stdout
----

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

.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:

[source,shell]
----
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:

.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 xref:protocols/proxy/radsec_client.adoc[configure
FreeRADIUS as a RadSec test client] so that we can verify that our
RadSec server is working.