I know this has been a topic in the past about why captive portals exist, should they be there, what purpose do they serve, and why do companies want to monetize a service that most people believe is as crucial to running a facility as indoor plumbing and running water is.
At the recent CWNP Wi-Fi Trek in Orlando, we had many discussions about captive portals that followed in this same train of thought. What I noticed, and had the exact same conversation about twice, is no one knows what to do when traveling and you find yourself stuck behind one of these monstrosities. What I have found in my professional life is the executives of my company complaining that the Wi-Fi in the hotel they were staying in while traveling “didn’t work.” Of course the Wi-Fi didn’t work, I DIDN’T DESIGN IT! Sad part is there might be a very qualified Wi-Fi professional on the other end of that design, very well could be one with more certifications and experience than I have, but some mid-level manager horked up their Wi-Fi system with a captive portal and now users complain. The point of this discussion is captive portals are a way of life for the foreseeable future, and this is how to deal with them.
Back to the poor Wi-Fi professional who put tons of time and effort in to designing a system that has perfect RF, great data flow, everything that a great Wi-Fi architect/engineer has dedicated years of their professional life training to do, only to hand it off to a server guy to mess up our work. It’s always the Wi-Fi system’s fault so as a guy in the know; I came up with a plan to deal with this bane of our existence.
In the spirit of full disclosure, I have been responsible for deploying captive portals in the past, and I know of at least 3 that are still in operation to this day. Guess what, I’m a MUCH better RF guy than I am an HTML coder, so in my example, I’m the server guy that messed up my Wi-Fi system. That’s how I know these tricks. There are 3 steps, and I will list them off and then explain why and how it works.
- Never, and I mean NEVER, click on the little window that pops up that says “Click here to access the internet.”
- After NOT clicking the window or dohicky pop-up thing discussed in step 1, launch the browser of choice on your given device.
- Browse to a website of your choosing that is http and not https.
Explanation time, so hold on tight. For those that want to bail out, now is the time to do it. Spoilers do come next. As with all rules, and these in particular, you can break the rule but understand why you are breaking the rule and if things go sideways realize you might have to come back to step one, possibly even resetting the TCP-IP stack type step one. If you are reading this, after you get some idea of the mechanisms behind a captive portal, you will be able to tell rather quickly when you can break the process and when you have to go through the steps. My wife, who makes me do all this for her anyway, is never allowed to break this process.
Step 1 – Never click the little window or pop up. This ties back to the server guy who configured the captive portal and wrote the HTML script. Sometimes that guy is awesome; sometimes he still lives in his mother’s basement. This also ties in to step three, so we will refer back to this. The pop up windows can be defeated if the server is programmed to pass the URL’s that common devices ping after they establish a connection to tell if you are connected to the internet. Can I ping apple.com? I’m on the Internet and there is no portal. I can’t – must be a captive portal, let me show my user the pop up window. The issue with this is the browser you get after clicking on that window isn’t always a full-blown browser. In my experience, iPad’s are the worse. The Safari browser that launches on an iPad doesn’t support Bluetooth keyboards. Try explaining to your CEO why she has to turn off her Bluetooth keyboard, get the onscreen keyboard to launch, type her room number in, press enter on the screen and then turn her keyboard back on, right after she got off a 15-hour flight to Asia. Step 1 was painful to be learned. Step 1 also allows you to fulfill Step 3. If you skip Step 1, you might get stuck on Step 3.
Step 2 – Open up a browser session. I like this because I have taken control back from the robots that inhabit my devices and makes it do crazy things when I don’t want it to. This will also allow me to proceed to Step 3, the most important step actually. Different browsers will behave differently, and I can pick which browser I want to be in. It doesn’t really matter, but the CEO of my company, and my wife (not the same person in this case, I really do have a separate CEO of the company) don’t get this and think they are stuck using whatever browser pops up. Having something familiar when navigating the coding of some unknown person after a long day of traveling always helps.
Step 3 – Browse to an http website. This is crucial, and I can’t stress this step enough. Recent security concerns have prompted device, OS, and application folks to really lock down what your browser will allow you to do. Hijacking an https session, which is what a captive portal is trying to do, makes the previously mentioned folks unhappy, which in turn makes you unhappy. Fortunately for us, there are some websites that are still http and I keep a list of them handy and distributed throughout our company for this purpose. Entering an http website allows a couple of things to happen, and understanding them is REALLY helpful. When someone hits enter, their device tries to reach the Internet. DNS servers “should” be white listed so your device tries to browse to remote server, and since it is an unsecured connection, your device will allow the captive portal to hijack the session and return it’s own HTML page in it’s place. Someone at WiFiTrek said they enter 18.104.22.168, bypassing any possible DNS issues, to trigger the captive portal and it does work. Depending on how savvy the end user is, this is a possibility. Chris Reed recently suggested using http://neverssl.com which oddly enough was built for this purpose specifically. I do take umbrage with them attacking the Wi-Fi system but that’s another battle for another day.
Back to my wife; she gets the http URL. There are ways to make it happen when accessing an https site but it takes a lot of time babysitting the server to keep the security certificates up to date and everything kosher on the back end. Large organizations with dedicated IT can pull this off somewhat successfully. This process is really for the Days Inn you find yourself staying in while visiting the scenic town that is Rawlins, Wyoming.
Anyway, you will finally be seeing the captive portal in a browser you know and one that has all the functionality you expect to have. Now you can actually interact with the page and enter your name, room number, place of birth, blood type, your first neighbor’s pets middle name, and what you ate for dinner exactly 259 days ago; you know, the normal stuff. Hit enter and then drop to your knees and pray. Not really, but it can’t hurt.
Assuming the information you entered is correct, you will be allowed past the captive part of the captive portal. Remember, a negative answer from a server isn’t a malfunction, it’s simply a negative answer, but it’s still an answer! A negative answer means you now need to contact someone onsite to verify what you entered is correct. In some instances, staff have to manually enter your credentials and the problem might reside there. If you are validated on the captive part of the system, you are now in a grey area that can change based on any number of factors. This is where following the steps eliminates the amount of grey area you encounter and give you the best shot of not being confused. To clarify this, we now need to talk about server programming that will “break” the Wi-Fi system.
Captive Portal systems have a “feature” known as “post-authentication redirection.” What this means is the server has the ability, if enabled, to send you to a predetermined URL that is entered by the programmer. This is used to send you to the homepage of the location you are at or a different URL if the system owner decides that. Either way, it’s simply a URL that’s entered on a single line in the server. If the portal you are navigating has this enabled, and the URL is still valid, you will see a web page. This is great because it means you have completed the process. The portal will log your Wi-Fi MAC address for a predetermined time, like a DHCP lease timer, and you are now free to surf the internet on your preferred browser; the one from Step 2. The process is done until the timer runs out and you must repeat the process. The issues come when this post-authentication redirection isn’t enabled or they are trying to be fancy and the redirection gets lost and never sent to you. This scenario is why this process even exists.
Possibility 1 – Post-authentication redirection isn’t set up. This is the most common and easiest to diagnose / solve. If Step One isn’t followed, this becomes an issue. When clicking on the little pop-up window, you are opening up a browser with the sole purpose of loading an HTML page. You never actually tried to go anywhere. Without the redirect, you now have nothing to show. Depending on the device, browser, OS, personal settings, etc., you may get something, a blank screen, or possibly even the log in page again. It was the last HTML page it displayed, so it just shows it again. If you don’t know any better, you start cussing the Wi-Fi and throw your device against the opposite wall. Funny thing is you are actually online and just don’t know it. Close the browser and continue on your way. If you followed these steps, you entered a website in Step 3 that will now appear. This is a visual indicator to you, your spouse, and your boss that they are now online because they got where they were headed. Wi-Fi obviously works and no devices are injured in this experience. Wi-Fi designer is AWESOME (of course we are) and they continue on with their life and go drink cognac wearing a smoking jacket next to the fire, or whatever normal people do in hotels.
Possibility 2 – Post-authentication redirection is set up but they tried to be fancy and it’s broken. This is harder to diagnose and solve because now it’s not just one designer that failed, it’s a whole team of them. There is a certain airport Wi-Fi provider that is pervasive around the world and they have this problem all the time. They don’t admit it, but they do. Based on where you are and how you logged in and how much you pay they will show you a different experience. Sometimes they get too fancy and you end up being shown a dead-end road. From my experience this is a white screen with a banner at the top. Also in my experience, you may or may not be online; the end user has to attempt to browse to a new website to see if works. This scenario is harder for the end user to overcome because what you see seems to contradict what you think you know. If your intended web page shows up, you are online and can close the browser and go get a stiff drink as a reward for successfully completing this gauntlet of terror.
If attempting to browse to your website doesn’t work you will see the home page of the portal again. Try to navigate it again and if you get the dead end again, you are now at the mercy of the portal operator. If the name of that operator starts with a “B” and sounds like something you would hear at the local Bingo Parlor on a Thursday night, give up and go hide your head. If it’s a different provider, you might be able to contact them and convince them to white list your Wi-Fi MAC address through the captive portal, preventing you from needing to navigate the portal altogether. It’s an outside shot, but it can be done. The unfortunate truth is the client is ALWAYS the one who suffers in this outdated attempt to monetize a service that should be free. If you aren’t going to plan a guest Wi-Fi that is fast, free, and frictionless, just don’t do it at all. End of story. If your real-world experience ends here, I offer my heartfelt apologies. Wish there was more I could do for you.
There it is. The end of our journey. All I can say is unless something drastically changes in the industry very soon, captive portals are going to be a part of our lives for a long time to come. While dealing with them isn’t pleasant, I hope this helps you to at least reduce some of the friction when trying to explain something that shouldn’t exist to someone who doesn’t understand it. I would love to hear others experience and their tips for dealing with captive portals so please share your story!