How does the captive portal redirect work behind the scenes

Question

As a project I am building my own captive portal web pages for "unauthenticated" users. Those are users that have not hit a button on my captive portal page. I want this to be out of band (like a packetfence deployment option), so that my Linux machine is not acting as a router / proxy.

To do this I need to know HOW the device, in my case an iPhone running iOS 8, is redirected to the captive portal page.

This is what I think should happen:

1. iPhone connects to the Wi-Fi
2. DNS points at my Linux machine which resolves all requests with the IP of itself
3. The Linux machine has a web server that responds to everything on port 80, and redirects everything using the HTTP Location: header to a page with the content and a button
4. The button is pressed and the user's mac address is added to "something", and from then on the DNS does proper resolution (??) or maybe iptables redirects DNS requests to another public DNS host (??)

I have been through this site and Google for a few days now have even tried to look at the Packetfence code (I'm not a perl developer), I need to confirm if my process above is correct, or a bullet point list of correct steps. I have had a look at this serverfault post, it's the detail on how the redirect happens, and more importantly how to NOT have the redirect happen once the user is "authenticated".

I appreciate if anyone has this knowledge to fill in the gaps or point me at a web site that has the "how / what does the redirect - dns / dhcp / http / iptables).

The problem I am trying to solve is to articulate the technical process of how this works, expanding on other posts on this site which say things like "the first request should be redirected". My question is... how / what tools do I need to do that.

Thanks!

Answer 1

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 ( client side ) through promiscuous mode raw socket and when the browser initiated traffic for a unauthenticated client is detected a HTTP redirection is given to it as response. so browser on receiving gets redirected to our CAPTIVE portal homepage, which can be hosted in-line on authenticator or out of box at some external web server.

The sole work of this page is to provice user a UI to enter credentials. the credentials entered are forwarded back to the authenticator Daemon like chilli in case of coova chilli, further these credentials are passed as radius request to the RADIUS server or may be checked locally. Upon successful authentication the state of the client at authenticator is marked authorized and client is granted access.

How Redirection is achieved

The most widely used approch is to intercept the HTTP request initaited by user and 302 code as reponse to client. in chilli it is dove via below funtion

http_redirect2() { cat < < EOF

HTTP/1.1 302 Redirect

Location: $1

Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID

Set-Cookie: COOVA_USERURL=$COOVA_USERURL

Connection: close

EOF

exit

}

This redirection can be easily achieved programatically controlled tuntap interface to client side interface which intercepts client traffic. Further redirection can be achieved via DNS poisoning too. but may sometimes cause problem if responses got cached at client browser Further things can be done more specifically according to the problem domain.

I can help you with that if you want