MikroTik Hotspot With External RADIUS and a Cloud Captive Portal: A Practical Setup Guide

How a MikroTik hotspot works with an external RADIUS server and cloud portal, an illustrative RouterOS configuration, and the common mistakes that break logins.

Wireless Networking·2 October 2026·8 min read·Super Next Technologies

MikroTik routers are popular for guest Wi-Fi in hotels, cafés, worker accommodation and offices because they are affordable and capable. The built-in hotspot works on its own, but serious deployments usually connect it to an external RADIUS server and a cloud captive portal, so users, vouchers and plans are managed centrally rather than router by router. This guide explains how the pieces fit, shows an illustrative configuration and lists the mistakes we see most often.

How the Pieces Fit Together

  1. A user's device joins the guest network and receives an IP address from the MikroTik DHCP server.
  2. The hotspot intercepts the first web request and redirects the user to the login page — either a local page on the router or, more commonly, an external cloud portal.
  3. The user logs in (voucher, room number, email code and so on). The portal sends the credentials back to the router's hotspot login URL.
  4. The router sends an Access-Request to the RADIUS server.
  5. RADIUS replies with Access-Accept plus the session rules — for example rate limit, session timeout and data quota — or Access-Reject.
  6. During the session the router sends accounting updates (start, interim, stop), so the platform knows who is online and how much they use.
  7. If the platform needs to disconnect a user or change their speed mid-session, it sends a Disconnect or CoA message to the router.

Before You Start

  • RouterOS version 7 is recommended for new deployments.
  • Decide which interface or bridge carries guest traffic and keep it separate from staff networks (its own VLAN).
  • Get from your RADIUS/portal provider: the RADIUS server address, the shared secret, the authentication and accounting ports, and the portal domain names that must be reachable before login.
  • Make sure the router has the correct time — accounting depends on it.

Illustrative RouterOS Configuration

The commands below are a simplified example with placeholder values. RADIUS_SERVER_IP, RADIUS_SECRET and portal.example.com must be replaced with the values from your provider, and your hotspot profile name may differ. Always test on a non-production router first.

  • /system ntp client set enabled=yes servers=pool.ntp.org
  • /radius add service=hotspot address=RADIUS_SERVER_IP secret=RADIUS_SECRET authentication-port=1812 accounting-port=1813 timeout=3s
  • /radius incoming set accept=yes port=3799
  • /ip hotspot profile set [find name=hsprof1] use-radius=yes radius-accounting=yes radius-interim-update=5m login-by=http-chap,http-pap,mac-cookie
  • /ip hotspot walled-garden add dst-host=portal.example.com action=allow
  • /ip hotspot walled-garden add dst-host=*.example-cdn.com action=allow

What each line does:

  • NTP keeps the clock accurate so session times and logs are correct.
  • /radius add registers the external RADIUS server for the hotspot service. The secret must match exactly what is configured on the server for this router.
  • /radius incoming lets the router accept Disconnect and CoA requests, so the platform can end sessions or change speeds without waiting for timeouts.
  • The hotspot profile turns on RADIUS authentication and accounting, sends interim updates every five minutes, and enables the login methods your portal uses.
  • The walled garden allows unauthenticated users to reach the portal and anything it loads (fonts, scripts, payment pages) before they log in.

To use an external portal, the hotspot's login page on the router is replaced with a small page that redirects to the cloud portal, passing details such as the user's MAC address, IP address and the router's login URL. The portal then posts the credentials back to that login URL.

Mistakes That Break Logins

  1. Shared secret mismatch: one typo and every login fails with no obvious error to the user. Check the RADIUS log on the router (/log print where topics~"radius").
  2. Wrong source IP: the RADIUS server only answers known routers. If the router reaches the internet through NAT or changes its public IP, requests arrive from an address the server does not recognise. Use a static IP or a VPN tunnel and register that address.
  3. Firewall blocks UDP 1812/1813 or 3799: outbound on the router, inbound on the server, or anywhere in between.
  4. Incomplete walled garden: the portal loads but looks broken, or the payment step hangs, because a CDN or payment domain is missing. Test every page of the login flow on a fresh device.
  5. Clock drift: wrong time leads to strange session lengths and confusing reports.
  6. No interim accounting: without interim updates the platform cannot see live usage, data quotas are not enforced correctly and "ghost" sessions build up.
  7. Expecting HTTPS redirection: captive portals cannot cleanly intercept HTTPS sites. Phones detect the portal using their own plain-HTTP checks; make sure those checks are not blocked or accidentally whitelisted.
  8. Hotspot DNS name problems: if you set a DNS name for the hotspot, it must resolve correctly, and if you use HTTPS for the local login page, the certificate must match it.
  9. Ignoring MAC randomisation: phones may present a different MAC per network or over time. Rely on proper session handling and cookies rather than MAC-only rules.
  10. Guest and staff on one network: always isolate guests in their own VLAN and enable client isolation on the access points.

Testing Checklist

  • Connect a fresh phone and a laptop; confirm the portal appears automatically.
  • Log in with a valid and an invalid voucher; check the router log and the platform's session list.
  • Confirm the speed limit with a speed test (supernxt.com/tools/speed-test/).
  • Disconnect a user from the platform and confirm the router drops them immediately.
  • Leave a session running past an interim interval and confirm usage updates.

Let the Platform Generate the Config

Hand-writing hotspot configuration for every site is slow and error-prone. WiFiNexa (wifinexa.com), the cloud captive portal and RADIUS platform from Super Next Technologies, generates the MikroTik configuration for each router automatically — RADIUS entries, hotspot profile, walled garden and portal redirect — so you paste one script and the site is ready. It then handles vouchers, plans, live sessions and reports from one dashboard. Read more at supernxt.com/products/wifinexa.

Next Step

If you are setting up a new hotspot or fixing one that keeps failing, try WiFiNexa at wifinexa.com or call the WiFiNexa team on +971 55 362 5025. For complete network design and installation, see our wireless hotspot services at supernxt.com/wireless-hotspot or contact us at supernxt.com/contact.

Need help with Wireless Networking?

Talk to our team - free consultation, no commitment, wherever you are.