A guest picks the network, gets an address without trouble, and then nothing happens. No pop-up, no login screen. Browse to a website yourself and you get a certificate warning or a timeout instead of the portal.
This chapter is about the page that does not appear. If the guest gets no address at all, go to A device gets the wrong address first. If logging in works but there is no internet afterwards, that is the ordinary route: see No internet after applying.
The quick checks, in order
- Is the hotspot running?
/ip hotspot print. A good answer ishotspot1on the intended interface, without theIflag for invalid. A hotspot on an interface with no address becomes invalid and does nothing at all. - Does the hotspot see the guest?
/ip hotspot host print. A good answer is a line with the device's MAC and IP address. If the guest is not listed, their traffic is not passing through the hotspot interface. That is nearly always because they are on the bridge while the hotspot is on a VLAN, or the other way round. - Is the address on that interface right?
/ip address print. A good answer is exactly one address on the hotspot interface, and it is the one in the profile. - Can you reach the portal by hand? On the guest device, go to
http://10.5.50.1/login(your hotspot address). If that page appears, the portal works and only the automatic opening fails. That halves the search. - Does the router answer DNS?
/ip dns print. A good answer isallow-remote-requests: yes. The redirect leans on the router resolving the name the guest is going to. - Is the walled garden right?
/ip hotspot walled-garden print. A good answer has the detection hosts of Apple, Google and Microsoft in it, onallow. - Are the pages there?
/file print where name~"hotspot". A good answer is ahotspotdirectory with the stock login pages in it.
The usual causes, most common first
The device's own detection cannot get through
iOS, Android and Windows each fetch a fixed, plain http page on joining to see whether there is internet. If the hotspot does not answer that, the device concludes there is internet and shows nothing. Those hosts therefore have to pass the walled garden. The tool fills them in by default; if you emptied the box, put them back.
The guest opened an https address
A hotspot cannot intercept https without a certificate error, and modern browsers refuse outright. Always test with an address starting with http://. This also explains the certificate warning people report: that is the portal trying to step in.
The guest uses their own DNS
A phone with DNS over HTTPS or a hard-set 8.8.8.8 does not ask the router, so there is nothing to redirect. On recent phones that is on by default.
The hotspot is on the wrong interface
With the hotspot on the bridge while the guests sit on a guest VLAN, their traffic never enters the hotspot. They do get an address, because DHCP works, and nothing else happens.
Two addresses on the same interface
Give the guest VLAN an address in the VLANs section and the hotspot a different one on that same interface, and both end up on the interface and the redirect gets confused. The tool warns about it.
The device was already logged in
With cookie or MAC login the hotspot recognises a returning guest and lets them straight through. No page, and that is correct. /ip hotspot active print shows it.
What the configurator does about it
The Hotspot, PPPoE server, RADIUS section is off by default. Switched on, it gives you the fields that matter: the interface (preferably a guest VLAN), the router's hotspot address (default 10.5.50.1/24), the portal DNS name, the login methods (HTTP CHAP and cookie by default), a rate limit per user, simultaneous logins, session and idle timeouts, the users, the walled garden, and an https portal with a self-signed certificate.
The walled garden comes pre-filled with *.apple.com, captive.apple.com, connectivitycheck.gstatic.com, *.gstatic.com and www.msftconnecttest.com, precisely so that iOS, Android and Windows detection gets through. Some Android builds and Linux desktops use other hosts again; those you add yourself.
The script creates an address, a pool and a DHCP server on the hotspot interface, unless that address is already the LAN or VLAN address. If a different address is already on that VLAN, the tool reports it and asks you to make them equal. The hotspot adds its own dynamic NAT and filter rules; the script says so in as many words and writes no manual firewall rules for the portal.
Not checked, and this is the important one here: the tool does not look at whether the router answers DNS. Switch off Router as DNS server for the LAN in the DNS section and the redirect breaks with nothing warning you. No login page is built either: RouterOS uses its own stock pages from the hotspot directory. Vouchers, SMS verification, your own house style and a terms page are not in the tool.
When it is not your router
The guest's device decides for itself whether to show a portal. A phone with an always-on VPN, with private DNS or with a profile from its employer will not show the screen no matter how well your hotspot is set up. The way out that always works is to put the portal's address on a card, so somebody can go there by hand.
Read on: Hotspot, Recipe: hotspot in a hotel and DNS.