RADIUS Server Not Responding on MikroTik RouterOS v7

What “RADIUS server not responding” can mean

The message is not a single failure. It may mean the router cannot route to the RADIUS server, a firewall drops UDP, the RADIUS client is registered with the wrong source address, the server does not recognize the router as a NAS client, or the reply is rejected because the shared secret is wrong. A PPPoE client can also fail earlier during discovery, before RADIUS is involved at all.

Use this order: PPPoE discovery → IP reachability → RouterOS RADIUS entry → PPP AAA → RADIUS server client definition → shared secret and ports → authentication response → accounting.

1. Confirm that the failure reaches the RADIUS layer

If the client never receives a PADO, the issue is usually the subscriber-facing interface, bridge, VLAN, service name, or PPPoE server state—not RADIUS. On a test client, first confirm that the PPPoE server is visible and the client is attempting the expected service name.

On the router, print the PPPoE server configuration:

/interface pppoe-server server print detail

Confirm that the server is enabled, the interface is the subscriber-facing interface, and the service name matches the client when one is required. Do not put a normal IP address on the interface that receives PPPoE discovery unless your topology specifically requires a different design.

Then watch only the PPPoE and PPP log topics while making one test connection:

/log print follow where topics~"pppoe|ppp"

If there is no discovery or session activity, fix Layer 2 or the PPPoE server before investigating RADIUS.

2. Test IP reachability from the router

Replace the placeholder with the real RADIUS address. Run one command, read the result, and do not assume that a working ping proves UDP/1812 is allowed; it only proves that ICMP reached the address.

/ping address=<RADIUS_SERVER_IP>

If the address is in another subnet, inspect the route chosen by RouterOS:

/ip route check <RADIUS_SERVER_IP>

If the RADIUS server is reached through a specific VRF, source address, or tunnel, perform the test from that same routing context. A common WISP mistake is testing from a management path while PPP traffic uses a different VRF or source address.

3. Inspect the RouterOS RADIUS entry

Print the entry without exposing the secret in a screenshot:

/radius print detail

For PPPoE, verify that the entry includes service=ppp. The default authentication and accounting ports are UDP 1812 and 1813. Verify the server address, source address, and timeout. If you set src-address, the RADIUS server must know that source IP as the router/NAS client.

When a request is made, inspect the RADIUS counters:

/radius monitor [find]

Look for requests, accepts, rejects, timeouts, and bad replies. A timeout points toward routing, firewall, wrong address, or a silent server. A bad reply often points toward a shared-secret mismatch or a response that the router cannot validate.

4. Confirm that PPP is allowed to use RADIUS

Registering a server under /radius does not by itself enable remote authentication. Print PPP AAA:

/ppp aaa print

For remote PPP authentication, use-radius=yes must be enabled. For usage records, accounting=yes must be enabled as well. An interim update such as 5m is a practical starting point, but choose an interval that your RADIUS and billing systems can handle.

Remember the local database rule: RouterOS checks a matching local PPP secret first. A local test account can therefore succeed while the RADIUS path is never exercised. Test with a username that does not exist locally when you need to prove remote authentication.

5. Check the RADIUS server’s NAS/client definition

The RADIUS server must have a client definition for the router’s actual source IP. Check these values on the server side:

• Client/NAS address: the source IP seen by the RADIUS server, not necessarily the router’s management address.
• Shared secret: must match exactly, including case and hidden whitespace.
• Authentication port: normally UDP 1812.
• Accounting port: normally UDP 1813.
• Service: the RouterOS entry must include PPP for PPPoE.
• Policy: the user must be allowed to authenticate through PPP/PPPoE.

Do not change the secret on both systems at once without a controlled test. Change one side, test one account, and check the server log before moving to the next variable.

6. Read the logs while performing one test login

Open a dedicated log view, start one connection attempt, and stop the view after the attempt. RouterOS supports topic-based logging, including radius, ppp, and pppoe.

/log print follow where topics~"radius|ppp|pppoe"

Interpret the result as a decision tree:

7. Check firewall counters without opening the router

First print filter counters and rule order:

/ip firewall filter print stats

Look for a drop rule that matches traffic between the router and the RADIUS server, or a rule that drops input traffic if the RADIUS server is on the router itself. If you add a temporary allow rule for testing, place it narrowly, document it, and remove it after the test. Do not disable the whole firewall as a troubleshooting shortcut.

For a RADIUS server behind a tunnel or NAT, also confirm that return traffic follows the same path. A one-way UDP path can look exactly like a dead RADIUS server.

8. Verify accounting separately from authentication

Authentication and accounting are different conversations. A successful login proves that an Access-Accept was accepted; it does not prove that Accounting-Start, Interim-Update, and Accounting-Stop records are reaching the billing system.

After one test session is connected, inspect active PPP sessions:

/ppp active print detail

Then confirm the server receives accounting records on UDP 1813 and that the session ID and byte counters are changing. If authentication works but accounting does not, do not rotate the user password; inspect the accounting port, firewall path, server listener, and /ppp aaa settings instead.

9. A repeatable test matrix

Sources and version notes

This checklist follows MikroTik's official RADIUS, PPP AAA, PPPoE, and logging documentation. RouterOS menus and defaults can change between releases, so confirm the exact syntax on the target version before production use. RADIUS authentication is described in RFC 2865, and accounting in RFC 2866.