Section 3.120. <ServerRADSEC>

3.120. <ServerRADSEC>

This clause accepts RadSec (RFC 6614) connections from <AuthBy RADSEC> clauses in other Radiators other RadSec clients and processes RADIUS requests sent over the RadSec connection in a similar way to how a Client clause received conventional UDP RADIUS requests. RadSec can be used to provide secure reliable proxying of RADIUS requests from one Radiator to another, even over insecure networks. For more information, see RadSec white paper

.

Both <ServerRADSEC> and any RadSec clients that connect to it must have the same Secret configured, otherwise they are not able to exchange RADIUS requests correctly, irrespective of whether any TLS or other configuration parameters are correct. For compliance with RFC 6614, ServerRADSEC defaults to a Secret of radsec.

All valid RADIUS requests received by <ServerRADSEC> are dispatched to the first matching <Realm> or <Handler> clause, in the same was as the <Client> clause. The reply to any incoming request will be automatically delivered back to the original requesting RadSec client.

<ServerRADSEC> supports TLS. For more information about TLS parameters, see Section 3.11. TLS configuration. When you enable TLS, you must configure a server certificate, otherwise a RadSec client is not able to establish a TLS encrypted connection to <ServerRADSEC>.

ServerRADSEC has TLS_RequireClientCert enabled by default. When a RadSec client presents a certificate to the RadSec Server, the RadSec server performs a number of checks to validate the client certificate. The client certificate is checked for valid start and end dates, and also checks the chain of validity back to the issuing Certificate Authority, using the root certificates specified in TLS_CAFile or TLS_CAPath. If TLS_PolicyOID parameter is defined, the OIDs must be present in the certificate path. Also a client certificate is only accepted if at least one of the following conditions are true:

The IP address of the client exactly matches a subjectAltName with type IPADD (IP Address) in the certificate. If subjectAltNameDNS is configured, its value is used to match the certicicate's subjectAltName values with type DNS.
The Subject in the certificate matches the pattern specified by the TLS_ExpectedPeerName parameter in this <ServerRADSEC> clause.

and

If TLS_SubjectAltNameURI parameter is defined in the <ServerRADSEC> clause, the certificate must contain a subjectAltName of type URI that matches the TLS_SubjectAltNameURI regular expression.
If TLS_CertificateFingerprint parameter is defined in the <AuthBy RADSEC> clause, the certificate's fingerprint must match at least one of the TLS_CertificateFingerprint options.

Note that the default TLS_ExpectedPeerName pattern is .+, which matches any Subject. This means than in the default configuration, <ServerRADSEC> accepts any client whose client certificate can be validated against a root certificate specified by TLS_CAFile or TLS_CAPath.

These certificate validation rules are consistent with RFC 2595.

3.120.1. Port

This optional parameter specifies which network port <ServerRADSEC> listens to for connections from RadSec clients. The default value 2083, the official IANA port number for RadSec. Port can be a numeric port number or symbolic port or service name.

3.120.2. BindAddress

This optional parameter specifies one or more network interface addresses to listen for incoming connections. It is only useful if you are running Radiator on a multi-homed host (a host that has more than one network address). The default value is the global BindAddress, which defaults to 0.0.0.0. It listens to all networks connected to the host. For more information, see Section 3.7. Global parameters.

Using this parameter, you can run multiple instances of Radiator on the one computer, where each instance listens to connections directed to a different host address. BindAddress can include special formatting characters, and multiple comma separated IPv4 and IPv6 addresses.

When SCTP multihoming is supported, all addresses defined with BindAddress must be either IPv4 or IPv6 addresses. Radiator binds all addresses to one listen socket instead of creating multiple listen sockets.

Here is an example of using BindAddress:

# Only listen on one IPv4 address and the IPv6 loopback
BindAddress 203.63.154.1, ::1

3.120.3. Secret

This parameter specifies the shared secret that will be used between this <ServerRADSEC> and RadSec clients that connect to it. The shared secret is used in the same way as Secret parameter in the Client clause: to encrypt passwords and generate message authenticators. The shared secret must be configured identically into <ServerRADSEC> and all RadSec clients that connect to it, regardless of whether TLS is enabled or not. An authentication error will occur if the shared secret is not correctly configured. For compliance with RFC 6614, the default value is radsec.

3.120.4. RewriteUsername

This is an optional parameter. It enables you to alter the username in authentication and accounting requests. For more details and examples, see Section 8. Rewriting user names.

3.120.5. StripFromRequest

This optional parameter strips the named RADIUS attributes from the RADIUS requests received by ServerRADSEC before passing them to any authentication modules. The value is a comma separated list of attribute names. StripFromRequest removes attributes from the request before AddToRequest adds any to the request. There is no default.

# Remove any NAS-IP-Address,NAS-Port attributes
StripFromRequest NAS-IP-Address,NAS-Port

3.120.6. AddToRequest

This optional parameter adds any number of RADIUS attributes to the RADIUS requests that <ServerRADSEC> receives. It can be used to tag requests arriving from RadSec for special handling within Radiator or in remote RADIUS servers.

Here is an example of using AddToRequest:

AddToRequest NAS-Identifier=RADSEC

3.120.7. AddToRequestIfNotExist

This string is an optional parameter. It adds attributes to the requests that <ServerRADSEC> receives. Unlike AddToRequest, an attribute is added only if it does not exist in the request already. The value is a comma-separated list of attribute-value pairs.

3.120.8. AllowInReject

This optional parameter specifies the only attributes that are permitted in an Access-Reject. This can be useful in Handlers with multiple AuthBys where the attributes added before a rejecting AuthBy need to be stripped from the resulting Access-Reject.

AllowInReject is not set by default and does not remove anything from Access-Rejects.

# Only permit a limited set of attributes in a reject.
AllowInReject Message-Authenticator, EAP-Message

3.120.9. DefaultRealm

This optional parameter can be used to specify a default realm to use for received RadSec requests that have a user name that does not include a realm. If the incoming user name does not have a realm (i.e. there is no @something following the user name) and if DefaultRealm is specified, the User-Name in the resulting RADIUS request will have @defaultrealm appended to it. The realm can then be used to trigger a specific <Realm> or <Handler> clause. This is useful if you operate a number of RadSec clients for different customer groups and where some or all of your customers log in without specifying a realm.

# Realmless logins to this NAS will be treated
# as if they are for realm open.com.au
<ServerRADSEC>
      Secret ....
      .....
      DefaultRealm open.com.au
</Client>
<Realm open.com.au>
      .....
</Realm>

3.120.10. Protocol

This optional parameter specifies which Stream protocol is used to carry RadSec. Options are tcp for TCP/IP or sctp for SCTP (Stream Control Transmission Protocol). The default value is tcp. Not all hosts are able to support sctp, consult your vendor. The protocol setting must be the same in each RadSec server and client.

Protocol sctp

Tip

On modern Linux hosts, SCTP support is in a loadable module, and can be enabled with:

modprobe sctp

3.120.11. PreHandlerHook

This optional parameter allows you to define a Perl function that is called during packet processing. It can be configured within several types of clauses for which its functionality is slightly different:

Client clause
PreHandlerHook is called for each request after per-Client user name rewriting and duplicate rejection, and before the request is passed to a Realm or Handler clause.
AuthBy clause
The functionality depends on the used EAP authentication type:
- PEAP, EAP-TTLS, EAP-FAST
  PreHandlerHook specifies a Perl hook to be called before the inner request is re-dispatched to a matching Realm or Handler.
- LEAP
  If EAP_LEAP_MSCHAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
- EAP-MSCHAPv2
  If EAP_PEAP_MSCHAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
- EAP-GTC
  If EAP_GTC_PAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
AuthBy DYNAUTH clause
PreHandlerHook is called for each request created by the clause before the request is passed to a Realm or Handler clause.
ServerRADSEC clause
PreHandlerHook is called for each request after global and per-ServerRADSEC user name rewriting and before the request is passed to a Realm or Handler clause.
ServerDIAMETER clause
PreHandlerHook is called for each request received by ServerDIAMETER before the request is passed to a Realm or Handler clause.
ServerTACACSPLUS clause
PreHandlerHook is called for each request before it is passed to a Realm or Handler clause. If a Client is found for the request, Client's PrehandlerHook is run before ServerTACASPLUS's PreHandlerHook. Global and per-Client user name rewriting and other processing is done before the hooks are run.

A reference to the request is passed as the only argument.

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code are reported to the log file at start-up time. Runtime errors in your hook are also reported to the log file when your hook executes. Multiline hooks with trailing backslashes (\) are parsed by Radiator into one long line. Therefore, do not use trailing comments in your hook.

PreHandlerHook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things. Here is an example of using PreHandlerHook:

# Fake a new attribute into the request
PreHandlerHook sub { ${$_[0]}->add_attr('test-attr', \
      'test-value');}

3.120.12. Identifier

This optional parameter can be used to match Client-Identifier check items in Handler and other clauses, so that you can trigger special behaviour for requests received by a particular ServerRADSEC clause.

3.120.13. PacketTrace

This optional flag forces all packets that pass through this module to be logged at trace level 5 until they have been completely processed. This is useful for logging packets that pass through this clause in more detail than other clauses during testing or debugging. The packet tracing stays in effect until it passes through another clause with PacketTrace set off or 0.

PacketTrace is available for the following clauses:

Client
Handler
Realm
AuthBy
ServerDIAMETER
ServerRADSEC
ServerTACACSPLUS

Here is an example of using PacketTrace:

# Debug any packets that pass through here
PacketTrace

3.120.14. StatusServer

Normally, when a Status-Server request is received, Radiator replies with some statistics including the total number of requests handled, the current request rate and so on. You can control Status-Server response by setting StatusServer to one of the following values:

off
Status-Server requests are ignored.
minimal
Reply without any attributes.
default
Reply with statistics.

3.120.15. MaxBufferSize

This optional advanced parameter specifies the maximum number of octets that are output and input buffered by Radiator's Stream modules. This advanced parameter usually does not need adjusting.

3.120.16. DisconnectTraceLevel

This optional parameter specifies log trace level for peer initiated disconnects. The default value is error level 0. When connections are known to be short-lived, a non-default value may be useful. This parameter is available for all Stream based modules, such as <ServerDIAMETER> and <AuthBy RADSEC>.

# Debug logging is enough for peer disconnects
DisconnectTraceLevel 4

3.120.17. StreamMaxClients

This optional parameter specifies the maximum number of accepted connections for each listen socket. This parameter is not set by default. When the parameter is set to zero or unset, no restrictions apply. This parameter is available for all StreamServer based modules, such as <ServerDIAMETER> and <ServerRADSEC>.

With server farm, see FarmSize, this parameter allows distributing all incoming connections equally between worker processes. For example, if the number of connections is known not to exceed 10, a farm of 12 workers will have 2 spare workers with each of the 10 remaining workers handling one connection each.

Note

Currently this parameter is used as follows: All values larger than 0 are treated as 1.

# Allow one connection for each listen socket
StreamMaxClients 1

3.120.18. Clients

This optional parameter specifies a list of IP addresses that connections will be accepted from. You can specify one or more comma or space separated IP addresses on each Client line. You can specify multiple Client parameters. Only exact matches are supported at present. The default is to accept connections from any and all clients.

If Clients is specified and a client attempts to connect from an IP address that is not named, Radiator will log a WARNING level message then reject and close the connection.

# Only accept connections from some addresses
Clients 127.0.0.1, 203.63.154.29
Clients 203.63.154.27