Nothings seems easier than redirecting a web request to another page – just send an HTTP
302 and we're done! Well, .. sadly this is not true in the world of captive portals. Let's have a
closer look at redirects.
An increasing number of WiFi operators wants to redirect users to an arbitrary website
before or after logging in. There are lots of different usecases where redirects are made to
The operator of a captive portal has two possibilities when to redirect a client:
1. Either take a client online first and then redirect to the external website
2. or redirect the client in an offline state exclusively to a particular website
Both methods have real problems every captive portal has to deal with nowadays.
Let's look at the more common version of redirects first. The guest has logged into the
network by whatever method (password, facebook login, …) and is now allowed to access
the internet. Now the captive portal sends a redirect (HTTP 302). Everyone expects this
page to show up now … but wait … where has my browser gone? The captive browser on
many mobile devices closes right after successful connectivity check. This is true for
millions of android devices. Apple iOS devices keep their captive browser open and provide
a "Done" button. This makes redirects after login virtually useless with more than 50%
android devices out there.
Read more about connectivity checks in our blog post The protocol gap of Captive Protals
As it is a much more complicated thing to provide, redirect before login is not supported on
all captive portals. In order to cope, the system has to offer a so called walled garden
feature allowing a client to access a certain website but no other site. On the IACBOX we
call this feature free to use pages.
Back in the old days a website was fully self contained and all the files were served
unencrypted from one webserver under one domain. While whitelisting one domain is easy,
nowadays a typical website is served encrpyted, has highly dynamic content, and contains
lots of external references like
This leads to the following problems:
As you can see - a walled garden feature is something rather fuzzy - nothing you would call a rock solid functionality.
We see more and more end customers out there wondering why redirects are not working
like they're expected to. You can't really blame non tech-savvy person for wrong
expectations. We are a bit surprised that even companies who provide redirect-websites
sometimes sell their platforms to customers promising „our page just pops up after the
guest logs into the network“ and „this works with nearly any router-like box out there“. The
reality is different, at least with Android devices, and none of us can change that behaviour.
Captive portal operators have to deal with the current state of having a redirect that works
propably only on iOS devices and laptops. And for the rest the only solution is a handout at
the hotel check-in.
The IACBOX also supports the complex task to serve pages in offline state via our walled
garden free to use for a redirect-before-login, but it mainly depends on the website itself if
stable access can be provided to all its external dependencies.
Currently there's no other option, we have to look at each redirect page separetely and
decide which is the best solution for that particular case.
Are you interested in wireless Internet access for guests, staff or things for your enterprise, or do you provide network solutions for clients? Drop a few lines to share your opinion with us: firstname.lastname@example.org
At Asteas, we see it as our task to shape wireless Internet access in networks efficient and legally conformant for the supplier, efficient and comfortable for the user and secure for both.
For more information, visit our website www.asteas.com or contact us here.