# FreeRADIUS server: a multi-protocol policy server for RADIUS, DHCP and TACACS+ > FreeRADIUS centralizes authentication and authorization for 802.1x, VPN and dialup networks, with back ends from MySQL to Active Directory. It is a C daemon configured through commented text files, and the README warns that version 4 is unreleased. **FreeRADIUS/freeradius-server** — FreeRADIUS - A multi-protocol policy server. - Repository: https://github.com/FreeRADIUS/freeradius-server - Website: http://freeradius.org - Stars: 2,600 · Forks: 1,193 - Language: C - License: GPL-2.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/freeradius-freeradius-server ## What FreeRADIUS centralizes, and who ends up running it A network with one access point and one shared password does not need a policy server. The moment there are several NAS devices, several user stores and several authentication methods, every device needs its own copy of the user list, and adding or deleting a user means touching all of them. FreeRADIUS exists to remove that duplication. The README states that using RADIUS allows authentication and authorization for a network to be centralized, and minimizes the number of changes needed when adding or deleting users. The project describes itself as a high performance and highly configurable multi-protocol policy server supporting RADIUS, DHCPv4, DHCPv6, DNS, TACACS+ and VMPS. In practice the RADIUS side is what most people deploy: 802.1x for WiFi, dialup, PPPoE, VPNs and VoIP. The intended operator is a network or infrastructure engineer who owns the access layer and is comfortable editing configuration files and reading packet-level debug output. The README is candid that the server may be difficult to configure, install or administer, calling it a complex system with many configuration possibilities. That is not marketing modesty; it is a fair description of the surface area. ## How the server processes a request: config files, modules and policy The repository layout shows where the moving parts live. The raddb/ directory holds the default configuration, src/ holds the C sources, doc/ holds documentation, and man/ holds manual pages. The server is built from a GNU Make based system: the top-level Makefile requires GNU Make 4.0 or higher and checks for the load keyword used by dynamically loaded extensions, and it refuses to proceed without Make.inc, which is produced by running ./configure. Configuration is not a single schema file. It is a tree of text files under raddb/ that define which modules are loaded (SQL, LDAP, Redis and others), which clients may talk to the server, and how a request is routed through the policy sections. The README notes that many parts of the server are documented only with extensive comments inside those configuration files, so the config is also the manual. That design keeps everything inspectable and diffable, and it is why the project's own recommended workflow is incremental: start from the defaults, keep a known-working copy, and change one thing at a time. The back ends are the other half of the architecture. The README lists MySQL, MariaDB, PostgreSQL, Oracle, Microsoft Active Directory, Apache Cassandra, Redis and OpenLDAP among the supported stores. A typical deployment keeps credentials or authorization attributes in one of those and lets the policy sections decide what to do with the result. The same binary also answers DHCP and TACACS+ traffic, which is why it is described as multi-protocol rather than as a RADIUS server alone. ## Installing FreeRADIUS and sending a first test packet The README points to an installation instructions document at doc/antora/modules/installation/pages/index.adoc rather than embedding steps. It does not give package names or a download link for a specific platform, so the commands below are limited to what the repository itself shows: building from source with the project's own configure script, then running the daemon in debug mode. The build requires GNU Make 4.0 or higher and a Make.inc generated by configure. Run configure first, then make, then install: ```bash ./configure make sudo make install ``` After installation, the README's preferred first step is to verify that the server starts in debugging mode. It names the command radiusd -X and says the output should be read carefully, because it includes warnings about common issues and suggestions for fixing them: ```bash radiusd -X ``` With the server running in that mode, the README says to send it test packets using radclient, or a NAS or access point. radclient is the project's own test client; a NAS or AP is the real device you intend to authenticate. If the server does not behave as expected, the README's loop is to change the configuration and restart in debug mode, or revert to the last working configuration. It explicitly recommends against changing large amounts of configuration at once, and against the fast and loose approach. One installation caveat comes from the README itself: version 4 is in development and has not been officially released, and it tells readers to wait for an official release before using it. If you build from the master branch you are working with that unreleased code. The 3.x series is what the recent release tags cover. ## Where FreeRADIUS is the wrong tool The most obvious mismatch is a small network. If you have one access point and a handful of users, the cost of a policy server plus its back end exceeds the cost of configuring the AP directly. FreeRADIUS pays off when there are many devices or many users, not before. A second mismatch is the expectation of a graphical interface. The README documents configuration files, a debug mode and mailing lists. It does not document a GUI, and the project's troubleshooting guidance assumes you are reading radiusd -X output and the comments inside raddb/ files. If your team will not read either, the deployment will stall. Platform expectations matter too. The build system is GNU Make and configure, the repository ships debian/ and redhat/ packaging directories, and the topics list posix and daemon. The README does not document a Windows service or a macOS install path. Running it on Windows 11 or macOS is not something the repository supports describing, and the supported path is a POSIX-style system. Finally, there is the support model. The README states that the issue tracker must not be used for support requests and that such issues will be closed and locked, with a ban from all FreeRADIUS project repositories for repeat offenders. Questions belong on the freeradius-users mailing list. If your organization needs a contractual support channel, the README mentions commercial support through the project's help pages, but the default community path is a mailing list where, in the project's own words, no one is getting paid to answer your questions. ## FreeRADIUS against a vendor RADIUS appliance The realistic alternative for most buyers is a vendor RADIUS product bundled with their access points or switches, or a hosted authentication service. The difference is not feature count; it is where the policy lives and who can change it. A vendor appliance typically ships a web interface, a support contract and a narrower set of integrations tuned to that vendor's hardware. FreeRADIUS goes the other way. Policy lives in text files under raddb/, the back ends are the databases you already run (MySQL, MariaDB, PostgreSQL, Oracle, Active Directory, Cassandra, Redis, OpenLDAP), and the same daemon can answer RADIUS, DHCPv4, DHCPv6, DNS, TACACS+ and VMPS. You can diff the configuration, put it in version control, and reproduce it on another host. You also own the debugging. That trade is the whole decision. A vendor appliance hides complexity behind a UI and absorbs it into a support contract. FreeRADIUS exposes the complexity and gives you the source, under GPLv2, plus a mailing list. Teams that need an auditable, scriptable authentication policy and have the staff to maintain it tend to prefer the second model. Teams without that staff tend to regret it. ## Maintenance, versions and the GPLv2 licence The repository is not archived, and the last push was on 2026-09-24, which is recent. Recent release tags include 3.2.10 and 3.0.28, both dated 2026-06-03 and 2026-06-02 respectively, and 3.2.9 from 2026-06-01. The 3.0.x and 3.2.x lines are both still receiving releases, which means a deployment has to choose a line and track it rather than assuming a single current version. The upgrade cost is tied to the configuration model. Because policy lives in raddb/ files that you edit, and because the README says many parts of the server are documented only in comments inside those files, upgrades can require reconciling your edited files with new defaults. The README's own workflow, keeping a copy of the default configuration and a copy of the working configuration with notes on what changed and why, is the practical mitigation. Budget time for that reconciliation on each upgrade rather than treating it as a drop-in package update. The licence is GPL-2.0, and the README states the server is available under the terms of the GNU GPLv2. That matters if you plan to distribute a modified server or link it into a product. This is a description of what the repository says, not legal advice; if you intend to redistribute a modified build, have your own counsel review the GPLv2 obligations. Running the unmodified server inside your own network is the ordinary use case the project is built around. ## Conclusion Adopt FreeRADIUS if you need a self-hosted RADIUS or TACACS+ policy server with database back ends and you are willing to work through text configuration and debug output. Do not adopt it if you want a GUI, a Windows-native service, or a drop-in appliance, and do not run version 4 in production while the README says it has not been officially released. Before committing, verify that your distribution ships a 3.x package, that your NAS or access point speaks RADIUS, and that you can run radiusd -X and read the result. ## FAQ ### What is a FreeRADIUS server? It is a multi-protocol policy server that supports RADIUS, DHCPv4, DHCPv6, DNS, TACACS+ and VMPS, and it centralizes authentication and authorization so that adding or deleting users does not require changes on every network device. ### Is FreeRADIUS actually free? The README states that the FreeRADIUS Server Project is available under the terms of the GNU GPLv2. The project also points to commercial support options through its help pages, but the software itself is distributed under that licence. ### Is there a GUI for FreeRADIUS? The README documents configuration files, the radiusd -X debug mode and mailing lists, and it does not document a graphical interface. Configuration is done by editing the files under raddb/ and reading the comments inside them. ### How do I install the FreeRADIUS server? The README refers readers to the installation instructions document in doc/antora/modules/installation/pages/index.adoc rather than listing steps itself. Building from the repository uses ./configure, make and sudo make install, with GNU Make 4.0 or higher required. ### How do I set up the FreeRADIUS server? The README recommends starting from the default configuration files, keeping a copy of that working default, verifying the server starts with radiusd -X, then sending test packets with radclient or a NAS, and making only small changes before repeating the debug step. ## Sources - [FreeRADIUS/freeradius-server on GitHub](https://github.com/FreeRADIUS/freeradius-server) - [License: GPL-2.0](https://github.com/FreeRADIUS/freeradius-server/blob/master/LICENSE) - [Project website](http://freeradius.org) - [README](https://github.com/FreeRADIUS/freeradius-server/blob/master/README.md) - [Releases](https://github.com/FreeRADIUS/freeradius-server/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/freeradius-freeradius-server