Operations → RADIUS troubleshooting

RADIUS Troubleshooting for MikroTik PPPoE and Hotspot

Stop guessing at RADIUS failures. Collect evidence in order, test one identity, and distinguish authentication from accounting.

Written by Diaa · Last reviewed 21 September 2026 · RouterOS v7.x focus

When a MikroTik PPPoE or Hotspot deployment fails, changing the router configuration repeatedly can hide the real cause. RADIUS troubleshooting is faster when you separate the path into four questions: can the router reach the server, is the router an allowed client, does authentication work, and is accounting being recorded?

Use one test identity and one change at a time. Keep the username, router source address, timestamp, and RADIUS server log entry together. That turns a vague “login failed” report into an evidence trail.

The four-layer diagnostic order

Layer	Question	Evidence
1. Reachability	Can the router reach the RADIUS server over the intended route?	Route table, ping where appropriate, server-side packet capture or logs.
2. Client definition	Does the server recognize this router's source IP as a RADIUS client?	NAS/client entry and the source address seen by the server.
3. Authentication	Does the test username receive Access-Accept with the expected attributes?	Access-Request, response code, username, profile, address, and rate limit.
4. Accounting	Do Start, Interim-Update, and Stop records arrive?	Accounting logs and byte counters in the billing platform.

Start with RouterOS evidence

Collect output before changing anything. Redact secrets before sharing it with another person.

/radius print detail
/ppp aaa print
/ip route print
/log print where topics~"radius|ppp"
/ppp active print detail

Check that the service matches the access method: PPPoE uses the PPP service; Hotspot uses the Hotspot service. Confirm the router's actual source address is the address registered on the RADIUS server. A management address, loopback address, or NAT address can be different from the address you expected.

Authentication failures

If there is no Access-Request at the server, troubleshoot routing, firewall policy, UDP 1812, and the source address first. If the request arrives and the server rejects it, inspect the username, password, client definition, and policy rules. If the server accepts it but RouterOS reports a timeout, compare the return path and any intermediate firewall rules.

Symptom	Likely cause	Next test
No RADIUS log entry	Wrong route, blocked UDP, wrong server address, or the router is not sending requests.	Check route and firewall counters, then observe traffic on the server.
“Unknown client”	The server does not have the router's source IP in its client/NAS list.	Add the exact source IP and reload the RADIUS service.
“Invalid secret” or silent reject	Shared secret differs, contains whitespace, or the wrong client entry is matched.	Set a new unique secret on both sides and test once.
Access-Accept but no session	RouterOS service, profile, address pool, or returned attribute is incompatible.	Inspect the response attributes and the PPP/Hotspot log.

Accounting failures

Do not treat a successful login as proof that billing works. Verify accounting=yes, the accounting service, and the interim interval. UDP 1813 may be blocked even when UDP 1812 is open. A Stop record may also be delayed until the session ends, so use an Interim-Update for a live test.

/ppp aaa print
/log print where topics~"radius"
# Then keep one test session active for at least one interim interval.

Compare the router's session start time with the server's record. If authentication and accounting appear from different source addresses, fix the routing or source-address selection rather than creating duplicate client entries without understanding the path.

Safe test sequence

Record the current configuration and time in UTC.
Test reachability and verify the route to the RADIUS server.
Confirm the server sees the router as the expected client.
Use one test account and verify Access-Accept attributes.
Keep the session active until an Interim-Update is visible.
Disconnect the client and verify the Stop record and final byte counters.
Only after all six checks pass, test a second account or a second access interface.

What not to change blindly

Do not disable the firewall globally, copy a shared secret into a public ticket, change the subscriber pool while sessions are active, or add multiple RADIUS servers to hide a timeout. Each change makes the evidence less clear and can create a wider outage. Use the deployment checklist when the issue is part of a larger rollout.

References

For protocol and RouterOS behavior, consult the official RADIUS, PPP AAA, and Log documentation. This page explains a diagnostic method; it does not replace the manual for the exact RouterOS release in use.