All mobile OS just check a web page to decide whether they're behind a captive portal or not.
The mechanism is this:
If bar.html == [expected content] > Open Internet
If bar.html != [expected content] > Captive Portal
If bar.html[status] != SUCCESS > No Network
Also, for iOS, you need to have a domain for your WiFi network ...
You need a HTTP proxy. It is impossible to do this with iptables only.
Block access to all HTTP hosts (except of your proxy) with iptables, for all except of the proxy. Then configure the proxy to allow or deny specific URLs.
First for achieving the redirection, you need an inline authenticator (access controller).
In context of your topic, you will need a Wireless lan controller if you opt for central management of AP. OR you can also place a captive portal type of network access controller with Wall garden features.
NAS monitors the traffic entering the downlink (client side) ...
Chrome attempts to fetch http://clients3.google.com/generate_204 and determines it's hitting a captive portal if that URL returns something other than a 204.
Apple's operating systems do this as well via http://www.apple.com/library/test/success.html.
when I use address=/#/127.24.2.1, the internet requests that go from
internal scripts also fail
It seems that your internal scripts use to resolve DNS names the same local dnsmasq server as you wifi clients.
Check your /etc/resolv.conf configuration and if there is present your dnsmasq server address (127.24.2.1 or 127.0.0.1 or other) - remove it. ...
In case anyone is curious about an update (in 2017) to this question... I was able to recreate the issue and figured out a solution.
Disable dnsmasq from resolving for the loopback interface (in /etc/dnsmasq.conf):
Add to the tail file of resolvconf (in /etc/resolvconf/resolvconf.conf.d/tail)
Yes it can be achieved.
Redirect all the user traffic to 3rd party captive portal (can be an open sourced like free radius or similar) and over that portal, you can write whatever logic you want.
DaloRadius is one of the open source solution which provides similar stuff.
You might be able to get a small portion of your clients to accept a captive portal. However, these may break security of connections, so clients that need secure connections are likely to refused your service and switch to a different hotel. It is unlikely you will be able to easily lure those clients back.
Very few protocols allow injection of something ...
Consider the question you're asking ("How can I serve a blockpage instead of https://playboy.com without my users having to do anything") as "How can I serve my own version of https://trusted-bank.com without my users' knowledge".
HTTPS and browsers are (these days) designed to avoid exactly this. This makes web filtering hard.
Even if you pushed a wpad, ...
Amazon Kindle (Fire)
The Amazon Kindle (Fire) makes the following request, and if it cannot be retrieved "... it assumes that the user has to login and throws up a Log In screen.":
See Also: https://forums.developer.amazon.com/forums/thread.jspa?threadID=834
For the latest iOS I had to ...
This will not work this way.
Both because DNS doesn't keep track of who resolved which address and because your DNS servers are unlikely to be queried on a second visit. Instead the old answer will be remembered (cached).
There is a great description of this at https://www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htm.
Here's part of it:
Captive Portal Authentication Process
Captive portal is a Layer 3 authentication, which requires that the devices connect to the network and obtain an IP address and related DNS information before ...
Your wifi needs to be connected to a gateway where you can redirect the traffic towards your captive portal (login page).
You can do this by using iptables on linux. Say that your interface eth0 is connected to your access point with the 192.168.0.0/24 subnet and your gateway (linux server) is configured at 192.168.0.1 and has internet access on a separate ...
Sounds like you're looking for something called a "Captive Portal" feature. If your router doesn't come with one out of the box, you have 2 options:
Get a router that does come with the feature, or
Depending on your router's model, flash it with custom firmware, like Tomato or DD-WRT
Please note that option #2 requires quite a bit of work, depends on the ...
It would be based on a MAC address. Basing it on a cookie would not work, as the cookie would not be presented to the access-point (etc.), but based on the DNS name of the domain they are currently viewing. It would also prevent things like email (not webmail) working.
The difficult part is how to effectively present the authorisation part of the portal, ...
This might happen automatically with a proper captive portal. However be aware that the sign in 'recognition' that you see on that android device is not a feature of the wireless network itself, but a feature of the client device. In other words it is up to client devices whether or not they are able to detect if an open wifi network has a captive portal ...
Yes. The captive portal page is just a webpage. It can do anything a webpage can, as long as the videos are hosted somewhere accessible before they get full access. Just make the page submit a hidden login form after the video plays.
I recommend against explicitly dealing with captive portal problems on the server side. Mobile devices include captive portal detection already as does Chrome and I think I've seen it in Firefox too. These existing mechanisms will recognize problems due to captive portals and give the user the ability to accept the necessary conditions etc inside a separate ...
As for now, there's no way to cleanly redirect HTTPS. IETF is already working on a solution, and the first milestone is August/2018.
But Android and iOS will detect a captive portal and ask user to login, and Windows/MacOS users will receive a notification too. You can put QR-Codes around with the authentication portal, and people will look around the walls ...
I understand what you're trying to accomplish. Your proposed method is not the way it should be done, unfortunately.
Here's a rough list of what you should implement:
Two wireless SSIDs, one for students, one for staff
WPA2 Enterprise authentication, using your AD or other radius directory. This way each user (whether staff or student) authenticates to the ...
First thing you need to achieve redirection is some in-line authenticator ( access controller ), as in context of topic you will be needing a Wireless lan controller if you opt for central management of AP. you can also place in captive portal type of network access controller with Wall gardened features
NAS monitors the traffic entering the down-link ( ...
As it is the public you are catering to, I feel you cannot reasonably ask them to install your SSL root certificate (how do they know you won't then mitm them on their home connections?). The process for this is also very technical and varies by browser.
I feel your options are to maintain an IP blacklist, or to disable https connections entirely. For the ...
A router that sends people to a captive portal often uses a firewall that looks for a flag, or can check a user's MAC, or any number of other methods to see if they have been properly authenticated, to decide where they are routed.
The logic is simple (maybe not this simple though),
if user != authenticated -> captive portal; else -> internet;.
You can implement PFSense as a routing/firewall solution, which has captive portal capability, http://doc.pfsense.org/index.php/Captive_Portal. I don't know if not require flushing the router with DD-WRT means hacking an off the shelf router or not, but PFSense can be installed on an off the shelf server or it's own appliance, no hacking necessary.
You should consider using a central RADIUS server for authentication. It will keep a list of valid (and logged-in) users/devices and can inform the access points about the status of a device, which then needs to manage only currently connected devices.
Another approach, which can also be combined with the RADIUS solution, is to have a central, powerful ...
You'll need two network cards in the CentOS server and let it act as a router.
Chilispot doesn't have a built-in DHCP server, IIRC. Install dhcpd on the CentOS machine or use the one that might be offered by the access point.
To my knowledge, Chilispot is dead (last release in 2007 or something).
I would do this in three steps.
Find a proxy software that fits your authentication needs, and set it up so that it can talk to the users network(s)
Setup your firewall such that ALL outbound connections from that network are dropped by default (then obviously allow traffic to the internal systems they need)
Set all web browsers to use the proxy