Troubleshooting the probe

This page is about getting the probe itself to run cleanly. If the probe runs but reports a failure on your server, that failure is the finding — start from its next-check line. The cases below are the ones where the tool can't get a straight answer yet.

First run times out — "all requests lost"

By far the most common first-run result. You'll see something like:

all 1 request(s) lost — nothing answered; the server is down or
unreachable, this probe isn't registered as a client, or the secret is
wrong (silent drop) — not intermittent

A RADIUS server silently drops requests from a source it doesn't recognise — there is no "access denied" reply to see. So a timeout almost always means one of:

• The probe isn't registered as a client. Add its IP as a RADIUS client (a client{} block in FreeRADIUS, a RADIUS Client in NPS) — see step 2 of the quickstart. On a first-run timeout the probe prints the exact clients.conf / NPS snippet with your detected source IP already filled in.
• The secret is wrong. Also silent — as the shared-secret check says: "Most RADIUS servers silently drop requests when the secret is wrong OR when the client isn't whitelisted, so a timeout alone can't tell them apart. Fix reachability/whitelisting first, then re-run."
• A firewall is eating UDP/1812 between the probe and the server, or the server isn't listening on that address/port.

It's registered, still timing out — the NAT trap

If anything between the probe and the server rewrites the source address (a NAT gateway, some VPNs), the server sees a different IP than the one on the probe's own interface — and drops the request as unregistered.

Register the post-NAT address — the one the server actually sees. If you're not sure what that is, the server's own log shows the source IP of the dropped request (FreeRADIUS in -X mode logs it), or check the NAT device. Registering the probe's local IP when NAT is in the path is the classic "I added the client and it still times out" mistake.

Multi-homed host — pin the interface with --bind

Jump boxes and monitoring servers usually have several interfaces. By default the OS picks the source address, which may not be the one you registered — or not the one on the path to the server. Pin it:

# multi-homed jump box: send from the interface on the user VLAN
authhound-probe radius test --server radius.corp.com --bind 10.20.0.5

--bind takes a local IP address (optionally IP:port), not a hostname — it's about which interface leaves, not name resolution. The registration snippet the probe prints on a timeout reflects the bound source IP, so you can paste it as-is. (If NAT is also in the path, the server still sees the post-NAT address — register that instead.)

"Works with radtest but not the probe"

Almost always a source-IP or method difference, not a server fault:

• radtest usually runs on the RADIUS server itself, so its source is 127.0.0.1 — which is registered as a client by default. The probe runs from where your clients live, from a different IP that has to be registered separately. That's the whole point of the probe (it tests the path radtest skips) — but it means "radtest passes" doesn't imply the probe's source is whitelisted.
• Different method. radtest sends PAP by default; a policy that only permits PEAP/EAP will reject it. Match methods before comparing: test PAP with --pap user, PEAP with --peap user.
• Different secret. Give the probe its own registered client and secret rather than reusing the switch's.

EAP-TLS certificate file errors

• "--client-cert and --client-key must be given together" — EAP-TLS needs both the certificate and its private key. Pass both flags, pointing at PEM files.
• "No client certificate supplied — skipped" — the EAP-TLS check only runs when you give it a cert; without one it's skipped, not failed.
• "certificate untrusted" — the client cert's issuing CA isn't trusted by the RADIUS server, or the chain is incomplete. Fix the CA trust on the server, or supply a cert the server's CA issued.
• Path / permission errors reading the PEM — check the file exists and is readable by the user running the probe. Point --client-cert/--client-key at a device's existing cert, or issue one test cert (the one-line openssl commands are in the README).

Same for --secret-file / --password-file: the probe refuses a world-readable file on unix (must not be world-readable). chmod 600 it.

Server-certificate name validation is skipped (WARN)

Without --server-name, the probe reads the server certificate but can't check the name on it matches — reported as a warning, not a failure. Pass the name the certificate should be valid for (it's also sent as TLS SNI) to turn the warning into a real check: --server-name radius.corp.com.

Windows terminal & colour quirks

• ANSI escape codes showing as garbage (e.g. in an older console, a log file, or a CI capture) — pass --no-color to disable colour. The probe also auto-disables colour when output isn't a terminal.
• "not recognized as a command" — run it with the path (.\authhound-probe.exe) or move the .exe onto your PATH. Scoop / winget packages aren't published yet; use the PowerShell download in the quickstart.

Intermittent — passes sometimes, fails others

Don't chase it by hand. --count N runs the checks N times (2–50) and reports aggregate stats — success count, timeouts, and latency min/median/p95/max — so "flaky" becomes a number:

authhound-probe radius test --server radius.corp.com --count 20

Requests lost while the rest succeed points at packet loss or an overloaded server; all-or-nothing points back at registration or the secret. Raise --timeout from the 5s default only if the server is genuinely slow — a long timeout hides a reachability problem.

Still stuck?

• Flag reference

  Exact syntax and defaults for every flag mentioned here.

• Log analyzer

  If you have the server-side radiusd -X or NPS log, paste it in for a read on the reject reason. Runs in your browser.

• Probe FAQ

  Timeouts, NPS specifics, credentials, and scripting, maintained in the repo.