MikroTik Hotspot Setup With a Cloud Captive Portal and RADIUS

A MikroTik hotspot setup with a cloud captive portal has two halves. The router, running RouterOS, handles the local work: it holds new devices, redirects them to a login page and enforces limits. A cloud platform handles the thinking: it serves the login page, checks OTPs or vouchers, takes payments and answers the router over RADIUS.

RouterOS has had a built-in hotspot feature for many years, which is why MikroTik is common in Indian hotels, hostels and ISP networks. Its local user list works for small sites, but it does not scale to many venues, paid plans or OTP login. Connecting the hotspot to a RADIUS server in the cloud solves that.

This guide covers what you need, how to plan the network, what the configuration does, how to test, and how to fix the problems that come up most often.

Gather these before touching the router:

• A MikroTik router on a current, supported RouterOS version, with enough capacity for your expected number of users.
• Access points: MikroTik or other brands in bridge mode, so the router, not the access point, hands out addresses.
• A working internet connection with a stable public path to the cloud platform. Note whether your ISP puts you behind carrier-grade NAT.
• Admin access to the router (WinBox, WebFig or SSH) and a recent configuration backup.
• An account on the cloud platform with your venue, plans and portal already created.
• If you will sell plans, your payment gateway account details, so its pages can be added to the walled garden.

Decide who will use the Wi-Fi before you configure anything. A hotel, for example, may need four different experiences: free guest Wi-Fi, a faster paid tier, a conference network for event delegates and a staff network. Each should have its own login method, plans and page.

On a MikroTik router, the clean way to do this is to give each group its own network, either a separate SSID or a separate VLAN carried to the access points, and run a hotspot server on each. Each hotspot then points to its own portal. Guests on the conference SSID see the event page with vouchers; guests on the main SSID see OTP login and paid upgrades.

Keep the address pools separate, size them for peak occupancy with some headroom, and set DHCP lease times long enough that returning guests keep their address during a stay. Keep staff and payment terminals off the hotspot entirely or on their own network.

You can configure every piece by hand in RouterOS, but it is easy to miss a detail. Cloud platforms usually generate a configuration script for you to paste into the router terminal. Whichever route you take, the result should include:

• Hotspot server and hotspot profile: the hotspot is bound to the guest interface or VLAN, and the profile tells it to use RADIUS and where the external login page lives.
• RADIUS client: the address of the RADIUS server, a shared secret, and the hotspot service enabled for both authentication and accounting.
• Accounting updates: interim updates at a sensible interval so data usage and session time are reported while the session runs, not only at the end.
• Incoming RADIUS (CoA): the router accepts disconnect and change requests from the server, so an admin can end a session or a plan change takes effect immediately.
• Walled garden: the login page host, its static assets and, if needed, payment gateway domains, reachable without logging in.
• Heartbeat: a small scheduled check-in so the platform can show the router as online or offline.
• Time sync: an NTP or SNTP client so the router clock is correct.

If guests will pay for Wi-Fi, the walled garden needs more care. A payment gateway’s checkout page loads resources from several domains, and those can change. Add the gateway’s documented domains, then test a real payment on a phone.

UPI is harder. When a guest taps “Pay with UPI”, the phone switches to a UPI app, which needs to reach its own servers and the bank’s. Bank OTP pages for cards and net banking behave similarly. Listing every one of those hosts in the walled garden is not practical. The usual solution is a short, limited “payment window”: once the guest starts a payment, the platform opens the internet briefly for that device so the payment can complete, then logs the guest in when payment is confirmed.

Test with real phones, not only a laptop. Android and iPhone detect captive portals differently, and both matter.

• Join each SSID and confirm the login page pops up on its own within a few seconds.
• Log in with each method (OTP, voucher, membership) and confirm the correct plan limits apply.
• Check the session appears in the router’s hotspot active list and in the cloud console.
• Use some data and confirm accounting updates arrive and the counter moves.
• Disconnect the session from the console and confirm the phone actually loses access.
• Make a small test payment with UPI and with a card, if you sell plans.
• Reboot the router and confirm it comes back online in the console and guests can still log in.

Wrong clock. Many MikroTik models do not keep time through a power cut. If the clock is wrong, HTTPS pages and certificate checks can fail and session times look odd. Make sure time sync is configured and working.

DNS issues. The hotspot relies on DNS to intercept and redirect. If clients use a hard-coded DNS server that the router does not handle, or the router’s own DNS is not working, the page will not appear. Check the router can resolve names and that the hotspot’s DNS settings are sensible.

Login page loads partly or payment stops midway. Something is missing from the walled garden. Open the page on a laptop with developer tools to see which requests fail, then add those hosts.

RADIUS reject or timeout. Check the shared secret matches exactly, the RADIUS server address is correct and outbound UDP traffic to it is not blocked by your ISP or firewall.

Disconnect from the console does nothing. CoA requests travel from the server to the router, so the router must accept incoming RADIUS and be reachable. Behind carrier-grade NAT or a strict upstream firewall, these requests may never arrive. Talk to your ISP about a public IP or check how your platform recommends handling this.

Guests keep getting logged out. Look at the idle timeout and keepalive timeout in the hotspot profile, and at the session length your plan sends back.

OKWiFi supports MikroTik RouterOS today; other RADIUS-capable gateways are planned. When you add a router in the console, OKWiFi generates a RouterOS script that sets up the hotspot, RADIUS authentication, accounting and CoA disconnect, the walled garden and a heartbeat, so the router shows as online or offline in the console.

Each network on the router can point to its own portal profile, with its own login methods, plans and branding. Paid plans use your own payment gateway (Easebuzz, AblePay and Razorpay are supported) with the payment window handled for you, and live sessions can be viewed and disconnected from the console.