RADIUS Server Not Responding – Complete Troubleshooting Guide

When your RADIUS server stops responding, every second counts. Subscribers get disconnected, support tickets pile up, and your ISP's reputation takes a hit. Whether you are running OneRADIUS or any AAA RADIUS server, this complete troubleshooting guide will help you systematically identify and resolve the issue fast.

---

What Does 'RADIUS Server Not Responding' Actually Mean?

The error 'RADIUS Server Not Responding' typically appears on your NAS (Network Access Server), router, or access point when it sends an authentication or accounting request to the RADIUS server and receives no reply within the configured timeout window.

This can affect:

  • **PPPoE authentication** for broadband subscribers
  • **Wi-Fi 802.1X authentication** for hotspot or enterprise networks
  • **VPN login authentication**
  • **Accounting start/stop packets** causing session tracking failures
⚠️ Do not restart your RADIUS server blindly as the first step. Always diagnose before taking action — a restart may clear logs needed to identify the root cause.

---

Step 1 – Verify the RADIUS Service is Actually Running

The most obvious but often overlooked first step is confirming the RADIUS daemon is up and running on your server.

For Linux-based OneRADIUS deployments:

  • Run: **systemctl status oneradius** or the relevant service name
  • Check for any 'failed' or 'inactive' status in the output
  • Review the last few log lines shown in the status output for crash messages

For Windows-based deployments:

  • Open **Services** (services.msc)
  • Locate the RADIUS or OneRADIUS service
  • Confirm it shows 'Running' status
  • Check Windows Event Viewer for any application errors
💡 OneRADIUS includes a built-in service health dashboard. Always check the dashboard first before diving into command-line diagnostics.

---

Step 2 – Check RADIUS Port Availability (UDP 1812 and 1813)

RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting by default. If these ports are blocked or not listening, your NAS will never get a response.

How to check:

  • Run: **netstat -anup | grep 1812** on Linux to see if the RADIUS process is listening
  • Use: **ss -ulnp | grep 1812** as an alternative
  • On Windows: **netstat -ano | findstr 1812**

What to look for:

  • The output should show the RADIUS process bound to **0.0.0.0:1812** or your server's specific IP
  • If nothing appears, the RADIUS service is not listening — restart it and re-check
  • If another process is occupying port 1812, there is a port conflict that must be resolved
⚠️ Some ISPs still use the legacy ports UDP 1645 and 1646. If your NAS is configured for legacy ports and the server is on standard ports, this mismatch will cause 'no response' errors.

---

Step 3 – Firewall and Network ACL Checks

Even if the RADIUS service is running perfectly, a firewall rule can silently drop all incoming packets before they ever reach the server.

Linux firewall check (iptables):

  • Run: **iptables -L -n -v | grep 1812**
  • Ensure there is an ACCEPT rule for UDP port 1812 from your NAS IP
  • If missing, add: **iptables -A INPUT -p udp --dport 1812 -s <NAS_IP> -j ACCEPT**

Linux firewall check (firewalld):

  • Run: **firewall-cmd --list-ports**
  • Add if missing: **firewall-cmd --permanent --add-port=1812/udp && firewall-cmd --reload**

Network-level ACLs:

  • Check if your upstream switch, router, or cloud security group is blocking UDP traffic
  • For cloud-hosted OneRADIUS (AWS, Azure, GCP), verify the security group inbound rules allow UDP 1812/1813 from NAS public IPs
💡 Always test connectivity using a RADIUS test tool like **radtest** from a machine on the same network as the NAS before concluding the server is at fault.

---

Step 4 – Validate NAS IP and Shared Secret Configuration

RADIUS authentication is IP-based. If the NAS (router, OLT, BNG) is not registered in the RADIUS server's client list with the correct IP and shared secret, the server will silently drop or ignore the request — which looks like 'no response' from the NAS side.

Things to verify:

  • Open OneRADIUS admin panel and check **NAS Clients / Devices** list
  • Confirm the NAS IP matches exactly what is shown in RADIUS logs (not a NAT'd address)
  • Verify the **shared secret** is identical on both NAS and RADIUS — case-sensitive
  • If your NAS is behind NAT, the RADIUS server sees the NAT IP, not the LAN IP — update accordingly
⚠️ A wrong shared secret does not always produce an explicit error in older NAS firmware — it may simply result in the request being ignored, appearing as a timeout.

---

Step 5 – Review RADIUS Server Logs for Errors

Logs are your best friend during troubleshooting. OneRADIUS maintains detailed logs that capture every authentication request, response, and error.

Where to find logs:

  • **OneRADIUS Web Panel**: Navigate to Logs > Authentication Logs or System Logs
  • **Linux log file**: Typically at **/var/log/oneradius/** or **/var/log/freeradius/** depending on your setup
  • **Real-time log tailing**: Run **tail -f /var/log/oneradius/radius.log**

Common log errors and what they mean:

  • **'Unknown client'** – NAS IP not found in client list. Add it.
  • **'Invalid shared secret'** – Shared secret mismatch. Correct it on NAS or RADIUS.
  • **'No response to packet'** – RADIUS is receiving but not processing. Check database or handler.
  • **'Connection refused' on DB** – RADIUS cannot reach MySQL/database. See Step 6.
  • **'Failed to bind socket'** – Port conflict or permission error during startup.
💡 Enable **debug mode** in OneRADIUS temporarily during troubleshooting to get verbose packet-level logs. Remember to disable debug mode in production after diagnosis.

---

Step 6 – Database Connectivity Issues

OneRADIUS and most modern RADIUS platforms use a database (MySQL/MariaDB) to store user credentials, plans, and session data. If the RADIUS server cannot connect to its database, it will fail to process authentication requests — appearing as 'not responding.'

How to diagnose:

  • Check RADIUS logs for database connection errors
  • Try connecting manually: **mysql -u radius_user -p -h 127.0.0.1 radius_db**
  • Verify MySQL/MariaDB is running: **systemctl status mysql**
  • Check if the database max connections limit is reached: **SHOW STATUS LIKE 'Threads_connected';**

Common database-related causes:

  • MySQL service crashed or restarted
  • Database password changed but not updated in RADIUS config
  • Too many open connections causing new ones to be rejected
  • Database host changed (especially in cloud environments)
⚠️ In high-traffic ISP networks, database connection pool exhaustion is a very common cause of intermittent RADIUS failures during peak hours. Tune your connection pool settings accordingly.

---

Step 7 – Check Server Resource Exhaustion

Sometimes the RADIUS server is running, ports are open, and the database is fine — but the server is simply overwhelmed.

Resource checks to perform:

  • **CPU usage**: Run **top** or **htop** — if CPU is pegged at 100%, the server cannot process requests fast enough
  • **RAM**: Check free memory with **free -m** — low memory can cause process slowdowns or crashes
  • **Disk space**: Run **df -h** — a full disk can prevent log writing and cause service failures
  • **File descriptor limits**: RADIUS servers under high load may hit OS limits on open files/sockets

Solutions:

  • Increase RADIUS worker threads if your platform supports it
  • Upgrade server RAM or CPU for high-subscriber deployments
  • Archive and rotate old logs to free disk space
  • Increase **ulimit** for the RADIUS user: **ulimit -n 65535**
💡 OneRADIUS is optimised for Indian ISP scale deployments. If you are experiencing consistent resource exhaustion, contact the OneRADIUS support team at ARCR Technologies for performance tuning consultation.

---

Step 8 – NAS-Side Configuration Verification

The problem is not always on the RADIUS server. Sometimes the NAS device itself is misconfigured.

NAS-side things to verify:

  • Confirm the **RADIUS server IP** is correctly entered on the NAS (not a typo or old IP)
  • Check **RADIUS port numbers** match what the server is listening on
  • Verify the **shared secret** on the NAS matches exactly
  • Confirm the NAS is sending requests to the correct **primary RADIUS server** (not a decommissioned backup)
  • Check NAS **timeout and retry settings** — overly short timeouts cause false 'no response' errors
  • Review NAS logs or debug output for what it is actually sending
💡 For Mikrotik routers — a very common NAS device in Indian ISP networks — use **Tools > Radius** to verify configuration and use **Torch** or packet sniffer to confirm packets are being sent.

---

Step 9 – Test RADIUS with radtest or radclient

Using the radtest tool is the fastest way to isolate whether the problem is in the network path or the RADIUS server itself.

Running a basic radtest:

  • Install if needed: **apt install freeradius-utils**
  • Command: **radtest username password <RADIUS_SERVER_IP> 0 sharedsecret**
  • A successful response shows: **Received Access-Accept**
  • A failure shows: **No reply from server** or **Access-Reject**

Interpreting results:

  • **Access-Accept** – RADIUS is working fine; problem is on the NAS side
  • **Access-Reject** – RADIUS responded but rejected credentials; check user account in OneRADIUS
  • **No reply from server** – Confirm firewall, port binding, and service status
  • **Connection refused** – RADIUS is not listening on that port at all
💡 Run radtest from the same IP as your NAS device when possible. This ensures you are testing the exact same network path and NAS IP registration that real traffic would use.

---

Step 10 – High Availability and Failover Considerations

For production ISP environments, a single RADIUS server is a single point of failure. OneRADIUS supports high-availability configurations to prevent 'not responding' scenarios from impacting subscribers.

Recommended HA practices:

  • Deploy a **secondary/backup RADIUS server** and configure your NAS to failover automatically
  • Use **database replication** (MySQL master-slave) to keep both RADIUS servers in sync
  • Implement **health checks and monitoring** using tools like Zabbix, Nagios, or PRTG
  • Set up **automated alerts** when RADIUS stops responding — do not wait for subscriber complaints
  • Use **OneRADIUS redundancy features** for seamless failover in large ISP networks
⚠️ Many Indian ISPs discover their backup RADIUS server is not actually in sync only when the primary fails. Test your failover scenario regularly in a maintenance window.

---

Quick Reference Troubleshooting Checklist

Use this checklist whenever you face a 'RADIUS Server Not Responding' situation:

  • [ ] **Service running?** – Check systemctl or Windows Services
  • [ ] **Ports listening?** – Verify UDP 1812/1813 with netstat
  • [ ] **Firewall rules?** – Allow UDP 1812/1813 from NAS IPs
  • [ ] **NAS IP registered?** – Confirm in OneRADIUS client list
  • [ ] **Shared secret correct?** – Verify on both NAS and RADIUS
  • [ ] **Logs checked?** – Look for specific errors in RADIUS logs
  • [ ] **Database up?** – Confirm MySQL/MariaDB is running and accessible
  • [ ] **Resources OK?** – CPU, RAM, Disk, file descriptors
  • [ ] **NAS config verified?** – Correct IP, port, secret on NAS side
  • [ ] **Tested with radtest?** – Isolate server vs. network issue

---

Why Choose OneRADIUS for Your ISP?

OneRADIUS by ARCR Technologies, Hyderabad, is purpose-built for Indian ISPs. It offers:

  • **Intuitive admin panel** for easy subscriber and NAS management
  • **Real-time logs and alerts** for proactive issue detection
  • **Scalable architecture** supporting thousands of concurrent subscribers
  • **Local support team** that understands Indian ISP infrastructure challenges
  • **Integration-ready** with billing systems, OLTs, BNGs, and Mikrotik routers
💡 Facing a RADIUS issue right now? Visit **oneradius.com** or contact the ARCR Technologies support team in Hyderabad for expert assistance tailored to your ISP network.

---

Conclusion

A RADIUS server not responding is a critical issue but almost always has a diagnosable cause. By following this systematic troubleshooting approach — from service health to firewall rules, database connectivity, and NAS configuration — you can resolve most RADIUS failures quickly and minimise subscriber impact.

Implementing proactive monitoring and high-availability configurations will ensure that your RADIUS infrastructure stays reliable 24/7 — keeping your ISP subscribers connected and your business running smoothly.