PPPoE Local Secrets and RADIUS: Avoiding Identity Conflicts

This guide covers PPPoE local secrets. Start with the checks below. Then compare your result with the example before changing a live service. Mixed local and centralized authentication needs an explicit design. Investigate duplicate identities before assuming the billing application is updating the account that actually authorizes the subscriber.

PPPoE local secrets: practical checks

1. Inventory matching usernames in the relevant authentication stores.
2. Confirm the RouterOS authentication behavior for the deployed configuration.
3. Use one controlled account to test changes and observe which policy applies.

PPPoE local secrets: a working example

An old local account may make a new centralized configuration appear inconsistent. Removing records without understanding the live path can interrupt access or conceal the original conflict.

First, write down the starting state and the expected result. Then make one controlled change. Next, compare the result with the example above. Finally, record what changed and who should follow up. Keep private account details out of shared notes.

Where LinkDesk fits

LinkDesk includes local PPPoE workflows and a FreeRADIUS bridge. These require deployment testing. Enforced PPPoE or RADIUS data quotas and strict global simultaneous-session enforcement for RADIUS PPPoE are not included in the documented current scope.

For the tool or product details behind this guide, see MikroTik RADIUS documentation. The checklist and example above are WayaDesk’s operating guidance.