fbpx

What is a captive portal?

How to set up a captive portal in your Cafe or Restaurant

How to set up a captive portal in your Cafe or Restaurant

Hello, in this article we will cover what captive portals are, how they work with the Quickapp Wifi  platform, and some quick troubleshooting advice for any problems that may occur. Captive portals are commonly used to present a login page that requires a user action to authenticate. They are commonly used at public venues, restaurants, malls, Cafe’s, or other space where a user is required to log into a free guest WiFi service provided by the commercial space. Once authenticated, a user can surf the internet. How the entire system works is simple. A space will have one or more Access Points which are a device that allows a mobile phone or laptop to associate to the wireless network.

Access points typically work in conjunction with each other through a physical or cloud-based controller. For the purposes of this video, we will use the term AP loosely to describe their system. First, the AP broadcasts the name of the WiFi network, known as an SSID, which a mobile phone picks up and displays in their WiFi settings. This is similar to a home WiFi system where the phone sees a list of networks to connect too. Usually these are locked and require a password to sign in. Once signed in, a phone would have access to the internet. A captive portal system usually does not have a password but requires further authentication. Once a phone associates to the wireless network the phone will check to see if the network is online through a URL that calls out to the internet. Here’s how a phone knows it is connected to the internet. Android phones will check through Google’s connectivitycheck.gstatic.com URL while Apple iPhones will try to confirm access to the world wide web via captive.apple.com.

If these URLs confirm access to the internet a user will be able to surf automatically. If these URLs indicate that a mobile device cannot access the internet, then it can reasonably assume that some form of authentication is required and a special captive portal browser is displayed. A captive portal browser works independently of the regular phone browser. The reason for this is that it creates an isolated sandbox with its own cookies. Those cookies are not persistent and are erased to keep the captive browser secure. In a captive portal type scenario, when a user associates to the AP, a user is only given limited access to a pre-authorised walled garden. A walled garden is list of websites that the user can access without further authorisation. Quickapp Wifi Connection  setup allows certain websites and social media platforms— such as Facebook, Twitter, and quickapp.com.au as part of the walled garden. Since gstatic.com or captive.apple.com are not included in the walled garden, when the phone associates to the WiFi it is not able to confirm unrestricted connection to the internet.

Hence, the captive portal browser is triggered. When the phone tries to connect to any website which is not part of the walled garden, the AP redirects the request to a pre-configured splash page since the webpage wants additional authorisation or permissions. In  Quickapp Wifi case, that requires a connection to a social media account, email address, or phone number. Once the splash page requirements are fulfilled by logging in via a social network, email address or phone number, the splash page indicates to the AP that the user is authorised to proceed. The AP confirms this through the RADIUS protocol. Once confirmed, the AP grants access out of the walled garden and onto the world wide web. When authentication completes, no traffic passes through Quickapp.com.au  All traffic goes directly from phone to AP to the internet.

Note that apps requiring internet usage, such as chat apps, may not work until the captive portal authorisation process is completed. With Connect, a user will never have to go through the splash page process again and instead be presented with a welcome back screen. However, the authentication process itself does not change and each time a phone associates with an AP it will still go through the same steps to confirm access through RADIUS. For a variety of reasons the captive portal may not work as expected.

         

Here are a few common issues and solutions when troubleshooting. Many modern phones are intelligent enough to counteract any WiFi disruptions by relying on cellular data. If a mobile phone cannot connect to a webpage via WiFi, it may opt to automatically connect to the webpage using 4G/LTE. At the time of troubleshooting, a common way to make sure the system is running properly is simply by turning off cellular data. Once it has been deactivated, the webpage should still load. Samsung mobile phones running Android also have a setting which allows a phone to automatically switch to mobile data if the phone thinks the connection to the internet via WiFi is poor.

This smart network switch can be deactivated in the WiFi section of the phone settings. As you connect to the WiFi— via an SSID or network name— a captive portal should pop up. If the sign-in portal does not pop up this could indicate that gstatic and captive.apple are located in the walled garden. Another possibility is that the DNS is unreachable and located outside the walled garden. In this case, when you try to surf the internet your android phone browser will say that there is no internet or your iPhone is not connected to the internet. Another common possibility is that a user signs into WiFi but no splash page appears. When they visit a website they receive a security certificate error or warning. This is because the AP is trying to redirect the user from a requested secure website to a splash page. Secure HTTPS protocols do not allow such redirects in order to protect the user.

A user must visit a non-secure HTTP site. A quick way to check this issue is to visit a website without HTTPS. We suggest trying to visit neverSSL.com which does not use HTTPS. If a splash page then pops up, authenticate as normal. If the splash page authentication takes place successfully, but user still does not have full internet access, it may be because the RADIUS authentication step failed. This is usually due to a firewall configuration error. If the neverSSL.com webpage did not load at all and no captive portal appeared then it may be a configuration issue. Here is the entire process of logging onto an quickapp.com.au  enabled guest WiFi. First, a user will enter their WiFi settings and choose your network.

The phone will then begin to associate to the AP. Once successfully associated to the AP, the phone will go through the process of seeing whether it is connected to the internet using Apple’s captive.apple.com or Google’s connectivitycheck.gstatic.com. The check will reveal that there is additional authentication required. A captive portal browser loads the splash page which a user can then use to sign in through social media accounts or other means. After clicking through Facebook, a user is presented with the Facebook opt-in page.

Once they confirm access, they will be brought to the success page. When a person returns to the venue at a different time or day, the same process repeats. The WiFi still associates to the splash redirection and RADIUS authenticates. However, quickapp Wifi  replaces the splash login page with the same success page since the user doesn’t need to login again. We hope this video has given you a high-level look at how the Quickapp  captive portal operates and some helpful troubleshooting advice. Thank you for watching.   Please visit www.wifi.quickapp.com.au  or call 1300 515 611 to learn more.

Scroll Up