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 www.googleanalytics.com 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.

Solutions?

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.