Client Definitions

A client is defined via a section called client NAME { …​ }. The NAME field is mandatory, and is used as the "short name" of the client.

The default configuration allows packets from 127.0.0.1, and no other IP address. This configuration is to allow testing of the server after an initial installation. If you are not going to be permitting RADIUS queries from localhost, we suggest that you delete, or comment out, the 'localhost' entry.

IPv4 or IPv6 addresses with optional CIDR notation /<mask> to specify ranges can be used. ipaddr will also accept domain names, e.g. example.org, and will resolve the name via DNS (however, see note of recommendation below).

If both A and AAAA records are found, A records will be used in preference to AAAA.

The server also looks up the IP address from DNS once, and only once, when it starts. If the DNS record is later updated, the server will not see that update.

If unspecified, defaults to "udp", which is the traditional RADIUS transport. It may also be "tcp", in which case the server will accept connections from this client only over TCP.

The secret can be any string, up to 8k characters in length.

Control codes can be entered via octal encoding:

secret = "\101\102" is the same as AB

Quotation marks can be entered by escaping them:

secret = "foo\"bar"

or by using triple quotes:

`secret = """foo"bar"""

A note on security: The security of the RADIUS protocol depends COMPLETELY on this secret! We recommend using a shared secret that at LEAST 16 characters long. It should preferably be 32 characters in length. The secret MUST be random, and should not be words, phrase, or anything else that is recognisable.

Computing power has increased enormously since RADIUS was first defined. A hobbyist with a high-end GPU can try ALL of the 8-character shared secrets in about a day. The security of shared secrets increases MUCH more with the length of the shared secret, than with number of different characters used in it. So don’t bother trying to use "special characters" or anything else in an attempt to get un-guessable secrets. Instead, just get data from a secure random number generator, and use that.

You should create shared secrets using a method like this:

dd if=/dev/random bs=1 count=24 | base64

This process will give output which takes 24 random bytes, and converts them to 32 characters of ASCII. The output should be accepted by all RADIUS clients.

You should NOT create shared secrets by hand. They will not be random. They will will be trivial to crack.

The default secret below is only for testing, and should not be used in any real environment.

require_message_authenticator::Require Message-Authenticator in Access-Requests.

RFC 5080 suggests that all clients should include it in an Access-Request. The configuration item below allows the server to require it. If a client is required to include a Message-Authenticator and it does not, then the packet will be silently discarded.

If value is` auto`, then when an Access-Request packet from the client contains a valid Message-Authenticator attribute, the server will then require that it exist in all future Access-Request packets from that client.

This flag exists solely for legacy clients which do not send Message-Authenticator in all Access-Request packets. We do not recommend setting it to no, as that may allow the BlastRADIUS attack to take place.

The number one way to protect yourself from the BlastRADIUS attack is to update all RADIUS servers, and then set this flag to yes. If all RADIUS servers are updated, and if all of them have this flag set to yes for all clients, then your network is safe. You can then upgrade the clients when it is convenient, instead of rushing the upgrades.

Allowed values: yes, no, auto

The default is "no".

The BlastRADIUS attack allows an attacker to manipulate the contents of responses to Access-Request packets, without knowing the shared secret.

The attack relies on controlling a portion of the data sent back in the response by the RADIUS server. As Proxy-State is always echoed back verbatim from the request, it can be leveraged to manipulate the data sent back from the server and facilitate the attack.

The attack also relies on deficiencies in the original RADIUS standards which do not provide xintegrity protection for `Access-Request`s.

The attack is mitigated by requiring the Message-Authenticator, which contains a HMAC over the entire request, preventing modification of the request by the attacker.

If value is` auto`, then when an Access-Request packet from the client contains does not contain a Proxy-State attribute, the server will the discard Access-Request packets from the client which contain Proxy-State, but no `Message-Authenticator.

This provides some level of protection against the blastradius attack, without requiring Message-Authenticator in all packets, or breaking existing deployments.

Allowed values: yes, no, auto

The default is "auto".

It is accepted for compatibility with 1.x, but it is no longer necessary in >= 2.0.

By default, shortname is set to the name of the subsection. e.g. if we have client localhost {…​}, then shortname is set to localhost.

Defining an IPv6 client for localhost using the ipv6addr option.

All IPv6 Site-local clients

client sitelocal_ipv6 { }

Client that uses a DNS hostname. (See important note on the use of hostname above.)

client example.org { }

You can specify one secret for a network of clients. When a client request comes in, the best match is chosen, i.e. the entry from the smallest possible network.

client private-network-1 { }

client private-network-2 { }