Redirects are easy, right?

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.

Why do we want to redirect users?

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
websites of

  • hotels with information about breakfast, special offerings, wellness ...
  • restaurants, cafes or pubs providing their menu
  • (third party) guest portals offering information about possible guest activities in the area
  • currently attented events for displaying a time schedule
  • any website wanting to show advertisements before they allow login

When to redirect

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.

1. Redirect after login (or no login at all)

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

2. Redirect before login

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

  • Widgets of social platforms (e.g. providing a facebook like button, twitter feed, ...)
  • Static files like fonts, images
  • Analytics/tracking services like google analytics
  • Advertisment services
  • And many others

This leads to the following problems:

  • Huge platforms like Google, Facebook aso. have an endless number of servers answering requests on the same domain. For example a DNS entry for has a very short lifetime of not even 3 minutes before another IP address is provided. Many server farms also provide more than one IP address per domain and the client picks one of them (round-robin). This means we have to ensure free access to a ton of IP addresses plus they have to be updated very often.
  • Webpages with a lot of traffic spread their content over CDNs (content delivery networks) for performance reasons with the same characteristics as described above.
  • Domain whitelisting is easy for unencrypted traffic, but because more and more webpages are served encrypted via HTTPS we have to deal with IPs instead of domains. A transparent proxy for TLS traffic can cause trouble for non web-traffic.
  • Giving access to huge platforms (Google, Facebook, Amazon Cloud, …) makes large parts of the internet accessible for the sake of having a fully functional website.
  • Dynamic content from third-party platforms also leads to an additional problem: a walled garden has to have a dynamic resolution of external links, which is not an easy task in the age of on-the-fly generated Javascript webpages.

As you can see - a walled garden feature is something rather fuzzy - nothing you would call a rock solid functionality.

Wrong expectations

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:

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 or contact us here.

More information
This website uses cookies to improve its usability.