2.10 Lab: Configure A Radius Solution – The One Trick Cisco Pros Don’t Want You To Know!

Ever tried to get a handful of network devices to talk to the same authentication server and ended up pulling your hair out?
That moment when a user can’t log in, the switch blinks red, and the syslog is a wall of “Access‑Reject” messages—yeah, we’ve all been there. The good news? A properly configured RADIUS solution can turn that chaos into a smooth, single‑sign‑on experience Took long enough..

In this lab‑style walk‑through I’ll show you how to set up a RADIUS server from scratch, hook it up to a Cisco router and a Windows client, and verify that everything works the way it should. No fluff, just the steps that actually matter, plus the pitfalls most people hit on the way.

What Is a RADIUS Solution

Think of RADIUS (Remote Authentication Dial‑In User Service) as the gatekeeper for network access. That's why when a device—say a switch, VPN concentrator, or Wi‑Fi AP—receives a login request, it forwards the credentials to the RADIUS server. The server checks the username and password (or a certificate), decides whether to allow or deny access, and sends back a response.

In practice the RADIUS server does three things:

• Authentication – “Is this user who they claim to be?”
• Authorization – “What are they allowed to do once they’re in?”
• Accounting – “When did they log on, for how long, and what did they do?”

Most labs focus on the first two; accounting is a nice extra but not required for a basic proof‑of‑concept.

The Pieces You’ll Need

• RADIUS server software – FreeRADIUS on Linux is the go‑to, but Windows NPS works too.
• Network device(s) – A Cisco router or switch that will act as the RADIUS client.
• User database – Usually just a local file or an AD/LDAP backend for the lab.
• Test client – A Windows or Linux machine with a telnet/ssh client to generate login attempts.

Why It Matters

Why bother with a separate authentication server instead of local device passwords?

• Centralized control – Change a password once, it updates everywhere.
• Policy enforcement – Role‑based access can be enforced from a single point.
• Audit trail – Accounting logs give you a clear picture of who did what, when.

When you skip RADIUS, you end up with a patchwork of passwords scattered across devices. The short version is: security and manageability both take a hit Took long enough..

How to Configure a RADIUS Solution

Below is the step‑by‑step guide for a classic 13.2.Practically speaking, 10 lab. I’ll use Ubuntu 22.04 with FreeRADIUS 3.Consider this: 2 and a Cisco IOS router. Feel free to swap in Windows NPS if that’s your environment.

1. Install FreeRADIUS

sudo apt update
sudo apt install freeradius freeradius-utils

That pulls in the core daemon and a handful of useful tools like radclient. Once installed, the service should be up and listening on UDP port 1812 (authentication) and 1813 (accounting).

2. Create a Test User

Open the users file:

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

Add a line like this:

testuser Cleartext-Password := "P@ssw0rd"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Framed-IP-Address = 10.10.10.100

Save and exit. This creates a simple local user that the RADIUS server can authenticate.

3. Define the Client (Cisco Router)

Edit the clients.conf file:

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

Add:

client cisco-router {
    ipaddr = 192.168.1.1
    secret = testing123
    require_message_authenticator = no
}

Replace 192.But 168. 1.Consider this: the secret is the shared key both sides will use to encrypt the RADIUS packets. 1 with the actual IP of your router. Keep it strong; don’t reuse passwords.

4. Restart the RADIUS Service

sudo systemctl restart freeradius

Check the status:

sudo systemctl status freeradius

You should see “active (running)”. Here's the thing — if not, look at /var/log/freeradius/radius. log for clues.

5. Configure the Cisco Router

Enter global configuration mode:

Router# configure terminal
Router(config)# radius server RADIUS1
Router(config-radius-server)# address ipv4 192.168.1.10 auth-port 1812 acct-port 1813
Router(config-radius-server)# key testing123
Router(config-radius-server)# exit

Now tell the router to use RADIUS for line login:

Router(config)# aaa new-model
Router(config)# aaa authentication login default group radius local
Router(config)# aaa authorization exec default group radius local
Router(config)# line vty 0 4
Router(config-line)# login authentication default
Router(config-line)# exit

The local fallback is handy for lab work; in production you’d probably drop it Simple as that..

6. Test the Authentication

From a Windows client, open a command prompt and run:

telnet 192.168.1.1

When prompted, type testuser and P@ssw0rd. If everything is wired correctly, you should get a login shell Nothing fancy..

If you prefer a quick Linux test, use radclient:

echo "User-Name = testuser, User-Password = P@ssw0rd" | radclient -x 192.168.1.10 auth testing123

A “Access‑Accept” response means success; “Access‑Reject” tells you something’s off Small thing, real impact..

7. Verify Accounting (Optional)

Enable accounting on the router:

Router(config)# aaa accounting exec default start-stop group radius

Now, after you log in and log out, check the FreeRADIUS accounting log:

cat /var/log/freeradius/radacct/* | grep testuser

You should see start and stop records with timestamps Worth keeping that in mind. That's the whole idea..

Common Mistakes / What Most People Get Wrong

1. Mismatched secrets – The shared secret must be identical on both sides, down to case and any trailing spaces. A stray space is a silent killer.
2. Wrong IP address in clients.conf – If the router’s address isn’t whitelisted, the server will drop the packet silently.
3. Firewall blocks – UDP 1812/1813 need to be open on the RADIUS host. I’ve seen labs where the OS firewall was the hidden culprit.
4. Using the wrong authentication method – FreeRADIUS defaults to PAP for cleartext passwords. If you try CHAP from the router without enabling it, you’ll get rejects.
5. Neglecting to restart the service – After editing users or clients.conf, you must restart the daemon; otherwise you’ll be chasing ghosts.

Practical Tips – What Actually Works

• Keep a test user separate – Don’t mix lab accounts with production ones. It avoids accidental lockouts.
• Log at debug level while building – Run sudo freeradius -X to see live processing of each request. It’s the fastest way to spot where a packet is failing.
• Use show aaa servers on Cisco – That command tells you whether the router can reach the RADIUS server and what secret it’s using.
• Document the shared secret – Store it in a password manager, not in a plain‑text README.
• Plan for redundancy – In real deployments you’ll have at least two RADIUS servers. The Cisco radius server command supports multiple entries; just list them in order of preference.

FAQ

Q: Can I use LDAP instead of a local user file?
A: Absolutely. FreeRADIUS has an ldap module you can enable in mods-enabled. Point it at your AD or OpenLDAP server, and you can authenticate against the same directory you use for Windows logins The details matter here..

Q: Do I need to configure encryption for the RADIUS traffic?
A: RADIUS itself only encrypts the password field, not the whole packet. If you’re worried about sniffing, place the server and clients on a trusted VLAN or use IPsec/Tunnel‑mode VPN to protect the traffic Easy to understand, harder to ignore..

Q: What’s the difference between port 1812 and 1645?
A: 1812/1813 are the officially assigned ports for authentication and accounting. 1645/1646 are legacy ports some older gear still expects. If you run into “no response” errors, double‑check which ports your device uses.

Q: How do I add a Windows domain user without replicating the password file?
A: Use NPS on a Windows Server or enable the ntlm_auth helper in FreeRADIUS. That way the RADIUS server forwards the credentials to the domain controller for verification That's the whole idea..

Q: My router says “RADIUS server unreachable” even though I can ping it.
A: Verify UDP connectivity (not just ICMP). A quick nc -u -zv 192.168.1.10 1812 from a Linux box will confirm the port is open. Also, make sure the router’s source IP matches the entry in clients.conf No workaround needed..

Setting up a RADIUS solution isn’t rocket science, but it does demand attention to the tiny details that can break the whole chain. Once you have the lab working, you’ll see how much smoother device onboarding becomes, and you’ll have a solid foundation for scaling up to a full‑blown AAA infrastructure.

Give it a try, break a few things, and then fix them—because that’s the fastest way to make the knowledge stick. Happy authenticating!