RADIUS deployment architectures

The following sections describe commonly recommended RADIUS deployment architectures.

Active-Passive failover behind a VPN such as Cisco ASA

This is the simplest deployment model and is sufficient for environments that don’t have high throughput requirements beyond what a single active Okta RADIUS Server agent can provide.

In this approach, configure one Okta RADIUS Server agent as the active server on the VPN device, along with another Okta RADIUS Server as passive failover. The total throughput depends on what a single RADIUS Server agent can achieve.

Active-Active behind a load balancer–high throughput

Some examples and terms in this section assume an F5 load balancer with the Cisco ASA VPN client.

For the best throughput and availability Okta recommends deploying two or more Okta RADIUS Server Agents behind a load balancer. This approach allows horizontal scaling by adding more RADIUS Server Agents into the load-balancing pool and distributing the traffic load evenly between them. The number of RADIUS Server Agents depends on the anticipated volume and peak transactions per minute.

• Virtual networks

  Set up a separate virtual server for each device sending RADIUS requests. Create a separate server pool for each virtual server.

• Session persistence

  Load balancing should be done using session persistence (sticky sessions) based on the end user’s VPN client or IP to optimize performance. This is especially important in situations where waiting for user input to a 2FA challenge is done off-band (for example, Okta Verify with push). The Okta RADIUS Server Agent handles resolves duplication of requests from the originating RADIUS client. However, if they're spread between multiple agents, duplications are resolved on the Okta service side resulting in unnecessary load.

  The recommended configuration for stickiness is generally using the Calling-Station-ID combined with the Framed-IP. Calling-Station-ID for many VPNs is the client IP address of the originating client. If a different RADIUS attribute is storing the client IP address, then configure the load balancer to use that attribute instead.

• Load-balancing method

  Okta recommends setting a load-balancing method of Least Connections where available to distribute load on active RADIUS Server Agents.

• Health check

  Use a load balancer health-check function with synthetic sign-ins to ensure that if there's a RADIUS Server Agent issue a failover occurs seamlessly, with minimum user impact. Each virtual server should have its own health check over its respective port. To configure your load balancer or RADIUS client to do health checks, create a user account that is used only for this purpose. Okta recommends the following steps:

1. Create a user with no assigned groups, no application access, and no privileges beyond a basic user account.
2. Create a strong, unique password for the health check user account.

   Note: the password and username can't contain a hash (#) character.

3. Create a custom RADIUS application for triaging this inbound health check
4. Assign this user to the RADIUS application (thus allowing access)

The purpose of this account is to validate that the RADIUS client can access the Okta service and field an authentication request appropriately. Typically health check should only involve primary authentication, since second-factor transactions usually require some form of user input or dynamic response.

Set a load balancer to remove RADIUS server out of rotation after two consecutive failures. Set the load balancer to add the server back in rotation after one successful response from server

• Load Balancer high availability

For the best overall system availability, consider a redundant system configuration for the load balancer to avoid a single point of failure. See the load balancer vendor documentation for recommendations.

For F5’s overall recommendation for RADIUS load balancing, refer to the F5 RADIUS load-balancing documentation. F5 supports an iApp for managing RADIUS volume. This iApp also supports automated health checks through synthetic transactions to ensure that the end users are able to authenticate.