Test FreeRADIUS with Radtest Access Accept and Access Reject Explained
One command, run on the server itself, tells you whether FreeRADIUS, your user and your password are all correct — before a single real device enters the picture. The skill is in reading its three possible answers.
✍️ Technical Anshu🐧 Ubuntu Server📡 FreeRADIUS 3
🎥 Watch the full FreeRADIUS setup in the video, step by step
The most expensive mistake in a RADIUS setup is testing everything at once: server, switch, WiFi and phone all changing together, so no failure has a clear owner. Radtest exists to prevent that. It sends a single test login from the server to itself, and its answer — Accept, Reject, or silence — tells you exactly which layer to look at. This page shows the command, decodes each answer honestly, and gives the testing order that professionals use.
Terminal — radtest result
$ radtest testuser TestPass123 localhost 0 testing123
Sending Access-Request of id 214 to 127.0.0.1 port 1812
User-Name = "testuser"
User-Password = "TestPass123"
rad_recv: Access-Request packet from host 127.0.0.1 port 1812
Received Access-Accept packet from host 127.0.0.1 port 1812
Reply-Message = "Welcome, test user"
👆 The result you want: Access-Accept, with your Reply-Message proving your exact users-file entry matched (panel recreated with the real radtest wording)
1
What Radtest Actually Does
radtest ships in the freeradius-utils package and plays the role of a tiny RADIUS client. It sends one Access-Request with a username and password to the server and prints the verdict. It exists so you can separate two questions that beginners constantly mix up: is the server working? and is my access point talking to the server correctly? Radtest answers the first question with no network device involved.
The command has five parts: radtest testuser TestPass123 localhost 0 testing123 — 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 the built-in localhost client, whose default secret is testing123.
2
Read the Three Possible Answers
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.
Access-Reject — the server answered, but said no. The request arrived and was understood; the password is wrong, the user entry is in the wrong place in the file, or the entry never matched. This is a configuration detail, not a network problem.
No reply — radtest retries, then gives up — the request never got an answer. The service is stopped, the server is listening on a different address, a firewall dropped the packet, or the secret did not match (a wrong secret is dropped silently, deliberately).
Each answer points at a completely different fix, which is exactly why this one command saves hours.
3
The Testing Order That Never Wastes Time
Radtest on the server itself, as shown above — proves server, user and password
Radtest from another machine on the LAN (install freeradius-utils there) using the server's LAN IP and a proper client entry — proves the network path and firewall
Only then, a real login through the access point or switch — now if it fails, the fault is in the device's settings, and you know it
Skip step one and you will debug three systems at once, changing settings at random. Follow the order and every failure has exactly one home.
🔴 Radtest proves the server, not the WiFi: a passed radtest does not mean your WPA2 Enterprise WiFi will work — EAP methods and certificates are a separate layer that radtest does not exercise. It means the foundation is correct, which is the thing you must know before touching that layer.
🎥 Watch the Full FreeRADIUS Setup Video
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.
Radtest gets no reply at all. Where do I look first?
Check the service is running with sudo systemctl status freeradius, then check a client entry exists for the address you are testing from with the secret you used. A wrong shared secret produces exactly this symptom — silence — because the server drops packets it cannot authenticate instead of answering them.
Radtest says Access-Accept but the access point still rejects logins. Why?
Because radtest only proves the server core. The access point path adds its own layers: the client entry and secret on the device side, and for WiFi, the EAP method and certificates. Compare the device secret character by character and watch sudo freeradius -X while a real login is attempted — the debug output shows which stage fails.
Can I run radtest from my laptop instead of the server?
Yes — install the freeradius-utils package on any Linux machine, add that machine as a client in clients.conf with its own secret, and run radtest against the server's LAN IP. That variant also tests your firewall and network path, which the on-server test deliberately skips.
This guide is based on the Technical Anshu FreeRADIUS video • Stuck on any step? Ask in the video comments — you will get an answer there 🙏