I’m having issues with HTTPS and the hotspot system we use for hotels
I’ve taken over as lead network engineer, the previous employee had put together a hotspot system that I am slowly understanding, piecing together and fixing issues with
The main issue I have at the moment is HTTPS sites don’t redirect to the hotspot login page
I have come to realize that we need a signed certificate. So i’ve followed this https://wiki.mikrotik.com/wiki/Manual:Hotspot_HTTPS_example and managed to get an initial redirect request for ‘some’ HTTPS sites, but many of the larger ones i.e. google throw an SSL error
I can bypass some sites by manually adding walled garden entries. But i’m still having issues with our hotspot page not loading when accessing https: redirects but works fine with http: - i’m not sure if its the hotspot system or a MikroTik issue
I want to know what people are doing with hotspot systems these days? In an ideal world i’d like users to get redirected to the hotspot page no matter what they try and do (as I personally HATE support calls about this sort of thing). Is this currently possible with Mikrotik’s hotspot implementation or are people using another service for it?
I don’t mind completely changing our hotspot system and paying for something that works correctly 99.9% of the time
I’m not sure what our current hotspot system is based on, but it runs on a hosted linux server, has a management GUI and allows us to create sites and edit a lot of parameters. It allows us to download a config file specifically for mikrotik devices and it contains a hotspot folder with a bunch of images etc that we apply on the main management page, as well as a config file that contains a bunch of information - including scripts and scheduler items. It routinely updates itself and replaces things like walled garden entries, downloads and ensures images and text for the hotspot page are up-to-date etc. After following the example above I noticed it does not work with https at all. It simple says
Redirecting to Welcome Portal…
Redirect error!
Connection lost, Welcome Portal not reachable or walled garden not updated!
I have enabled ‘wwl-ssl’ service and enabled HTTPS in ip->hotspot. I don’t know if this is a mikrotik issue or an issue with the hotspot files - i’ll have to look into it when I get some time
Problem is time is extremely limited and every day I have a very full plate that often spills over for days/weeks, so i’d like some input from people to get this all working as smoothly as possible. With or without our current hotspot system
In general, you will never be able to reliably redirect HTTPS (for purpose of Captive Portal CP or anything else), unless you are able to install special certificate on the users device.
Which is not possible for a public hotspot.
This is just a feature of HTTPS, especially designed to inhibit such interference.
However, most of users devices trigger the CP because of probing the internet connection using standard http.
In case, user ignores the devices hint (similar to popup in IOS, Android, Windows), but directly opens the browser, having https://anydomain.com as homepage, user might be lost.
would it be possible to have a page within hotspot server, when user enters HTTPS address, they get redirected to this page and it will say that please use HTTP or http://anydomain.com instead?
No. As you wrote, it also needs an (impossible) https-redir. “Best” you could do is to trigger some error messages from browser, regarding invalid cert. But this frightens the user even more.
So just to ignore https here only viable solution.
Make sure your hotspot is intercepting requests to hotspot-detection services that any modern OS has. This includes HTTP requests to URLs such as http://gstatic.com/generate_204 and intercepting all DNS requests eg for invalid / random hostnames like “xgjaiobman”
Sorry, no idea, but doing this for long time already, on openwrt-based devices.
Which are much better suited for hotspots with “advanced features”, like this one.
Doesn’t change the fact that other hotspot devices have far, far better hotspot handling than MikroTik. It seems to ‘just work’ far more often.
Whereas we constantly get the odd device that just doesn’t play ball with MikroTik’s hotspot implementation and doesn’t detect it
How do they do it? I don’t know, but MikroTik needs to either improve their implementation, or post information in the Wiki on how to improve it themselves (i.e. publish the mechanisms that all devices are using to detect captive portal systems so we can manually do redirects etc)
We tell people to manually go to the IP address of the router but it’s not something we should have to do
Any recommendations for a package we can put on a low cost or low form factor device like a Raspberry Pi3/4?
At the end of the day if I can put something in that ‘just works’ i’m happy to entire ditch MikroTik for the hotspot functionality. I really don’t care that much, I just want it to work and to stop getting complaints from hotel managers. But it has to be something that is hierarchical and centrally managed. We use a third party package through a web GUI that handles all the hotspot data like user accounts and images/HTML pages as well as access for hotel managers to generate vouchers etc
At the moment this functionality outweighs the problems with MikroTik hotspot handling, but I want to improve the reliability and it seems this is a dead end for that unless I can get some further help from MikroTik or someone who’s worked it out for themselves
As I wrote already,
you will never be able to reliably redirect HTTPS (for purpose of Captive Portal CP or anything else), unless you are able to install special certificate on the users device.
Which is not possible for a public hotspot.
Valid for MT-hotspots, openwrt-based ones etc. No difference.
I do not know implementation of CP (Captive Portal) on MT, whether based on iptables rules (wifidog) or much smarter, like using coova-chilli, which is the most advanced CP, as it easily integrates radius features, like speed- or volume limits, accounting etc.
MT might even use coova, but the real problem is the fact, that RoS is NOT open source. For example, on openwrt I can combine a real powerful proxy to coova, like squid, to do some “http-mangeling”. Or I can combine a local websever (on openwrt-device) with coova-chilli, to fake an internet connection, i.e. to suppress the annoying “popups” on Android, asking to connect to possibly available WiFi networks. Or I can keep the landing page open, on Android, after connection to web, for ads to be displayed. Or I can even serve local content (movies, music etc.) to the hotspot user, i.e. on a mobile hotspot, in public transport.
I started with MT-hotspots couple of years ago, but switched because of the limitations, being not open source.
However, the special features I mentioned are not ready-made in an openly available package for openwrt, more like customized features for clients.
Which usually also include remote firmware updates.
My main focus here is not in actually trying to redirect HTTPS, I really honestly don’t give a flying stuff about that
The real issue is simply when hotspot detection fails, the user gets no prompt or no notification in any way that they need to first ‘sign in’ and the normal behavior is they just open up a web browser and by default it’ll usually be a HTTPS site, this just leads to a the connection being dropped. So the idea of HTTPS redirection is just a band-aid for the real problem
Once again, I really don’t at all care about a redirect, but I want the captive portal/hotspot detection to JUST WORK so that this never happens, and they ALWAYS get a notification to sign in. MikroTik sucks at this
HTTPS redirection is just a band-aid for the crap hotspot detection. I have seen it done in some places, where manually trying to go to i.e. google.com does infact have an intercept successfully happen saying to first sign in, without just dropping the connection like there’s no internet, or having certificate warnings. What system it was I don’t know, how it ‘actually’ worked (probably not a HTTPS redirect but infact a graceful negotiation with the device/browser)
Regardless if it can’t be done, fine, don’t care, lets move on to actually fixing the underlying problem
Whether that be manual rules in the MikroTik router to improve hotspot detection, or just ditching it entirely and going with something that can be spun up on a low footprint device like a rasp pi and installing that inplace instead i’m all for it
I just want a solution
So the CP-detection is your real issue. I am a bit wondering about this, as I thought, MT-hotspots are quite often used,
and I expected MT to have a reasonable solution, at least.
Your issue(s) need more detailed discussion, it looks like, as CP-detection
also is dependent upon clients device, although the general principle is always the same:
Clients device tries to connect to “well-known” server, and expects certain feedback.
In case, it fails, considering other conditions (DNS, WiFi), a CP is assumed, and a “minibrowser” is opened.
Now slightly different scenarios, especially for IOS and Android, even different between Andoid versions.
I.e. IOS practically forbids JS in the “minibrowser”, before successful login. Newer Androids do NOT allow
redirection after login (connection to internet), simply closing the “minibrowser” automatically. Which can be delayed, if required, using special tricks.
So, careful integrated design of the “Landing Page” and the hotspot-device/CP to be done.
As we are now going off-topic, you can reach me via my antispam adrs augustus_meyerATyahooDOTde
Wait a moment… this should read: make sure your hotspot is not intercepting…
It is very important that you do not handle such special detection services in a special way!
So do NOT return a fake IP on those DNS requests, do NOT redirect those special requests to local servers, do NOT place these special sites in the walled garden, etc!
Those requests should fail. When they do, the software behind it knows they are on a network without immediate internet access, and they use this to show the user a special page that informs them about the issue and lets them proceed to the login page of your hotspot (by trying to load a dummy http page).
Once that has been done, they can go back to their https homepage.
Any special handling you put on those special requests (like allowing them through) will break the clever software and cause problems for your users!
I have the same issue when i connect with ssid “hotspot services” With computer’s, After connect to ssid and i go to broswer like google chroum (If i set before in browser login page like “https://www.google.com”, In this case the hotspot login page can’t change automatic to hotspot server), Whats the problem or how can resolve the issue?, In mobile when i connect to ssid hotspot service the mobile direct go to login page of hotspot but in computer’s can’t change?
I haven’t certificate.
As written many times above, that issue cannot be solved!
However, the writers of software like Chrome and Android do know that, and they use requests that you do not enter yourself (some DNS and some HTTP requests) to detect this situation.
When they find that they are on a hotspot/portal network, they allow the user to enter the login info instead of going to the homepage site.
The captive portal detection not working for you is almost certainly caused by some kind of hotspot walled garden entry that shouldn’t be there. The hotspot manager you are using I believe is HSNM hotspot manager. I would go through the walled garden with a fine-tooth comb and clean up anything from there that might be causing a problem. Something I see on the software page that is a bit alarming is the fact that they display YouTube videos when you are not authenticated, as well as other resources. Those same Google servers are likely being used to host the captive portal detection sites, and if they are allowed through by a walled garden entry, then the captive portal detection will be broken. In essence, you may be giving up reliable captive portal detection in exchange for the ability to play youtube videos for unauthenticated users. I’m not sure the trade-off is worth it.
