FreeRADIUS Replacement Guide for Carrier Networks

• FreeRADIUS does not provide active-active HA, native Diameter termination, or a commercial SLA – the three things carrier networks need when scale, access diversity, and availability obligations increase.
• Session continuity is the primary migration risk: an unplanned cutover drops active subscriber sessions. A parallel-running phase with gradual traffic shifting is the only way to eliminate that risk.
• Evaluation criteria must include protocol depth (does the platform natively handle Diameter S6b, SWx, Gx without a translation layer?), K8s session architecture (StatefulSets with external session store), and contracted MTTD/MTTR with a named TAM.
• Alepo AAA runs 100+ operator deployments globally at 36,000+ TPS and sub-millisecond authentication latency, with active-active geo-redundant HA designed for 99.999% availability – fewer than 6 minutes of unplanned downtime per year.
• Alepo has migrated 50+ operators from legacy AAA systems, including FreeRADIUS, using a parallel-running methodology that eliminates subscriber-impacting cutover events.

Choosing the wrong FreeRADIUS replacement platform costs carrier networks months of re-engineering and in the worst case- a full re-procurement cycle. Network architects planning this migration face constraints that generic AAA vendor content never addresses: active session continuity across cutover, BRAS/BNG compatibility with RADIUS CoA (RFC 5176), EAP method coverage for mixed-access environments, and the high-availability architecture that comes with a 99.999% uptime commitment.

This guide is written for network architects and infrastructure leads at CSPs, ISPs, and MNOs who have outgrown FreeRADIUS at carrier scale- or who are evaluating what that transition involves before it becomes urgent. It covers why carrier networks outgrow FreeRADIUS, where open-source breaks down at production scale, how to structure a migration with zero-session-loss cutover, what to evaluate when selecting a replacement, and what Alepo’s approach looks like across 100+ operator deployments globally.

Why Carrier Networks Outgrow FreeRADIUS

FreeRADIUS is the rational starting point for RADIUS-based subscriber authentication. The decision to replace it is almost never sudden – it accumulates over years of engineering workarounds, each one reasonable in isolation, until the operational debt of maintaining a community-supported platform at carrier scale outweighs every other consideration.

What FreeRADIUS Gives You for Free

FreeRADIUS implements RFC 2865 (RADIUS) and RFC 5176 (CoA/Disconnect) correctly and supports PAP, CHAP, MS-CHAPv2, EAP-TLS, EAP-TTLS, and EAP-PEAP out of the box. For a regional ISP or fixed-access broadband network with a stable subscriber base and a small NOC team, this is a reasonable production platform. The unlang policy language is expressive enough for complex attribute-based logic, and the community is technically sophisticated.

Production deployments at Tier-2 ISPs have run FreeRADIUS reliably at hundreds of thousands of authentication requests per day for years. The value proposition is real: if scale, access-type mix, and SLA tolerance fit within the operational model of a community-supported project, FreeRADIUS delivers. The problem is when one of those three parameters changes – and for carriers, they all eventually do.

Where Open-Source Breaks Down at Carrier Scale

The failure mode is rarely a single event. It is the convergence of several constraints at the same time: authentication throughput requirements climb as the subscriber base grows; the BRAS/BNG footprint expands to multiple PoPs, each needing independent RADIUS redundancy; the network team deploys VoWiFi or LTE data that requires Diameter (S6b, SWx, SWm) rather than RADIUS; and someone in the NOC needs to modify a live session mid-flight via Change of Authorization without waiting for a community patch cycle.

At that point FreeRADIUS hits a structural constraint: it is a RADIUS server. It does not natively terminate Diameter interfaces. HA requires a separately managed session replication layer the operator builds and maintains. Each of these can be engineered around – but the engineering cost sits entirely with the operator, not the vendor.

Support, Maintenance, and Operational Risk

When an authentication failure pattern emerges at 2 AM – reject codes that match no configured policy, EAP-TLS negotiation failures after a BRAS firmware upgrade, intermittent CoA timeouts under load – the available support resource is the mailing list. There is no defined incident severity, no contracted MTTD, no named engineer with knowledge of your deployment. For an operator whose subscriber SLA is measured in minutes, that is not a supportable operating model.

The risk compounds as engineers who understand the specific unlang configuration leave. What remains is a production system with policy logic nobody currently on staff fully understands – a situation Alepo’s migration engineers encounter consistently in carriers that have run FreeRADIUS for five or more years.

FreeRADIUS Limitations at Carrier Scale

FreeRADIUS delivers exactly what it is designed to deliver. The limitations below are not failures of the project – they are architectural constraints that emerge specifically at carrier scale, across mixed access types, with commercial SLA obligations.

Protocol Coverage: RADIUS Only

FreeRADIUS implements RADIUS (RFC 2865, RFC 2866) and the Dynamic Authorization extensions in RFC 5176. It does not natively terminate Diameter. This matters when a carrier needs to support VoWiFi (which requires Diameter SWm, SWx, and S6b interfaces with the ePDG and HSS), LTE packet-core authentication (S6a/S6d for MNOs), or 5G SA subscriber authentication via the AUSF/UDM interfaces.

Operators who started on RADIUS for FTTH or cable broadband and have since added mobile data offload or Wi-Fi calling face a specific problem: they need to run a separate Diameter AAA (Authentication, Authorization, and Accounting) stack in parallel with FreeRADIUS. Two separate authentication infrastructures – each with its own session state, HA architecture, and operational tooling – doubles engineering burden and introduces subscriber identity inconsistency between systems.

Session State and High Availability

FreeRADIUS does not provide built-in active-active clustering with shared session state. The standard HA approach is primary/secondary failover using rlm_sql or rlm_redis for session store, with the operator responsible for all replication and failover logic. Under a failover event, in-flight sessions not yet committed to the shared store are lost.

For a carrier with a 99.999% availability requirement – fewer than 6 minutes of unplanned downtime per year – this requires engineering active-active session replication at the application layer. FreeRADIUS does not provide this natively. The build, validation, and ongoing maintenance cost is the operator’s throughout.

Kubernetes Deployment: The Stateful Problem

Containerizing FreeRADIUS on Kubernetes introduces a well-documented problem: RADIUS is a stateful protocol and Kubernetes was designed around stateless workloads. Horizontal pod autoscaling does not work correctly when session state lives inside the pod – a new pod has no knowledge of sessions being handled by other pods, and a pod termination mid-session produces accounting record gaps.

The correct architecture for containerized AAA on Kubernetes uses StatefulSets with an external Redis or database-backed session store, so session state survives pod restarts and is accessible across all replicas. This is a solvable engineering problem – but it requires purpose-built implementation, not a containerised FreeRADIUS with default configuration.

Step-by-Step Replacement Process

A FreeRADIUS replacement at carrier scale is a structured program, not a lift-and-shift. Skipping any phase increases the risk of subscriber-impacting events during cutover. The sequence below reflects the migration methodology Alepo has applied across 50+ operator migrations globally.

Pre-Migration Assessment Checklist

Before any configuration work begins, the operator needs a complete inventory of the existing FreeRADIUS deployment:

1. Document all RADIUS clients — IP addresses, shared secrets, and CoA port configuration for every NAS/BRAS/BNG. Every client must be re-provisioned in the new platform before cutover.
2. Export and map all unlang policy logic — Map each policy decision to its intended business rule. This is typically undocumented; it requires time with whoever originally wrote the configuration.
3. Capture the full EAP method set — PAP/CHAP/MS-CHAPv2 for legacy devices, EAP-TLS or EAP-TTLS for enterprise 802.1X clients, EAP-SIM/AKA for SIM-based Wi-Fi offload. The replacement platform must match this coverage on day one.
4. Identify all external integrations — LDAP/SQL subscriber databases, mediation systems receiving CDRs, SIEM systems receiving auth logs, and any PCRF/PCF receiving Gx requests triggered from the AAA layer.
5. Measure peak TPS from production logs — not average load. The cutover architecture must be validated at the peak authentication rate.
6. Define rollback criteria and authority — who has authority to trigger a rollback without management escalation, and at what error-rate threshold?

Parallel Running and Traffic Shifting

The safest cutover architecture runs FreeRADIUS and the new AAA platform simultaneously, shifting traffic gradually:

7. Deploy in shadow mode first — the new platform receives real authentication requests but does not respond. This confirms all RADIUS clients can reach the new platform and requests are parsed correctly.
8. Activate at 5–10% of traffic using weighted DNS or NAS configuration. Monitor authentication success rate, latency distribution, and accounting record completeness for 24–48 hours before advancing.
9. Increase in stages: 10% → 30% → 70% → 100%. Each stage holds for at least 24 hours under peak load. Authentication error rate on the new platform must match or improve on FreeRADIUS before advancing.
10. Maintain FreeRADIUS in standby for 30 days after full cutover. Do not decommission until at least one full billing cycle has been validated against new-platform accounting records.

Avoiding Common Migration Pitfalls

These failure modes appear consistently across carrier AAA migrations:

11. Policy logic translation errors — FreeRADIUS unlang encodes business rules not documented anywhere else. Translating without a complete business-rule review causes authentication failures for edge-case subscribers that do not appear in test traffic.
12. Missing NAS clients — Operators routinely discover NAS devices not in the original inventory: legacy BRAS nodes, CPE with embedded RADIUS clients, test systems still sending live auth requests. A 30-day parallel-running phase surfaces these before FreeRADIUS is decommissioned.
13. Accounting record gaps at cutover — If Start records and Stop records for the same session are sent to different platforms, CDRs are incomplete and billing is affected. Traffic shifting must be session-sticky: all records for a session must follow the platform that received the Start record.
14. CoA not tested explicitly — CoA messages (RFC 5176) originate from the PCRF or network management platform, not from subscriber devices. They use separate RADIUS client credentials and are frequently excluded from migration test plans, failing silently post-cutover.

Evaluation Criteria for a FreeRADIUS Replacement

Selecting a FreeRADIUS replacement is a 5–7 year infrastructure decision. An evaluation framework built on feature checkboxes produces a platform that passes the RFP and fails in production. These are the criteria that actually differentiate carrier-grade platforms.

Protocol Depth and Standards Compliance

Every commercial AAA vendor supports RADIUS. The questions that separate carrier-grade platforms are:

• Does the platform natively terminate Diameter interfaces — specifically S6b, SWx, SWm, Gx, Gy – without a protocol translation layer that adds latency and a failure point?
• Which EAP methods are supported natively without third-party modules? Minimum for carrier scale: EAP-SIM, EAP-AKA, EAP-AKA’ (SIM-based); EAP-TLS, EAP-TTLS, EAP-PEAP (certificate-based).
• Which 3GPP releases does the platform implement? For 5G SA, R15 is the floor. R16 and R17 interfaces matter for NR policy. Ask for specific release numbers – not “the latest 5G standards.”
• Does the platform support RFC 5176 CoA with sub-second response for live session modification – the mechanism BRAS/BNG uses to modify QoS, disconnect subscribers, or enforce policy without re-authentication?

High Availability Architecture

Request the vendor’s HA architecture documentation – not the product slide. Ask specifically:

• Active-active or active-passive? Active-passive failover is measured in seconds. Active-active means the redundant instance is handling live traffic continuously; failover is sub-second.
• Where does session state live? In-memory per-instance (sessions lost on failover), shared database (latency added), or external in-memory store (Redis, Memcached) with sub-millisecond access?
• What happens to in-flight requests during a K8s pod restart? Session continuity across pod termination requires StatefulSets and an external session store – confirm this is the production architecture, not the reference architecture in the documentation.
• What is the tested TPS at which HA failover has been validated in production? Ask for the specific number, the topology, and whether the figure comes from a lab or a live deployment.

Migration Methodology and Support SLA

The vendor’s migration methodology is as important as the platform:

• Does the vendor provide a defined parallel-running phase — simultaneous operation of FreeRADIUS and the new platform under production load before cutover?
• What is the traffic-shifting mechanism? Gradual percentage-based shift (10% → 30% → 70% → 100%) or hard cutover? Gradual shift gives the NOC time to validate error rates at each stage before committing.
• What is the contracted MTTD and MTTR for production incidents — specifically, how long until a named engineer with knowledge of your deployment is working the issue?
• Is there a named Technical Account Manager (TAM) — a senior engineer who understands your topology, participated in your integration, and is the first escalation point during and after cutover?

Migration Planning: Parallel Running and Cutover

Parallel running is not just a technical validation phase – it is the period in which the NOC team builds operational familiarity with the new platform’s tooling, alarm patterns, and support escalation path before those skills are needed under pressure.

Defining the Validation Gate for Each Traffic Stage

Each traffic stage requires a defined pass/fail gate before advancing. Without explicit gates, the NOC has no objective basis for the proceed-or-hold decision. The minimum gate at each stage:

• Authentication success rate on the new platform >= FreeRADIUS baseline, measured over the same 24-hour window including peak hours
• P99 authentication latency on the new platform <= FreeRADIUS P99 under equivalent load
• Accounting record completeness — all Start records have corresponding Interim-Update and Stop records for sessions initiated on the new platform
• CoA response rate — all CoA requests from the PCRF or policy platform receive correct responses within the configured timeout
• Zero CDR gaps — no discrepancies that would affect billing for the subscriber population on the new platform

Handling Active Sessions at Cutover

The hardest operational problem is sessions active at the moment of cutover. These sessions started on FreeRADIUS – the Accounting Start record was sent to FreeRADIUS. If the NAS is reconfigured to send subsequent records to the new platform, the new platform has no Start record and the CDR is incomplete.

Three approaches are used in practice: (1) session-sticky routing – each NAS sends all traffic for active sessions to the platform that received the Start record, routing new sessions to the new platform only; (2) session drain – hold cutover until all sessions active at that moment have terminated naturally; (3) CDR reconciliation – accept a small number of incomplete records across the migration window and reconcile offline. The right approach depends on session duration distribution and billing tolerance for manual reconciliation.

Rollback Criteria and Authority

Define rollback criteria and authority before cutover begins – not during an incident. A workable approach: if authentication error rate on the new platform exceeds 1% above the FreeRADIUS baseline at any traffic stage, hold the percentage and open vendor escalation. If the error rate exceeds 3% above baseline, rollback triggers automatically. Document these thresholds, assign authority explicitly, and ensure the NOC knows the rollback procedure without needing a run-book search at 2 AM.

Also Read: Cloud-Native AAA Guide

Post-Migration Validation

Cutover is not the end of a migration – it is the start of validation. Accounting record reconciliation, policy coverage confirmation, and SLA verification all happen under real production load. This phase typically takes 30 days, aligned with one full billing cycle.

Accounting Record Reconciliation

Run a full CDR reconciliation against the billing system for the first complete billing cycle:

• Every subscriber active during the migration window must have complete Start + Interim-Update + Stop records. Sessions with a Start on FreeRADIUS and a Stop on the new platform should be identified and handled per the agreed reconciliation procedure.
• Total session minutes and data volumes from the new platform must match the FreeRADIUS baseline within < 0.5% variance. Larger variance indicates accounting gaps that must be investigated before the billing run.
• Prepaid subscribers require explicit testing — online charging integration (Gy to OCS) must deliver correct quota exhaustion events and session termination signals. Prepaid accounting failures are subscriber-visible within seconds.

Authentication Coverage Validation

Test every EAP method and authentication mechanism in production use:

• PAP/CHAP/MS-CHAPv2 — test with legacy CPE that cannot be upgraded
• EAP-TLS — test with enterprise 802.1X clients; confirm certificate chain validation against all active CAs in the trust store
• EAP-SIM/AKA/AKA’ — test with SIM-based Wi-Fi offload clients across all MCC/MNC combinations in the realm database
• CoA (RFC 5176) — test every CoA attribute in use (session timeout, bandwidth policy change, disconnect) against all NAS vendors in the deployed BRAS/BNG footprint

SLA and Support Model Validation

• Open a test incident during off-hours and measure time to first response from a named engineer – verify the contracted SLA is operational, not theoretical.
• Confirm the NOC has working access to the AAA management console: active session search, auth log pull, and basic subscriber trace without vendor assistance.
• Verify that SIEM, NMS, and on-call integrations are generating correct alarms for authentication failure spikes, accounting processing delays, and platform health events.

Schedule a free demo, about your FreeRADIUS migration.

Alepo as a FreeRADIUS Replacement

Alepo AAA runs 100+ operator deployments globally at 36,000+ TPS and sub-millisecond authentication latency, with active-active geo-redundant HA designed for 99.999% availability. The platform has been deployed across broadband, mobile, VoWiFi, and MVNO environments by carriers across the US, Europe and MiddleEast.

Protocol Coverage Across RADIUS and Diameter

Alepo AAA terminates RADIUS (RFC 2865, RFC 2866) and Diameter natively on the same platform – no protocol translation layer. Diameter interfaces in production: S6a, S6b, SWx, SWm, Sh, Gx, Gy, Sd, STa, SWa, and SWd. A carrier that starts on RADIUS for FTTH and later adds VoWiFi (requiring Diameter SWm/SWx/S6b) does not need to deploy a separate Diameter stack. Both access types run on the same Alepo platform with shared subscriber identity and unified session management.

EAP support covers the full method set: EAP-SIM, EAP-AKA, EAP-AKA’ for SIM-based Wi-Fi offload and Wi-Fi calling; EAP-TLS, EAP-TTLS, EAP-PEAP for certificate-based and enterprise 802.1X authentication; PAP/CHAP/MS-CHAPv2 for legacy devices. No third-party modules required.

Deployment Architecture: From Bare-Metal to Kubernetes

Alepo AAA deploys on Kubernetes, VM, bare-metal, private cloud (AWS, Azure, GCP), or on-premises – and as a fully managed service where the operator wants Alepo to run the platform operationally. The K8s deployment uses StatefulSets with an external session store so session state survives pod restarts and is shared across all replicas, making horizontal scaling consistent with session continuity requirements. Alepo’s production K8s deployment at a Tier-1 US fiber operator on GCP is the architecture reference for cloud-native FreeRADIUS replacement.

For operators migrating from FreeRADIUS on bare-metal or VM, Alepo runs on the same infrastructure topology – containerization is an option, not a requirement.

Deployment Track Record

Alepo has migrated 50+ operators from legacy AAA systems using the parallel-running approach described in this guide. Named references across the AAA portfolio include Saudi Telecom (STC) for DSL/broadband AAA, GTPL for carrier AAA, Zain Jordan for carrier AAA, and Telefonica Colombia for VoWiFi across SWm/SWx/S6b.

For further reading on Alepo AAA capabilities, see the Alepo AAA Server product page.

Frequently Asked Questions

Q. What is a FreeRADIUS replacement and why does it matter for telecom operators?

A FreeRADIUS replacement is a commercially supported, carrier-grade AAA (Authentication, Authorization, and Accounting) platform that takes over subscriber authentication, session management, and accounting from a FreeRADIUS deployment. It matters because FreeRADIUS does not provide the active-active HA architecture, native Diameter termination, or commercial SLA coverage that carrier networks need as subscriber scale, access-type diversity, and availability obligations grow.

Q. What is the RADIUS authentication flow step by step?

When a subscriber device connects to a NAS (Network Access Server – BRAS, BNG, or wireless controller), the NAS sends an Access-Request to the RADIUS server containing subscriber credentials. The RADIUS server validates credentials against the subscriber database, evaluates the applicable access policy, and responds with Access-Accept (including policy attributes: session timeout, bandwidth, IP pool) or Access-Reject. On session start the NAS sends Accounting-Start; during the session it sends periodic Interim-Update records; on termination it sends Accounting-Stop. The AAA server processes all three record types and forwards CDRs to mediation and billing.

Q. What is RADIUS Change of Authorization (CoA) and when is it used?

Change of Authorization, defined in RFC 5176, allows a RADIUS server or policy system to modify an active subscriber session without requiring re-authentication. The PCRF (Policy and Charging Rules Function) sends a CoA-Request to the NAS, which either applies the change (bandwidth modification, QoS update) or disconnects the session via a Disconnect-Message. CoA is used for fair-use enforcement, prepaid quota exhaustion disconnect, and mid-session speed tier upgrades. Explicitly validating CoA is a mandatory step in any FreeRADIUS migration.

Q. Does RADIUS work for 5G networks?

RADIUS is used in specific 5G scenarios – N3IWF (Non-3GPP Interworking Function) and trusted non-3GPP WLAN access via the STa interface. However, the core 5G Standalone authentication architecture (3GPP Release 15 and later, specified in TS 23.501 uses Diameter and SBI (Service-Based Interface) over HTTP/2 for AUSF, UDM, and AMF interfaces. Operators deploying 5G SA require a platform that handles both RADIUS (for existing fixed and Wi-Fi access) and Diameter/SBI (for the 5G core) – a RADIUS-only platform is insufficient.

Q. Is FreeRADIUS suitable for carrier-scale deployments?

FreeRADIUS operates at carrier scale at some operators, but requires substantial custom engineering to do so safely. Active-active HA with session continuity, CoA under load, and multi-protocol support (RADIUS + Diameter) all require the operator to build and maintain custom architecture on top of FreeRADIUS. The question is whether the cost of building and operating that custom architecture is lower than a commercially supported platform that provides it natively. For most carriers past a defined scale and access-complexity threshold, it is not.

Q. What is the total cost of ownership (TCO) of running FreeRADIUS vs commercial AAA?

FreeRADIUS software cost is zero. TCO is not. Primary cost components: engineering hours to build HA architecture, develop and maintain policy logic, manage integrations, and respond to production incidents. Add recruiting and retention cost for engineers with FreeRADIUS expertise, cost of unplanned downtime outside any contracted SLA, and re-engineering cost when a new access type (VoWiFi, 5G SA) requires Diameter support. A complete TCO comparison accounts for all of these across a 5-year horizon – and the operational cost of responding to incidents without a contracted support SLA is typically the largest single line item.

Conclusion

FreeRADIUS replacement is an operational decision, not a procurement one. When maintaining custom HA architecture, multi-protocol support, and production incident response on a community-supported platform costs more engineering resource than a commercially supported replacement, the decision calculus is straightforward. The migration itself – parallel-running, gradual traffic shift, defined validation gates, explicit rollback authority – removes the subscriber-impacting risk that makes carriers defer the decision.

Alepo AAA brings 20+ years of AAA deployment experience, 100+ live operator deployments globally at 36,000+ TPS, and 50+ completed legacy-to-carrier-grade migrations to this decision. The platform handles RADIUS (RFC 2865, RFC 2866, RFC 5176 CoA) and Diameter (S6b, SWx, SWm, Gx, Gy, and nine further interfaces) on the same stack, runs on Kubernetes, VM, bare-metal, or managed service, and delivers active-active HA designed for 99.999% availability.

Schedule a free demo, about your FreeRADIUS migration.