1-Minute FreeRADIUS Setup on Ubuntu

Install FreeRADIUS and the Test Tools

RADIUS is the quiet gatekeeper behind office WiFi logins, 802.1X switch ports and VPN sign-ins: the device asks the server, and the server says yes or no. FreeRADIUS on Ubuntu is the standard free way to run that gatekeeper. Two packages give you everything this guide uses — the server itself and the utilities package that contains the radtest tool — and Ubuntu starts the service on its own after the install.

sudo apt update
sudo apt install -y freeradius freeradius-utils

All of the server's configuration lives in one folder: /etc/freeradius/3.0/. Out of everything in there, this setup mainly touches two files — clients.conf (which devices may ask) and users (who may log in).

Confirm the Service Is Running and Listening

Before changing any configuration, confirm the freshly installed server is alive and waiting for requests. The service should report active (running), and the port check should show UDP 1812 — that is the authentication port. Its partner, UDP 1813, handles accounting.

sudo systemctl status freeradius
sudo ss -lunp | grep 1812

If the service is not running at this point, fix that first — every later step depends on a server that is actually up.

Add a Client in clients.conf

A RADIUS server trusts nothing by default. In RADIUS language, a "client" is not the laptop or phone logging in — it is the network device that asks the server for a decision: the access point carrying the WiFi login, the switch running 802.1X, or the VPN gateway (also called a NAS). That device must be registered with its IP address and a shared secret — a password both sides know. An unregistered device gets no error and no rejection: its packets are silently dropped, by design.

Open the clients file and add one block per device, at the end of the file:

sudo nano /etc/freeradius/3.0/clients.conf

client office-ap {
    ipaddr = 192.168.1.10
    secret = MyStrongSecret42
    shortname = office-ap
}

The IP address and the secret above are examples — always replace both with your own. The ipaddr is the exact address the requests will come from, and the same secret must later be typed into the access point or switch itself, character for character. If the two sides do not match exactly, the server silently ignores the device: no error, just nothing.

Add a Test User in the Users File

Now give the server somebody to authenticate. Open the users file and add one test account at the top of the file — FreeRADIUS reads this file from top to bottom and the first matching entry wins, so order matters.

sudo nano /etc/freeradius/3.0/users

testuser Cleartext-Password := "TestPass123"

The password shown is an example — pick your own, and remember what you set, because the test in the next step uses it. A plain-text test user like this is perfect for proving the setup works; on a real office server you would later connect FreeRADIUS to your existing user database or Active Directory instead of keeping passwords in this file.

Save the file, then check the whole configuration before restarting — the check must end with "Configuration appears to be OK":

sudo freeradius -C
sudo systemctl restart freeradius

Prove It Works with Radtest

Never test a new RADIUS server by pointing real users at it. The radtest tool (it ships in the freeradius-utils package you installed in Step 1) sends one fake login from the server itself, using the built-in localhost client. Its answer separates two questions beginners constantly mix up: is the server working, and is my access point talking to it correctly? Radtest answers the first one with no network device involved.

radtest testuser TestPass123 localhost 0 testing123

The five parts are: username, password, server address, NAS port (0 is fine for a test), and the shared secret of the client the request pretends to come from. Testing from the server itself uses that built-in localhost client, whose stock secret is testing123. Read the answer like this:

Received Access-Accept — the server checked the password and said yes. Your users entry, password and localhost secret are all correct; the server side is finished.
Received Access-Reject — the server answered but said no: wrong password, or the user line is in the wrong place in the file. A configuration detail, not a network problem.
No answer at all — the request never got a reply: the service is down, the port is wrong, or the secret did not match (a wrong secret is dropped silently, deliberately).

Lock It Down Before Real Devices Use It

Only after the local test passes should you configure a real access point or switch: enter the RADIUS server's IP (this Ubuntu machine), port 1812, and the same shared secret you put in its client block in Step 3 — then try one real login. If something fails at that point, the fault is in the device's settings, because the server side is already proven.