{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Transport{{ transportBadge }} Security{{ securityBadge }} Review{{ reviewBadge }}

RADIUS topology visual unavailable.

Use a device-specific high-entropy value. The shipped value is deliberately non-deployable.
Generation and checks stay in this browser.
Transport:
Choose the transport accepted by the target FreeRADIUS listener.
Required is the strict default. Use Automatic or legacy compatibility only after checking real packet behavior.
One NAS per line: name and IP/CIDR are required; NAS type, shortname, virtual server, and per-client secret are optional.
{{ parsedInputCount }} non-comment row{{ parsedInputCount === 1 ? '' : 's' }} detected.
Applied only when a client row omits the NAS type column.
Applied only when a client row omits its virtual server column.
Comments are optional and do not change FreeRADIUS behavior.
{{ params.include_comments ? 'Enabled' : 'Disabled' }}
Use one reviewed `key = value` directive per line. Do not place per-device secrets here.
{{ computation.values.config_text }}

Generate or enter a deployable shared secret before copying or downloading the configuration.

The chart renderer is unavailable. Address types remain available in the client ledger.

ClientAddressScopeNAS typeSecretCopy
{{ row.block_name }}{{ row.address }}{{ row.address_type }}{{ row.nas_type }}{{ row.secret_source }}
StateCheckFindingNext actionCopy
{{ row.state }}{{ row.check }}{{ row.detail }}{{ row.action }}
Interface Description Standard Checker Check network interface descriptions for endpoint evidence and policy gaps, then prioritize duplicates or length issues before cleanup and change review.
CSP Header Policy Checker Check a Content-Security-Policy header for risky script sources and missing baseline directives, with reporting and rollout blockers explained.
OpenVPN Client Config Generator Generate an OpenVPN client profile with matched routing, TLS, cipher, and credential choices plus import and security review warnings.
WireGuard Config Generator Generate WireGuard server and client configurations with CIDR validation, route-scope warnings, and explicit placeholders for safer key handling.

Network access servers such as switches, wireless controllers, and VPN gateways do not become trusted RADIUS senders merely because they can reach the server. The RADIUS server needs a client definition that ties each device to an address and a shared secret. In this context, a client is the network device sending authentication or accounting packets, not the person signing in.

The address decides which sender may use the secret. A single host address keeps that trust boundary narrow, while a CIDR range allows every address in the range to present the same credentials. Network-wide definitions can be useful for a deliberately managed appliance pool, but they also make accidental overlap and secret reuse more consequential. A hostname is possible, although FreeRADIUS resolves it when the server starts, so a stable address is usually easier to operate.

Shared secrets protect RADIUS traffic between a network access server and the RADIUS server. They should be unique to a device, long enough to resist guessing, and installed at both ends through a controlled channel. Reusing one secret across a fleet makes rotation simpler at first, but one disclosure then affects every device that shares it.

Message-Authenticator
An integrity attribute that lets the server detect modified Access-Request packets. Requiring it is stronger, but legacy devices that do not send it will be rejected.
Proxy-State limit
A related safeguard for requests that carry Proxy-State without Message-Authenticator. It reduces exposure to response-manipulation attacks.
Virtual server
An optional FreeRADIUS routing choice that sends one client's requests to a named policy context.

UDP is the traditional RADIUS transport. TCP should be selected only when the listener and every affected network device support it. Transport and security settings therefore belong to a deployment plan, not a formatting preference.

A syntactically clean client stanza is still only a candidate configuration. The installed FreeRADIUS release, listener setup, firewall path, device firmware, and real packet behavior determine whether it is safe to deploy.

How to Use This Tool:

Start with the smallest set of known network devices and choose settings that those devices have already been shown to support.

  1. Enter a strong Shared secret. A sixth CSV column can replace it for an individual device, which is the preferred route when each device has its own secret.
  2. Choose UDP or TCP, then select the Security posture. Keep the hardened setting only when every listed device sends Message-Authenticator as required.
  3. Paste one Client row per device in name, address, NAS type, shortname, virtual server, and optional per-client secret order. Only the name and address are required; the list accepts at most 200 rows.
  4. Review normalized names, duplicate addresses, hostnames, broad CIDR ranges, and secret findings in Deployment review. Correct blocking input errors before relying on the generated stanza.
  5. Inspect Client config, then validate the complete fragment with the installed FreeRADIUS release before placing it in service.

Interpreting Results:

Ready means the rows passed the local structure and secret checks. It does not prove that a device can reach the listener, that both ends share the same secret, or that the device sends the attributes required by the selected security posture.

  • If Secret state says to replace the sample, the configuration can be inspected but copy and download remain unavailable.
  • A review item identifies a choice that needs operator confirmation, such as a hostname, a duplicate address, TCP transport, or a broad network definition.
  • The address profile is an inventory summary. A small host count does not make a CIDR entry safe, and a clean chart does not replace a configuration test.

Technical Details:

A FreeRADIUS client block names one trusted packet source, identifies that source through ipaddr, and associates it with a secret. Optional values add an operator-friendly short name, a NAS type, a virtual server, TCP transport, and security requirements. The generated blocks are deterministic: the same validated rows and settings produce the same configuration text.

Transformation Core:

Each non-comment CSV row is parsed, validated, completed with defaults, and emitted as one client block. A header row beginning with name and address is ignored.

Stage Rule Result
Row parsing Read up to six CSV cells; quoted commas and doubled quotes are supported Name, address, NAS type, shortname, virtual server, secret
Defaulting Fill omitted NAS type, virtual server, and secret from the shared values One complete client record
Normalization Keep safe block tokens; replace unsupported name characters with hyphens A review item when the name changes
Composition Emit the required lines, selected security directives, and reviewed extra directives One client NAME { ... } stanza per valid row

Rule Core:

Blocking rules prevent ambiguous or unsafe syntax from reaching the configuration. Review rules preserve output while calling attention to a deployment decision.

Subject Accepted rule Review boundary
Address IPv4 or IPv6 host, CIDR network, or valid hostname IPv4 prefixes shorter than /24 and IPv6 prefixes shorter than /64 are marked broad; hostnames carry a startup-resolution warning
Secret 1 to 128 unquoted safe characters with no whitespace or block delimiters Placeholders, fewer than 20 characters, or missing upper case, lower case, number, or symbol classes are not deployable
Security posture Hardened emits yes/yes; Automatic emits auto/auto; Legacy emits no/no; Server defaults emits neither directive Every posture except Hardened requires an explicit review
Transport UDP emits no proto line; TCP emits proto = tcp TCP requires listener and device compatibility review
Batch limits At most 200 rows and 20,000 characters; extra directives are limited to 4,000 characters Duplicate block names block output; duplicate addresses produce a review item

Extra directives must be single bounded key = value lines. Braces, comments, angle brackets, and semicolons are rejected, and every retained directive is appended to every client block. Per-device secrets belong in the client rows, not in this shared field.

Security and Privacy Notes:

Client rows and secrets are processed in the browser and are not sent to a server for generation. The resulting configuration contains the secrets in readable form, so treat copied or downloaded output as sensitive configuration data.

  • Replace the supplied sample value and avoid sharing one secret across unrelated devices.
  • Store generated fragments with restricted permissions and keep them out of tickets, chat logs, and public repositories.
  • Test strict Message-Authenticator settings against real device traffic before enforcing them across a mixed or legacy fleet.

Worked Examples:

One access switch with a device-specific secret

A row for core-sw at 10.44.1.10 can supply its own sixth-column secret while using the shared NAS type and virtual server defaults. With Hardened selected, the stanza also requires Message-Authenticator and limits Proxy-State. The result is ready only after the per-device secret passes the length and character-variety checks.

A network range that widens trust

Entering 10.44.0.0/22 is valid IPv4 CIDR syntax, but the prefix is shorter than /24, so the deployment review marks it as broad. Replace the range with individual NAS addresses unless every address in that network is intentionally allowed to use the same client definition.

References: