The server ignores unknown devices completely — by design. Registering your access point or switch in clients.conf, with a strong shared secret typed identically on both sides, is the step that makes requests start arriving.
A very common first-day problem: FreeRADIUS is installed, a user exists, the access point points at the server — and absolutely nothing happens when someone tries to log in. The usual cause is the missing client entry. In RADIUS, the device asking the question must be known and trusted first. This page explains what a client really is, how to write the clients.conf block, and why the shared secret is the detail that decides everything.
Forget the everyday meaning of the word. In RADIUS, 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 on its ports, or the VPN gateway. That device is also called a NAS (Network Access Server).
The server will only answer devices it knows. An unknown device does not get an error or a rejection — its packets are simply dropped, because RADIUS treats unauthenticated requests as untrusted by design.
Open the file with sudo nano /etc/freeradius/3.0/clients.conf and add your block at the end:
client office-ap { — the name in the heading is a label; pick something you will recognise in logsipaddr = 192.168.1.10 — the exact IP the requests will come from. If the access point sits behind NAT, this must be the address the server actually seessecret = MyStrongSecret42 — the shared secret. Make it long and random, and never reuse the example values from any guide, including this oneshortname = office-ap — a short log-friendly name, then close the block with }You can also allow a whole subnet, for example ipaddr = 192.168.1.0/24, but one entry per device with its own secret is the safer habit: one leaked secret should not open the whole network.
sudo freeradius -C — fix any error it reports; it names the file and linesudo systemctl restart freeradius1812, and the same secret, character for characterThe classic failure is a secret that matches on one side only, or a typo in the client IP. Both produce the same symptom — total silence — which is why the debug window on the server is your best friend here.
client 0.0.0.0/0 so "any device" can ask the server. That lets anyone who can reach the port attempt logins with a guessable shared secret. Register each real device by its own IP, with its own secret.The complete setup on a real Ubuntu server — install, first client, first user and the live test, all shown step by step in the video.
▶️ Watch Full VideoBecause until the access point is listed in clients.conf, the server does not know it and silently discards its packets. Check that the client IP matches the address requests actually come from, restart the service after editing, and confirm the shared secret is identical on both sides.
Yes, a subnet entry such as 192.168.1.0/24 with one secret will work, and it is fine in a small lab. For a real network, one entry per device with a different secret is better practice, because a single leaked or retired device then cannot expose the secret that protects every other device.
FreeRADIUS reads clients.conf only when it starts. Run sudo freeradius -C to validate the file, then sudo systemctl restart freeradius. If the restart itself fails, the -C output will tell you which line is wrong instead of leaving the server down without explanation.