brilliant, thank you. I saw the example but couldn't find an example with the variable. Not having experience of this Im grateful for the help. I didn't realise it was literally simply put"$PORTAL_MESSAGE$" in the HTML!
Interestingly I did all my testing with a Windows 10 and Windows 11 laptop until I was happy with my captive portal. I tested at each stage:
set up captive portal with defaults, no authentication.
set up voucher roll and voucher authentication.
add SSL certificate (I already use an ACME letsencrypt with pfsense so I added another URL to the SAN for the captive portal)
set up radius
customise the logon HTML and the "error" HTML
I was happy that this all worked - only the "edge browser" seems to have an oddity with captive portal (force redirect sorted that and I was going to force redirect to my "company landing page" anyway, chrome and firefox have no issue sending its captive portal check plus redirecting back. Now to test with other devices:
*Ipad worked fine.
*Android did not. Android was convinced that it was connected - it attempted a www.gstatic.com/generate_204 which apparently (according to the device) succeeded pre authentication! There was no traffic flow though (good). However I could not get the captive portal page to trigger on an android device, it was convinced that it needed to "sign in" but then would simply say that it was connected.
I spent quite a lot of time looking at firewall logs, device logs and trying to fathom why the android device was convinced it had a connectivity allowed and I was never shown the captive portal page, I checked everything from DNS (I use pfsense forwarder and there is only one "exception" which is a "disclaimer landing page" simple URL on a local webserver).
In the end I found that if I "disconnected all users" then this would work. After digging it seems that if I make a change to the pfsense portal settings I need to disconnect all users for my android device to see the captive portal. Most odd.
Android device is version 12. I have no idea what this will do to the people who have vouchers when I disconnect (radius auth will be irrelevant of course, they can re-sign in.
@bitrot You marked this as fixed, so others, like me, will also go through the entire journey of registering for pfsense+ and updating all the way up to 22.05 just to see the same old Captive Portal issues.
No. I found an issue with Captive Portal in 22.05, made a post about it, troubleshot it, and created a bug report about it. Once a patch was available I linked it and marked the issue as fixed.
The other issue you've mentioned is Regression #13290: dummynet. This is a cosmetic issue only that does not affect functionality and is also already fixed.
If you have some other "same old Captive Portal issues" I again suggest you be much, much more specific and also open a separate thread and maybe create a bug report that deals with your specific problems instead of hijacking another thread that is about a different issue that has already been fixed.
Anyone having the same or similar problems? Or any idea?
The thing is, if I recall the entire forum (and I can't / don't, although I'm posting here since a decade or so), you are the first I see posting about a voucher usage on a big scale.
And its not one set up, but multiple setups 190.
My advise is : start logging.
Not using the GUI, as the GUI probably offer 'close to none' possibilities here.
I would add lines lines like :
log_error("This is a log line in file abcd.php");
This line will get shown in the System main log like this :
change abcd for the file name you placed your log line.
You can / should add variables.
I don't have much experience with vouchers, I just played with them, by creating some 30 minutes vouchers and use them, and see how they time out of the preset time.
That is, I know, that if a voucher is used for the first time, and it's 'valid', the voucher code will get entered in the 'used voucher' database (probably the SQLITE3 PHP database file that is kept for every portal).
The captive portal uses a 'mini cron' process :
53161 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1
that runs every 60 seconds, the function captiveportal_prune_old() in /etc/inc/captiveportal.inc gets called. That's where the magic is happening.
The good news is : nothing magic is going on. See for yourself. Its plain vanilla PHP - PHP was removed from the rocket science list in 1999.
Vouchers are created, and you can print them out.
They are not known to the captive portal authentication system at this moment. They are generated, and you print them.
If 26000 vouchers are shown as used, then they had to be typed in by some one one by one.
Vouchers are active the moment they get entered.
The voucher code identifies the duration of the "roll" it belongs.
The voucher stays valid while ("enter date/time" + "roll duration") < "current time".
The same questions was asked, way back in time, on this forum.
My "find", at the top of the screen, is somewhat broken (I'm using a small phone right now), I advise you to find and look for yourself what can be done to make the voucher code smaller.
A soon as it becomes 'easy' to write and maintain firewall rules that take in account ttl header values, it will also become easy to pre-set these ttl to 65 129 and 257 on the other, lower side router, the one that shares the connection.
So, pf, the pfSense firewall, will see 64, 128 or 256 and thus detects nothing special.
And for that matter also iptables,or any other firewall you use.
You use the DHCP server on every LAN interface, even when you don't need it ;)
ON a portal type interface, where you don't know if people have set up a correct static IP setup (changes are close to zero), you need a DHCP server.
You'll be needing a working DNS server, the default unbound setup will do just fine.
Why you talk about NAT ??
NAT rules and related firewall rules are needed for your local services that you need to make accessible for devices somewhere on the Internet. NAT has nothing to do with a captive portal.
I know, this one : Captive Portal on pfSense 2.3/2.4 is old. But it's still very useful to make a working portal in < 5 minutes.
First, go vanilla.
Then : add your VLANs. If thats breaks, you'll know where to look ;)
I don't see us directing any resources toward changing that, but if someone were to propose and develop a solution as a pull request that wasn't too disruptive we could consider it.
Totally get where you're coming from and understand that. I'll consider that as a possibility as it would be a nice bit of work. As I have one or two students with there final thesis linig up, perhaps we can throw a bit of work into this. Thanks for the idea :)
We are seeking valuable solution from PFsense members on how to restrict/block users that are connected to the devices using another hotspot.
Like for example :- We have wireless solution with voucher guest control (Captive Portal) and issuing limited period single user vouchers to users. Now, we came to know that,users are misusing the issued vouchers by sharing their connection to other customer through his mobile hotspot facility. As far as our concerned, this is major loophole and needs to be restrict/block at the earliest.
I hope the the issue above is clear and awaiting for somebody to help us to solve the issue as much as earlier.
Really appreciated any one prompt response.
Sorry for the late answer.
A "Netgate TAC Word Class black card VIP" member access won't give you an answer.
As this issue can not be solved - period.
It's not a pfSense problem.
Its a router after a router problem.
pfSense being the first router - and the device sharing the connection being the second.
Now go to Youtube, enter the search phrase "what is a IPv4 router - how does it work ?", look some videos, came back here and say " ..... wtf, this is an real issue, and can't be solved ".
Your ISP gives you a connection, with some IP like a.b.c.d./32
You slide in the RJ45 Ethernet cable in your PC, set up your NIC so it has a.b.c.d mask 255.255.255.255 - you add a DNS, add a gateway, the ISP gave you one, and know, your are connected !!!
You'll say : one I, one IP ? What about all my other xx devices @home ?
Well, initially, you had to open xx number of connections to your ISP. Easy.
But routers were defined. And 'local RFC1918 networks.
It works like this : on the local LAN, all devices can talk to each other as one big family.
Resources that are not on your LAN, like youtube.com (sorry : 216.358.209.238) do not "match" the local network (192.168.1.0/24) so the request is send to the local gateway : your router.
The router takes the incoming LAN IP (like 192.168.1.10 port 443, MAC aa.bb.cc.dd.ee.ff) as the "source" and initiates a TCP/IP session behalf of you on the WAN side, to "216.358.209.238 port 443". Answers coming back from the TCP session are converted back to 192.168.1.10, using the original requester port (not 443 per se).
Keep in mind that the 216.358.209.238 (youtube) never even sees the WAN MAC of the router (let alone le LAN PC MAC).
The beauty is : 216.358.209.238 will only see requests coming from your WAN IP, 216.358.209.238 can not see that these requests came from 192.1638.1.10 - or 192.168.1.253, or 192.168.1.58 etc. That info is on the routers WAN interface.
Internal states in the router keeps track of the "what TCP session belongs to what device on LAN".
And, no, you can "see" this state table on the WAN side. That would be a security risk.
So, no, on the captive portal (just a LAN) you see "one" connected user == one IP, one MAC, and you can suspect that that single "user" using one voucher is actually generating the traffic of many users behind this "user" - as this user is a router.
Because all traffic is https these days (http is dead) you can't see a thing.
Don't feel alone here. The NSA/CIA/KGB/FBI can't see (decrypt) neither here : welcome to the club : you can't 'crack' https (TLS).
said, it's a "user" thing.
When you suspect a user abuses his voucher contract, throw him of the portal.
But be careful, you can suspect, never be really sure.
Btw : in a near future, when when IPv4 finally dies and IP traffic is all IPv6, there are possibilities as a single IPv6/128 can't be sub routed anymore.
Btw2: there were some tests with the TTL field in the TCP header, as every router hop decreases this field by one, but this wasn't really conclusive.
If I'm not mistaken, this was discussed in this forum, a decade or so ago.
you could also not redirect but use a case statement to include the different languages as required.
@pierrelyon Sir may I ask what version of pfsense are you using? I also have the same issue. I mean I have ADDS LDAP on my server and bind it on my pfsense. Then implement Captive portal user authentication with ADDS LDAP but it won't work. I am using pfsense 2.6.0.
If you are using v2.6.0, may I know Sir what did you do to make it work? TIA!