FreeRADIUS clients.conf example — generate your client block

What a working clients.conf client block looks like

This is the generator's exact output for a client named office-ap-01 at 192.0.2.10 — the minimum FreeRADIUS 3.x needs to stop ignoring a client, plus the current hardening default:

# FreeRADIUS 3.x client block — generated by radius-client-config (runs locally; nothing is transmitted)
# Add to clients.conf:
#   Debian/Ubuntu: /etc/freeradius/3.0/clients.conf
#   RHEL/Rocky:    /etc/raddb/clients.conf
client office-ap-01 {
	ipaddr = 192.0.2.10
	secret = "<32-character-generated-secret>"
	# Require Message-Authenticator on every request from this client
	# (BlastRADIUS hardening). Requires FreeRADIUS 3.2.5+ / 3.0.27+;
	# remove this line on older versions.
	require_message_authenticator = yes
}
# Check syntax, then reload:
#   Debian/Ubuntu: freeradius -XC && systemctl reload freeradius
#   RHEL/Rocky:    radiusd -XC && systemctl reload radiusd
# Secret: 32 chars from a 76-symbol set ≈ 199 bits of entropy.
# Note: if NAT sits between the client and the server, the server sees a
# different source IP — register the post-NAT address instead.

Three details people miss: the file lives at /etc/freeradius/3.0/clients.conf on Debian/Ubuntu but /etc/raddb/clients.conf on RHEL/Rocky; the block only takes effect after a reload; and require_message_authenticator is a per-client setting that needs FreeRADIUS 3.2.5+ (or 3.0.27+) — on older builds, drop the line rather than wonder why the config check fails.

Add a RADIUS client in NPS with PowerShell

The Windows equivalent is one cmdlet — but the part everyone forgets is the restart. NPS does not apply a new RADIUS client until the service restarts:

# Windows NPS RADIUS client — generated by radius-client-config (runs locally; nothing is transmitted)
# Run in an ELEVATED PowerShell prompt on the NPS server:
New-NpsRadiusClient -Name 'office-ap-01' -Address '192.0.2.10' -SharedSecret '<32-character-generated-secret>' -AuthAttributeRequired $true
Restart-Service IAS  # NPS only applies new RADIUS clients after a service restart
# -AuthAttributeRequired $true = console option "Access-Request messages must
#   contain the Message-Authenticator attribute" (BlastRADIUS hardening;
#   matches require_message_authenticator on the FreeRADIUS side).
# GUI alternative: nps.msc > RADIUS Clients and Servers > RADIUS Clients >
#   New > "Address (IP or DNS)": 192.0.2.10
# NPS limits shared secrets to 128 characters.
# Secret: 32 chars from a 76-symbol set ≈ 199 bits of entropy.
# Note: if NAT sits between the client and the server, the server sees a
# different source IP — register the post-NAT address instead.

New-NpsRadiusClient ships with the NPS role on Windows Server 2012 and later. -AuthAttributeRequired $true is the PowerShell spelling of the console checkbox "Access-Request messages must contain the Message-Authenticator attribute" — the NPS side of the same BlastRADIUS hardening as require_message_authenticator above.

The fix for "Ignoring request from unknown client"

When radiusd -X shows Ignoring request to auth address ... from unknown client, FreeRADIUS is dropping the packet without any reply — no client {} block covers that source IP. The NAS never sees a reject; it sees a timeout, retries, and reports "RADIUS server not responding" while the server works fine for everyone it knows. The fix is exactly the block this page generates, registered for the IP in the log line. The full failure — including why multi-homed NAS devices keep re-triggering it — is in the error library: FreeRADIUS "unknown client" — why the NAS times out, not fails. NPS behaves the same way: unregistered clients get silence, not event 6274.

The NAT trap: register the IP the server actually sees

The client entry must match the source IP as it arrives at the RADIUS server. If NAT sits anywhere in the path — a branch firewall, a VPN concentrator, a cloud NAT gateway — that is the post-NAT address, not the address configured on the NAS. This is the trap that keeps "unknown client" alive after you're sure you added the entry: you registered the address the NAS thinks it has. When in doubt, take the IP from the server's own log line, or register the NAT pool as a CIDR range (FreeRADIUS accepts CIDR in ipaddr; NPS accepts an IP address range syntax of its own, so the generator notes the caveat when you enter a CIDR).

Shared secrets: length beats cleverness

The shared secret is the only thing authenticating your NAS to the RADIUS server outside of TLS, and RADIUS's own MD5 construction is weak by modern standards — the practical defense is entropy. Short, human-invented secrets are the ones offline attacks recover. The generator defaults to 32 random characters from a 76-symbol set (≈199 bits), created with the browser's CSPRNG (crypto.getRandomValues) via Go's crypto/rand — and pairs it with the Message-Authenticator requirement on both platforms, the concrete mitigation for the BlastRADIUS class of forgery. One secret per client, please: shared "site secrets" turn one leaked switch config into every switch's problem.