Radiator 10.34 now available!

This article was originally published by LOGON’s partner Radiator Software. Click here to view the original article.

We’re happy to announce the release of Radiator 10.34.0. The main highlight is RadiatorDB, a new built-in database functionality. We’re also highlighting ipmap, which provides an efficient way to manage dynamic RADIUS clients and networks.

There are also important improvements to RADIUS performance, backend load balancing, scheduled tasks, configuration management, and RADIUS/1.1 over TLS.

RadiatorDB

New in 10.34.0

RadiatorDB is a built-in multimaster document database for Radiator Server, backed by PostgreSQL. It provides a flexible way to store AAA data, operational records, and other Radiator-managed data without requiring a separate application layer around an external database.

RadiatorDB stores data as JSON documents organised into collections. Multiple PostgreSQL instances can be configured for multimaster replication, allowing writes to any instance while changes are automatically replicated between them.

RadiatorDB features:

Multimaster replication between PostgreSQL instances
Writing to any RadiatorDB instance
Flexible JSON document storage
Role-based access control for the Radiator UI and REST API
Radiator UI support for creating, viewing, editing and deleting documents
Revision history and audit trails
Automatically expiring documents
Automatic PostgreSQL schema management
Automatic replication management defined in Radiator configuration

Although RadiatorDB is backed by PostgreSQL, it is a document database rather than a conventional SQL database. Data is managed through the RadiatorDB REST API, Radiator configuration, and the Radiator Management UI.

Dynamic RADIUS Clients with ipmap

New in 10.33.2, enhanced in 10.33.3

The ipmap functionality provides an in-memory IP prefix map for IPv4 and IPv6. It can be populated from external data sources and used to dynamically determine which RADIUS client configuration applies to an incoming request.

In practice, this means ipmap can be used as a dynamic RADIUS client list. Instead of maintaining a large list of RADIUS clients directly in the configuration, client addresses and networks can be kept in a database or other data source. Radiator loads that information into ipmap and performs client lookups against the in-memory data.

Example ipmap data:

Network: 192.0.2.0/24 → Client: branch-office-1
Network: 198.51.100.0/24 → Client: branch-office-2
Network: 2001:db8:1234::/48 → Client: head-office

ipmap uses longest-prefix matching, so both individual addresses and larger network ranges can be managed efficiently. It can also be repopulated automatically when the source data changes.

The combination of RadiatorDB and ipmap is particularly useful:
RadiatorDB → JSON data → ipmap → dynamic client matching → RADIUS processing

RadiatorDB can provide JSON data containing client and network information, while ipmap keeps the information in memory for fast lookups.

Further Improved RADIUS Performance

New in 10.34.0

Radiator 10.34.0 changes the way RADIUS backend connections are selected. RADIUS backend pools now use least-outstanding connection selection by default. Requests are sent to the connection with the fewest outstanding requests, making better use of available connections when there is a high level of parallel traffic.

The connection window setting can also be used to control how many requests may be in flight on a connection. These changes are aimed particularly at high-throughput deployments.

Backend Load Balancing and High Availability

New in 10.33.1, enhanced in 10.34.0

The 10.33.x releases introduced several improvements to backend load balancing for PostgreSQL, MySQL, and LDAP:

Least-connections server selection strategy: Requests are sent to the server with the fewest connections currently in use.
Faster failover: When a backend connection pool is saturated.
Lazy connection pooling: Radiator can now start even when a database server is temporarily unavailable and establish connections when they are needed.

These capabilities make it easier to build backend configurations that distribute traffic across multiple servers while handling backend failures without unnecessary delays.

RADIUS/1.1 over TLS

New in 10.34.0

Radiator 10.34.0 adds support for RADIUS/1.1 over TLS, based on RFC 9765. RADIUS/1.1 can be negotiated using TLS ALPN. It provides stricter packet validation and uses mutual TLS rather than the RADIUS/1.0 packet authenticator.

Support is opt-in, so existing RADIUS/TLS configurations continue to work as before. The radiator-client and radperftest tools can also be used to generate and test RADIUS/1.1 traffic.

Scheduled Tasks

New in 10.33.4

The new timer configuration block allows Radiator to run pipelines on a schedule. Timers can use fixed intervals or cron expressions, with support for jitter and IANA time zones. This is useful for tasks such as periodic maintenance, polling, cache updates, and other work that needs to happen automatically at regular intervals.

Configuration Management Improvements

Enhanced in 10.33.2 and 10.33.3

Configuration archives now include metadata (Radiator version, creator, timestamps, deployment changes). The Management UI can show this information and warn about version mismatches.
Configuration export and import provide a way to package and deploy Radiator configurations through the Management UI and REST API.

Other Changes

Key enhancements between 10.33.0 and 10.34.0 include:

TACACS+ over TLS (10.33.2, extended in 10.33.3)
PBKDF2-HMAC password hashing (10.33.3)
The must action for making required authentication actions fail explicitly (10.33.3)
JSONPath support for iterating JSON data (10.33.3)
Improved radiator-client testing with response attribute and message assertions (10.33.1)
Environment variables for all major configuration value types (10.33.1)

Upgrade to Radiator 10.34.0

Radiator 10.34.0 brings together the changes from the 10.33.x releases and introduces RadiatorDB and RADIUS/1.1 support.

We particularly encourage customers to try RadiatorDB and ipmap. Used together, they provide a straightforward way to keep RADIUS client information in a database while using an efficient in-memory map for client matching.

As always, we recommend testing the release in a development or staging environment before upgrading production systems, and backing up your configuration before the upgrade process.

Ready to upgrade to Radiator 10.34?

LOGON Software Asia – the trusted Radiator partner in Asia – offers:

✅ Free Proof of Concept (POC)
✅ Preferred pricing
✅ Priority support
✅ Local expertise

The Developer of the most flexible AAA software in the world

RADIUS, Diameter, TACACS+

Solution Highlight

Blog, Radiator Software Blog