RADIUS deployment architectures

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 is capped by what a single RADIUS Server agent can achieve.

Some examples and terms assume F5 load balancer with Cisco ASA VPN client

For best throughput and availability we recommend deploying two or more Okta RADIUS Server Agents behind a load balancer. This approach allows horizontal scaling by adding additional RADIUS Server Agents into the load balancing pool and distributing the traffic load evenly between them. Number of RADIUS Server Agents will depend 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 (aka sticky sessions) based on the end-user’s VPN client or IP to optimize performance, especially in situations where waiting for user input to 2FA challenge is done off-band (e.g. Okta Verify w/ Push). The Okta RADIUS Server Agent handles de-duplication of requests from the originating RADIUS client, however, if those are spread between multiple agents, they are only de-duplicated at Okta service side resulting in unnecessary load. See Load Balancer Session Persistence Notes below for more detail.

Recommended configuration for stickiness is generally using the Calling-Station-ID combined with the Framed-IP. Calling-Station-ID for many VPNs will be 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

We recommend setting load balancing method of Least Connections where available to distribute load on active RADIUS Server Agents.

• Health check

Use load balancer health check function with synthetic logins to ensure that in case of RADIUS Server Agent issue a failover occurs seamlessly and with minimum user impact. Each Virtual Server should have it’s own health check over its respective port. To configure your load balancer or RADIUS client to do health checks, create a user account that will be used only for this purpose. We recommend:

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 cannot contain a hash (#) character

3. Create a custom RADIUS application for triaging this inbound healthcheck
4. Assign this user to the RADIUS application (thereby 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 load balancer to remove RADIUS server out of rotation after 2 consecutive failures. Set load balancer to add server back in rotation after 1 successful response from server

• Load Balancer high availability

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

For F5’s overall recommendation for RADIUS load balancing, please refer to the F5 RADIUS Load Balancing documentation. F5 supports an iApp for managing RADIUS volume. This iApp also supports automated healthchecks via synthetic transactions to ensure that the end users are able to authenticate.