RADIUS Client Config Generator

RADIUS client trust is decided at the edge of the authentication exchange. Before a user password, certificate, VLAN, or group rule matters, the server has to recognize the network access server that sent the packet. An unknown source address or a mismatched shared secret can stop the conversation before ordinary authentication policy begins.

A client definition is therefore part allowlist, part shared-secret contract, and part device-routing hint. Switches, wireless controllers, VPN gateways, firewalls, and RADIUS proxies often need distinct entries because they have different source addresses, vendor behavior, monitoring needs, and upgrade histories. Reusing one broad range for many devices may save typing, but it also makes incident review harder because many packet sources inherit one trust decision.

NAS

The access device that sends RADIUS requests, such as a switch, wireless controller, VPN gateway, or firewall.

Client definition

The server-side allowlist entry that names the NAS address, shared secret, and optional handling rules.

Shared secret

The secret configured on both sides of the RADIUS relationship. It is separate from user passwords.

Address scope deserves the same care as the secret. A single host address usually gives operators the clearest audit trail because each request maps to one device. A CIDR range can be reasonable for managed access-point pools or a proxy farm, but every address in the range can use the same client relationship. Hostnames add a DNS dependency because FreeRADIUS resolves client names when the service starts, so a later DNS change may need a reload before it affects client matching.

Modern RADIUS hardening also changes what a safe client definition should require. Message-Authenticator protects request integrity, and Proxy-State handling matters because proxies echo that attribute back in responses. Older NAS firmware can force a compatibility exception, but that exception should be tied to the named device rather than becoming the default posture for the whole estate.

Client configuration does not create users, assign VLANs, define EAP behavior, open firewalls, or prove that a reload succeeded. It prepares the RADIUS server to recognize trusted request sources. A clean stanza still needs a server syntax check, a controlled reload, and a real request from the device before the change is finished.

How to Use This Tool:

Build the shared trust values first, then paste the NAS inventory and let the review output decide whether the fragment is safe to copy.

1. Enter the Shared secret that will be configured on the NAS and server, or use Generate Secret for a 32-character local candidate.
   A placeholder, short, or low-variety secret produces a review warning. Replace it before a deployment draft leaves your workstation.
2. Choose Security posture. Hardened emits require_message_authenticator = yes and limit_proxy_state = yes. Compatibility emits no for both and should be reserved for a documented legacy client. Omit leaves those lines out.
3. Paste Client rows as CSV in the order name,address_or_cidr,nas_type,shortname,virtual_server,secret. The last four columns are optional, and a sixth-column secret overrides the default secret only for that row.
4. Use Normalize CSV after pasting rough rows, then check the parsed client count. If the count is lower than expected, look for blank lines, comments, or an unclosed quoted cell.
5. Open Advanced only for deployment-specific defaults: Default NAS type, Default virtual server, Add status_server = yes, Include operator comments, and reviewed Extra per-client directives.
6. Read the summary before using the output. RADIUS clients need fixes, blocking issue, or fix required means the FreeRADIUS fragment stays blank until errors are corrected.
7. Use Deployment Review to resolve Error rows first, compare Client Ledger with the device inventory, then copy or download FreeRADIUS Clients after block names, addresses, secret sources, and generated options match the planned change.

Interpreting Results:

The FreeRADIUS fragment is useful only when the summary reports ready client blocks and the error list is empty. A ready fragment means the rows passed local checks and were converted into client stanzas. It does not prove that the server accepts the configuration, that the NAS is using the same secret, or that the NAS can send the required request attributes.

Warnings are deployment decisions, not cosmetic messages. A broad CIDR may be intentional for an access-point pool, a hostname may be acceptable in a tightly managed DNS environment, and compatibility mode may be required for one old device. Each choice should be visible in the change record because it changes audit clarity, request integrity, or secret ownership.

The safest follow-up is outside the browser: paste into the intended FreeRADIUS configuration path, run the server's syntax or debug check, reload during a change window, and verify one authentication or status request from each listed NAS.

Technical Details:

A FreeRADIUS client stanza is an allowlist entry for a packet source. The server compares the source address against configured clients and uses the matching shared secret when validating packet authenticators and protected attributes. User policy begins only after that client relationship is accepted.

The client definition also carries operational intent. shortname gives operators a stable label, nas_type can help older policy logic or vendor handling, virtual_server routes requests to a named FreeRADIUS policy context, and status_server supports RADIUS status probes when monitoring uses them. Security directives belong near the client because older devices and modern hardening requirements can coexist inside the same estate.

Transformation Core:

Each accepted NAS row becomes one client stanza. When any blocking error is present, the configuration fragment is suppressed while review rows remain visible so the failed condition can be corrected before configuration is copied.

Rule Core:

Most checks are structural preflight checks for a text fragment. They reduce obvious paste mistakes and trust-boundary mistakes, but they do not replace FreeRADIUS' own parser or device testing.

Message-Authenticator is an HMAC-based RADIUS attribute used to protect packets that need stronger request integrity. Standards and FreeRADIUS guidance have moved toward requiring it for EAP-related and authorization-sensitive Access-Request traffic, and current FreeRADIUS documentation treats require_message_authenticator = no as a legacy choice with security tradeoffs. limit_proxy_state is related because Proxy-State is echoed through responses, so accepting it without request integrity can expose response manipulation risk.

Extra per-client directives are intentionally narrow. A line has to look like a simple key = value client directive, and braces or angle brackets are rejected so an extra line cannot open another block or change the surrounding structure. That check protects the shape of the fragment, not the correctness of the directive for a particular vendor or policy.

Status-Server support is separate from ordinary authentication success. A Status-Server probe can show whether a RADIUS server responds on the tested hop, but it does not prove a downstream proxy, user database, EAP method, or authorization policy will accept a real user session.

Privacy and Security Notes:

Secret generation, CSV parsing, validation, and text assembly run in the browser session. That keeps the entered shared secret out of a remote conversion step, but normal handling still matters because copied configuration, downloaded files, screenshots, and ticket notes can expose the same secret.

• Replace placeholders before sharing a change plan or attaching generated configuration.
• Move final shared secrets through the same secret-management path used for device configuration.
• Treat compatibility mode as a documented exception, not a global shortcut.
• Use the server's own syntax and debug tooling before a production reload.

Advanced Tips:

• Use per-client secrets for high-value VPN gateways, internet-facing firewalls, and shared infrastructure where one leaked secret would affect many users.
• Prefer one host address per NAS when inventory and routing allow it. Treat IPv4 ranges broader than /24 and IPv6 ranges broader than /64 as documented exceptions.
• Keep Hardened as the default security posture. Move to Compatibility only after testing the exact NAS that cannot send the required request integrity attribute.
• Use Default virtual server when all listed clients should land in the same policy context. Leave it blank when routing is controlled elsewhere.
• Turn on Add status_server = yes only when trusted monitoring clients send Status-Server probes and the firewall path allows that traffic.
• Limit Extra per-client directives to safe, reviewed client options that truly apply to every row in the pasted inventory.

Worked Examples:

Modern access devices with one default secret

Rows such as core-sw,10.44.1.10,cisco,core-sw,default, wifi-controller,10.44.2.20,other,wlc-01,default, and vpn-gateway,10.44.3.30,other,vpn-gw,default with Hardened selected produce a ready summary with 3 clients. Client Ledger shows default secret for each row, and FreeRADIUS Clients includes the hardened integrity lines for every stanza.

Access-point range that crosses the review threshold

A row like branch-aps,10.55.0.0/16,other,branch-aps,default can emit a stanza, but Deployment Review flags the address scope because /16 is broader than the IPv4 /24 review threshold. That may be reasonable for a controlled AP pool, but the change note should explain why many addresses share one client definition and secret.

Legacy NAS that cannot meet hardened checks

An older VPN appliance might require Compatibility. The resulting stanza emits require_message_authenticator = no and limit_proxy_state = no, the summary shows legacy compatible, and Deployment Review asks for documentation. The expected action is to tie the exception to that named appliance and retest when the vendor firmware changes.

Broken row that blocks all output

A line such as bad-client,10.44.999.10,other fails the address check. The summary changes to RADIUS clients need fixes, Deployment Review records a Client address Error, and FreeRADIUS Clients stays blank until the address is corrected.

FAQ:

Glossary:

RADIUS

Remote Authentication Dial-In User Service, the protocol used by access devices to ask a server for authentication, authorization, and accounting decisions.

NAS

Network access server, the device that sends RADIUS requests on behalf of users or sessions.

Client stanza

A FreeRADIUS client definition such as client NAME { ... } that identifies a trusted request source.

Shared secret

The secret value configured on both the NAS and the RADIUS server for a client relationship.

Message-Authenticator

A RADIUS attribute used to protect packet integrity, especially for EAP and modern request-hardening cases.

Proxy-State

A RADIUS attribute that proxies echo back in responses, making it important to handle carefully when request integrity is weak.

Status-Server

A RADIUS packet type used by monitoring clients to check whether a server responds on a given hop.

References:

• Client Definitions, The FreeRADIUS project, 2025.
• RFC 2865: Remote Authentication Dial In User Service (RADIUS), RFC Editor, June 2000.
• RFC 3579: RADIUS Support For Extensible Authentication Protocol (EAP), RFC Editor, September 2003.
• RFC 5080: Common RADIUS Implementation Issues and Suggested Fixes, RFC Editor, December 2007.
• RFC 5997: Use of Status-Server Packets in RADIUS, RFC Editor, August 2010.