MikroTik Hotspot + RADIUS:
how voucher billing actually works

Why hotspot instead of PPPoE

PPPoE assumes a subscriber has a router or app dialing in with credentials — fine for a fixed installation with a dish and an indoor unit. It's the wrong model for walk-up access: a customer buying a one-day voucher at a shop, a hotel guest, a café. Nobody's installing PPPoE client software on a phone for a coffee shop.

Hotspot solves this with a captive portal: the device connects to open (or WPA-protected) Wi-Fi like any normal network, gets an IP address immediately, and only sees a login page — no software, no configuration, just a username and password printed on a card.

The actual connection sequence

This is the part most tutorials skip, and it's the key to debugging anything that goes wrong:

1. DHCP first. The device joins the Wi-Fi and gets an IP from the pool — before any authentication. This is why the generator includes a full DHCP server block; without it, the device never even gets an address.
2. Interception. RouterOS watches for the client's first HTTP request and, since the session isn't authenticated yet, redirects it internally to the router's own login page instead of letting it reach the real destination.
3. Login. The subscriber enters the voucher's username and password. RouterOS forwards this to RADIUS with service=hotspot — a separate service type from PPPoE's service=ppp, so the same RADIUS server can run both without conflict.
4. Accounting starts. Same as PPPoE — Start, Interim-Update every 5 minutes, Stop — so the voucher's remaining time or data balance can be tracked.

The two things that actually break deployments

DNS resolution for the login page

The dns-name field (what shows in the browser, like login.mynetwork.com) needs to resolve to the router for hotspot clients specifically. If your DHCP hands out external DNS servers directly (8.8.8.8, 1.1.1.1 — the generator's default), those servers obviously have no idea your login hostname exists, and resolution can fail before the client even reaches the interception step.

In practice RouterOS's own DNS handling and the interception mechanism cover most cases automatically, but if you see subscribers stuck on "page not found" instead of the login page, this is the first thing to check — try pointing the DHCP DNS server at the router's own IP instead of an external resolver, so it can answer for the hotspot hostname itself.

HTTPS everywhere

Almost all web traffic today is HTTPS, and RouterOS can't transparently intercept an HTTPS request the way it can HTTP — doing so would trigger a certificate warning, since the router isn't the real destination. This is a limitation of every captive portal system, not just MikroTik's.

In practice this is less of a problem than it sounds: modern phones and laptops run their own captive portal detection (a background probe to a known HTTP URL right after connecting) and pop the login page automatically. But on older devices, or if that detection fails, a subscriber staring at a browser that only opens HTTPS sites will never see the redirect. Printing "open any non-HTTPS site, or wait for the login popup" on the voucher card heads off a lot of support questions.

Reading the generated script

Every parameter, explained

Full example: a voucher hotspot at a shared compound

A common scenario: a residential compound or small business area selling time-based vouchers, with SAS4 as the RADIUS platform on the same LAN as the router.

Common mistakes and how to fix them

Best practices

• Size the client pool for peak concurrent devices, not just active subscribers — idle phones and routers often hold a lease.
• Only add a walled garden entry if you're actually selling vouchers through a web page reachable before login.
• Test one voucher end to end — purchase, login, session start — before printing a full batch.
• Keep the login page hostname consistent across support documentation, since that's what subscribers will actually see and reference.