Captive Portal - Open WiFi or Set WPA2 Password?

richardsago

Good day. I think open wifi is bad for security but I would like to ask the community how you decided on your setup:

Set it to Open WiFi with the convenience of giving the users only one information (the voucher code) - All the shops that I've tested went this way
Set it to WPA2 WiFi and giving the users two information (the WiFi password and the voucher code) - I'm leaning towards this with a simple WiFi password like '12345' posted everywhere because (I think) it's useless without a valid voucher code

Gertjan

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

I think open wifi is bad for security

No need to think or presume.
You have a pfSense, so you can actually see what's going on.

Packet capture the pfSense that has an AP attached to it.
Visit the GUI of the AP, and see who is connected. Now you have the MAC and or IP addresses of these device.
Goto Diagnostics > Packet Capture

Select the interface with the AP, and enter the IP of the device connected, ask for full details, and hit start.

What you will see :
DNS requests
The usual TCP and UDP packets, and have all something in common : the content is ecryoted, as all traffic is TLS these days.
True : you can the packet headers : the source and destination IP, for example the source will be the IP from your device, and the destination for example the IP of facebook.com. The source port will be some random port between 1024 and 65535, and the destination port will be 443 = as that is what TLS (https) web servers use. You'll see some more flags, like packet number, protocol type (UDP or TCP), etc.
The data itself is encrypted. You, me, the NSA and KGB can't read it.
So, yeah, you could add another layer of encryption, why not.
Btw : I presume your device - and you - don't use 'plain mail' or http etc, but that you went full TLS (https etc). If you still use http to visit web sites then you have a problem, bigger as what WPA3 can for you.

The main goal of a captive portal is : you receive visitors that want an Internet access, and you don't want them on your private network (like LAN). So you give them that access.

You want to make live simple for them to, so no 16 digit WAP3 code to type, just a nice login screen with a simple user password, or a voucher code (and the will have to retry often, copying a random string of letters and numbers is already hard these days).
If the portal visitor doesn't trust your wifi or whatever router, AP and other stuff you use, then that is the moment they can activate their VPN.

Captive portals used by hotels, public buildings, trains, planes, ferries and so on never use an encrypted wifi. Don't believe me, go visit the local McDonalds or town hall, use their public wifi and see for yourself. I'll put my bets on "No WAP or WPAx code asked".

At home, you can go full thin-foiled-hat mode of course. But at home you won't use a captive portal because @home you trust your devices so no need to bother with a captive portal.
Most home ISP routers even offer a dual Wifi : one for you with your WPA3 code, and one for visitors and other device you don't (can't) trust. No need for a portal at all.

Btw : all this my my opinion, carefully crafted since I saw Apple presenting world's very first Access Point and when "wifi" was introduced.

slu

@richardsago better solution is OWE:
https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption

Edit:
If you are using UniFi it's since 10.2 avalible:
https://blog.ui.com/article/introducing-unifi-network-10-2

But this is only for the wifi connection, that's what you meant, right?

richardsago

Thank you @Gertjan and @slu for the replies. I tested OWE and it works for our needs when used in captive portal. But we have a few old access points that don't have OWE functionality. In case we cannot replace the old access points right away: for the captive portal will it make sense to set OWE for the majority of the access points and set to Open for the few old access points?

slu

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

for the captive portal will it make sense to set OWE for the majority of the access points and set to Open for the few old access points?

You can do that, but I'm sure clients will have issues on (re)connect or roaming between this APs.

johnpoz

@richardsago What is your userbase? Are these guests to your location? Are you wanting to collect info from them?

Are you wanting a way to keep other users off the network.

Do you just want a way to have them get wifi without having to give them extra info? Like a hotel normally you put in your last name and room number to auth to the captive portal.

Are people paying for access - ie to get the voucher code, etc?

Without knowing the end goal here, hard to say what would be your best option. What exactly would encrypting the wifi get you or the users if you just want them to pay via voucher code? Why would you care if some smart user in the area could sniff your wifi users dns?

Authing to captive portal, keeps unpaid users off - allows for easy setting of timed access, etc.

Captive portals can lead to more user questions and issues, vs say a simple wpa psk like setting it to todays date or something. Or just a rotation psk that is posted or given to the users as they check in or ask.

OWE is great and all - but its quite possible user devices might not support it, etc. Which could lead to more user questions or problems.

richardsago

Thank you @slu and @johnpoz for the replies. My setup is a small school with dorms that has separate VLANs for a.) Faculty and Staff, b.) Students and Spouses, c.) Online Classrooms, and d.) IoT like solar panels and attendance biometrics. The price per bandwidth is high where we are located so management decided to require MAC Address Registration for all devices, place a limit on the number of devices per VLAN Group, and to set limiters per VLAN Group. There are no charges for internet use for all registered devices, and no data is collected other than the default report from pfblockerNG when blocking only pornography and online gambling.

The school regularly has short-term visitors like speakers, and accreditors who will be hassled by MAC Address Registration so this captive portal (not yet in production) was recently created in a new VLAN for their use, patterned after coffeeshops using vouchers. I'm thankful for the replies in this thread so now the VLAN Groups were changed from WPA2-PSK to WPA3&WPA2-PSK to accommodate users with older devices, and the captive portal was set to OWE to encrypt data without WiFi password. But there are a few older access points that have no OWE functionality so currently the test captive portal is not available in some areas of the school.

If the few older access points will be set to Open WiFi so that the captive portal can cover the whole school, is the risk limited to:
Captive portal users connecting to the old access points (Open WiFi) can know the voucher code of other captive portal users also connecting to the Open WiFi, but they cannot know the voucher code of other captive portal users who connect to access points with OWE. If this is the case then can the risk be lessened by setting Services > "Captive Portal" > Configuration > "Concurrent user logins" to "First login" so that sniffing of other's voucher code is no longer useful?

Gertjan

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

If the few older access points will be set to Open WiFi so that the captive portal can cover the whole school, is the risk limited to:
Captive portal users connecting to the old access points (Open WiFi) can know the voucher code of other captive portal users also connecting to the Open WiFi, but they cannot know the voucher code of other captive portal users who connect to access points with OWE. If this is the case then can the risk be lessened by setting Services > "Captive Portal" > Configuration > "Concurrent user logins" to "First login" so that sniffing of other's voucher code is no longer useful?

Sniffing a voucher code ?
That's only possible if your pfSense captive portal login page, the web page where the voucher code has to be entered by the portal user, is plain http. Plain http is something of the past. You should really make the pfSense captive portal 'https' :

( You need to certificate which means you need a registered domain name, the pfSense acme.sh package, and you're good )

You can't (.... no .. shouldn't) use a http portal login page, as that would mean that, while looking for security, you'll be adding the biggest insecurity yourself.
As you've noticed : everything is https these days.
Nobody can snif https = TLS traffic.

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

than the default report from pfblockerNG when blocking only pornography and online gambling.

Safe yourself the time and effort. You won't find any hits. Portal users visiting web sites with that kind of content always use a VPN

richardsago

Thank you @Gertjan for the reply. Thanks to your instructions from the other post the captive portal is connected to https.

If my understanding is correct, if a captive portal user connects to an older access point that does not have OWE functionality and so is set to Open WiFi: then even if the captive portal has certificate then other people connecting to that old access point can sniff the user's voucher code. <-- is this correct?

If this is correct: can we lessen the risk by setting Services > "Captive Portal" > Configuration > "Concurrent user logins" to "First login" so that sniffing of other's voucher code is no longer useful? Because the voucher code can no longer be used unless the rightful user has logged off.

Gertjan

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

older access point that does not have OWE functionality and so is set to Open WiFi: then even if the captive portal has certificate then other people connecting to that old access point can sniff the user's voucher code. <-- is this correct?

If you see :

in the navigator, the traffic between the navigator and the web server (pfSense portal web server) is TLS encrypted.
This means that whatever you (the navigator) receives from, and post back to the web server, the voucher code, won't be 'visible'.
You don't have to 'snif' the wifi, as you have pfSense has even better : goto diagnostic > packet capture and capture traffic on the pfsense captive portal NIC, and add the IP of the connected device, ask for full packet details. You'll see for yourself : the data payload is, as 99 % of all traffic, encrypted.
This, is essence, is what https is all about.

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

... be used unless the rightful user has logged off.

Portal normally can't 'logout', or more precisely : have their portal session deleted.
True, you could check this option :

(as you see, I didn't check it )

because you already know what happens. When you install a browser/navigator, way way in the past, popup windows where allowed. These days, 2026, these are always disabled by default, because no one likes theses pesky popups. It's something of the past.
And you can't tell your portal user to "allow" popups in their navigator. They probably won't know how to do that anyway.
That means that users have no easy way to disconnect themselves.

To disconnect, portal user need to know their "portal session ID", and that would show up on the popup page (in a pre crafted URL) so clicking (posting) this URL against the portal web server would disconnect the user.

What will happen :
You are using voucher codes. The very moment a user uses a code, the countdown timer for this voucher code starts.
If the user now runs out of the building, shuts down it's device, or shuts down the the wifi, the counter will keep on running.
This is how vouchers behave.
Let's presume the (wifi) connection was lost for a moment.
The user comes back. Wifi is re established .... and the very first thing that happens is : a DHCP request is made to obtain an IP, network, gateway and DNS.
If - and only if, the user obtains the same lease = the same IP as before, then the pair "device MAC + device IP" is identical as before, and the existing portal session will get recognized/reused : the portal user is still granted access.

If, over time, the previous IP it was using is already attributed to another device, the "device MAC + device IP" will not be the same. The portal can not find an existing session, and presents the user again with a portal login page.
Lets presume the voucher hasn't timed out yet, so the voucher code will be granted again.
What will happen next depends on this setting :

richardsago

Thank you @Gertjan for the reply. Just to be on the safe side we will not activate Open WiFi on the older access points, and will only activate OWE every time one of the older access points get replaced.

Gertjan

@richardsago

There is a way to make the portal 'better'.
The captive portal, as implemented by "90 %" : the visiting device and "10 %" by pfSense can be made better. The actual technology is 'old' and years ago, progress was made, and rfc8910 was created, judged, and validated. many devices can use rfc8910 these days. Apple and Microsoft does. Android ... dono, might take a decade or so, but they will catch up.

After reading rfc8910 you'll think : "New rocket science ?!"
Btw : forget about the IPv6 part, pfSense portals don't use IPv6 yet.

Read this thread "captive portal is not working on mobiles" - don't bother about the subject of the thread, it's misleading, just read the content so you can the idea.

Now, grab some popcorn, and read this one : Captive Portal not working on iOS devices only (DHCP 114)
Now yo know what to do, I'll summarize the steps : Create a 'php' file in this folder /usr/local/captiveportal/ and call it for example 'rfc8910.php'.
The content of this is the last thread I mentioned. It's PHP so readable and understandable. It's actually a close copy of the 'index.php' file in the same folder.

You have to inform the DHCP server of the captive portal that it should give a DHCP option "114".
With kea, that easy :

{
  "option-data":  [
      {
        "name": "v4-captive-portal",
        "data":  "https://portal.your-portal-url.tld:8003/rfc8910.php?zone=cpzone1" 
      }
    ]
}

You have to change "portal.your-portal-url.tld" for your own captive portal URL.
I advice you also the check the hardcoded port value"8003". Ask you pfSense admin to confirm.
Give him this command :

sockstat -4 | grep '800'

and know that the 'even' numbers are for "http" and uneven for "https". you want the uneven number, in my case it was 8003. If you have just one pfSense interface that uses the captive portal, it's probably 8003 for you also.

Be warned : the kea IPv4 Custom Configuration JSON Configuration does not allow syntax error and other finger/keyboard problems. It has to be exact. No errors allowed.

Save and apply the config, and done.

Now, it's testing time.
Use :

and hit Start.
Connect a device to the portal, and you'll see the good old DHCP sequence :
First, the device sends out a "Discover" :

12:38:36.150808 2c:c2:53:b0:65:89 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 255, id 56840, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 2c:c2:53:b0:65:89, length 300, xid 0x1ad9375c, Flags [none] (0x0000)
	  Client-Ethernet-Address 2c:c2:53:b0:65:89
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Discover
	    Parameter-Request (55), length 10: 
	      Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway (3), Domain-Name-Server (6)
	      Domain-Name (15), Unknown (108), URL (114), Unknown (119)
	      Unknown (162), Unknown (252)
	    MSZ (57), length 2: 1500
	    Client-ID (61), length 7: ether 2c:c2:53:b0:65:89
	    Lease-Time (51), length 4: 7776000

and then pfSense, kea, the DHCPv4 server sends an answer with the proposed DHCP lease.
As you can see, a lease is more then just an IPv4 :

12:38:36.152279 90:ec:77:29:39:2d > 2c:c2:53:b0:65:89, ethertype IPv4 (0x0800), length 425: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 411)
    192.168.2.1.67 > 192.168.2.10.68: [udp sum ok] BOOTP/DHCP, Reply, length 383, xid 0x1ad9375c, Flags [none] (0x0000)
	  Your-IP 192.168.2.10
	  Client-Ethernet-Address 2c:c2:53:b0:65:89
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Offer
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Default-Gateway (3), length 4: 192.168.2.1
	    Domain-Name-Server (6), length 4: 192.168.2.1
	    Hostname (12), length 18: "iphone-xv-gertjan"
	    Domain-Name (15), length 20: "your-portal-url.tld"
	    Lease-Time (51), length 4: 86400
	    Server-ID (54), length 4: 192.168.2.1
	    URL (114), length 65: "https://portal.your-portal-url.tld:8003/rfc8910.php?zone=cpzone1"

You saw the last line ?
Now the device knows, as soon as it received this DHCP Lease answer from the pfSense portal's DHCP server, that :

This network uses a captive portal.
The devices knows it should fire up a web browser with the URL "https://portal.your-portal-url.tld:8003/rfc8910.php?zone=cpzone1" so the user can connect to the portal.

No more need to do DNS and http web request interceptions etc !! Gone the 4+ decades old technology, this is way better. Like if it was made for this precise situation : handling captive portals.
This wasn’t invented in a garage, [but it was Apple of course (2020)](ow to modernize your captive network).
And things are even better : if the device doesn't know what this DHCP Option 114 is - it doesn't know anything about RFC8910, then the original pfSense captive portal method kicks in and will works as before.
Other words : you have the best of both worlds.

Nice side effect : the RFC8910 method is way faster. Less error prone.

And now the cream on top of the ice : when connected (identified against the portal), on your device, go to the list with your Wifi SSIDs and click/tap on the SSID you use right now, the captive portal's SSID. You should see a list with this connection's related info, and also "portal page" button/link, this will open a page for you and you will see the ... "pfSense Portal Disconnect page " where you can disconnect the device (remove the session on pfSense).

I'm using this RFC8910 for over two years now. It's just perfect.
I wonder why Netgate pfSense didn't integrate this into pfSense by now.

Feel free to ask if questions.

richardsago

Thank you @Gertjan for the usual help replies. Concerning my last post: I spoke too soon because it turns out some of our computers do not support OWE. The problem was that the computer I tested for the OWE was fairly new and so got connected successfully, but some of our computers including what I use do not support OWE. Will our captive portal visitors using voucher encounter serious security and privacy issues if we go with the setup below?

Captive portal's WiFi to Open (no encryption)
Captive portal web page is https using acme

johnpoz

said in Captive Portal - Open WiFi or Set WPA2 Password?:

OWE is great and all - but its quite possible user devices might not support it

Just saying - I brought this up quite a bit ago.

Open wifi with https as your portal is fine - vouchers can not be sniffed ;)

Gertjan

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

Will our captive portal visitors using voucher ....

I could consider voucher codes even better as what I use : classic user + password login.
Voucher codes, even if they 'leak', are valid for a limited time and then gone forever.
Voucher codes give you the possibility to know who is connected and when, for how long, and even how much data the consumed.

Keep in mind : the identification gives you control who and how long a 'unknown' user can access a resource you want to make avaible.

In my case, a portal user logs in the hotel room number, like "202"and a password, which is (don't laugh) for all the captive portals login accounts the same.
I don't want to be bothered with generating and maintaining lists with voucher codes.
I handle the Internet access a bit like the TV set and the toilet in the room : if the client (portal visitor) knows how to operate the remote, they can use the resource. If they don't, then that's fine also.
No need to locate the paper with the voucher codes, copy one over and mark is as used.
No need to give a access user code : I ask the client if they know their hotel room number (they normally do), I even show it on the login page :; enter your 3 digit ROOM number (and even then I see the most strange login codes used, as failed logins are logged).
I only have to say the login password.
Again : this is for simplicity. I don't need to sell or admin anything.

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

encounter serious security and privacy issues if we go with the setup below?

You can not, shall not, will not be responsible what portal users do with their device and connection.
Normally, a person can consider his own home wifi network as 'safe'. Your portal visitors are for you 'untrusted' users, and that goes also in the other way : your portal users shouldn't 'trust' your (wifi or cable) portal network. Remember : it's 2026 : if users wants to protect themselves, they know what to do : every existing Youtube video avaible starts with the reminder : "Get a VPN ^^". And for ones, I agree with this.
It's the portal user's responsibility, using your network, to protect himself. You are there to give an access, that's it.
Normally, the user connect to your wifi (portal), and uses your https login page.
Ones connected, if they think its needed, they fire up their VPN.
Done.
Your have just one job : make the access method as simple as possible.
You don't want to deal with the "I can't connect my xxxx device, because your access doesn't work" (pfSense admins are like ordinary people : everybody want to break DNS) . You'll find out that people do really strange things with their devices ... which is fine of course, and shouldn't be your problem.

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

encounter serious security and privacy issues if we go with the setup below?

There's one : the device the user is using should use 'pfSense' as a DNS.
This permits you as the admin to intercept their DNS requests. So now you know they visit facebook and istagram. That's a massive security risk ( ).
Again : as soon as the connection is up, they could activate their VPN. Where the P stands for their Privacy. If they think they need it.
You should tell them they need a VPN for a simple reason : Your - you ! - digital and personal security is at risk when you offer a connection to "strangers".
You don't give a d*mn if they visit that pornh#b web site, but you can have huge legal issues if they try to access the web sites where the nuclear launch code are stored. You will see black helicopters hover above the building, and you - the owner of the Internet access will be questioned. Be ready to loose your loose your basic human rights very fast. And they won't offer you a free lawyer neither.
In most countries, sharing your Internet access isn't a big deal, but you, the one who pays the Internet access, is accountable for it's "usage". This will make you think : I route all portal traffic out over a VPN ? and yeah, that will help protect you. This will introduce some issues for the portal user though.

In short : there is no perfect solution for all this. So, chose for yourself : apply the KIS concept.

@richardsago said in Captive Portal - Open WiFi or Set WPA2 Password?:

Captive portal's WiFi to Open (no encryption)
Captive portal web page is https using acme

That's how I operate the portal.
https isn't a chocie, it's mandatory. http mode exist only to kickstart the portal, and do initial testing.

Have a look at Captive portal.
The HTTP redirect method is what pfSense uses.
I already mentioned above about the Captive Portal API (RFC8910) method.

richardsago

Thank you @johnpoz and @Gertjan for the replies that are helpful as always.