Almost every MikroTik hotspot guide gets you to a working captive portal. Far fewer warn you that the moment it starts working, it may capture the very computer you are configuring it from — and that if you have not planned for that, you are now locked out of your own router.
This is the most common way a first hotspot setup goes wrong. It is also entirely avoidable.
Why it happens
A hotspot server is bound to an interface. Every device reaching the router through that interface becomes an unauthenticated hotspot client, and unauthenticated clients cannot do anything except reach the login page. That includes Winbox on port 8291, and it includes the API on port 8728.
If your laptop is plugged into the bridge that you just turned into a hotspot, your management session is now a captive one.
Work out where you are first
Before you configure anything, find out which interface your own machine reaches the router through. In Winbox open IP → ARP and find your own address, then note the interface next to it. Compare that against the interface you are about to hand to the hotspot.
If they are the same, you have three options, in order of preference:
- Manage from a different interface. Plug into a port that is not part of the hotspot bridge. Cleanest solution.
- Bypass your own device. Add an IP binding of type
bypassedfor your machine’s MAC address before you create the hotspot server. It then passes through without authenticating. - Accept it and have credentials ready. Create the hotspot user before the server, so when you are captured you can immediately log in.
The second option is the one to reach for if you only have one cable. Bind by MAC address rather than IP, because your address may change when the new DHCP server takes over.
The order that works
Sequence matters more than people expect. Creating the hotspot server before the address pool exists, for example, produces a server that hands out nothing.
- Bridge — create it and add the ports that will serve clients.
- Address pool — the range clients will be given.
- Router address — the gateway address on that bridge.
- Router DNS — set the router’s own DNS servers and, critically, enable
allow-remote-requests. - DHCP network — the gateway and DNS handed to clients. See the warning below.
- DHCP server — bound to the bridge, using the pool.
- NAT masquerade — so client traffic can leave through your uplink.
- User profile — how long access lasts, how fast, how many devices.
- A user — at least one, before you are captured.
- Bypass your own machine — if you are on the hotspot interface.
- Server profile — the login method and DNS name.
- Hotspot server — last. This is the switch that makes it live.
The DNS trap
Step five deserves its own warning, because it produces a failure that looks like something else entirely.
It is tempting to hand clients a public resolver — 8.8.8.8, say. Do not. An unauthenticated hotspot client cannot reach the internet by definition; that is what the hotspot is enforcing. If the only DNS server it knows is out on the internet, it cannot resolve anything, so the browser never issues the request that the hotspot would intercept, so the login page never appears.
Hand clients the router’s own address as their DNS server, and enable allow-remote-requests on the router’s DNS so it will answer them. Put your public resolvers in the router’s DNS settings instead — the router forwards on the client’s behalf once they are authorised.
This one setting is behind a large share of “the hotspot works but the login page won’t load” reports.
Give yourself a way back
Two habits make a lockout a nuisance rather than a disaster:
- Winbox can connect by MAC address. It works at layer 2, so it keeps working when IP routing does not. Know this before you need it.
- Take a backup before you start.
/system backup savetakes seconds. Restoring it takes seconds. Rebuilding a configuration from memory takes an afternoon.
Doing it without the sequence in your head
All of the above is what MikrotikAdmin’s guided hotspot setup does for you. It runs the thirteen steps in the correct order, detects existing configuration by both name and interface so it does not collide with a router’s default setup, hands clients the gateway as their DNS rather than a public resolver, and warns you before it captures the machine you are working from.
You still see every change before it is applied. The point is not to hide the configuration — it is to stop the order and the details being something you have to get right from memory.