Back to Blog
Technical Guide

Complete MikroTik PPPoE Billing Setup Guide: RADIUS, Bandwidth & Automation (2026)

Step-by-step guide to setting up MikroTik PPPoE billing with RADIUS authentication, bandwidth management, and automated billing. For ISPs using RouterOS v6 and v7.

Updated First published 7 min read

PPPoE is the workhorse of fixed-line ISP and WISP networks across Africa. It gives every subscriber a unique login, ties their session to a billing record, and lets you enforce speed plans at the router. When you pair a MikroTik PPPoE server with RADIUS, you turn a static box into a fully automated access layer: customers are authenticated centrally, given the right bandwidth, and switched on or off the moment payment status changes. This guide walks through the full setup, from the PPPoE server to M-Pesa-triggered activation.

What You Need Before Starting

You should have a MikroTik router running RouterOS v6 or v7 with admin access, an upstream internet feed, and a block of private IP addresses to hand out to subscribers. You also need a RADIUS server that holds your subscriber credentials and plan logic. Building and maintaining FreeRADIUS yourself is possible but operationally heavy, so most operators use a billing platform that ships RADIUS as a managed service. Iterative Billing, for example, provides built-in RADIUS with Change of Authorization support, so you point the router at one endpoint and manage everything from a dashboard instead of editing flat files.

Step 1: Create an IP Pool

Subscribers need addresses. Create a pool that RADIUS or the default profile can draw from.

  • /ip pool add name=pppoe-pool ranges=10.10.0.2-10.10.255.254

Keep this range large enough for your subscriber base plus headroom. The pool sits behind NAT, so private space is fine.

Step 2: Define a Default PPP Profile

The profile sets the gateway IP that anchors every tunnel and the pool used when RADIUS does not specify an address.

  • /ppp profile add name=default-pppoe local-address=10.10.0.1 remote-address=pppoe-pool dns-server=8.8.8.8,1.1.1.1

The local-address is the PPPoE server's IP on the subscriber side and is required for the tunnel to come up. You can create additional profiles per speed tier, but with RADIUS most operators keep one profile and let RADIUS push the rate limit dynamically.

Step 3: Point the Router at RADIUS

Add the RADIUS server and enable it for PPP. The shared secret must match exactly on both ends.

  • /radius add service=ppp address=YOUR_RADIUS_IP secret=YOUR_SHARED_SECRET
  • /ppp aaa set use-radius=yes accounting=yes interim-update=5m

Turning on accounting lets RADIUS track who is online and for how long, which feeds usage reporting and session timeouts. The interim-update value controls how often the router reports live session data.

Step 4: Enable RADIUS Incoming for CoA and Disconnects

This is the step that makes automation real. The incoming listener lets your RADIUS server reach back into the router and act on live sessions.

  • /radius incoming set accept=yes port=3799

RouterOS supports both RADIUS Disconnect Messages and Change of Authorization (CoA) per RFC 3576/5176, and this applies to PPP/PPPoE sessions, not just hotspot. Both packet types arrive on UDP port 3799. The practical difference matters for billing:

  • CoA updates an active session in place. The most common use is pushing a new Mikrotik-Rate-Limit to upgrade or throttle a customer without dropping their connection, so a plan change can take effect with no downtime.
  • A Disconnect (also called Packet of Disconnect) terminates the session and forces a fresh re-authentication on the next redial.

The one limitation to plan around is that CoA cannot change a session's IP address, IP pool, or routes. If your suspension flow moves a user into a different walled-garden pool or profile, that requires a disconnect and reconnect rather than a live CoA. Because RouterOS does not accept this traffic by default, add a firewall rule allowing UDP 3799 from your RADIUS server to the router's input chain, or the messages will be silently dropped.

Step 5: Start the PPPoE Server

Bind a PPPoE server instance to the interface facing your subscribers (or your access switch or OLT uplink).

  • /interface pppoe-server server add interface=ether2 service-name=ISP default-profile=default-pppoe disabled=no one-session-per-host=yes authentication=pap,chap

Enabling one-session-per-host prevents a single account from opening multiple tunnels. With this running, any device that dials PPPoE on that interface will be challenged for a username and password, and the router will forward those credentials to RADIUS.

Step 6: Enforce Speed Plans with Rate Limits

Instead of building dozens of profiles and queues by hand, let RADIUS return the speed in the Mikrotik-Rate-Limit attribute when a user authenticates. The router automatically builds a dynamic simple queue for that session. The attribute format is rich and supports bursting.

Rates are read from the router's point of view, so rx is the client's upload and tx is the client's download. A value of 5M/10M therefore means a 5 Mbps upload and 10 Mbps download cap. The extended form adds burst behaviour. For example 5M/10M 7M/14M 5M/10M 16/16 reads as rate, then burst-rate, then burst-threshold, then burst-time in seconds. Units use k or M. Because the queue is created and destroyed with the session, you never have stale queues, and changing a customer's plan is just changing the attribute your RADIUS returns, either on the next connect or live via CoA.

Step 7: Automate Activation and Suspension

This is where billing logic drives the network. Your RADIUS source should make a simple decision at authentication time: is this account paid and active?

  • If active, RADIUS returns an Access-Accept with the correct Mikrotik-Rate-Limit for the customer's plan.
  • If unpaid or expired, RADIUS either returns Access-Reject, or accepts the user into a restricted profile that points only to a payment page.

The restricted-profile approach is friendlier than a hard reject because the customer can still reach your portal to pay. A plan upgrade or downgrade can be applied to a live session with CoA so the speed changes without a drop. Moving a lapsed account into a walled-garden pool is the one case that needs a disconnect and a clean reconnect, since the IP pool cannot change mid-session. When the customer pays, the reverse happens automatically. Iterative Billing handles this loop end to end: automated invoicing, SMS reminders before expiry, and instant disconnect or re-enable based on payment state, with a customer self-service portal for logins and receipts.

If you would rather not maintain these steps by hand on every router, the MikroTik billing system page shows how the platform writes profiles, queues and RADIUS settings for you, and PPPoE billing covers the session lifecycle from first payment to expiry.

Step 8: Wire Up M-Pesa Activation

For Kenyan operators, M-Pesa is the activation trigger that closes the loop. The Safaricom Daraja API supports STK Push (Lipa na M-Pesa Online), Paybill, and Till. The flow is straightforward:

  • A customer pays from the self-service portal or an SMS link, which fires an STK Push to their phone.
  • The customer confirms the amount and enters their M-Pesa PIN. The prompt typically arrives within a few seconds and they have about a minute to approve before it times out.
  • Safaricom sends a result callback to your billing platform's callback URL with the transaction status, receipt code, and amount.
  • On a successful callback, the platform marks the invoice paid, sets the account active, and re-authorizes the RADIUS session so the subscriber is online almost immediately.

Because the callback is the source of truth, you should never rely on the customer telling you they paid. The platform reconciles automatically. Beyond M-Pesa, Iterative Billing also supports Co-op Bank, KopoKopo, SasaPay, Pesapal, Flutterwave and Paystack, so you can offer card and other mobile-money options alongside Daraja.

Putting It Together

A complete MikroTik PPPoE plus RADIUS deployment means a new customer can sign up, pay by M-Pesa, and be online with the correct speed in under a minute, with no manual intervention from your team. Suspensions, upgrades, and reactivations all flow from payment events. That is the difference between running an ISP off spreadsheets and running one that scales.

If you would rather not stand up and babysit a RADIUS server, you can connect your MikroTik to a managed platform and have the whole activation-to-suspension cycle work out of the box. Start a free trial at https://billing.iterativebilling.com/register and point your router at it to see PPPoE billing run on autopilot.

Frequently asked questions

Does MikroTik PPPoE support RADIUS Change of Authorization (CoA) for live plan changes?
Yes. RouterOS supports both RADIUS Disconnect Messages and Change of Authorization per RFC 3576/5176, and this includes PPP/PPPoE sessions, not only hotspot. You can push a new Mikrotik-Rate-Limit to an active session with CoA so a plan upgrade or downgrade takes effect without dropping the connection. Both CoA and Disconnect packets use UDP port 3799, and the router needs a firewall rule allowing that traffic from your RADIUS server. The one limitation is that CoA cannot change a session's IP address, IP pool, or routes; those require a disconnect and a fresh reconnect, which is why suspensions that move a user into a walled-garden pool typically use a Disconnect instead.
How do I set different speed packages without creating a profile for every plan?
Return the speed dynamically from RADIUS using the Mikrotik-Rate-Limit attribute instead of building static profiles. Rates are read from the router's point of view, so a value like 5M/10M sets 5 Mbps upload and 10 Mbps download, and the router automatically creates a dynamic simple queue for that session. The extended format adds burst rate, burst threshold, and burst time in seconds. Changing a customer's plan becomes a matter of changing the attribute your RADIUS server returns, applied either on the next connect or live via CoA, with no manual queue editing.
How does M-Pesa actually switch a subscriber on after payment?
Payment uses the Safaricom Daraja API. The customer gets an STK Push prompt, confirms the amount, and enters their PIN, with roughly a minute to approve before it times out. Safaricom then sends a result callback to your billing platform's callback URL with the transaction status, receipt, and amount. On a successful callback the platform marks the invoice paid, activates the account, and re-authorizes the RADIUS session so the customer is online within seconds. The callback is the source of truth, so activation is automatic and reconciled, never based on the customer self-reporting payment.

Ready to Automate Your ISP Billing?

Start your 3-day free trial. M-Pesa integration, MikroTik management, PPPoE & hotspot billing, all in one platform.