How To Install FreeRADIUS on Fedora 43

Network security starts with knowing exactly who is connecting to your infrastructure. A compromised shared Wi-Fi password, an unauthorized VPN login, or an unverified device plugged into a managed switch — each of these is a real-world threat that centralized AAA (Authentication, Authorization, and Accounting) solves cleanly. FreeRADIUS is the world’s most widely deployed open-source RADIUS server, trusted by ISPs, universities, enterprises, and home-lab engineers across the globe. This guide walks through a complete, production-ready installation of FreeRADIUS on Fedora 43 — from the first DNF command to a verified authentication response using radtest. Follow each step in order, and by the end you will have a fully functional RADIUS server securing your network on its own terms.

What Is FreeRADIUS?

RADIUS — Remote Authentication Dial-In User Service — is a client-server networking protocol that centralizes user authentication, authorization, and accounting for network access control. Instead of every device managing its own user database, all authentication requests flow through one RADIUS server that approves or denies access. FreeRADIUS is the open-source GPL-licensed implementation of this standard, actively maintained by the FreeRADIUS Project.

The server handles three distinct functions. Authentication verifies identity — checking credentials against a local user file, SQL database, or directory service. Authorization determines what the verified user can access after they log in. Accounting logs session activity — login timestamps, session durations, and data transferred — for auditing and compliance purposes.

FreeRADIUS communicates over UDP. Port 1812 handles authentication requests, and port 1813 manages accounting. On Fedora 43, the daemon is named radiusd, following the RPM service naming convention used across Fedora, RHEL, and CentOS systems.

Why Run a RADIUS Server on Fedora 43?

Fedora 43 is an excellent platform for hosting FreeRADIUS. It ships with SELinux in enforcing mode by default, providing OS-level process isolation that contains the impact of any service compromise. DNF cleanly resolves FreeRADIUS dependencies without manual intervention, and systemd makes starting, stopping, enabling, and monitoring the radiusd service straightforward.

Common real-world use cases for a self-hosted RADIUS server include WPA2-Enterprise Wi-Fi authentication (replacing shared PSK passwords with individual credentials), VPN gateway authentication, 802.1X port-based access control on managed switches, and ISP dial-up or PPPoE subscriber management. FreeRADIUS on Fedora 43 gives complete control over the authentication infrastructure — with zero licensing fees and full auditability.

Prerequisites Before You Begin

Confirm the following before starting the FreeRADIUS installation on Fedora 43:

• Fedora 43 installed on a physical server, virtual machine, or cloud VPS — minimum 1 GB RAM and 10 GB available disk
• Root or sudo privileges — every command in this guide requires elevated permissions
• An active internet connection to download packages via DNF
• Basic Linux terminal familiarity — navigating directories, editing files with nano or vim
• A RADIUS client device (Wi-Fi AP, VPN gateway, or managed switch) for end-to-end testing — optional for the basic walkthrough

Take a system snapshot or full backup before making any configuration changes on a production machine. This small step saves hours of potential recovery time.

Step 1 — Update Your Fedora 43 System

Always update the system before installing new server software. This prevents dependency conflicts, applies current security patches, and avoids outdated libraries causing unexpected behavior during installation.

Run the full system update:

sudo dnf update -y

The -y flag auto-confirms all prompts. DNF resolves and downloads every available update. If a kernel update was included, reboot afterward:

sudo reboot

After rebooting, verify the Fedora version to confirm you are on the right release:

cat /etc/os-release

The output should show Fedora Linux 43. Proceed only after this is confirmed.

Step 2 — Install FreeRADIUS on Fedora 43

Install FreeRADIUS using DNF. It is available directly from the Fedora repositories — no third-party repo needed:

sudo dnf install freeradius -y

To also install the testing utilities and optional database support in the same command:

sudo dnf install freeradius freeradius-utils freeradius-mysql -y

Here is what each package provides:

• freeradius — the core RADIUS server daemon (radiusd)
• freeradius-utils — provides radtest, radclient, and other diagnostic command-line tools
• freeradius-mysql — adds MySQL/MariaDB backend support, enabling user accounts stored in a relational database

After installation, verify the version:

freeradius -v

The output confirms the installed FreeRADIUS version string. All configuration files live under /etc/raddb/ on Fedora and other RPM-based Linux distributions.

Step 3 — Start and Verify the radiusd Service

Start the FreeRADIUS authentication daemon:

sudo systemctl start radiusd

Immediately check the service status:

sudo systemctl status radiusd

A healthy output shows active (running) — the daemon is alive and listening for RADIUS requests. For verbose, real-time diagnostic output during initial configuration, start FreeRADIUS in debug mode instead:

sudo radiusd -X

Debug mode prints every configuration load step, module initialization, and incoming request to the terminal. It is the single most useful tool for FreeRADIUS troubleshooting. Press Ctrl+C to exit. Always run radiusd -X first when something is not working — it shows the exact error before the server exits, making diagnosis fast and precise.

Step 4 — Understand the FreeRADIUS Configuration Directory

All FreeRADIUS configuration lives under /etc/raddb/. Knowing this layout before editing any files prevents costly mistakes.

Before touching any configuration file, create a backup:

sudo cp /etc/raddb/radiusd.conf /etc/raddb/radiusd.conf.orig

Apply this pattern to every file that gets edited. One misplaced character can prevent radiusd from starting, and a backup lets you revert in seconds without guesswork.

Step 5 — Generate TLS Certificates

FreeRADIUS requires TLS certificates for EAP-based authentication methods — PEAP, EAP-TLS, and EAP-TTLS — which are the underlying protocols powering WPA2-Enterprise Wi-Fi networks. Navigate to the certs directory and run the included bootstrap script:

cd /etc/raddb/certs
sudo ./bootstrap

The script generates a complete set of self-signed certificates: ca.pem (Certificate Authority), server.pem (server certificate), server.key (private key), and Diffie-Hellman parameters in the dh file. Without valid certificates in place, EAP-based authentication will fail entirely.

Verify the generated files exist:

ls /etc/raddb/certs/

For production deployments, replace these self-signed certificates with certificates from a trusted CA — either an internal enterprise PKI or a public Certificate Authority. Self-signed certificates work for testing, but client devices may display certificate trust warnings until a proper CA-signed certificate is in place.

Step 6 — Configure radiusd.conf

Open the main configuration file:

sudo nano /etc/raddb/radiusd.conf

Key settings to review and configure:

• prefix — the server installation prefix, usually /usr
• confdir — the path to the configuration directory (/etc/raddb)
• run_dir — runtime directory for the PID file (/var/run/radiusd)
• log { } section — set destination = files to direct logs to /var/log/radius/radius.log; set auth = yes to log every authentication attempt
• $INCLUDE clients.conf — confirm this line is present and not commented out

In the listen { } block, bind FreeRADIUS to a specific network interface rather than all interfaces:

listen {
    type   = auth
    ipaddr = 192.168.1.10
    port   = 1812
}

Binding to a specific IP address is a simple, effective way to reduce the attack surface. Save and exit when done (Ctrl+O, then Ctrl+X in nano).

Step 7 — Add Users to the authorize File

The authorize file maps usernames to passwords and is the simplest user database FreeRADIUS supports. Open it for editing:

sudo nano /etc/raddb/mods-config/files/authorize

Add a plain-text user entry:

john   Cleartext-Password := "Str0ngP@ss!"

Plain-text storage carries risk if the server is ever compromised. A more secure approach uses MD5-hashed passwords. Generate the hash first:

echo -n "Str0ngP@ss!" | md5sum | awk '{print $1}'

Then use the MD5-Password attribute in the file:

john   MD5-Password := "5f4dcc3b5aa765d61d8327deb882cf99"

Add multiple users by repeating the format on separate lines. The file is case-sensitive — usernames and passwords must match exactly what users will provide during authentication. For environments managing hundreds of users or more, migrating to a SQL backend with freeradius-mysql is the right long-term approach. A flat text file works well for small deployments but does not scale.

Step 8 — Define RADIUS Clients in clients.conf

In FreeRADIUS, a “client” is not an end user — it is a network device (Wi-Fi access point, VPN server, managed switch) that forwards authentication requests to the RADIUS server. Open the clients file:

sudo nano /etc/raddb/clients.conf

The default localhost entry is already present — leave it in place for local radtest testing. Add a block for each remote network device:

client office-ap {
    ipaddr    = 192.168.1.254
    secret    = "Y0urStr0ngSh@redKey!"
    shortname = office-access-point
}

The ipaddr field specifies the RADIUS client device’s IP address. The secret is the shared key both FreeRADIUS and the network device use to encrypt and sign RADIUS packets — a mismatch here silently drops every authentication request. Always enclose shared secrets in double quotes inside clients.conf to prevent parsing issues with special characters. Repeat this client block for each device on your network, then save the file.

Step 9 — Open RADIUS Ports in the Fedora 43 Firewall

Fedora 43 uses firewalld as its default firewall manager. RADIUS ports must be explicitly opened before any remote client can reach the server. Add permanent rules for both authentication (1812) and accounting (1813):

sudo firewall-cmd --permanent --add-port=1812/udp
sudo firewall-cmd --permanent --add-port=1813/udp

Reload the firewall to activate the rules immediately:

sudo firewall-cmd --reload

Confirm the ports are listed as open:

sudo firewall-cmd --list-ports

Expected output: 1812/udp 1813/udp

If only testing locally with radtest on the same machine, this step is technically optional. The moment any remote device needs to send authentication requests to this server, the firewall rules become mandatory.

Step 10 — Restart FreeRADIUS and Verify the Configuration

With all configuration files edited, restart the radiusd service to load every change:

sudo systemctl restart radiusd

On any server where uptime matters, test the configuration syntax before restarting to avoid taking down a live service on a bad config:

sudo radiusd -XC

The -C flag performs a full config check and exits without starting the daemon. A clean configuration outputs: Configuration appears to be OK. If errors appear, they specify the exact file and line to fix. After the restart, verify the service is still active:

sudo systemctl status radiusd

Confirm active (running) before moving on to the authentication test.

Step 11 — Test RADIUS Authentication with radtest

The radtest utility sends a test Access-Request packet directly to the RADIUS server — the fastest way to confirm the entire setup is working:

sudo radtest john "Str0ngP@ss!" localhost 0 testing123

Breaking down the syntax:

• john — username, must exist in the authorize file
• "Str0ngP@ss!" — the user’s password
• localhost — RADIUS server address
• 0 — NAS port number (use 0 for testing)
• testing123 — shared secret, must match the localhost entry in clients.conf

A successful authentication returns:

Received Access-Accept Id 25 from 127.0.0.1:1812

A failure returns Received Access-Reject. Common causes include a typo in the username or password in the authorize file, a shared secret mismatch in clients.conf, or forgetting to restart radiusd after an edit. For the full server-side view, open a second terminal, run sudo radiusd -X, and re-execute radtest — the debug output shows every packet attribute and every decision the server made, in order, in real time.

Step 12 — Enable FreeRADIUS to Start on Boot

The systemctl start command starts the service only for the current session. A server reboot stops it. Enable FreeRADIUS to start automatically at every boot:

sudo systemctl enable radiusd

Or combine start and enable in a single command:

sudo systemctl enable --now radiusd

Confirm the setting:

systemctl is-enabled radiusd

Output: enabled. The RADIUS server now survives reboots without any manual intervention — essential for any server in a production or always-on home-lab environment.

Viewing Logs and Accounting Records

FreeRADIUS writes authentication events to /var/log/radius/radius.log by default. Monitor it live:

sudo tail -f /var/log/radius/radius.log

Successful logins appear as Login OK: [username]. Failures appear as Login incorrect. Accounting records — session start and stop times, data transferred, NAS device information — are stored as dated flat files per client:

/var/log/radius/radacct/<client-ip>/detail-YYYYMMDD

Read today’s accounting file for a specific client:

sudo cat /var/log/radius/radacct/192.168.1.254/detail-$(date +%Y%m%d)

Setting auth = yes in the radiusd.conf log section enables logging of every authentication attempt — valuable for compliance auditing. For the most verbose output available, nothing replaces radiusd -X in a foreground terminal.

Troubleshooting Common FreeRADIUS Issues on Fedora 43

radiusd Fails to Start

Run sudo radiusd -XC to perform a configuration syntax check. The output names the exact file and line of any error. Also check for port conflicts — another process may already be using UDP 1812:

sudo ss -ulnp | grep 1812

Access-Reject on Correct Credentials

The authorize file is strictly case-sensitive. Verify the username and password match exactly, including capitalization and special characters. Ensure no trailing spaces follow the password value. Always restart radiusd after editing the authorize file — changes do not take effect until the service reloads.

Client Connection Refused or Dropped Silently

Check that the client’s IP address is listed in clients.conf and that the shared secret matches exactly what is configured on the network device. Confirm firewall ports are open with sudo firewall-cmd --list-ports. If the shared secret contains special characters, wrap it in double quotes inside clients.conf to prevent parsing failures.

SELinux Denials on Fedora 43

FreeRADIUS and SELinux can conflict on Fedora when the daemon tries to access socket paths or write to log directories that the default policy does not allow. Check for denials in the audit log:

sudo ausearch -m avc -c radiusd

Generate and install a custom policy module to allow the specific denied action:

sudo audit2allow -a -M freeradius-local
sudo semodule -i freeradius-local.pp

Never disable SELinux with setenforce 0. It is a core security layer on Fedora — use policy modules to resolve individual denials without removing this protection.

TLS or EAP Certificate Errors

If EAP-based authentication fails with certificate-related errors, regenerate the self-signed certificates by re-running the bootstrap script:

cd /etc/raddb/certs && sudo ./bootstrap

Verify the eap module is active by confirming a symlink exists at /etc/raddb/mods-enabled/eap.

Congratulations! You have successfully installed FreeRADIUS. Thanks for using this tutorial for installing FreeRADIUS on your Fedora 43 Linux system. For additional or useful information, we recommend you check the official FreeRADIUS website.