The system settings for a RADIUS client allow multiple different client settings to be created by name. L2TP uses RADIUS by default, and if not set then the first settings found are used. However, you can set a named RADIUS client setting to be used for each L2TP server setting. This then looks for the named client setting for accounting and/or authentication.

The corresponding RADIUS servers are queried for the authentication or account messages. Each client setting can list multiple servers. Normally the first matching setting is used, and all of the listed servers considered. However, if all of the servers listed are currently blacklisted then the next matching named entry (i.e. with same name) is considered, and its listed servers considered. You can see the status of each RADIUS server in the Status/RADIUS menu. This includes the average response time, and the last 64 responses (good/bad).

The set of servers being considered are put in order based on their previous responses. The least recently failed to respond are listed first and then the fastest responding servers listed first. Only the last 64 responses being considered. The first 5 servers are then considered for answering the RADIUS query. If fewer than 5 are available, then the list is repeated. This give 5 requests in a row to try, even if that is one server 5 times.

Each server is then given a timeout. The timeout is normally based on the scale-timeout multiplied by the average response time of that server. If this is more than one fifth of the max-timeout then that is used instead. The final (5th) server is given a timeout to extent to at least the min-timeout as total since the first request is sent. This creates a sequence of requests to be sent to one or more RADIUS servers.

If, within the overall timeout, any of the servers respond then this is accepted. If none respond then all record a timeout.

To allow servers to recognise duplicate requests, each request in the sequence that is to the same server has the same content and ID. This allows the server to simply resend the previous reply if it was dropped.

In addition to these timeouts, it is also possible to set a maximum queue for the set of servers. This limits how many concurrent requests can be waiting.

For each request to a server, a log is made of whether there was a response or a timeout, and this is recored and shown on the server status page. This logs the last 64 requests.

If all of the last 64 requests have failed then the server is blacklisted. This stops it being considered when there are other servers to consider. If all are blacklisted then the blacklisted servers are used anyway.

However, it is quite possible for a server to go away when there are no current RADIUS requests, or even come back when not being used for current requests. To allow for this the FireBrick sends status-server requests to the server periodically, and records the responses in the 64 bit response queue. This means a blacklisted server will be recorded as usable again once it starts answering such requests. It also means a server can become blacklisted is a server stops responding to such requests without actually losing any real RADIUS requests.

If a server has never answered a status-server request, it is assumed not to be enabled. We strongly recommend enabling this feature on your RADIUS servers. If not enabled then servers are provided with a dummy good response periodically to take them out of blacklisted status and allow then to be tried occasionally in case they are now working again.