{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
Enter the default RADIUS client secret used by generated FreeRADIUS client blocks.
Secrets stay local in the browser.
Use hardened for modern clients; use compatibility only when a known legacy NAS cannot send Message-Authenticator.
One NAS per row. Use CSV: name, address or CIDR, optional NAS type, shortname, virtual server, and per-client secret.
{{ result.clientCount }} parsed client{{ result.clientCount === 1 ? '' : 's' }}.
FreeRADIUS accepts other for generic devices; use a vendor value only when your policy depends on it.
Use default for simple deployments, or leave blank when client routing is controlled elsewhere.
Emits status_server when your monitoring probes use RADIUS status requests for these clients.
Adds concise comments for handoff without changing FreeRADIUS behavior.
One directive per line, such as login = admin. Avoid secrets or policy lines that should differ per device.
{{ result.configText || '# Fix validation errors to generate the FreeRADIUS client blocks.' }}
Client block Address NAS type Secret source Generated options Copy
No client rows parsed yet.
{{ row.blockName }} {{ row.address }} {{ row.nasType }} {{ row.secretSource }} {{ row.optionSummary }}
Check Status Detail Next action Copy
{{ row.check }} {{ row.status }} {{ row.detail }} {{ row.action }}
Tags: Networking, Security, Sysadmin
Export to PDF Fullscreen
Customize
Advanced
:

RADIUS client configuration tells a RADIUS server which network access servers are allowed to send authentication, accounting, or status traffic. Each switch, wireless controller, VPN gateway, firewall, or other NAS needs a recognizable client block with an address and a shared secret. If the client definition is missing, too broad, duplicated, or paired with the wrong secret, valid authentication requests can be ignored or unauthorised devices can be trusted too widely.

The job is small but easy to get wrong during onboarding. A client name must be safe for the configuration file, the address should point at one device or an intentional CIDR range, the shared secret must match the NAS exactly, and security directives need to reflect what the device can actually send. Modern deployments usually prefer Message-Authenticator protection, while older equipment sometimes needs a compatibility setting until it can be replaced or upgraded.

RADIUS client stanza flow CSV client rows become validated RADIUS client stanzas with shared secrets, security directives, review findings, and handoff outputs. CSV rows name address Validate tokens and IPs Secret check length variety client name {} ipaddr secret nas_type shortname Review pass warn error Handoff config ledger JSON
A useful client block is more than an address and secret. It also needs safe naming, narrow scope, compatible security directives, and a review note for handoff.

Client blocks do not create users or authorization policy by themselves. They define the trusted devices that may ask the server to process RADIUS requests. That makes the result suitable for staging a clients.conf fragment, preparing a change note, or comparing a NAS inventory against what will be pasted into the server. It does not prove that the NAS, user database, EAP method, firewall path, or server reload will succeed.

The strongest review habit is to treat generated configuration as a draft until the final address, secret, and security posture are checked against the device and the server version. A clean fragment can still fail if the NAS sends requests from a different source IP, uses a copied placeholder secret, or cannot include the Message-Authenticator attribute required by a hardened server.

Technical Details:

RADIUS uses a client-server trust relationship. A NAS sends an Access-Request or related packet to a RADIUS server, and the server first decides whether the packet came from a configured client address with a matching shared secret. Unknown clients are ignored. Known clients can then be processed by the server policy, user database, proxy logic, or virtual server assigned to that client definition.

A clients.conf-style block is a server-side allowlist entry for a client address. The required pieces are the block name, the client address or range, and the shared secret. Optional fields such as short name, NAS type, virtual server, status support, and security directives add routing and operational intent. Ranges are convenient for managed access-point fleets, but one broad CIDR also means every address in that range shares the same client trust decision.

Message-Authenticator is an HMAC-based integrity attribute for RADIUS packets. Requiring it makes request tampering harder and is especially important when Proxy-State could otherwise be echoed through server responses. Compatibility settings can keep older devices working, but they should be tied to a named legacy device rather than used as a general default.

Rule Core

The generated stanza follows a fixed client-block pattern. Optional directives appear only when the relevant setting or CSV column provides a value.

Directive or field Source Meaning in the client block Review cue
client NAME {} CSV name column Names the client stanza and gives operators a stable label for review. Duplicate names block output because client stanzas must be unique.
ipaddr CSV address column Accepts an IPv4 host, IPv6 host, CIDR range, or safe hostname. Broad IPv4 ranges under /24, broad IPv6 ranges under /64, and hostnames are flagged for review.
secret Row secret or default shared secret Supplies the shared secret used between the NAS and server. Blank values, unsupported characters, placeholders, short values, and weak character variety are flagged.
shortname and nas_type CSV columns or defaults Add operator-friendly identity and NAS family hints. Unsafe token characters are normalized or rejected so pasted configuration stays parseable.
virtual_server CSV column or default virtual server Routes requests from that client to a named server policy when present. Leaving it blank omits the directive, which is appropriate when routing is handled elsewhere.
require_message_authenticator and limit_proxy_state Security posture Controls request integrity and Proxy-State handling for each emitted client. Hardened emits yes/yes; compatibility emits no/no; omit leaves both directives out.
status_server Status-server switch Allows monitored Status-Server requests when the deployment uses RADIUS status probes. Use it only when trusted monitoring clients are expected to send those probes.

CSV parsing accepts six columns in order: name, address or CIDR, NAS type, short name, virtual server, and per-client secret. The last four columns are optional. A header row beginning with name, is skipped, quoted CSV cells are accepted, and rows starting with # are ignored. Each valid row becomes one stanza; rows with blocking errors stay out of the generated fragment.

Condition Status Practical meaning
Invalid address, empty client inventory, duplicate client block, unsafe secret, or unsafe extra directive Error No usable client fragment is emitted until the blocking issue is fixed.
Placeholder secret, short secret, missing character variety, broad CIDR range, duplicate address, hostname address, or compatibility security posture Review The fragment can be emitted, but the change owner should confirm the choice before deployment.
Extra valid directives, status-server choice, normalized names, or generated option summaries Info The item changes the handoff note or final stanza without blocking output.
Strong default secret, hardened security posture, and at least one valid client row Pass The draft is ready for a server-side review and a controlled reload test.

Extra per-client directives are appended to every client block only when each line starts with a simple key, then an equals sign. Braces, angle brackets, and malformed lines are rejected because they could break the surrounding stanza or hide another block. That protection does not judge whether a directive is semantically right for a vendor; it only keeps the emitted fragment structurally narrow.

Everyday Use & Decision Guide:

Start with a small NAS inventory instead of a whole estate. Enter a real Shared secret, choose Hardened for modern clients, and paste one row per device into Client rows. The default sample shows the expected shape: client name, address, NAS type, short name, and virtual server. Add the sixth column only when a specific device needs its own secret.

Use Generate Secret for a 32-character candidate secret, then copy it into the NAS configuration through your normal secret-handling process. The local check requires a non-empty value without spaces, braces, or comment characters. It also warns on placeholders, values under 20 characters, and secrets that lack mixed upper-case, lower-case, numeric, and symbol characters.

  • Use one host address per row for switches, firewalls, VPN gateways, and controllers unless a CIDR range is intentional and documented.
  • Leave Default NAS type as other unless server policy depends on a vendor token such as cisco or juniper.
  • Set Default virtual server to default for simple deployments, or leave it blank when client routing is controlled elsewhere.
  • Keep Add status_server = yes enabled only when monitoring probes are expected for those clients.
  • Use Extra per-client directives for reviewed lines that truly apply to every listed NAS device.

The main mistake is treating a generated stanza as proof that the client will authenticate. It only means the fragment passed local syntax and review checks. Confirm the NAS source IP, the secret on both ends, the Message-Authenticator capability, firewall reachability, and the server reload plan before pasting the output into production.

Use Deployment Review as the change checklist. Clear every Error, document each Review item, then compare Client Ledger against the device inventory before copying the final client fragment.

Step-by-Step Guide:

Work from inventory to review so blocking issues appear before the fragment is used.

  1. Enter Shared secret or press Generate Secret. If Deployment Review reports a placeholder, short value, or unsupported characters, replace the secret before using the client fragment.
  2. Choose Security posture. Hardened emits require_message_authenticator = yes and limit_proxy_state = yes; Compatibility emits no for both and should produce a review note.
  3. Paste rows into Client rows using name,address_or_cidr,nas_type,shortname,virtual_server,secret. Press Normalize CSV when pasted rows have inconsistent spacing or quoting.
  4. Open Advanced and set Default NAS type, Default virtual server, Add status_server = yes, Include operator comments, and Extra per-client directives only as needed for the deployment.
  5. Read the summary box. RADIUS clients need fixes and a fix required badge mean the generated client fragment is intentionally blank until errors are corrected.
  6. Open Deployment Review. Fix Error rows first, then decide whether each Review row is acceptable for the change record.
  7. Open Client Ledger and compare Client block, Address, NAS type, Secret source, and Generated options with the device inventory.
  8. Use FreeRADIUS Clients for the final stanza text, then keep JSON nearby when another system or ticket needs the same client count, review rows, and settings in structured form.

Interpreting Results:

The final client fragment is usable only when there are no blocking errors. A ready summary means valid rows produced stanzas; it does not mean the server accepted the file, the NAS secret matches, or the client can send the required packet attributes.

Review warnings deserve a real decision. A hostname address may resolve differently after service start, a broad CIDR may trust more devices than intended, and compatibility mode reduces the integrity checks that hardened mode emits. A placeholder secret warning should stop handoff until the secret is replaced on both the NAS and server.

Visible cue Best reading What to verify next
blocking issue in the summary At least one row or directive prevents config output. Use Deployment Review to find the exact failed address, secret, duplicate, or directive.
placeholder secret badge The output may still contain a demo-style secret. Replace it and confirm the same value is entered on the NAS.
legacy compatible badge Compatibility directives are selected instead of hardened request checks. Document the legacy device and retest hardened mode when the NAS supports it.
row secret in Client Ledger That client uses the sixth CSV column instead of the default secret. Verify that the device owner expects a unique secret for that NAS.

The review output gives a clean handoff path, not operational proof. Test the pasted fragment with the server’s own configuration checker or debug mode, reload during a change window, and confirm one real Access-Request from each NAS before closing the task.

Worked Examples:

Three modern NAS devices

A row set 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, Add status_server = yes, and a non-placeholder secret produces 3 clients in the summary. Client Ledger shows default secret for all three rows and generated options including require_message_authenticator=yes, limit_proxy_state=yes, and status_server=yes.

Broad range that needs a change note

A row like branch-aps,10.55.0.0/16,other,branch-aps,default can still emit a client block, but Deployment Review flags the address scope because an IPv4 prefix under /24 covers a broad client range that will share one secret. The result may be right for a managed AP pool, but the change note should explain why a range is intended instead of one block per NAS IP.

Legacy compatibility with a named exception

If an older VPN appliance cannot send Message-Authenticator, selecting Compatibility emits require_message_authenticator = no and limit_proxy_state = no. The summary badge changes to legacy compatible, and Deployment Review asks for documentation. Treat that as an exception tied to the VPN device, not as a default for the rest of the client inventory.

Broken CSV row before output

A line such as bad-client,10.44.999.10,other produces a Client address error because the IPv4 address is invalid. The summary changes to RADIUS clients need fixes, and the client fragment shows a placeholder message instead of stanzas. Correct the address, then recheck Client Ledger before copying the final text.

FAQ:

Can I use one shared secret for every client?

The generator supports one default Shared secret for all rows, but Client Ledger makes the source visible so you can decide whether per-client secrets are needed. A row-specific secret in the sixth CSV column overrides the default for that client only.

Why is the generated client fragment blank?

Blocking validation errors suppress the fragment. Open Deployment Review and fix errors such as an invalid address, duplicate client block, unsafe secret, unclosed quoted CSV cell, empty inventory, or unsafe extra directive.

Should I use hardened or compatibility mode?

Use Hardened for clients that can send Message-Authenticator. Use Compatibility only for a documented legacy NAS because it emits no for both request integrity and Proxy-State limiting directives.

Are hostnames accepted for client addresses?

Yes, safe hostnames are accepted, but the review warns you to confirm resolution behavior. A fixed IP address is usually easier to audit because the server trusts the address that sends the RADIUS packet.

Where are secrets processed?

Secret generation, CSV parsing, validation, and output assembly run in the browser. The result still needs careful handling because copied configuration, downloaded files, and ticket notes can expose shared secrets.

Glossary:

NAS
A network access server such as a switch, wireless controller, VPN gateway, or firewall that sends RADIUS requests.
Shared secret
The secret value configured on both the NAS and the RADIUS server for that client relationship.
Message-Authenticator
A RADIUS integrity attribute that helps the server verify that a packet has not been modified.
Proxy-State
A RADIUS attribute that proxies echo back in responses, which is why limiting it matters for request integrity.
Virtual server
A named server policy target that can route requests from a client to a specific processing path.
Status-Server
A RADIUS status probe used by monitoring clients to check whether a server is responsive.

References: