Is it possible to create a multi-page custom captive portal?
-
A few months back, I stayed in a hotel. When I connected to their wi-fi, my browser landed on their captive portal page. 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. Of course, it was all HTTP, for the obvious reason that they could 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.
I'm not a fan of captive portal, I'm more of a FreeRADIUS person. Honestly speaking, providing credentials on a web page, let alone an unsecured one, does not sound like a good idea to me. Why not just embed them in your network settings once and be done with it forever?
Recently, someone asked me to do something similar. He asked me if I could build a more sophisticated captive portal than the one provided. The users should be able to register themselves –in a database, through PHP– preferably on the same page as the login page.
It's not like I didn't try, nor that I didn't try and find a similar project on the Internet, but since I'm writing this lengthy post, you know I have failed.
I know pfSense creates *.html files in the /var/etc folder, but I don't want to resort to ugly hacks. Is it even possible? How should I approach this problem?
-
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 :
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 ....
-
I see the captive portal is highly customizable. I have learned a lot the past few days, trying to get it to work the way I like.
One of the key things I've discovered is that pfSense serves the CP the pages over
nginxandPHP, and is therefore programmable. However, there's a missing component: the PHPPDOlibrary, which I believe should be included in the default installation. (I believe it should have full support forMySQLandPGSQLandUnix ODBCtoo, but that is another subject for debate.)I concur HTTPS is the way to go, and I'll try and convince the person that asked me to concoct the custom CP to obtain a DNS name. Also, the only information that is asked is the mobile phone number, which I think shouldn't be an issue.
It works, beautifully now, I am pleased with the outcome.
-
@scilek said in Is it possible to create a multi-page custom captive portal?:
However, there's a missing component: the PHP PDO library, which I believe should be included in the default installation
A 'default pfSense' doesn't use SQL.
If you need SQL yourself, all you have to do is :said in Is it possible to create a multi-page custom captive portal?:
Note : Just install (don't need to set it up) the pfSense FreeRadius package, and you have the MySQL client PHP part installed as a bonus.
@scilek said in Is it possible to create a multi-page custom captive portal?:
the person that asked me to concoct the custom CP to obtain a DNS name
I have the PHP PDO library :

If you recap everything I've said above :
There is an investment to make : a portal network which includes dedicated switch(es) and access points, and a domain name to rent.@scilek said in Is it possible to create a multi-page custom captive portal?:
Also, the only information that is asked is the mobile phone number, which I think shouldn't be an issue.
I agree with you.
A potential portal visitor has now the choice :
He uses its own phone's monthly 'data' from his phone company.
Or, against the phone number, (so, example, she/he can receive an SMS with an portal access 'user and password ?!) he can use the portal.