Verify MikroTik PPPoE RADIUS Authentication and Accounting

A PPPoE connection that comes online does not, by itself, prove RADIUS is working. A local subscriber record may have handled authentication, the default profile may have supplied policy, or accounting may never have reached the server. Verify each boundary separately before billing or support teams rely on the session record.

Prerequisites: define the platform and test boundary

Applicable platform: MikroTik RouterOS 7. Record and verify the exact deployed release, router model, RADIUS server configuration and PPPoE access design. The supplied MikroTik reference is a frozen documentation page; check the current vendor documentation for release-specific settings before making changes. This workflow deliberately avoids configuration commands that could be applied to the wrong deployment.

Run the first test on an isolated lab router and PPPoE client representing your production configuration. If a production pilot is necessary, use a designated test subscriber, an approved maintenance window and a management connection independent of that subscriber session. Do not change shared PPP settings merely to test one customer.

• Record the existing PPP authentication and accounting settings, RADIUS entries and their order, default profile, and relevant routing and firewall configuration.
• Preserve a recoverable configuration and document who can restore it. Keep secrets out of tickets, screenshots and published evidence.
• Prepare a test identity, intended package policy and an approved negative-authentication test.
• Confirm access to router session information, RADIUS client statistics and server-side authentication and accounting records.

The NOC engineer should perform approved router and RADIUS changes using appropriately scoped access. Billing should confirm the intended subscriber entitlement; support should receive sanitized results rather than configuration privileges. The service owner approves customer-impacting changes and rollback. Validate applicable versions, configurations, service contracts and local regulations, particularly around subscriber data collection and retention.

Verification: prove the authentication path

Use this sequence after a new integration, authentication incident, firmware change or subscriber migration. Capture baseline counters and timestamps so unrelated traffic cannot be mistaken for the test.

1. Exclude local authentication. Check that the test username has no matching local PPP access record. MikroTik documents that the RADIUS database is consulted only when a matching local user record is absent. Prefer a unique test identity rather than deleting production records. Expected result: the test cannot succeed through an unnoticed local match.
2. Inspect service selection and reachability. Confirm that the intended RADIUS entry includes the PPP service and that PPP is configured to use RADIUS. Review entry order, destination, protocol, source address and the server’s corresponding client definition. Check authentication and accounting paths separately. For UDP, documented defaults are 1812 and 1813, but validate the actual configured ports. Expected result: both sides agree on the endpoint and client identity.
3. Connect with valid test credentials. Correlate the server authentication event, router statistics and active PPPoE session using the test identity and time. Expected result: a server acceptance and a corresponding router session, not simply a successful client login.
4. Test rejection. Disconnect only the test session, then attempt authentication with deliberately incorrect test credentials. Expected result: rejection at the server and no established test session. Restore valid credentials afterward. An explicit rejection is different from a timeout and should be recorded separately.

If the server accepts the request but the router does not establish the session, inspect replies rather than assuming the subscriber password is wrong. MikroTik documents that a shared-secret mismatch can allow a CHAP or MS-CHAP request to be accepted at the server while the router rejects the reply. An increase in bad replies is relevant evidence; it is not permission to expose the secret in a support ticket.

For RadSec deployments, verify certificate trust, identity checking and the documented protocol-specific secret behavior against the deployed release. Do not apply UDP troubleshooting assumptions without checking the configured transport.

Verification: separate acceptance from applied policy

Authentication proves identity, not the complete service entitlement. Compare the RADIUS response with the test subscriber’s intended package and the policy actually applied to the router session.

MikroTik documents that received RADIUS attributes override corresponding default-profile values. Parameters not supplied by RADIUS come from the respective default profile. This makes an apparently correct session ambiguous unless you identify which system supplied each required value.

1. Write the expected policy. Identify required address allocation, profile and bandwidth-policy outcomes. Confirm the supported attributes and interpretation for your exact release rather than assuming a package name translates directly into router behavior.
2. Inspect the accepted session. Compare the returned attributes and relevant router state with that expectation. Where RADIUS omits a value, inspect the default profile that supplies it. Expected result: every required outcome has an identified source and matches the approved test entitlement.

If login succeeds but policy is wrong, preserve the acceptance evidence and investigate attribute mapping or profile inheritance. Do not alter credentials to troubleshoot a policy problem. Billing should sign off on the entitlement; the NOC should sign off on its implementation.

Verification: follow accounting through the session lifecycle

Authentication and accounting are separate checks. MikroTik documents that accounting information is sent to the RADIUS server for the service when accounting is enabled. A successful authentication response therefore does not establish that session records are usable.

1. Confirm accounting configuration. Inspect PPP accounting settings and the selected accounting destination. Verify the actual path and server processing independently of authentication. Expected result: accounting is enabled intentionally and records are being received and retained where the team expects.
2. Exercise a controlled session. Connect the test subscriber, generate modest known traffic, and disconnect normally. Look for the expected session-start and session-stop evidence. If interim updates are required, verify support, configuration and the expected interval on the deployed versions, then keep the test active long enough to observe them.
3. Reconcile the records. Check available subscriber, NAS, session-identifier, timestamp, duration and traffic fields. Verify field availability and interpretation in your actual integration. Expected result: the records can be associated with one test session without mixing another subscriber or router into the result.

Check clock alignment before interpreting event order. If interim records appear but closure is missing, investigate the disconnect and accounting path rather than declaring the session complete. Where usage affects billing, validate counter units and direction before applying charging rules.

Router restarts and broken network paths require a separate failure test in the lab. Establish how your server handles incomplete or duplicate records; do not infer those behaviors from a clean disconnect. Until that handling is proven, incomplete accounting should remain an exception for investigation rather than unquestioned billing input.

Map the verified handoff to ISPbills

ISPbills is an ISP billing and network operations platform with FreeRADIUS integration, subscriber access workflows and RouterOS API monitoring. These capabilities serve different parts of this verification: centralized RADIUS handles the authentication and accounting operating model, while API monitoring supplies supported router context. Successful API monitoring is not proof that RADIUS works.

Use ISPbills to evaluate the handoff between the subscriber’s billing entitlement, network access and the evidence support needs. In a representative pilot, ask the team to trace the same test subscriber through a successful connection, a rejection and a completed accounting session. Verify which information is visible under the actual roles and configuration, and which checks still require router or RADIUS-server inspection.

The practical benefit to assess is whether billing can confirm entitlement and support can identify the session without losing the NOC’s technical evidence. Confirm current ISPbills feature availability on the feature or pricing page; do not assume every plan or router release provides identical behavior.

Rollback and acceptance criteria

If authentication, policy or accounting fails, stop expanding the pilot. Disconnect the test session and restore only the settings changed during the test, using the preserved configuration and authorized management path. Restore the previous test entitlement where necessary, remove temporary diagnostic access, and verify the known-good access path again. Do not create a broad local-authentication fallback to conceal a RADIUS fault.

Keep a sanitized acceptance record containing the exact versions, test identity reference, expected policy, observed authentication outcome, accounting correlation and unresolved exceptions. Remove temporary verbose diagnostics when testing ends and retain evidence according to the approved policy.

Proceed only when valid credentials authenticate through the intended RADIUS path, invalid credentials are rejected, applied policy matches entitlement, and accounting can be reconciled to the controlled session. If any condition remains unproven, assign an owner and repeat that test before using the integration for production billing or access automation.

Sources consulted: MikroTik ISP Operations: RouterOS, PPPoE & RADIUS (checked 2026-10-03); RADIUS – RouterOS – MikroTik Documentation (checked 2026-10-03). AI-assisted content prepared for automatic publication after automated checks; not a claim of human or hardware verification. Validate versions, device models and deployment conditions before making changes.