RADIUS Server Configuration
Connect Warden to your existing RADIUS infrastructure for seamless authentication
What's This All About?
Already running a RADIUS server? Great news - Warden plays nicely with your existing setup. Whether you're using FreeRADIUS, Cisco ISE, Microsoft NPS, or a cloud-based MFA provider like Duo, you can chain Warden's authentication through your RADIUS infrastructure.
This is especially useful when you want to add two-factor authentication, integrate with existing user directories, or maintain a single source of truth for network access policies.
Common Use Cases
- Add MFA to existing infrastructure - Chain through Duo, Azure MFA, or RSA SecurID
- Integrate with Cisco ISE - Use ISE for policy decisions while Warden handles the frontend
- Centralize authentication - Point multiple Warden instances at a central RADIUS server
- Hybrid deployments - Combine cloud identity providers with on-prem RADIUS
Before You Start
Make sure you have these details handy:
- RADIUS server hostname or IP address
- Authentication port (usually 1812, but some legacy systems use 1645)
- The shared secret you'll configure on both ends
- Network connectivity between Warden and your RADIUS server
Pro Tip: Test network connectivity first with a simple ping or telnet to port 1812. Many RADIUS issues turn out to be firewall problems in disguise.
Setting Things Up
Step 1: Configure Your RADIUS Server
First, tell your RADIUS server to trust Warden. You'll need to add Warden as a client:
client warden {{'{'}
ipaddr = 10.0.1.100 # Warden's IP address
secret = your-shared-secret
shortname = warden
{{'}'}}
For other RADIUS servers (NPS, ISE, etc.), the concept is the same - add Warden's IP and a shared secret. Check your vendor's documentation for the specific steps.
Step 2: Add the Provider in Warden
- Navigate to My Providers
- Click Add Provider
- Select RADIUS Server as the type
- Fill in the configuration fields below
With MFA/push notifications: 60-90 seconds
With MFA: 1 retry (to avoid duplicate push notifications)
Two-Factor Authentication: Getting Timeouts Right
Here's where a lot of RADIUS+MFA setups go sideways. When you're using push notifications (Duo, Azure MFA, Okta Verify, etc.), your users need actual human time to respond. They might need to pull out their phone, unlock it, open the app, and tap "Approve."
The Problem: Most network devices ship with 5-20 second timeouts. That's fine for password-only authentication, but way too short when someone's fumbling for their phone in a meeting.
What Actually Happens During MFA
- User enters username and password
- Warden forwards the request to your RADIUS/MFA server
- MFA server sends a push notification to the user's phone
- User finds phone, unlocks it, opens authenticator app, taps "Approve"
- MFA server tells Warden "Access-Accept"
- Warden tells the network device "You're in!"
Steps 3-4 can easily take 30-60 seconds in the real world. If your timeout is set to 10 seconds, the connection gets dropped before the user even has a chance to approve.
Recommended Timeout Settings
Pro Tip: Set your NAS/client timeout slightly longer than Warden's timeout. This way, if something times out, Warden handles it gracefully rather than the network device just giving up with a confusing "no response" error.
Vendor-Specific Notes
Duo recommends 60 seconds with 1 retry. Their Authentication Proxy has its own timeout settings that should match. See Duo's documentation on RADIUS timeout configuration.
Microsoft recommends at least 60 seconds. The NPS extension has its own timeout that defaults to 60 seconds for the primary auth and 60 for secondary.
ISE respects the RADIUS timeout from the client. Make sure your network device configuration matches what you've set in Warden.
These typically default to 5-20 seconds. You'll almost certainly need to increase the timeout in the dashboard/controller settings when using MFA.
Testing Your Connection
- Save your identity provider configuration
- Click the menu icon (⋮) next to your provider
- Select Test Connection
- Enter credentials for a real user on your RADIUS server
- Click Run Test
Success! You'll see an Access-Accept response with any attributes your RADIUS server returned. If you're using MFA, you should receive a push notification during the test.
RADIUS Attributes Reference
Here's what Warden sends and receives during RADIUS authentication. Understanding these helps when debugging or configuring advanced policies on your RADIUS server.
What Warden Sends
What Warden Receives
Troubleshooting
Running into issues? Here are the most common problems and how to fix them:
Connection Timeout
What's happening: Warden can't reach your RADIUS server at all.
Check these things:
- Can you ping the RADIUS server from the Warden host?
- Is port 1812 (or your custom port) open in firewalls?
- Is the RADIUS service actually running?
- Try
telnet radius-server 1812to test connectivity
Access-Reject (But Credentials Are Correct)
What's happening: The RADIUS server received the request but said "no."
Check these things:
- Check the RADIUS server logs - they usually tell you exactly why
- Is the user account enabled and not locked?
- Are there time-of-day restrictions on the RADIUS server?
- For MFA: did the user approve the push in time?
No Response / Silence
What's happening: The RADIUS server is ignoring Warden's requests entirely.
Check these things:
- Shared secret mismatch - This is the #1 cause. RADIUS servers silently drop packets with bad secrets.
- Is Warden's IP address in the RADIUS server's allowed clients list?
- Copy/paste the shared secret to avoid invisible character issues
"Bad Authenticator" or "Invalid Packet"
What's happening: The shared secrets don't match.
The fix: Re-enter the shared secret on both sides. Watch out for:
- Trailing spaces or newlines
- Special characters that might be interpreted differently
- Copy/paste issues (some terminals add invisible characters)
MFA Push Never Arrives
What's happening: The authentication times out before MFA even starts.
Check these things:
- Is the user enrolled in MFA on the MFA server?
- Is the timeout long enough? (See the MFA timeout section above)
- Check the MFA server logs for errors
Testing with radtest
The radtest command is your best friend for debugging RADIUS issues.
It lets you test directly against the RADIUS server, bypassing Warden entirely:
For example:
If radtest works but Warden doesn't, the problem is in Warden's configuration. If radtest fails too, the problem is with the RADIUS server or network.
Security Best Practices
- Strong shared secrets: Use at least 20 random characters. Password managers are great for generating these.
- IP restrictions: Configure your RADIUS server to only accept connections from Warden's IP address.
- Encrypted transport: For RADIUS over untrusted networks, use IPsec, a VPN, or RadSec (RADIUS over TLS).
- Monitor logs: Keep an eye on RADIUS server logs for failed authentication attempts - they could indicate attacks.
- Different secrets per client: Use unique shared secrets for each RADIUS client, not one shared secret for everything.
Integration Examples
Duo Security
Duo's Authentication Proxy sits between Warden and your user directory, adding push-based MFA. Configure the proxy as your RADIUS server in Warden, and make sure to set timeouts to at least 60 seconds.
Cisco ISE
Add Warden as a Network Access Device in ISE. Use the shared secret you configured in Warden. ISE can handle complex policy decisions and return VLAN assignments or downloadable ACLs.
FreeRADIUS
Add Warden to clients.conf with its IP and shared secret. FreeRADIUS is incredibly
flexible - you can chain to LDAP, SQL databases, or other RADIUS servers.
Microsoft NPS
Add Warden as a RADIUS client in Network Policy Server. If you're using the Azure MFA extension, remember to increase timeouts on both NPS and in Warden.