radtest / radclient Builder

Build the exact radtest and radclient commands to test RADIUS authentication, accounting and CoA against a server, with the right auth type and port.

Config generator RADIUS & AAA Runs in your browser
Used only to build the command in your browser.
Try:

Result

Auth port (UDP)
1812
Accounting port (UDP)
1813
Auth type
PAP
Session ID
nv-1ksew48
Authentication test (radtest)
radtest testuser 'testpass' 127.0.0.1:1812 0 testing123
Accounting Start (radclient)
echo "User-Name = "testuser", Acct-Status-Type = Start, Acct-Session-Id = "nv-1ksew48", NAS-Port = 0, NAS-Port-Type = Ethernet, Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 10.64.0.100" | \
  radclient -x 127.0.0.1:1813 acct testing123
Accounting Stop
echo "User-Name = \"testuser\", Acct-Status-Type = Stop, Acct-Session-Id = \"nv-1ksew48\", Acct-Session-Time = 3600, Acct-Input-Octets = 12345678, Acct-Output-Octets = 87654321" | \
  radclient -x 127.0.0.1:1813 acct testing123
Server-side debugging
# Run the server in the foreground with full debug
radiusd -X
# or, on Debian/Ubuntu packages
freeradius -X

# Watch the raw packets
tcpdump -ni any -vv port 1812 or port 1813
Security
radtest sends PAP by default, which puts the password in the packet protected only by the shared secret. That is fine on a loopback test and unacceptable across an untrusted network - use MS-CHAPv2 or EAP there, and treat the shared secret as a real credential.

About radtest / radclient Builder

radtest is the fastest way to prove whether a RADIUS problem is the server, the NAS or the credentials. This builds the command with the correct ports, auth type and attribute syntax, plus the accounting and debugging commands you will want next.

Reading the response

Access-Accept means the credentials and policy are fine - if the NAS still rejects the user, the problem is between NAS and server, not in the user record. Access-Reject means the server made a decision: run radiusd -X and read the policy trace. No response at all means UDP is not arriving, or the client is not defined in clients.conf - a server drops packets from unknown clients silently, by design.

Auth types and what they need

PAP requires the server to hold or be able to derive the cleartext password. CHAP and MS-CHAPv2 require cleartext or NT-hash storage respectively - you cannot serve MS-CHAPv2 from bcrypt or SHA hashes, no matter how the documentation is worded. Pick storage to match the protocols your NAS will use, not the other way round.

Common use cases

  • Proving a new NAS shared secret before pointing a live BNG at it.
  • Testing accounting start and stop while building a billing integration.
  • Reproducing an authentication failure with a controlled request.

Edge cases and gotchas

  • Ports 1812/1813 are the standard; 1645/1646 are the legacy Cisco pair still found in old configuration.
  • A silent timeout almost always means the source IP is not listed in clients.conf on the server.
  • The password appears in your shell history - clear it or use a leading space if the shell is configured to skip those.

Frequently asked questions

radtest works but my NAS does not authenticate - why?
radtest runs from your workstation, so the source IP differs from the NAS. Check clients.conf covers the NAS address, that the shared secret matches exactly, and that no firewall sits between them on UDP 1812.
Why does MS-CHAPv2 fail with "Cleartext-Password required"?
MS-CHAPv2 needs the NT hash. If the account is stored as a one-way hash such as SSHA or bcrypt, only PAP can work. Store NT-Password for MS-CHAP users.