Redirects are quite simple, aren’t they?

Nothing seems to work more seamlessly than redirecting a request from one website to another – simply send an HTTP 302, and it’s done. It sounds simple, but like many things in the world of captive portals, it is not quite that easy upon closer inspection. We therefore want to take a closer look at redirects.

Why do we actually want to redirect users?

The operators of internet access, especially when access is available free of charge, wish to redirect users to any website before or after login. There are many different application examples of why this is desired. Often, the goals are of a marketing or organizational nature, such as the following:

• Hotels want to show information about weather, special offers, wellness, gala menus, etc.
• Restaurants, cafes, and pubs want to present their offerings
• Guest portals provide information on possible activities in the surrounding area
• Third-party providers want to display information such as an event calendar
• Advertising content should be shown before login
• … and many others.

When is the redirection possible?

The operator of a captive portal has two options for redirecting a user:

1. The user goes online and is then redirected to an external page
2. or the user is redirected to the external page while offline and only then taken online.

Both methods have weaknesses that one should be aware of.

1. Redirects after login

Let’s first look at the most common type of redirect. The guest has logged into the network in whatever way (password, Facebook login, …), and is now authorized to surf the internet. Now the captive portal sends a redirect (HTTP 302). The page appears… but wait… where did the browser go? The captive browser closes immediately on many mobile devices after a successful connection check has been performed. This applies to millions of Android devices. Apple iOS devices leave the captive browsers open and offer a “Close” button. However, since over 50% of all mobile devices are based on Android, redirects after login are therefore not really useful.

Read more about connection checks in our blog The Protocol Gap in Captive Portals.

2. Redirect before login

Since a redirect before login is far more complicated, it is not offered by all captive portals. To enable this redirection method, the system must have a so-called walled garden function, which allows the user to visit a single specific page without full online authorization. On the IACBOX, we call this function freely available pages. It is based on the whitelisting principle; you enter the desired page(s) there.

In the past, websites were complete and isolated without linked content from other pages, so all files came unencrypted from one web server under one domain. While it is easy to whitelist a domain, today a typical website is encrypted, has very dynamic content, and a lot of content from third-party servers such as

• Widgets from social platforms (e.g., a Facebook Like button, Twitter feed, …)
• Static files such as fonts and images
• Analysis/tracking services like Google Analytics
• Advertising opportunities
• and much more

This leads to the following problems:

• Large platforms like Google or Facebook respond with an almost infinite number of servers to requests for one and the same domain. For example, a DNS entry like www.google-analytics.com has a very short lifespan of just three minutes before another IP address is delivered. Many server farms also offer more than one IP address per domain, and the user’s device takes any one of them (round-robin). This means that we must allow access to a lot of IP addresses; furthermore, they must be updated regularly.
• For performance reasons, websites with high traffic distribute their content using CDNs (content delivery networks) using the same procedure as just described.
• A good method is whitelisting of unencrypted pages. However, since more and more pages are delivered encrypted via HTTPS, it is necessary to work with IPs instead of domains. A transparent proxy for TLS traffic can mean problems for non-web traffic.
• If access to large platforms (Google, Facebook, Amazon Cloud, …) is released, access is also granted to large or frequently used parts of the internet.
• An additional problem is dynamic content from third-party platforms: a walled garden must support dynamic resolution of external links, which is difficult to impossible in the era of dynamically generated Javascript websites.