PPPoE + RADIUS on MikroTik:
the reasoning behind the script

Why PPPoE instead of static IPs or plain DHCP

A wireless ISP connects and disconnects subscribers constantly — someone stops paying, moves, or gets a plan upgrade. Static IP assignment means manually tracking every lease by hand, and plain DHCP gives you no clean way to authenticate a subscriber before handing them a connection at all.

PPPoE solves both problems at once. Every session starts with a login (username and password), so a subscriber literally cannot get an IP address without authenticating first. When their session ends — router reboot, someone unplugs the antenna, they stop paying — the IP and the rate-limit profile attached to it are released automatically. There's no lease to clean up and no orphaned static route sitting on your router six months later.

The trade-off is a small amount of protocol overhead per packet, which is exactly why the MTU/MRU settings in the generated script matter — more on that below.

What RADIUS is actually doing

RADIUS is an AAA protocol — Authentication, Authorization, Accounting. RouterOS can authenticate PPPoE logins against a local list of secrets, but that doesn't scale past a handful of subscribers, and it gives you no usage data. RADIUS moves all three jobs off the router and onto a server built for it — SAS4, GalaxyRAD, or anything else that speaks RFC 2865.

Authentication

When a subscriber's PPPoE client sends a username and password, RouterOS forwards it to the RADIUS server named in /radius. The server checks it against its own subscriber database and replies accept or reject — RouterOS never needs to know the password itself.

Authorization

On accept, the RADIUS server can hand back attributes — which profile to apply, what static IP to assign via Framed-IP-Address, session timeout limits. This is how a billing platform pushes a "10 Mbps package" or "expired, redirect to payment page" decision onto the router without anyone touching RouterOS directly.

Accounting

This is the part people skip and then wonder why their billing platform shows no usage data. The line set use-radius=yes accounting=yes interim-update=5m tells RouterOS to send accounting packets to the RADIUS server: a Start packet when the session begins, Interim-Update packets every 5 minutes with live byte counts, and a Stop packet with the final total when it ends. Without accounting=yes, your billing platform has no idea how much data anyone used.

The full exchange, step by step

Reading the generated script

In order, here's what each block in the generator's output actually does and why it's in that order:

Where new deployments actually break

MTU and MRU

PPPoE adds 8 bytes of overhead to every packet. If max-mtu and max-mru aren't set to 1480 (down from Ethernet's standard 1500), subscribers get intermittent issues that look like a bad connection but are actually packet fragmentation — sites that load fine but images or video randomly stall. This is one of the most common "why does my PPPoE feel flaky" support tickets, and it's a one-line fix.

CGNAT on the WAN side

If your uplink is satellite internet or any other connection behind Carrier-Grade NAT, you don't get a public IP on the WAN interface at all — which means you can't reach the router remotely for monitoring or emergency changes without a separate tunnel (a VPS-hosted VPN, a reverse SSH tunnel, or a paid static-IP add-on if your provider offers one). This has nothing to do with the PPPoE/RADIUS config itself, but it's worth planning for before you have 40 subscribers and a router you can't reach at 2am.

RADIUS timeout with no fallback

If the RADIUS server is unreachable, new sessions fail to authenticate — existing sessions keep running, but nobody new can log in until it's back. Some operators add a second /radius entry pointing at a backup server for exactly this reason; RouterOS will fail over automatically if the first one stops responding.

Every parameter, explained

Full example: a 40-subscriber WISP on satellite backhaul

A realistic scenario end to end: a small WISP with a satellite internet uplink on ether1, an antenna sector on ether2, and SAS4 as the RADIUS/billing platform running on a local VPS at 10.0.0.5.

Because satellite internet sits behind CGNAT, this router has no public IP on ether1 — remote management goes through a WireGuard tunnel to the VPS running SAS4, not directly to the router. See the security guide for that setup.

Common mistakes and how to fix them

Best practices

• Test every new script on one subscriber before rolling out to the rest of the network.
• Keep a second /radius entry pointing at a backup server if your billing platform supports failover.
• Never reuse the router's admin password as the RADIUS shared secret.
• Document your actual interface names and IP scheme somewhere outside the router — a router that needs a factory reset shouldn't take your network map with it.
• Re-check MTU/MRU first whenever a subscriber reports "slow but not disconnected" — it's the most common false lead in PPPoE troubleshooting.