RADIUS diagnostics
Diagnose Sign In's RADIUS module: unreachable backend, rejected credentials, the server rejecting how the credential is sent, and timeout behaviour.
Sign In’s RADIUS module delegates authentication to an external RADIUS server (a library system, a visitor system, a legacy credential store). When it fails, the problem is almost always one of four things: reachability, the shared secret, the server rejecting how the credential is sent, or the backend rejecting the credential. This page walks each.
The failure modes, in order
Section titled “The failure modes, in order”1. Sign In can’t reach the RADIUS server
Section titled “1. Sign In can’t reach the RADIUS server”Symptoms: Guests get a generic “unable to sign in” message after a pause; the Dashboard records attempts but no responses.
What to check:
- Network path. From the Sign In side, outbound RADIUS traffic (UDP 1812 for auth, 1813 for accounting) must reach the external server. NAT, firewalls, and asymmetric routing are the usual culprits.
- Server reachability from your side. Confirm the server is up —
radtestor an equivalent tool from another client on the same network isolates the platform vs. the server. - Hostname resolution. If the server is configured by hostname, confirm DNS resolves correctly at sign-in time.
2. Shared secret mismatch
Section titled “2. Shared secret mismatch”Symptoms: Sign In records “Access-Reject” immediately without any meaningful reason; the external server logs show the request arrived but was rejected as “bad authenticator” or similar.
What to check:
- Re-enter the shared secret on both sides. Copy/paste errors and trailing whitespace are common.
- Some RADIUS servers treat the shared secret as per NAS; confirm Sign In is registered as a NAS on the external server with the matching secret.
3. The external server won’t accept how Sign In sends the credential
Section titled “3. The external server won’t accept how Sign In sends the credential”Symptoms: Specific credentials that work elsewhere are rejected here, even though the username and password are correct; the external server logs show an authentication-type rejection rather than a bad-password rejection.
What to check:
- Sign In submits the username and password as a standard credential check (an Access-Request carrying the password, not a challenge/response handshake). It does not perform CHAP or MS-CHAPv2.
- If the external RADIUS server only accepts MS-CHAPv2 or CHAP — for example Active Directory fronted by NPS, which stores MS-CHAP-style hashes — a plain password check is rejected. Configure that server to accept password-based authentication for the Sign In client (the NAS), or front it with a server that does and have Sign In point at that.
4. The external backend rejects the credential
Section titled “4. The external backend rejects the credential”Symptoms: The external RADIUS server logs do see the request, and do reject it with a meaningful reason (wrong password, expired account, locked out).
What to check:
- This isn’t a Sign In problem — the credential is genuinely invalid on the external system.
- Confirm the guest is using the right credential format (library systems often expect card number plus PIN; visitor systems may expect an emailed one-time code).
Session length and the Timeout setting
Section titled “Session length and the Timeout setting”- The Timeout field in the module’s Configuration tab is the granted session length, in minutes — how long a guest stays signed in after a successful RADIUS check. It is not a per-request timeout for the call out to the external RADIUS server, so changing it won’t help a slow or unresponsive backend.
- If the external server is slow to answer, the sign-in attempt fails and the guest can simply try again. A guest who retries after a server recovery doesn’t count against previous attempts.
Reading RADIUS logs on the external side
Section titled “Reading RADIUS logs on the external side”Most RADIUS servers log a line per Access-Request with:
- The NAS-IP (Sign In’s identity from the server’s perspective).
- The User-Name submitted.
- The response code (Access-Accept / Access-Reject / Access-Challenge).
- A diagnostic message.
When troubleshooting, ask the external server operator to share the log lines for the attempts you’re investigating. A matched line with a clear rejection reason saves hours of guessing.
Retry limits
Section titled “Retry limits”If you need retry limits on failed RADIUS authentications, configure them on the external RADIUS server — that’s the right enforcement point for credential-based modules.
When none of the above fits
Section titled “When none of the above fits”Two edge cases:
- The server is up but doesn’t respond at all — check for a silent-drop rule on the server side (some servers drop Access-Requests from unknown NAS IPs rather than rejecting them).
- The server responds but the payload format is unexpected — Sign In logs payload-parsing errors; check the Dashboard’s diagnostic output for the specific reason.