MikroTik PPPoE Server Setup for ISPs

Summary A MikroTik PPPoE server lets an ISP authenticate subscribers, assign each an IP address, and enforce a per-plan speed limit — all from RouterOS, with no external RADIUS for small deployments. The setup is a short, ordered chain: an IP pool, a PPP profile, subscriber secrets, the PPPoE service, and NAT. The harder problem is not configuring one concentrator but running consistent, verifiable config across many of them — often behind CGNAT. This guide covers both.

What Is a MikroTik PPPoE Server?

A MikroTik PPPoE server is a RouterOS service that authenticates each subscriber over Point-to-Point Protocol over Ethernet, hands them an IP from a pool, and applies a profile controlling their gateway, DNS, and speed limit. It is how most small-to-medium ISPs manage client connections: a customer dials in with a username and password, the server checks the credential, and the session inherits the assigned plan — per-user authentication, IP assignment, and bandwidth control without separate equipment (MikroTik Documentation — PPPoE).

PPPoE remains the ISP default because of accountability. Every subscriber holds an individual credential, so you can disable an account for non-payment, see who is online, and bind a fixed address or speed to a person — none of which bridged or DHCP delivery gives you cleanly. The whole configuration reduces to one idea: define the plan once in a profile, then attach subscribers to it.

Step 1 — Create the IP pool

Start with the addresses RouterOS will lend to subscribers. A pool is a named block — for example /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254 — sized to the simultaneous sessions this concentrator will carry, with headroom. Keep the profile’s gateway address (the local-address) outside the lendable range so it is never handed to a client by accident.

Size the pool against the hardware — a modest router handles hundreds of sessions, a CCR-class device the thousands (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). To hand out public IPs instead, point the pool at your routable block and skip the NAT in Step 5.

Step 2 — Build the PPP profile

The PPP profile is where a plan lives. It sets the local-address (the gateway every subscriber sees), the remote-address pool from Step 1, the DNS servers, and — most importantly for an ISP — the rate-limit that caps each session. Assign the profile to a subscriber and they inherit the speed, so a “20/10” plan is one profile reused across thousands of accounts (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).

One detail trips up almost everyone: direction. RouterOS reads the profile rate-limit as rx-rate/tx-rate from the server’s point of view — the subscriber’s upload first, download second, the reverse of how customers describe their plan. A “100 Mbps down / 30 Mbps up” package is written rate-limit=30M/100M. Get it backwards and every customer silently receives a swapped plan — exactly the fleet-wide error that templated config prevents.

Step 3 — Add subscriber secrets

Each subscriber needs a “secret” — a username, password, and the profile that defines their plan, created under /ppp secret. For a small base this is the entire user database: add a secret per customer, optionally pin a fixed remote-address for a static IP, and disable the secret to cut off service. This is the same per-credential accountability that MikroTik’s User Manager extends for hotspot subscribers, covered in our guide to the 10.5.50.1 hotspot gateway and User Manager.

Local secrets stop scaling in the hundreds-to-thousands range, where editing one router per customer change becomes the bottleneck. At that point you move authentication to an external RADIUS server, and the concentrators simply ask RADIUS whether a login is valid — keeping the subscriber database in one place.

Step 4 — Enable the PPPoE server on the access interface

Now turn on the service. Add a PPPoE server with /interface pppoe-server server, bind it to the interface facing your access network (a port, VLAN, or bridge), set its default-profile to the Step 2 profile, and choose the authentication methods — pap, chap, or mschap2. RouterOS then answers PPPoE discovery on that interface and authenticates any client that dials in with a valid secret.

Two settings matter at scale. The one-session-per-host option blocks a subscriber from opening multiple simultaneous sessions, and max-mtu/max-mru should be set so PPPoE overhead does not fragment customer traffic. Where the access network is segmented per customer or zone, our MikroTik bridge configuration guide covers the Layer 2 groundwork the server binds onto.

Step 5 — Add NAT and firewall rules

If you assigned subscribers private addresses in Step 1, their traffic needs translation. Add a masquerade rule in the srcnat chain bound to your WAN out-interface so every PPPoE session reaches the internet — the same NAT fundamentals covered in our guide to configuring NAT on MikroTik. If you handed out public IPs, skip the masquerade and route the block.

Then protect the concentrator. The PPPoE service should be reachable by subscribers, but the router’s management interfaces should not, so add firewall rules that drop Winbox, API, and WebFig access from the subscriber-facing side. A concentrator carrying live customer revenue is exactly the device you do not want reachable from a hijacked session.

Step 6 — Manage and verify the fleet remotely

Here is the part single-router tutorials skip. Standing up PPPoE on one box is easy; running identical profiles, MTU settings, and firewall rules across dozens of concentrators — and proving each one authenticates sessions and enforces the right rate limits — is the real ISP problem. It gets harder when an access router sits behind Carrier-Grade NAT with no public IP, increasingly common as operators lean on LTE and Starlink uplinks.

This is where centralised management earns its place: MKController keeps each router reachable over an authenticated outbound tunnel even when it has no public address — the same approach in our MikroTik remote access behind CGNAT guide — so you audit config and push fixes fleet-wide, with telemetry that flags a dropped-session box before customers call.

Tips

• Template the profile, not the secrets — every plan change should touch one profile, never thousands of accounts.
• Watch CPU on the concentrator: per-session queues from rate-limit add up, and an overloaded box drops sessions silently.
• Set max-mtu/max-mru deliberately. PPPoE adds 8 bytes of overhead, and the resulting fragmentation is the hidden cause of most “it’s slow on one site” tickets.
• Centralise authentication past a few hundred users — local secrets scattered across routers become impossible to audit.

Run your whole PPPoE edge from one screen

A PPPoE server on one MikroTik is easy. Running it across an ISP fleet — identical profiles, the rate-limit direction right on every box, management locked down, and proof each concentrator authenticates even behind CGNAT with no public IP — is where operators lose afternoons. That is the job MKController was built for: reach every router over a secure outbound tunnel, audit config, watch live sessions, and push a fix across the whole fleet at once, with telemetry that flags a dropped-session box before a customer ever calls. It is how ISPs running PPPoE on MikroTik turn a router-by-router chore into a single control plane.

Start your free MKController trial