A MikroTik RADIUS setup checklist for ISP teams.

Overview

Connecting MikroTik RouterOS to RADIUS is not only a server-address task. The access service, subscriber credentials, returned attributes, accounting messages and operational response all need to agree.

This checklist focuses on the decisions that reduce rollout surprises. Exact RouterOS commands and available attributes depend on the RouterOS version, service type and RADIUS design, so validate them against the current vendor documentation and a non-production environment.

Start with the access service and subscriber identity.

Decide whether the deployment covers PPPoE, hotspot or another supported service. Define the identifier a subscriber presents, where credentials are owned and which local RouterOS behavior remains available if the RADIUS service cannot be reached.

Keep the first test narrow. A single documented service and a small set of representative accounts are easier to diagnose than several access methods introduced at once.

• Service type and authentication method
• Username format, credential ownership and duplicate handling
• Expected behavior during a RADIUS timeout or outage

Register each router as a distinct RADIUS client.

Use an unambiguous NAS identity, correct source address and a strong, unique shared secret for each managed router or logical group. Restrict RADIUS traffic at the network boundary so only expected systems can reach the service.

Consistent naming becomes especially important across branches and zones. An accounting record should immediately reveal which router and service area produced it.

• NAS name, source IP, zone and responsible team
• Unique shared secret stored through an approved process
• Firewall rules limited to required RADIUS peers and traffic

Define what authorization should return.

Write down the successful result for every test subscriber: service profile, rate policy, addressing behavior, simultaneous-session rule and any vendor-specific attributes. Avoid adding attributes simply because they are available; each one should have a clear owner and enforcement point.

Test rejected and expired accounts as carefully as active ones. The support team should be able to distinguish bad credentials, policy rejection, billing state and infrastructure failure.

• Package or rate-policy result
• IP allocation and pool behavior where applicable
• Active, expired, suspended and unknown-user outcomes

Test accounting as an end-to-end record.

Confirm that session start, periodic updates and stop records reach the correct subscriber record with stable identifiers. Align time synchronization across RouterOS, the RADIUS service and the management platform before interpreting duration or usage.

If the design uses dynamic authorization, disconnect or Change of Authorization, test it separately and verify support across every component. Do not make it an assumed dependency.

• Start, interim-update and stop visibility
• Usage counters, session identifiers and time consistency
• Stale-session handling after a router or service restart

Roll out with evidence and a rollback path.

Move a controlled subscriber group first and observe both successful service and expected failures. Record authentication latency, rejection reasons, accounting completeness and the support questions generated by the change.

PHP Radius connects supported MikroTik access workflows to subscriber, billing and operational context. Compatibility and the exact available controls should be confirmed for the intended RouterOS version and topology during deployment planning.

• Configuration backup and tested rollback procedure
• Pilot group with active, expired and deliberately invalid accounts
• Named owner for monitoring and first-line incident response