FreeRADIUS AAA Server on AWS User Guide

Overview

This guide covers the deployment and configuration of FreeRADIUS on AWS using cloudimg AWS Marketplace images. FreeRADIUS is the most widely deployed RADIUS server in the world and the basis of many commercial RADIUS products. It provides centralised authentication, authorisation and accounting (AAA) for network access: Wi-Fi access points, VPN concentrators, 802.1X switches, captive portals and network access servers all ask FreeRADIUS whether a user may connect and record how long they were connected.

The image installs FreeRADIUS 3.2 from the official distribution package, run under systemd as the dedicated non-root freerad user. FreeRADIUS answers authentication on UDP 1812 and accounting on UDP 1813 across all interfaces. There is no web interface and no database: the configuration tree under /etc/freeradius/3.0 plus a flat user file are the whole configuration, so the server is defined by version-controllable text and reloads with a single command.

Secure by default — no known bootstrap credential. The stock FreeRADIUS package ships a well known client shared secret, testing123, and a demonstration user. Neither ships in this image: the testing123 secret is removed from the entire configuration and the demo user is stripped. On the first boot of every instance a one shot service generates a unique random shared secret for the built in localhost client and a unique sample user and password for that specific instance, and writes them to a root-only credentials file. No two instances share a credential, so the image cannot be authenticated against with a published default.

What is included:

• FreeRADIUS 3.2 from the official distribution package, run under systemd as the dedicated non-root freerad user (freeradius.service)

• A RADIUS authentication listener on 0.0.0.0:1812 (UDP) and a RADIUS accounting listener on 0.0.0.0:1813 (UDP)

• The standard files and pap authorisation flow, so a standard RADIUS client such as radtest authenticates a user against the flat user file out of the box

• A per-instance shared secret and a per-instance sample user + password, generated on first boot and written to /root/freeradius-credentials.txt (mode 0600, root only)

• The well known testing123 shared secret and the stock demonstration user removed from the configuration tree

• A clients.conf that $INCLUDEs an empty clients.d/ directory, so you add your own RADIUS clients as drop-in .conf files, and a cloudimg-users file for your own users, both reloadable with one command

Connecting to your instance

Connect over SSH on port 22 as the default login user for the AMI variant you launched. FreeRADIUS ships with no login of its own; the per-instance RADIUS credentials live in a root-only file on the instance.

ssh -i /path/to/key.pem ubuntu@<public-ip>

Prerequisites

• An AWS account and a key pair in the target region

• Subscription to the FreeRADIUS listing on AWS Marketplace

• A security group allowing TCP 22 (admin) from your address, and UDP 1812 and UDP 1813 from the NAS devices (access points, switches, VPN concentrators) that will authenticate against the server

Recommended instance type: m5.large (2 vCPU, 8 GB RAM) is ample for a departmental or site RADIUS server. FreeRADIUS is very light; larger sizes are only needed for very high authentication volumes or EAP-heavy 802.1X estates.

Step 1: Launch from AWS Marketplace

Search FreeRADIUS in AWS Marketplace, select the cloudimg listing, and click Continue to Subscribe, then Continue to Configuration and Continue to Launch. Choose the m5.large instance type, your key pair, and a security group. Configure the security group to allow UDP 1812 and UDP 1813 only from the RADIUS clients that will authenticate against the server, and TCP 22 for administration. RADIUS ports should never be open to the whole internet.

Step 2: Launch from the AWS CLI

AWS_REGION="us-east-1"
aws ec2 run-instances \
  --region "$AWS_REGION" \
  --image-id <freeradius-ami-id> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-group-ids <your-sg-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=freeradius1}]'

Step 3: First boot

On first boot a one shot service (freeradius-firstboot.service) generates this instance's unique RADIUS shared secret and a unique sample user and password, renders the built in localhost client into clients.d/localhost.conf, writes the per-instance user into mods-config/files/cloudimg-users, and records everything in /root/freeradius-credentials.txt (mode 0600). Only then does freeradius.service start, so the server never comes up with an unconfigured client. First boot completes within a few seconds of the instance becoming reachable.

Read the per-instance credentials:

sudo cat /root/freeradius-credentials.txt

Step 4: Confirm the service is running

systemctl is-active freeradius
freeradius -v | head -1
sudo ss -ulnp | grep -E ':1812|:1813'

The service is active, freeradius -v reports FreeRADIUS Version 3.2.5, and FreeRADIUS is listening on UDP 1812 (authentication) and UDP 1813 (accounting).

Step 5: Test authentication with radtest

The image ships radtest (from freeradius-utils). Load this instance's per-instance secret and sample user from the root-only credentials file and authenticate against the built in localhost client:

source <(sudo grep -E '^(RADIUS_SECRET|SAMPLE_USER|SAMPLE_PASSWORD)=' /root/freeradius-credentials.txt)
radtest "$SAMPLE_USER" "$SAMPLE_PASSWORD" 127.0.0.1 0 "$RADIUS_SECRET"

You receive an Access-Accept with a Reply-Message, proving end-to-end AAA: the per-instance sample user authenticates against the localhost client using the per-instance shared secret.

Step 6: Confirm the image is secure by default

A wrong password for a valid user is rejected, and the well known stock testing123 shared secret does not authenticate:

source <(sudo grep -E '^(RADIUS_SECRET|SAMPLE_USER|SAMPLE_PASSWORD)=' /root/freeradius-credentials.txt)
REJ="$(radtest "$SAMPLE_USER" wrong-password 127.0.0.1 0 "$RADIUS_SECRET" 2>&1 || true)"
echo "$REJ" | grep -q 'Access-Reject' && echo 'wrong password -> Access-Reject (correct)' || echo 'unexpected: wrong password was not rejected'
BAD="$(timeout 8 radtest "$SAMPLE_USER" "$SAMPLE_PASSWORD" 127.0.0.1 0 testing123 2>&1 || true)"
echo "$BAD" | grep -q 'Access-Accept' && echo 'FAIL: testing123 authenticated' || echo 'testing123 shared secret -> rejected (correct)'

Both checks confirm no known bootstrap credential ships in the image: a wrong password is rejected, and the stock testing123 secret is not accepted.

Step 7: Review the configuration tree

FreeRADIUS is driven entirely by the configuration tree under /etc/freeradius/3.0. clients.conf $INCLUDEs the clients.d/ directory (where the per-instance localhost client lives and where you add your own clients), and the per-instance sample user lives in mods-config/files/cloudimg-users:

sudo ls /etc/freeradius/3.0/
sudo grep INCLUDE /etc/freeradius/3.0/clients.conf
sudo ls -l /root/freeradius-credentials.txt

Step 8: Add your own RADIUS clients

Each network access server (access point, switch, VPN concentrator, captive portal) is a RADIUS client with its own shared secret. Add one as a drop-in .conf file under clients.d/ and reload. Set ipaddr to your device's address or your NAS management subnet (<your-mgmt-cidr>) and choose a strong secret:

sudo tee /etc/freeradius/3.0/clients.d/site-nas.conf >/dev/null <<'CLIENT'
client site-nas {
    ipaddr = <your-mgmt-cidr>
    secret = choose-a-strong-per-device-secret
    nas_type = other
}
CLIENT
sudo systemctl restart freeradius

Configure the same shared secret on the network device so it can talk to the RADIUS server.

Step 9: Add your own users

Add users to the flat file backend by editing mods-config/files/cloudimg-users, then reload:

sudo nano /etc/freeradius/3.0/mods-config/files/cloudimg-users
# add e.g.:
#   alice   Cleartext-Password := "<new-password>"
#           Reply-Message := "Welcome %{User-Name}"
sudo systemctl restart freeradius

For production you would typically grow beyond the flat file into an LDAP or SQL backend and enable EAP methods for 802.1X and enterprise Wi-Fi. cloudimg engineers can help you design these after purchase.

Step 10: Security recommendations

• Restrict the RADIUS ports. Open UDP 1812 and UDP 1813 in the security group only to the NAS devices that authenticate against the server, never to the whole internet.

• Use a unique shared secret per client. Every access point, switch or VPN concentrator should have its own strong secret in its own clients.d/ file.

• Keep the credentials file protected. /root/freeradius-credentials.txt is mode 0600 and readable only by root; do not relax its permissions or copy the per-instance secret onto other hosts.

• Prefer EAP for Wi-Fi. For enterprise Wi-Fi and 802.1X, use an EAP method (PEAP/EAP-TLS) with TLS rather than bare PAP, and consider an LDAP or SQL user backend.

• Patch regularly. Apply operating system and FreeRADIUS security updates; cloudimg provides upgrade and patch guidance.

Step 11: Support and Licensing

FreeRADIUS is open source software licensed under the GNU General Public License, version 2. This image repackages the upstream distribution package; additional charges apply for cloudimg support services. FreeRADIUS is a trademark of its respective owner; this image is not affiliated with or endorsed by the FreeRADIUS project.

Deploy on AWS

Subscribe to the FreeRADIUS listing on AWS Marketplace, launch the m5.large instance, and you have a hardened RADIUS server answering authentication requests within minutes.

Need Help?

cloudimg provides 24/7 technical support by email (support@cloudimg.co.uk) and live chat. We help with adding RADIUS clients and users, migrating to LDAP or SQL backends, configuring EAP and 802.1X for enterprise Wi-Fi, RADIUS accounting, per-user reply attributes such as VLAN assignment, and FreeRADIUS version upgrades. Critical issues receive a one hour average response time.