3.36. <AuthBy RADIUS> Previous topic Parent topic Child topic Next topic

<AuthBy RADIUS> forwards all authentication and accounting requests for this Realm to another (possibly remote) RADIUS server. This is called proxying. It is implemented in AuthRADIUS.pm. When the remote RADIUS server replies, the reply is forwarded back to the client that originally sent the request to the server.
This allows Radiator to act as a proxy RADIUS server, possibly running on the firewall of your organisation. You can also use it to set up roaming realms, or to make your RADIUS server act as a multiplexer for multiple realms. You can forward certain realms to other servers within your organisation in order to improve performance or redundancy.
By specifying multiple Host lines the requests can be forwarded to primary/secondary RADIUS server pairs. The normal behaviour is to try to forward the requests to the remote hosts in the order the hosts are listed in the configuration file. This means that it initially tries to forward a request to the first host listed (unless that host was marked as failed recently). If no reply is received from the first host (after Retries), it is marked as failed for FailureBackoffTime seconds, and the request is forwarded to the next Host in the list. This continues until a reply is received, or until all the Hosts are tried. This way, if a primary remote server fails, the secondary takes over. After FailureBackoffTime seconds, the primary is tried again. To change this behaviour, choose other load balancing versions of <AuthBy RADIUS>. For more information, see Section 3.51. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy EAPBALANCE>.
Attention
By default, an <AuthBy RADIUS> clause is completed as soon as the request has been forwarded to the remote RADIUS server. In this case, <AuthBy RADIUS> returns IGNORE for AuthByPolicy, so take care when using sequences of AuthBy clauses that include <AuthBy RADIUS>. <AuthBy RADIUS> does not wait for a reply before moving on to other AuthBy clauses, or handling new requests. You can change this behaviour with one of these flag parameters: Asynchronous and Synchronous. Be cautious if you enable the Synchronous flag. It can have a significant impact on performance. If you need to continue processing the reply with another AuthBy clause, the correct way to do that is with a ReplyHook or Asynchronous flag that has been added to Radiator 4.17.
Tip
If it is required to proxy RADIUS requests to a remote Radiator across an insecure or unreliable network such as the internet, consider using the RadSec protocol, and use <AuthBy RADSEC> instead of <AuthBy RADIUS>. RadSec provides encrypted, reliable transport of RADIUS requests to a remote Radiator. For more information, see Section 3.69. <AuthBy RADSEC>, Section 3.113. <ServerRADSEC>, and Section 16. RadSec (RFC 6614).
Tip
Perform load balancing as well as simple proxying by using <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE> or <AuthBy LOADBALANCE> instead of <AuthBy RADIUS>. For more information, see Section 3.51. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy EAPBALANCE>.
Tip
Be cautious when using Fork with AuthBy RADIUS. It usually results in requests being sent to the remote host, but the replies not received.
Tip
You can specify your remote RADIUS hosts either with Host parameters or <Host xxxxxx> clauses. For more information, see Section 3.36.2. Host and Section 3.37. <Host xxxxxx> within <AuthBy RADIUS>. The Host parameter is simpler but less flexible than the <Host xxxxxx> clause. For ease of understanding, do not mix formats in the same <AuthBy RADIUS>.
Tip
Radiator automatically copies any Proxy-State attribute from the incoming RADIUS request to the reply. If a request with the Proxy-State attribute is proxied to another server by <AuthBy RADIUS>, and the reply from that server also has a copy of Proxy-State in it, the reply to the NAS has 2 copies of the Proxy-State attribute. If this causes a problem with the upstream NAS (it usually does not), strip the Proxy-State from the forwarded request with:
StripFromRequest Proxy-State

Example

In case it is not obvious from the above, there are 2 ways of specifying which remote RADIUS Hosts to proxy to. The simplest, but the least flexible, way is to use Host parameters, and have the same secrets, ports etc. for all hosts:
<AuthBy RADIUS>
      # Same secret and timeout for all hosts
      Secret xyzzy
      RetryTimeout 2
      Host host1.bigco.com
      Host host2.bigco.com
</AuthBy>

Example

The other way allows you to customise some parameters on a host-by-host basis by using Host clauses:
<AuthBy RADIUS>
      # Same secret for all hosts
      Secret xyzzy
      <Host host1.bigco.com>
            # But a custom Timeout for this one
            RetryTimeout 2
      </Host>
      <Host host2.bigco.com>
            # And custom ports for this one
            AuthPort 1001
            AcctPort 1002
      </Host>
</AuthBy>
<AuthBy RADIUS> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.26. <AuthBy xxxxxx>.