Table of Contents Table of contents: Radiator® AAA Server Gossip configuration 3.13 - Gossip configuration <ClientListLDAP> 3.15 - <ClientListLDAP>

3.14. <Client xxxxxx>

The beginning of a Client clause. The clause continues until </Client> is seen on a line. A Client clause specifies a RADIUS client that this server will listen to. Requests received from any client not named in a Client clause in the configuration file will be silently ignored. The DEFAULT client (if defined) will handle requests from clients that are not defined elsewhere.
You must have a Client clause for every RADIUS client which your server is expected to serve, or else a DEFAULT Client. In each Client clause replace the xxxxxx with either the DNS name or the IP address of the host machine where the RADIUS client is running, or with MAC: and the MAC address of the client. IPv4 and IPv6 addresses are supported. IPv6 addresses can only be received if an IPv6 BindAddress has been specified (See Section 3.7.9. BindAddress). IPv4 and IPv6 CIDR address notation is permitted.
DNS names are resolved only once when the client instance is created during the configuration. MAC address of the client is looked up from Called-Station-Id RADIUS attribute.
Client clauses are also used by TACACS+. For more information, see Section 3.119. <ServerTACACSPLUS>.
If an incoming request is capable of matching multiple Client clauses, the clause is chosen as follows:
Tip
IPv6 addresses are not required to be prefixed with ‘ipv6:’ with Radiator 4.13 or later.
In the following example, the radius server will only respond to requests received from either oscar.open.com.au or from IPv4 address 203.63.154.7 or IPv4 network 203.10.1.0/24 or from IPv6 address 2001:db8:100:f101:0:0:0:1 or from IPv6 network 2001:db8:100::/64 and each client has a different shared secret. MAC match and DEFAULT client are commented out and thus not used.
Note
For more information about addresses starting with ::ffff, see Section 3.7.10. BindV6Only.
<Client oscar.open.com.au>
      Secret XG1gFty566
</Client>
<Client 203.63.154.7>
      # An IPv4 client
      Secret kj1fgkj77878&
</Client>
<Client 203.10.1.0/24>
      # An IPv4 class C address group
      Secret ljdfhjlsd
</Client>
<Client ::ffff:203.10.1.0/120>
      # See the note above
      Secret ljdfhjlsd
</Client>
<Client 2001:db8:100:f101:0:0:0:1>
      # An IPv6 client
      Secret pqr
</Client>
<Client 2001:db8:100::/64>
      # An IPv6 /64 sized network
      Secret pqr
</Client>

#<Client MAC:2a-1f-09-5a-25-2a>
#      # Client identified by its MAC address
#      Secret gshgs
#</Client>
## Handle all other clients with this secret
#<Client DEFAULT>
#      Secret xyzzy
#</Client>
Each Client clause can have a number of different parameters set, as described below.
Tip
If you are using an SQL database, you can list your clients in a RADCLIENTLIST table and use <ClientListSQL>. For more information, see Section 3.16. <ClientListSQL> instead of listing them in your config file. This may be convenient, especially if you are using RAdmin to manage your RADIUS system.

3.14.1. Secret

This defines the shared secret that is used to encrypt and decrypt User-Password and some other less frequently used attributes. Shared secret is also used for RADIUS message integrity checking with the exception of Access-Request messages. You must define a shared secret for each Client, and it must match the secret configured into the client RADIUS software. There is no default. The secret can be any number of ASCII characters. Any ASCII character except newline is permitted, but it might be easier if you restrict yourself to the printable characters. For a reasonable level of security, the secret should be at least 16 characters, and a mixture of upper and lower case, digits and punctuation. You should not use just a single recognisable word.
# This better agree with the client at
# 10.20.30.40 or we won't understand them!
<Client 10.20.30.40>
      Secret 66+6obaFGkmRNs-R
</Client>

3.14.2. EncryptedSecret

This defines the shared secret that is used with messages exchanged with this client. You must define a shared secret for each Client, and it must match the secret configured into the client RADIUS software. EncryptedSecret is in encrypted format and is preferred over Secret. See Section 3.14.1. Secret for more about RADIUS shared secrets.
EncryptedSecret is currently experimental and will be documented later.
# This better agree with the client at
# 10.20.30.41 or we won't understand them!
<Client 10.20.30.41>
      EncryptedSecret {rcrypt}1F67Kx6WXHKHpOuRZHSaIJdI
</Client>

3.14.3. DynAuthSecret

This defines the shared secret that is used to encrypt RADIUS dynamic authorisation requests that are sent to this client. The default is the client's Secret.
# 10.20.30.40 has separate secret for dynauth requests
<Client 10.20.30.40>
      Secret 66+6obaFGkmRNs-R
      DynAuthSecret 7e4+674.4a614A1b
</Client>

3.14.4. EncryptedDynAuthSecret

This defines the shared secret that is used to encrypt RADIUS dynamic authorisation requests which are sent to this client. EncryptedDynAuthSecret is in encrypted format and is preferred over DynAuthSecret.
EncryptedDynAuthSecret is currently experimental and will be documented later.
# 10.20.30.41 has separate secret for dynauth requests
<Client 10.20.30.41>
      EncryptedSecret {rcrypt}1F67Kx6WXHKHpOuRZHSaIJdI
      EncryptedDynAuthSecret {rcrypt}oVYMAWI/UUYPj4zbo3l95lKk
</Client>

3.14.5. TACACSPLUSKey

This is a per-client TACACSPLUS key which is used as the TACACS+ key if there is no Key defined in the ServerTACACSPLUS clause. Do not use this with RADIUS requests. For more information,see Section 3.119.1. Key.

3.14.6. EncryptedTACACSPLUSKey

This is a per-client TACACSPLUS key which is used as the TACACS+ key. EncryptedTACACSPLUSKey is in encrypted format and is preferred over TACACSPLUSKey. Do not use it with RADIUS requests. For more information, see Section 3.119.1. Key.
EncryptedTACACSPLUSKey is currently experimental and will be fully documented later.

3.14.7. DefaultRealm

This optional parameter can be used to specify a default realm to use for requests that have a User-Name that does not include a realm. The realm can then be used to trigger a specific <Realm> or <Handler> clause. This is useful if you operate a number of NASs 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
<Client acc1.open.com.au>
      Secret ....
      DefaultRealm open.com.au
</Client>
<Realm open.com.au>
      .....
</Realm>
Tip
Under some circumstances, some NASs send requests with no User-Name (usually for administrative reports). In that case, DefaultRealm will not add a realm to the User-Name, nor create a User-Name.

3.14.8. DupInterval

If more than one RADIUS request is received with the same source and destination IP address, source port, RADIUS authenticator and RADIUS Identifier within DupInterval seconds, the 2nd and subsequent requests are deemed to be duplicates or retransmissions. If the earlier request has already been replied to, then that reply will be resent back to the NAS. Otherwise the duplicate request will be dropped. A value of 0 means duplicates and retransmissions are always accepted, which might not be very wise, except during testing. RFC 5080 recommends a value between 5 and 30 seconds. Default is 10 seconds, which will detect and ignore duplicates due to multiple transmission paths and common retransmission intervals. In general you should never need to worry about or set this parameter. Ignore it and accept the default.
# brian.open.com.au is being tested
<Client brian.open.com.au>
      Secret 666obaFGkmRNs666
      DupInterval 0
</Client>

3.14.9. 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.14.10. IdenticalClients

This optional parameter specifies a list of other clients that have an identical setup. You can use this parameter to avoid having to create separate Client clauses for lots of otherwise identical clients. The value is a list of client names or addresses, separated by white space or comma. Each client may be specified as an IP address (IPv4 or IPv6), a MAC address in the form MAC:aa-bb-cc-dd-ee-ff, or an IPv4 or IPv6 CIDR address in the form nn.nn.nn/nn. You can have any number of IdenticalClients lines.
Tip
When you use the Client-Id check item, it matches against the name or address in the <Client xxxxxx> line, but not against any of the values listed in IdenticalClients. 
IdenticalClients 10.1.1.1 10.1.1.2 nas.mydomain.com
IdenticalClients 10.1.1.7 10.1.1.8 10.1.1.9
IdenticalClients 203.63.154.1 localhost
IdenticalClients MAC:11-22-33-44-55-66
IdenticalClients 203.10.1.0/24 220.10.0.0/16
IdenticalClients 2001:db8:22:1::/64 2001:db8:22:2::/64

3.14.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.14.12. 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.14.13. StatusServerShowClientDetails

Normally, when a Status-Server request is received, Radiator will reply with some statistics including the total number of requests handled, the current request rate etc. When you set the optional StatusServerShowClientDetails for a Client, the reply to Status-Server will also include details about that Client. This can result in a lengthy reply packet. The default is not to send the additional Client details for any Clients.
<Client xxxxxx>
      # Show stats about this client in Server-Status replies
      StatusServerShowClientDetails
      Secret xxxxxx
      ....
</Client>
Tip
You can test sending Status-Server requests with radpwtst -noacct -noauth -trace 4 -status

3.14.14. Identifier

This optional parameter acts as a label that can be useful for custom code in hooks. It can also be used in Client-Identifier matches with Handlers:
<Client 10.1.2.3>
      Identifier        www-proxy
      Secret            mysecret
</Client>

# www-proxy
<Handler Client-Identifier=www-proxy>
      <AuthBy FILE>
            Filename    %D/www-proxy-users
      </AuthBy>
</Handler>

3.14.15. 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.14.16. DefaultReply

This is similar to Section 3.14.20. AddToReply except it adds attributes to an Access-Accept only if there would otherwise be no reply attributes. StripFromReply does never remove any attributes added by DefaultReply. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. You can use any of the special % formats in the attribute values. There is no default.
Although this parameter can be used in any AuthBy method, it is most useful in methods like <AuthBy UNIX> and <AuthBy SYSTEM>, which do not have a way of specifying per-user reply items. In other AuthBy methods you can also very easily set up a standard set of reply items for all users, yet you can still override reply items on a per-user basis.
# If the user had no reply items set some
DefaultReply Service-Type=Framed,Framed-Protocol=PPP

3.14.17. StripFromReply

Strips the named attributes from Access-Accepts before replying to the originating client. The value is a comma separated list of RADIUS attribute names. StripFromReply removes attributes from the reply before AddToReply adds any to the reply. There is no default. This is useful, for example, with AuthBy RADIUS to prevent downstream RADIUS servers sending attributes you do not like back to your NAS.
# Remove dangerous attributes from the reply
StripFromReply Framed-IP-Netmask,Framed-Compression

3.14.18. AllowInReply

This optional parameter is the complement to StripFromReply: It specifies the only attributes that are permitted in an Access-Accept. It is useful, for example, to limit the attributes that are passed back to the NAS from a proxy server. This way you can prevent downstream customer RADIUS servers from sending back illegal or troublesome attributes to your NAS.
AllowInReply does not prevent other attributes being added locally by DefaultReply, AddToReply and AddToReplyIfNotExist.
# Only permit a limited set of reply attributes.
AllowInReply Session-Timeout, Framed-IP-Address

3.14.19. 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.14.20. AddToReply

Adds attributes to reply packets. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromReply removes attributes from the reply before AddToReply adds any to the reply. You can use any of the special % formats in the attribute values. There is no default. AddToReply adds attributes to replies to all types of request that are handled by this clause.
Although this parameter can be used in any AuthBy method, it is most useful in methods like AuthBy UNIX, which don’t have a way of specifying per-user reply items.
# Append some necessary attributes for our pops
AddToReply cisco-avpair="ip:addr_pool=mypool"

3.14.21. AddToReplyIfNotExist

This is similar to AddToReply, but only adds an attribute to a reply if and only if it is not already present in the reply. Therefore, it can be used to add, but not override a reply attribute. This is contributed by Vincent Gillet <vgi@oleane.net>.

3.14.22. NoIgnoreDuplicates

This optional parameter specifies one or more RADIUS packet types where duplicates are not ignored. NoIgnoreDuplicates is a comma or space separated list of request types, such as:
  • Access-Request
  • Accounting-Request
  • Status-Server
By default any request with an identical identifier received from the same NAS within the DupInterval period will be ignored or the previous reply retransmitted. If the request type is specified in NoIgnoreDuplicates, it will not be ignored, irrespective of the time since reception of a previous copy.
# Always handle dups of Accounting-Request packets
NoIgnoreDuplicates Accounting-Request

3.14.23. StripFromRequest

Strips the named attributes from the request before passing it to any Handlers or Realms. 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.14.24. AddToRequest

Adds attributes to the request before passing it to any Handlers or Realms. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromRequest removes attributes from the request before AddToRequest and AddToRequestIfNotExist adds any to the request. You can use any of the special % formats in the attribute values. There is no default.
# Append a Filter-ID and host name
AddToRequest Calling-Station-Id=1,Login-IP-Host=%h

3.14.25. AddToRequestIfNotExist

Adds attributes to the request before passing it to any Handlers or Realms. Unlike AddToRequest, an attribute will only be added if it does not already exist in the request. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromRequest removes attributes from the request before AddToRequest and AddToRequestIfNotExist adds any to the request. You can use any of the special % formats in the attribute values. There is no default.
# Append a Filter-ID and host name if they are not there already
AddToRequestIfNotExist Calling-Station-Id=1,Login-IP-Host=%h

3.14.26. ClientHook

This hook will be called for each request after the request has been decoded but before any other per-Client processing is done. A reference to the current request is passed as the only argument.

3.14.27. RequireMessageAuthenticator

Client clause checks the value of any Message-Authenticator attribute in incoming EAP or other requests. An incorrect authenticator causes the request to be ignored.
The optional RequireMessageAuthenticator flag causes the clause to require a correct Message-Authenticator attribute to be present in all incoming requests that support Message-Authenticator attribute. Most of the request types support Message-Authenticator. Accounting requests and responses do not support Message-Authenticator.
This flag parameter is not set by default.

3.14.28. LimitProxyState

The optional LimitProxyState flag parameter causes the Client to require a Message-Authenticator attribute to be present when one or more Proxy-State attributes are received. Radius clients that are not proxies should never send Proxy-State attributes. Proxies should always include a Message-Authenticator with the messages they forward. Limiting Proxy-State to requests which also include Message-Authenticator allows the server to discard unexpected requests from non-proxy clients.
This flag parameter is not set by default. Consider this parameter only for clients that are not proxies and are not capable of sending Message-Authenticator. Consider RequireMessageAuthenticator for proxies and other clients that support Message-Authenticator.

3.14.29. DynAuthPort

This defines a destination port to which RADIUS dynamic authorisation requests are sent. There is no default. This allows modules, such as AuthBy DYNAUTH, to provide a per request value that is not overwritten by this parameter. When set, a common value is 3799.
# Certain vendor may default to non-standard port
<Client 172.3.2.2>
      Secret 666obaFGkmRNs666
      DynAuthPort 1700
</Client>

3.14.30. UseMessageAuthenticator

This flag parameter adds a Message-Authenticator attribute to dynauth requests sent to this Client. Disabled by default.
# This NAS requires Message-Authenticator for dynauth requests
<Client 172.3.2.3>
      Secret 666obaFGkmRNs666
      DynAuthPort 1700
      UseMessageAuthenticator
</Client>

3.14.31. VsaVendor

VsaVendor sets the NAS vendor name for VsaTranslateIn and VsaTranslateOut. The NAS vendor names correspond to Perl modules in Radiator's /Radius/Nas/ directory. For more information about VSA translation, see Section 3.14.33. VsaTranslateIn.

3.14.32. VsaType

VsaVendor sets the NAS vendor type for VsaTranslateIn and VsaTranslateOut. Each NAS vendor module in Radiator can have multiple types, for example, IOS and IOS XE for Cisco. For more information about VSA translation, see Section 3.14.33. VsaTranslateIn.

3.14.33. VsaTranslateIn

Attributes in incoming and outgoing RADIUS messages can be translated to and from internal presentations. For example, different MAC address formats can be normalised for logging and values for reply attributes can now be set based on the Client or <AuthBy RADIUS> vendor type. The general format for VsaTranslateIn and VsaTranslateOut is:
VsaTranslateIn source_attr, dest_attr[, translation, strip|nostrip, extras]
  • source_attr is the translation source attribute.
  • dest_attr defines the name for the newly translated attribute.
  • translation defaults to copy which does no modification. The available translation depend on the VsaVendor and VsaType configuration parameters.
  • strip or nostrip defaults to nostrip for VsaTranslateIn and strip for VsaTranslateOut.
  • extras depends on the translation, VsaVendor and VsaType.
Full example showing VsaVenedor, VsaType, VsaTranslateIn, VsaTranslateOut, and the related configuration parameters is in goodies/vsa-translate.cfg.
# Translate incoming MAC address to common internal format
# and copy the DNS address in a VSA
<Client 192.168.3.49>
    Identifier juniper
    Secret mysecret

    # These control how the translation is done
    VsaVendor Juniper
    VsaType junos

    # macaddr transforms MAC addresses to and from internal presentation
    VsaTranslateIn Unisphere-Pppoe-Description, OSC-Mac-Address, macaddr

    # Convert internal presentation to what this client expects
    VsaTranslateOut OSC-DNS-Address1, Unisphere-Primary-Dns
</Client>

3.14.34. VsaTranslateOut

VsaTranslateOut an optional translation of attributes sent by Radiator to RADIUS clients. See VSATranslateIn for more information.

3.14.35. NasType

This optional parameter specifies the vendor type of this Client. It is required if you want Radiator to directly query the NAS to check on simultaneous sessions.
You can specify the maximum number of sessions allowable for a single user with the Simultaneous-Use check item, or for all the users in a Realm with the MaxSessions parameter in <Realm> or <Handler> clauses. In either case, during authentication, Radiator first checks its Session Database to see if the user's session count is exceeded. For more information, see Section 3.18. <SessionDatabase SQL> and Section 3.20. <SessionDatabase DBM>. Since this count can be inaccurate in the face of NAS reboots, lost packets etc. Radiator can also double check the count by interrogating the NAS directly (you enable this by specifying NasType in the Client clause).
If you specify unknown or do not specify any value at all, Radiator will never try to contact the NAS to check the user's sessions, and it will always assume that the sessions it thinks are present are correct. If you specify ignore, Radiator will never try to contact the NAS to check the users sessions, and it will always assume that there are no multiple sessions.
Tip
If Radiator detects problems or time-outs when using finger to verify simultaneous connections, it assumes that the user is still online (i.e. it assumes that the Session Database is correct).
Tip
You can also use NasType as a check item, to confirm that a request came from a client with a specific NasType.
The allowable values for NasType are:

Table 8. Allowable values of NasType, and their NAS query method

NasType Method used to connect to NAS
Livingston SNMP
Portslave Finger
PortslaveLinux Finger. For use with Portslave running on a Linux host, understands Linux finger format.
PortslaveMoxa Finger, requires ctlportslave to be installed as fingerd on the target Linux host. Supports Linux running Portslave and a Moxa multiport.
Cisco SNMP
CiscoVPDN SNMP, detects users terminated on a l2tp, pptp or l2f tunnel.
Colubris SNMP
Ascend Finger
AscendSNMP SNMP
Computone Finger
Cyclades SNMP
Hiper SNMP
NomadixSNMP SNMP
Redback SNMP
Shiva Finger
TotalControl pmwho
TotalControlSNMP SNMP
Bay, Bay5399SNMP, Bay8000SNMP SNMP
Bay4000SNMP SNMP
BayFinger Finger
Tigris, TigrisNew SNMP for new version of the Tigris MIB (i.e. firmware revision 10.1.4.14 or greater)
TigrisOld SNMP for old versions of the Tigris MIB
NortelCVX1800 SNMP
Xyplex Finger
Patton SNMP
Portmaster3 SNMP
Portmaster4 pmwho For use with Portmaster 4’s running ComOS 4.1 or later
Ping Verifies a login by ICMP pinging the Framed-IP-Address of the dialup user. This is not foolproof if the IP address has been reallocated. Requires that Radiator be run with root permissions (on Unix).
ignore Does not contact NAS under any circumstances. Always assumes that there are no multiple logins.
unknown The default value. Does not connect to the NAS under any circumstances. Always assumes the Session Database is correct.
CiscoSessionMIB SNMP, using the Session MIB available in Cisco IOS 12.2.15T and later.
Tip
You can add support for a new or custom NasTypes by adding a suitably named module to the Radius/Nas directory. Your new module should implement the isOnline function. See the existing Radius/Nas/*pm modules for examples. If you do implement your own module, send us a copy so we may include it in future releases.
Radiator uses a number of global parameters to specify how to communicate with the NAS. See Section 3.7.22. SnmpgetProg, Section 3.7.24. FingerProg, Section 3.7.25. PmwhoProg, Section 3.7.26. LivingstonMIB, Section 3.7.27. LivingstonOffs, and Section 3.7.28. LivingstonHole. 
# Make Radiator ask the NAS to confirm multiple logins.
# its a Total Control box
NasType TotalControl

3.14.36. SNMPCommunity

This optional parameter specifies the SNMP Community name to use to connect to the NAS when NasType uses SNMP. It is ignored for any other NasType. Defaults to public.
SNMPCommunity private

3.14.37. FramedGroup

This optional parameter acts similarly to Framed-Group reply items, but it applies to all Access-Requests authenticated by this clause. If FramedGroup is set and a matching FramedGroupBaseAddress is set in the Client from where the request came, then a Framed-IP-Address reply item is automatically calculated by adding the NASPort in the request to the FramedGroupBaseAddress specified by FramedGroup. For more information, see Section 3.14.38. FramedGroupBaseAddress.
Note
You can override the value of FramedGroup for a single user by setting a Framed-Group reply item for the user. 
# Work out the users IP address from the first 
# FramedGroupBaseAddress specified in out client
FramedGroup 0

3.14.38. FramedGroupBaseAddress

This optional parameter is used in conjunction with the Framed-Group reply attribute or the FramedGroup AuthBy parameter to automatically generate IP addresses for users logging in. It is ignored unless the user has a Framed-Group reply item, or unless their AuthBy clause contains a FramedGroup parameter. You can have as many FramedGroupBaseAddress items as you like.
You would only need to use this mechanism if you are using a NAS that is unable to choose IP addresses from an address pool, or if you want a more complicated address allocation policy than your NAS can support.
When a user logs in, Radiator can automatically choose an IP address for the user and return it to the NAS in a Framed-IP-Address reply attribute. To make this happen, you must specify one or more FramedGroupBaseAddress items in each Client clause, and you must specify a Framed-Group reply item for each user for whom you want address allocation. If the user is authenticated, Radiator will generate a Framed-IP-Address using Framed-Group reply item and the NAS-Port in the request. The Framed-Group in a user record selects the nth FramedGroupBaseAddress (0 based) from the Client they are logging in to, and NAS-Port is added to the last byte (modulo 255 or FramedGroupMaxPortsPerClassC) to generate a Framed-IP-Address.
Tip
Radiator also includes a much more sophisticated mechanism for allocating IP addresses from an SQL database or DHCP. For more information, see Section 3.53. <AuthBy DYNADDRESS>.
In the example below, if the user logs in on the Client at port 5, and their Framed-Group reply item is 1, they will be allocated a Framed-IP-Address of 10.0.1.6 (i.e. 10.0.1.1 + 5).
In the Radiator configuration file:
<Client ..>
      # This is the base address for Framed-Group = 0
      FramedGroupBaseAddress 10.0.0.1
      # This is the base address for Framed-Group = 1
      FramedGroupBaseAddress 10.0.1.1
      # This is the base address for Framed-Group = 2
      FramedGroupBaseAddress 10.0.2.1
      ....
</Client>
In the users file for each user you want to allocate an address for:
mikem       User-Password = "fred"
            Framed-Group = 1,
            Framed-Protocol = PPP,
            etc.
Alternatively, in an AuthBy clause:
<AuthBy whatever...>
      # This will cause all users authorised by this clause to get
      # an address allocated from the block starting 10.0.1.1,
      # unless overridden by a user-specific Framed-Group
      FramedGroup 1
      .....
</AuthBy>

3.14.39. FramedGroupMaxPortsPerClassC

This optional parameter defines the maximum number of ports that can be mapped to a class C or class B FramedGroupBaseAddress. The default is 255, which means that any address from 0 up to 255 in the 3rd or 4th octets will be permitted. It actually specifies the modulus for computing the 3rd and 4th octets of addresses calculated from FramedGroupBaseAddress. You might use this to limit the number of addresses used in each address block, or to prevent the allocation of the last address in a class C address block.

3.14.40. UseContentsForDuplicateDetection

This optional flag causes the Client to use an alternative duplicate detection algorithm. Normally, Client detects duplicate requests by looking at the source IP address, source IP port, the RADIUS request authenticator and the RADIUS request identifier of incoming requests. Requests with those identical attributes received in the last DupInterval seconds are deemed to be duplicates.
Note
This parameter is not needed in a ServerFarm environment when shared duplicate cache is used by the farm workers. See Section 3.7.55. DupCache.
In a ServerFarm environment, where the server farm is being used to load balance using, say, the EAPBALANCE module, the back end servers will receive requests (and potentially duplicate requests) from any of the front end servers in the server farm. This can defeat the normal duplicate detection algorithm. UseContentsForDuplicateDetection causes Client to look only at the contents of the request that would not be altered by passing through a proxy server, allowing duplicates to be reliably detected, even in a server farm. The packet contents used for duplicate detection when UseContentsForDuplicateDetection is set are:
  • RADIUS authenticator
  • User-Name
  • Called-Station-Id
  • Calling-Station-Id
It is essential that this parameter be defined in the Client clauses of back end servers of an EAPBALANCE Server Farm architecture, otherwise duplicate detection will not be performed correctly.

3.14.41. DynamicReply

This optional parameter specifies a reply item that will be eligible for run-time variable substitution. That means that you can use any of the % substitutions in Section 3.3. Special formatters in that reply item. You can specify any number of DynamicReply lines, one for each reply item you want to do replacements on. Any packet-specific replacement values will come from the Access-Accept message being constructed, and not from the incoming Access-Request. That means that special characters like %n will not be replaced by the received User-Name, because User-Name is in the request, but not the reply.
In the following example, substitution is enabled for USR-IP-Input-Filter in an AuthBy clause. When a user authenticates, the %a in the filter will be replaced by the users IP Address, which makes the filter an anti-spoof filter.
<AuthBy whatever>
      ......
      UseAddressHint
      DynamicReply USR-IP-Input-Filter
</AuthBy>
In the users file:
DEFAULT User-Password = "UNIX"
      Framed-IP-Address = 255.255.255.254,
      Framed-Routing = None,
      Framed-IP-Netmask = 255.255.255.255,
      USR-IP-Input-Filter = "1 REJECT src-addr != %a;",
      Service-Type = Framed-User
Note
This parameter used to be called Dynamic. That name is still recognised as a synonym for DynamicReply.

3.14.42. IgnoreAcctSignature

If you define IgnoreAcctSignature, it prevents the server from checking the authenticator Authenticator field in requests received from this client. Contrary to its name, it applies to all message types and also prevents checking the Message-Authenticator attribute. This parameter is useful because some clients do not send Authenticators that conform to RADIUS RFCs.
By default, the server logs and ignores messages that do not have a correct Authenticator, or any messages that do not have a correct Message-Authenticator attribute. Regardless of the setting of this parameter, the server always sends a correctly computed Authenticator and Message-Authenticator attribute.
CAUTION
This parameter is seldom required with current RADIUS implementations. You should first check that the shared secret between Radiator and client is correct before enabling this paramter.
If you get bad authenticator log messages and the accounting requests are not being stored even though authentication as such does not fail, and you have checked that the shared secrets are correct, try enabling IgnoreAccSignature. The bad authenticator log message looks this:
Bad authenticator in request from <client name> (<nas identifier>)
If you get bad EAP Message-Authenticator log messages and you have checked that the shared secrets are correct, it is possible that the NAS is sending an incorrect implementation of Message-Authenticator. Try enabling IgnoreAccSignature. The bad EAP Message-Authenticator log message looks this:
Bad EAP Message-Authenticator
Tip
Some NASs have separate secrets for authentication and accounting requests.
# brian.open.com.au has a broken legacy NAS
<Client 10.20.30.40>
      Identifier brian.open.com.au
      Secret 666obaFGkmRNs666
      IgnoreAcctSignature
</Client>

3.14.43. LivingstonOffs

Specifies the value of where the last S port is before the one or two ports specified in LivingstonHole are skipped (usually 22 for US, 29 for Europe). This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston in this Client clause. Defaults to the global value of LivingstonOffs, see Section 3.7.27. LivingstonOffs.

3.14.44. LivingstonHole

Specifies the value of the size of the hole in the port list (usually 1 for US, 2 for Europe) that occurs at LivingstonOffs. This optional parameter is only used if you are using Simultaneous-Use with a NasType of Livingston in this Client clause. Defaults to the global value of LivingstonOffs, see Section 3.7.28. LivingstonHole.

3.14.45. UseOldAscendPasswords

This optional parameter tells Radiator to decode all passwords received from this Client using the old style (non RFC compliant) method that Ascend used to use on some NASs. The symptom that might indicate a need for this parameter is that passwords longer than 16 characters are not decoded properly.
Table of Contents Table of contents: Radiator® AAA Server Gossip configuration 3.13 - Gossip configuration <ClientListLDAP> 3.15 - <ClientListLDAP>