Set Your Portal Free

It’s no secret that users hate captive portals. It’s no secret that WiFi engineers hate captive portals. So, why do we still have them? Well, there’s a few reasons people might have about why they think they need a portal, here are a some:

  1. Management wants to sell stuff
  2. Management wants to email stuff
  3. Management wants to track people to sell stuff, email stuff
  4. Management wants to make money
  5. To satisfy legal and regulatory requirements

So, other than number 5, there’s a common theme – this problem is well above Layer 7 – the majority of Captive Portals are used solely to exploit customers, staff, and the likes. It’s a bit of a fallacy though, captive portals are deterrents and actually give users a false sense of security, potentially exposing user data through poor knowledge of how these networks are secured.

Satisfying legal requirements is a difficult one to crack – whilst I’m not an expert, in the UK we have 2 pieces of legislation that we have to abide by if we’re the ISP and if we hold customer data – Investigatory Powers Act and GDPR.

Feel free to correct me, but to comply with the Investigatory Powers Act if you’re an ISP, you need to be able to identify a user and at the very least log source and destination addresses of services they are accessing. When the relevant authorities spot that you have a user accessing illegal content you need to be able to offer them up on a plate.
GDPR means that as well as offering a user up on a plate you have to tell them everything you plan to do with their data, whether its email lists, browsing habits, or just a list of their names. Users have to be able to opt out (which can be as simple as not using the network) and they have the right to be given all data that you hold (via a Data Subject Access Request).
In order to comply, it can be pretty costly to store and process all that data, and you probably need a few lawyers to help on the way.
There is a simple way around this though, but it comes at a cost… Don’t be the ISP! There are a few companies that you could partner with which takes the headache away, or you could build the capability internally – but let’s face it, who wants that burden?

I’m sure management won’t be keen on losing an advertising/revenue stream, but if people don’t use your network because of the portal, there isn’t much benefit! Just remind management that if somebody is on your wireless network they can see your store – a few eye-catching posters will get much more of a reaction than an ad on a portal.

One of the things that is almost impossible to find is data on some of the burning questions a WLAN engineer might have – how does it impact my network, how do I scale, and what do I need to watch out for?

Security and the bad habits

One of the first things that is noticed is that users have no idea how wireless security works! Now, I wouldn’t expect them to be experts, but there needs to be an education piece to tell users that Captive Portals do not mean security! 

Most users know that https in a URL means the website is secure and they incorrectly link a secure captive portal with a secure wireless network, potentially exposing theirselves. If you’re operating an internal guest network or a BYOD network, make sure your colleagues know that in order to be secure they ideally need to be using a VPN or at the very least, checking that their webpages are SSL.
A security savvy colleague is a safe one, even if you’re not thinking about kicking the portal it’s probably a good thing to do.
Oh yeah, and never log onto a website with a certificate error!

You will also probably get requests to put a PSK on the network, or even hide the SSID. Now, the analogy we have used to explain why this is stupid is that a widely shared PSK and a hidden SSID is akin to your favourite supermarket taking down all branding and signage, locking the doors with a single key, and then posting the address and a copy of they key to all its customers – that’s not security, just the illusion of security, and again, it drives bad behaviour.

How much bandwidth?

Well, this is obviously unique to all use cases, but in a carpeted office or high street retail store with users just doing normal user stuff (Facebook, Cloud Services, Email, Browsing, etc) you’re looking at less than 1Mbps per user over the air. It’s very, very hard to come up with a figure, but from experience, it barely tickles your WAN links – it’s not a lot to worry about! I would just make sure you have proper protection mechanisms such as a tested QoS policy. 

Try not to rate limit though, especially by using the wireless infrastructure. You may find a protection mechanism such as a policy map with a capped CIR is more beneficial at pinch points within your network if you are concerned, but make sure you build enough head room in – ideally, you want this traffic off your network as quickly as possible.

What kind of growth should you expect?

Again, unique to your use case. In an office environment, we find it works out quite well to assume that on average your users have 2.3 devices each, but would struggle to use more than 2 at any one time. If you’re on the phone, you’re not listening to music, but you could be checking your emails on an iPad. Obviously there are some exceptions to the rule, but using a multiplier of 2.3 has given fairly accurate figures in the past.
Clearly, 2.3 is a point in time figure, and you have to use your multiplier on the number of people in the locations, not the number of people using the service with a portal! Remember, people don’t like captive portals and won’t use them unless they simply have to! It would be safe to assume a growth of 300-500% of concurrent connections.

One of the more difficult things to overcome, especially in a large organisation across multiple areas, is that some APs get pretty hot and you start exceeding a comfortable number of users per AP – there isn’t much I can say about that except that the AP density in these sites was probably wrong to start with, use it as a basis to fight for funding and improve! 

What about channel utilisation?

More users means an increase of channel utilisation, right?

Wrong. Associated clients are happy clients, they don’t probe aggressively. You will quickly realise that a client associated and not talking uses less airtime than a client which isn’t associated, especially in 2.4GHz where clients quite happily probe on overlapping channels.

One of the other overlooked pieces is that again, people hate captive portals! Your users aren’t idiots, they’ll quickly learn that MiFi/Personal Hotspots/3G & 4G routers and even fixed line broadband is a quick way of getting online without the hassle; the friction the portal adds doesn’t stop them. Once you remove the portal, that headache will start to vanish – and guess what, that’s less beacons and less overhead! Great.

Don’t expect miracles though, you’re probably looking at an average of 2-5% decrease in 2.4GHz channel utilisation. 5GHz will more than likely remain the same.

Summary

A wise man by the name of Keith Parsons has campaigned that users want fast, free and frictionless WiFi access – and as I have mentioned above, users will do whatever they need to do to get online, usually at a detriment to your network. With the advent of 5G, we will see WiFi and Cellular technologies move closer than ever before, and users will simply expect a seamless shift onto WiFi – if that’s not offered, your network simply won’t be used. 

It is a bit of a journey, and there are a lot of unknowns – bad user behaviour will quickly come out of the woodwork and will need combatting.

In my opinion, in a corporate setting especially, a captive portal such as a sponsor portal shows zero trust; it shows users that they aren’t trusted to think or act by themselves and somebody else needs to be accountable for their behaviour. A portal free wireless service makes for a happy customer and a happy colleague.

The bottom line is, don’t be scared – your users will reward your hard work.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.