@scilek
I work for a hotel and I use pfSense, and one the reason is : it has portal functionality build in.
I'm using this pfSense portal for the last 10+years now. It works great.
Why does a hotel needs a portal ?
Because we all have probably have one thing in common : some one is responsible for the "Internet' connection" as people can do 'things' with a connection that can have legal consequences. And guess what ? As you don't know who did what, the subscriber of the connection faces the judge.
So, to keep things simple : don't offer a portal. Never ever share a network connection with some one else. Share the connection only if you are will do do "time" for these people. This seems harsh, but is probably very valid for a family internet usage case : you are responsible for the actions and interactions of your kids after all.
So : If you really want to keep things simple : do NOT share your Internet (phone, credit card, passport) connection. If you really have to, start by looking up possible (legal) consequences. I think a universal concept is : you won't be able to say "I didn't know". It's like driving : you can buy a car, and you will need assurance and a driver license. Exception : you drive on your own 'land', not on the public roads.
For a company's connection : the stakes are probably even higher, as you really (can't) know who uses your portal connection.
Consider this : use a separate Internet connection for your portal network, so if something happens, you don't lose all your Internet access.
With all this out of the way, I can start answer your questions.
A portal exists because it very unpractical to give everyone a WPA2 wifi access code. The pfSense portal doesn't care if portal clients are connected using Wifi or by wire. A wire connection doesn't have a WPA2 code anyway.
When you change the WPA2 code, all connected clients will have to use the new one. And your own devices connected to the portal/wifi network need to be reconfigured with the new WPA2.
This is why a 'captive portal' exists. Most often it's a 'open (!) Wifi connection, so an SSID and no WPA2 password. This is known as a scary thing, as traffic goes 'non encrypted' over the air, but this isn't the case in reality.
As you've said already yourself, "http" web traffic shouldn't be used anymore. Like no where, and no exceptions. So : the portal login page can't be a "http" page.
This means : a captive portal isn't free of charge. You need to rent a domain name, and this will cost you like what ? 5 $/€ a year ?
Why a domain name ? Because you need to obtain a signed certificate, one that is recognized by all existing browsers. When you have this certificate, you can create a https portal login page (and also, why not, a pfSense GUI https access).
The good news : you need the acme.sh pfSense package to obtain this eradicate, and it will be free. Ones setup, it's "for live" : no admin time needed.
Fast recap : https is mandatory these days. http is dead.
And because https means "traffic encrypted" the portal login phase is already not visible anymore over the wifi, so no one can see and 'steal' the login (or other) credentials.
Now, you'll understad that this :
@scilek said in Is it possible to create a multi-page custom captive portal?:
not be bothered by the ubiquitous IT-illiterate users asking what to do with the browsers' "This certificate is not good enough so I refuse to open your page." warning.
has to be rephrased as this :
the ubiquitous IT-illiterate admins ...
These days, if some one want to make a 'public' accessible web page (used by "IT-illiterate (portal) users", we all agree) , it has to https. Period.
@scilek said in Is it possible to create a multi-page custom captive portal?:
I'm not a fan of captive portal, I'm more of a FreeRADIUS person.
Planes are not cars (both have tires, that's true).
FreeRadius is not needed for the pfSense captive portal. It can be used to handle portal authentication if needed.
Freeradius can be used if you want to 'totally NOT KIS' portal authentication.
The build in pfSense user manager can handle your needs just fine. You don't need FreeRadius.
Btw : be aware : the pfSense FreeRadius package offers about 5 % of the capabilities of what FreeRadius really can do. The rest isn't exposed in the pfSense GUI, so inaccessible.
If you really want to use FreeRadius and have all the Radius tricks at your disposal, do not use the pfSense FreeRadius, but get the real FreeRadius, and inform pfSense to use that external (on a LAN ?!) FreeRdius server, and now you have full control.
I do use the pfSense FreeRadius for my portal, because I said to myself "why not" ? I'm using for classic user/password access, nothing else, no fancy options. I might as well use the pfSense user manager.
@scilek said in Is it possible to create a multi-page custom captive portal?:
On that page, they had the "Register" button, which I clicked, which directed me to another page, where I registered myself. After successful registration, that page redirected me to the main login page, where I entered my credentials and then managed to log in
Like what ?
A portal user has to give his name ? mail ? Credit card ? Social security number ?
If you want to use a portal for a company, here in France, you have a serious legal problem in less then a day.
It's 2026, which means handling (== asking) really hard to manage. Most potential portal user will refuse flat out.
It's ok to ask, but you have to store this info, give them access to this info so they can delete, modify etc this, at any time (that now a basic right for everybody I guess).
Making such a system is ... daunting. I mean, big companies like amazon, netflix etc deal with this and it costs them boat loads of $/€. If they don't, they can't propose their services in that country (for me : that's all Europe and some other civilized countries).
So : fast recap : do not ask people for their 'private' info.
The perfect 'why not' : give a lawyer 50 $/€, and he'll talk you out if in 10 minutes.
I'm not done yet, by far.
I'll continue posting later on.
Continued :
You've probably seen this :
[image: 1770382451035-121832e9-1d43-4418-835e-c98712b51757-image.png]
and some post in this forum (use the search button on this forum ^^) that used a "web front", a database (like MySQL or Maria or MongoDB) behind it, so the potential portal user can (== "has to") enter info, after which a the page, after clicking a button, bring the visitor to the real (pfSense) portal login, where final 'authorization' is handled.
You can also 'redo' the entire portal html script file (which may include PHP, so a lot is possible), and - I'm brainstorming now - with the installed MySQL client, you can make the login page 'communicate' with a back end database.
Note : Just install the pfSense FreeRadius package, and you have the MySQL client PHP part installed as a bonus.
But .... me thinking out loud again :
All this was nice and simple when 'http' was used. These days, it's https.
Now, roll the drums, no need to tell you you can not (shall not) redirect https pages to "some where else" - the client's browser will refuse that. This means, afaik, that you have to 'mod' the pfSense portal page where you do the data collection.
More to come ....
