Skip to main content
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, protocol mismatch, or the backend rejecting the credential. This page walks each.

​
The failure modes, in order

​
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 — radtest or 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

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. Protocol mismatch (PAP vs MS-CHAPv2)

Symptoms: Specific credentials that work elsewhere are rejected here; the external server logs show “no matching EAP type” or a similar rejection. What to check:
  • What the external RADIUS server actually expects — PAP, CHAP, or MS-CHAPv2. Some servers accept several; others are picky.
  • Match Sign In’s configured protocol to that expectation.
  • Some identity backends (Active Directory via NPS) require MS-CHAPv2 because the stored password hash is MS-CHAP-hashed; PAP won’t work against them.

​
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).

​
Timeouts and retries

  • Sign In applies a per-request timeout to the external RADIUS server. Long-running servers may exceed the default; adjust the timeout in the module’s Configuration tab if needed.
  • Retries are automatic within one sign-in attempt. A guest who retries after a server recovery doesn’t count against previous attempts.

​
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

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

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.

RADIUS module

Module overview and configuration.

Sign In Module issues

General troubleshooting when any module misbehaves.