FreeRADIUS EAP-TLS Configuration with Cisco VLAN Assignment

This guide walks through a basic FreeRADIUS 3.x deployment on Ubuntu using EAP-TLS for wired 802.1X authentication. It also includes a Cisco Catalyst access-port example and RADIUS-assigned VLAN configuration.

Important: Treat the addresses, VLANs, names, and secrets below as examples. Validate every setting in a lab before applying it to production. Do not copy example shared secrets or certificate passwords into a production environment.

What This Configuration Does

Installs FreeRADIUS and its administrative utilities.
Allows designated switches to communicate with the RADIUS server.
Configures EAP-TLS with a server certificate and a trusted client-certificate CA.
Returns the standard RADIUS tunnel attributes required for VLAN assignment.
Provides a starting configuration for Cisco Catalyst access ports.

Prerequisites

An updated Ubuntu server with a static IP address and synchronized time.
Administrative access using sudo.
A DNS record for the RADIUS server, such as radius.example.org.
A certificate authority capable of issuing a server certificate with the Server Authentication EKU.
Client certificates issued by a CA that FreeRADIUS will trust for EAP-TLS.
A test switch port and test endpoint configured for 802.1X.
A restricted or quarantine VLAN for failed or unauthenticated devices.

This article uses FreeRADIUS 3.x paths commonly found on Ubuntu. Confirm your installed version before making changes:

freeradius -v

1. Install FreeRADIUS

sudo apt update
sudo apt install freeradius freeradius-utils -y
sudo systemctl status freeradius --no-pager

Stop the service before editing its configuration. We will validate the files and run FreeRADIUS interactively before returning it to normal service.

sudo systemctl stop freeradius

2. Back Up the Default Configuration

sudo cp -a /etc/freeradius/3.0 /etc/freeradius/3.0.backup-$(date +%F)

Keep this backup until the server has been tested successfully. If you repeat the command on the same date, choose a different backup name so you do not overwrite the earlier copy.

3. Configure RADIUS Clients

In FreeRADIUS terminology, a client is a network access device such as a switch, wireless controller, or firewall—not the endpoint requesting network access.

sudo nano /etc/freeradius/3.0/clients.conf

Add a separate entry for each switch or the narrowest practical management subnet. A per-device definition limits which systems can submit RADIUS requests.

client access-switch-01 {
    ipaddr = 192.0.2.10
    secret = REPLACE_WITH_A_LONG_RANDOM_SHARED_SECRET
    shortname = access-switch-01
}

Security note: Use a unique, randomly generated secret and store it in your password-management system. The same value must be configured on the switch. Restrict UDP 1812 and 1813 at the host firewall so only approved network devices can reach the server.

4. Create the Server Key and CSR

Create a dedicated directory within the FreeRADIUS configuration tree:

sudo install -d -o freerad -g freerad -m 750 /etc/freeradius/3.0/certs/production
cd /etc/freeradius/3.0/certs/production

The following commands create an encrypted 3072-bit RSA private key and a certificate-signing request. Replace the subject and DNS name with values appropriate for your environment.

sudo openssl genpkey \
  -algorithm RSA \
  -aes-256-cbc \
  -out server.key \
  -pkeyopt rsa_keygen_bits:3072

sudo openssl req \
  -new \
  -sha256 \
  -key server.key \
  -out server.csr \
  -subj "/C=US/ST=Texas/O=Example Organization/OU=Technology/CN=radius.example.org" \
  -addext "subjectAltName=DNS:radius.example.org"

Submit server.csr to your internal CA. The issued certificate should include the DNS name in its Subject Alternative Name and the Server Authentication enhanced key usage. Export the server certificate and issuing chain in Base64/PEM format.

Place the issued files in the same directory using clear names:

server.key — the server private key
server.pem — the issued RADIUS server certificate
client-ca-chain.pem — the CA certificate or chain allowed to issue client certificates

sudo chown freerad:freerad /etc/freeradius/3.0/certs/production/*
sudo chmod 600 /etc/freeradius/3.0/certs/production/server.key
sudo chmod 640 /etc/freeradius/3.0/certs/production/server.pem
sudo chmod 640 /etc/freeradius/3.0/certs/production/client-ca-chain.pem

About encrypted keys: Do not use OpenSSL’s -nodes or -noenc option if you intend to protect the private key with a passphrase. Those options explicitly create an unencrypted key. An encrypted service key requires FreeRADIUS to have access to its password, so protect both the key and configuration files carefully. Some organizations instead use an unencrypted service key with strict filesystem permissions and compensating controls.

5. Configure EAP-TLS

sudo nano /etc/freeradius/3.0/mods-enabled/eap

Confirm that the default EAP type is TLS:

default_eap_type = tls

Inside tls-config tls-common, configure the certificate paths. Use the passphrase entered when the private key was generated.

tls-config tls-common {
    private_key_password = REPLACE_WITH_PRIVATE_KEY_PASSPHRASE
    private_key_file = /etc/freeradius/3.0/certs/production/server.key
    certificate_file = /etc/freeradius/3.0/certs/production/server.pem
    ca_file = /etc/freeradius/3.0/certs/production/client-ca-chain.pem
    require_client_cert = yes
}

The ca_file defines which certificate authorities FreeRADIUS trusts to issue client certificates. Keep this trust list as narrow as possible. A valid signature proves that a trusted CA issued the certificate; production authorization should also consider certificate identity, intended use, revocation, and device ownership.

6. Configure a Basic VLAN Reply

Open the files-module authorization policy:

sudo nano /etc/freeradius/3.0/mods-config/files/authorize

For a dedicated EAP-TLS test server where every successful request should receive the same data VLAN, add:

DEFAULT
    Tunnel-Type := VLAN,
    Tunnel-Medium-Type := IEEE-802,
    Tunnel-Private-Group-Id := "20"

Important limitation: This broad DEFAULT rule applies the same reply to every request that reaches this files policy. Use it only for a dedicated test or single-policy server. In production, authorize devices using certificate attributes, groups, a device inventory, LDAP, SQL, or another authoritative source. Do not add Auth-Type := EAP; FreeRADIUS detects EAP automatically, and its documentation warns that forcing the authentication type can interfere with other methods.

The three returned attributes are the standard values Cisco uses for RADIUS VLAN assignment:

Attribute 64: Tunnel-Type = VLAN
Attribute 65: Tunnel-Medium-Type = IEEE-802
Attribute 81: Tunnel-Private-Group-Id = VLAN name or ID

7. Validate the FreeRADIUS Configuration

Check the complete configuration before starting the service:

sudo freeradius -XC

Do not continue until the command ends with a successful configuration check. If it reports an error, correct the referenced file and line before proceeding.

8. Configure the Cisco Catalyst Switch

The example below illustrates the required concepts on a Cisco Catalyst access switch. Exact syntax varies by IOS XE release and whether the switch uses legacy authentication commands or the newer Identity-Based Networking Services policy model. Compare this example with the configuration guide for your platform and release.

aaa new-model

radius server RADIUS1
 address ipv4 192.0.2.20 auth-port 1812 acct-port 1813
 key REPLACE_WITH_THE_SAME_LONG_RANDOM_SHARED_SECRET

aaa group server radius DOT1X-RADIUS
 server name RADIUS1

aaa authentication dot1x default group DOT1X-RADIUS
aaa authorization network default group DOT1X-RADIUS
dot1x system-auth-control

Example access-port configuration:

interface GigabitEthernet1/0/21
 description 802.1X TEST PORT
 switchport mode access
 switchport access vlan 999
 switchport voice vlan 10
 authentication event server dead action authorize vlan 999
 authentication event server alive action reinitialize
 authentication order dot1x
 authentication priority dot1x
 authentication port-control auto
 authentication periodic
 authentication violation replace
 dot1x pae authenticator
 dot1x timeout quiet-period 2
 dot1x timeout tx-period 3
 spanning-tree portfast
 spanning-tree bpduguard enable

Design warning: VLAN 999 is only an example. The configured access, failure, critical-auth, and no-response behaviors determine what unauthenticated devices can reach. Use a restricted VLAN and ACL appropriate to your organization. Do not provide general production access merely because the RADIUS server is unavailable or an endpoint did not respond.

9. Test in Debug Mode

Run FreeRADIUS interactively while testing:

sudo freeradius -X

Wait for Ready to process requests, then connect a properly configured EAP-TLS endpoint to the test port. In the debug output, verify:

The request arrives from the expected switch address.
The server presents the intended certificate.
The client certificate chains to the expected CA.
The certificate identity matches the device you intended to authorize.
The server returns an Access-Accept.
The reply contains the expected tunnel attributes.

On the switch, use commands appropriate to the installed IOS XE release. Common checks include:

show authentication sessions interface GigabitEthernet1/0/21 details
show interfaces status | include Gi1/0/21
show radius statistics

Confirm that the method is dot1x, the session is authorized, and the assigned data VLAN is the VLAN returned by RADIUS.

10. Return FreeRADIUS to Normal Service

Press Ctrl+C to stop debug mode, then enable and start the service:

sudo systemctl enable --now freeradius
sudo systemctl status freeradius --no-pager

Troubleshooting Checklist

No request appears: Verify routing, host firewall rules, switch source interface, RADIUS server address, and UDP ports.
Unknown client: Confirm the switch source IP matches an entry in clients.conf.
Invalid Message-Authenticator or silent timeout: Confirm that both sides use the same RADIUS shared secret.
TLS handshake fails: Check certificate validity, key pairing, CA trust, EKU, SAN, system time, and client configuration.
Access-Accept but wrong VLAN: Verify the reply attributes, VLAN existence and state on the switch, and that the data VLAN does not conflict with the voice VLAN.
Works in debug mode but not as a service: Check file ownership, permissions, service logs, and whether the service account can read the key and certificates.

Rollback

If testing fails and you need to return to the previous state:

Move the test endpoint to a known working port.
Restore the switch interface’s previous configuration.
Stop FreeRADIUS.
Restore the configuration backup created earlier.
Run sudo freeradius -XC.
Start the service only after validation succeeds.

Where to Go Next

This configuration is a solid lab and proof-of-concept starting point. A production deployment should add identity-specific authorization, certificate lifecycle management, revocation checking, redundant RADIUS servers, restricted failure behavior, monitoring, configuration backups, and documented renewal procedures.

If you need help planning an 802.1X deployment, certificate strategy, or network-access-control project, contact Sales.

Configure FreeRADIUS EAP-TLS and Dynamic VLAN Assignment