@rm MAJOR UPDATE: So while comparing and applying previous settings I found the setting that was breaking my captive portal from functioning.

SystemAdvancedFirewall & NAT :Disable all packet filtering. When checked this breaks captive portal redirect on 2.7.2 and allows traffic.

@Gertjan Thanks for the detailed info, I will give it a go.

Much appreciated
Steve

@Gertjan
I think that I have issues with the DNS because when I connect to the WIFi and I type ipconfig/all the DNS is the IP that I have in my proxy server.

I am going to explain you better.
I have a proxy server with to ISP. So to have Ethernet in the pfSense server I put from proxy switch to WAN pfSense. But in this case i don't set up any DNS in the pfSense
So I have that question I will need to setup something else in the DNS pfSense server ?
Also I set up in my PC DNS auto
Here i attached some pictures.

There is the lease I can see my PC but I only can access to the captive portal if i put the IP.
7.png 8.png

@Bonesaw said in Family keeps blowing data cap, need guideance on captive portal idea:

Now I was thinking. Can I give each user their own cheap router and then setup a captive portal on my pfSense router on and have the captive portal handle it via MAC address to those routers. Have a captive portal for each user basically.

Normally, I would come out of my corner and say : don't place "routers" on a captive portal network as it will complicate live.
But in your case, and I'm thinking with you : this might actually be a good idea.

Create a captive portal network, for example 192.168.10.1/24.
Wire (wire up) the X routers (router + AP build in, this is the most common type), one for every family member. Use a strong wifi WPA2+password every router, members won't share thee as they won't share their bandwidth ^^

Connect every routers WAN port to a common portal switch, so all are hookud up pfSense.
Every router sgould have its own DHCP range, like
Member 1 on router 1 : 192.168.100.1/24
Member 2 on router 2 : 192.168.101.1/24
etc
Evey member 1's devices will get connected to router 1 Wifi and routers 1 LAN ports.
The user should use one device initially to login against the captive portal. All other devices connected to router 1 from that point will have internet access, as pfSense (the portal) will only see an IP traffic like 192.168.10.x/24 coming from router 1 (all traffic will use the same router's WAN MAC).

With some classic pfSense FreeRadius bandwidth limiting and/or quota limiting for each user, you'll can enforce control.

@ngpfpeter said in Captive Portal with self registering:

Or have you already integrated FreeRadius into PfSense?

You mean installing the pfSense Freeradius package ? Yes, I'm using it for several years now.
I had decided back then that I needed FreeRadius for the Portal authentication.
I've also set up a NAS as 'mysql' database, although not strictly needed.
When set up, I've switched the portal's Authentication Server to "Radius ...", assigned a bunch of portal users Services > FreeRADIUS > Users.

I've been using the official Netgate pfSense youtube video's.

@ngpfpeter said in Captive Portal with self registering:

Have you already implemented something like this or something similar? ( Captive Portal with self registering)

No, never, as this means adding a extra stuff that has to be maintained.
Also, some core pfSense script files have to be modified, although minimal. This does means that after every pfSense update, the portal 'breaks' and you have to re apply your own modifications. This is tedious and often dangerous, as updates get postponed to 'later' which introduces security issues.

@vahidmoghadam said in a User with one device get many IP addresses, why?:

This is a bug

No I wouldn't say that - its related to feature(s) that has yet to be enabled in the "PREVIEW" version of their kea implementation.

I am not a huge fan of the wording they used to notify users of the future removal of isc dhcp.. But if users would of spent some time reading over the release notes before blindly clicking over to using the new kea which they did clearly label as "preview" in the release notes.. And went over what features are not yet enabled, etc.

Better wording might of headed off some of the posts we are seeing with users trying to use kea that is not fully implemented yet with all its features and bells and whistles.

And also a "preview" version is prob more likely to have some kinks or bugs to work out..

Also with anything "preview" even if didn't read the release notes, when switching to it - would be a great idea to actually validate it is working for all the things you need before sticking with it.

I read the release notes, and knew right away it wasn't going to be viable for my use at this time. But I did switch to it, and yup client gets an IP from dhcp.. So it is functional as a dhcp server.. But again per the release notes its missing things in its current implementation that I am currently using in my setup. So for now I stick with ics dhcp..

Maybe with the note they popped up could of included a warning that all features are not fully mature or enabled - please validate it it will work for you before switch - link to release notes, etc.

Its hard to say what the best course of action is - warning the users of removal of isc dhcp at some future time is a good thing.. But maybe it might of been been better to just hold off on the warning, and put in the release notes (which seem to go unread by many) that there is a preview version of kea available if you want to play with it.. etc. It is currently missing xyz features, etc. So be warned.

@Gertjan If you allow navigation by entering the mac address, the device is set up to 100 Mbit/s DW/UP.

@Gertjan, I found the problem!

Is my UBIQUITI Wi-Fi configuration.

When I marked this option the "GUEST Wi-Fi" isolate the client.

d64276bd-aeb2-464d-8bb9-f53888e73ee8-image.png.

The problem has been solved.

Thanks a lot.

Regards.

@Gertjan what I meant is that on flight mode when I turn on WiFi, to access the hotspot 😄

@Chris00 Implementing two-factor authentication (2FA) in your captive portal using Pfsense and FreeRADIUS is a great way to improve the login security of your users. By adding an additional layer of verification beyond the user password, you can significantly reduce the risk of unauthorized access to your network.

There are two main methods for implementing 2FA using Pfsense and FreeRADIUS:

RADIUS clients. If your user authentication is handled by a RADIUS server other than FreeRADIUS, you can use the RADIUS client plugin for FreeRADIUS to integrate with Google Authenticator or other 2FA providers.

Native FreeRADIUS Support: FreeRADIUS 3.x and later have native support for 2FA using RADIUS attribute extensions. This method is simpler and does not require additional plugins.

Here's a general overview of how to implement 2FA using Google Authenticator:

Install and configure Google Authenticator. Download and install the Google Authenticator app on your mobile device. Create an account on the Google Authenticator website to generate QR codes.

Enable 2FA in Pfsense. In Pfsense, go to Radius -> Clients. Select the RADIUS client that uses your captive portal and enable the RADIUS Attribute Extensions option.

Set up the 2FA attribute. Create a new RADIUS attribute, such as Google_Authenticator, and set its type to Vendor-Specific. The attribute value will be the Base32 encoding of the QR code generated by Google Authenticator.

Update the users' RADIUS attributes. For each user in the RADIUS database, update their attributes to include a Google_Authenticator attribute with the corresponding QR code value.

Set up a captive portal. In the adaptive portal configuration, add a 2FA verification step after successful password authentication. This step should redirect the user to a web page that displays the QR code and instructions for scanning it using the Google Authenticator app.

Test and verify: Once configured, Two-Factor Authentication Methods verify it by logging into the captive portal using your user account. If the 2FA verification step appears and the user can successfully scan the QR code and enter the code provided by the application, the 2FA implementation is successful.

Be sure to update documentation and user guides to inform them of the new 2FA requirements. Provide clear instructions on how to set up Google Authenticator on mobile devices and how to enter the 2FA code when logging in.

@PierreFrench said in Chromebook and Captive portal unsafe page:

the connection to http://gtstaic.... is not same ???
As far as I understand that initial connect is always in http and not https so defacto "unsafe".

This "http://gtstaic...." is used by the Chrome OS to check if a direct, open, not filtered Internet is available right after the network interface comes up.
Every OS uses its own 'http' test URL. Here is the one from my iphone :
http://captive.apple.com/hotspot-detect.html - click on it and you'll se what happens.
When my phone request this page, and get a simple html page back with the text "Success", then it knows that it probably has a direct connection.
All it knows is that DNS works, and port 80 TCP is open.
If something else came back, the the OS knows that something is going on. Maybe there is a portal ?
So, it launches a fulls screen default browser, with the same test URL as a destination.

On the pfSense side of things, there will first be a DNS request from the portal client. In my case : what is the A record of "apple.com". The IPv4 is given to the requester, your portal device. This is all part of DNS.

Be warned : if your your device doesn't use the DHCPv4 IP it got during DHCP - most typically the pfSense portal IPv4, but some other DNS IPv4, then you have issues : this destination is blocked. So : no DoH, no DoT etc. Just plain old school DNS over port 53 to the local gateway.

Now, pfSense, the pf firewall, will receive a browser request : traffic to 'some IPv4' with destination port TCP 80 : a typical http:// browser request. This "TCP port 80" request will get redirected to the captive portal's web server, using something like TCP 800x. The web server will send over the login page.
Important to know : only http traffic can get redirected like that. https can't.
If you use the https portal login page, then your http web page request get redirected to a TLS TCP (800x+1) port. The redirection isn't an IPv4 anymore (the pfSense portal interface IP) but a host name should resolves to this IPv4. The certificate send by the web server should contain the very same host name, so the portal client's web browser accepts the certificate.

All this means : most of the captive portal support isn't build into pfSense, but in the device that connects to the portal !
Captive portals all work the same way.
Microsoft OS devices will test for a connectivity to http://www.msftncsi.com/ncsi.txt
Apple device will use http://captive.apple.com/hotspot-detect.html
And the android/chrome/whatever have their own URL as well.

Btw : http is used and that's ok, there are no security issues as close to nothing is send to the server - the traffic will never even reach the remote server, as it will get redirected and intercepted by the pfSense portal web server : traffic will never leave your site.
If you use a https captive portal login page, the portal page traffic is encrypted using TLS 1.2 so your very secret captive portal password ( 😊 ) is also very well protected, even if the traffic goes over an open (non WPA) encrypted wifi radio channel.

Back to you Chrome issue :
Check if DNS works on the pfSense side : if the resolver is listing on captive portal interface.
Check if DNS traffic is handled by pfSense.
Check what the chrome book is sending ; Status > System Logs > System GUI Service

Have a look at the captive portal firewall rule :
See /tmp/rules.debug : and look for the word "portal" - there are several rules.

It seems to be solved by putting the configuration page in English. If you do it that way it worked for me, it seems to be an error with the translation of the "Bold" "From" and "To" options. If you enter them in English, the rules seem to work.
link text

@exotic69 said in Captive Portal don't block HTTPS Site:

wifi public

Comme moi : un accès wifi pour le client de notre hotel.

Et comme j'ai dit plus haut : pas de MITM pour moi. Je ne cherche pas à savoir ce qu’ils font les gens avec leur connexion. C'est privé. Et c'est vrai, en cas d'abus, c'est le 'patron' qui va en prison, car c'est lui, la responsable de la connection, c'est lui qui doit répondre en cas de requête de la part de "hadobi", etc. mais, depuis 2001 ( ! ) je partage notre connexion Internet avec nos clients de l'hôtel, jamais eu des problèmes.
Probablement lié au fait que j'ai partagé 18 Mega octets/seconde (ADSL) (en 1 Mo/sec en émission) donc rien va très vite. Ca a changé depuis janvier dernier : 1 Go symétrique fibre : youpi.

Le certificat : nous sommes une société, j'ai donc quelques noms de domaines (chez OVH bien sur). Un nom de domaine est réservé pour l'usage interne - notre LAN de pfSense.
Je loue donc "my-hotel-brand.net" : un dot net, c'est env 14 € par an.
Car j'ai un nom de domaine 'à moi' je peux donc utiliser le pfSEnse package pour qu'il me donne un certificat, je demande carrément un wildcard "*.my-hotel-brand.net" donc le certificat obtenu fonctionne pour
pfsense.my-hotel-brand.net mais aussi pour
portal.my-hotel-brand.net (le portail captive de pfSense)
et aussi :
imprimante.my-hotel-brand.net, nas.my-hotel-brand.net et clim.my-hotel-brand.net etc etc, toutes mes appareils dans mon LAN qui ont un GUI et je peux maintenant les accéder par un https://....
Après tout : l'accès "http" est à bannir partout où c'est possible, le http fait partie du passé.
Typiquement, seule les requetés DNS passent encore en clair.
Sache que les clients qui ont un truc à cacher 😉 activent leur VPN dès qu’ils ont ouvert l’accès avec le portal captive. Tout le monde le sait d’ailleurs ; si t’es pas chez toi, après la connexion : active ton VPN. Et voila une autre raison que ‘MITM’ ne fonctionne pas.

Le fait d'avoir un certificat signé par Letsencrypt m'assure que mes clients peuvent se connecter sur notre portail avec un URL comme "portal.my-hotel-brand.net" sans aucun message d’alerte - sans qu'un IP comme "http://192.168.2.1" s'affiche.

Si t'es pas loin de Lot et garonne (47500 Fumel) : viens voir 😊

@exotic69 said in Captive Portal don't block HTTPS Site:

ça va être plus simple en français (si j'ai le droit)

Pas une question de droit, mais de 'logique'. Un forum anglais 'pollué' de russe, chinois et égyptien n'est guère utile pour personne. Même Google va plus comprendre.

C'est mieux de continuer ici : Home > pfSense > International Support > Français.

@Christopher87

Even after reading this : Troubleshooting Captive Portal ?

@nourgaser

Uncheck ?
I've set it :

4b40d34c-6eef-4237-8df2-5548b292ee49-image.png

as this check box does this :

/etc/inc/captiveportal.inc :

70aeb364-b2f8-4b36-9177-814f1662c094-image.png

which means "$cpentry[7]" gets used, and that's the value obtained from Radius.
Note : "$cpentry[7]" == "/* hard timeout or session_timeout from radius if enabled */"
Not setting this checkbox it means it will use the captive portal 'master' hard timeout value :

a6f8d9cc-2732-4214-968b-bc746a354a23-image.png

IMHO : "$cpentry[7]" == is the radius equivalent of a hard (seesion) time out.
"$cpentry[8]" is the soft (idle) timeout.

@sceptre357

Yeah, that looks plausible.
Something typical that wasn't tested like that.

So : easy to remove the issue : switch "Use custom captive portal page" off.
Save !!
Now, remove everything under "Captive Portal Login Page", as it is visible now.
Save !!
Activate (check) "Use custom captive portal page", add the files, feautes and stuff you want.
Save.
Done.

Some one should redmine this (no me, as I have to do the tests to chow case the issue, Ive no time right now 😊 ).

@sambu Try running radsniff -x from the console, try and auth, might give you a few more hints.

@sceptre357 said in Missing "Last Activity" for portal users - Idle timeout not working:

Why does this happen? Is this a known bug?

Hummm.
Shouldn't happen.

Long story short :

[23.09-RELEASE][root@pfSense.bhf.tld]/root: ps ax | grep prunecaptiveportal 3852 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1 4060 - I 0:00.86 minicron: helper /etc/rc.prunecaptiveportal cpzone1 (minicron) 97982 0 S+ 0:00.00 grep prunecaptiveportal

This says : the portal is 'pruned' every 60 seconds.

This is the prune function : captiveportal_prune_old()

Your situation is handled here : in this function. If traffic is 'not known' (zero) the "Last activity" (a time stamp) can't be determined. In that case, the "Session start" time/date is taken, the timeout value (soft time out or hard time out) is added, and that's the 'prune' time. If this prune time is smaller as the actual time, the user is disconnected.

Btw : what is the DHCP lease time for your captive portal ?
How many potienta portal devices ?
How big is the DHCP pool size ?
If a devices looses the lease, as it went away for the day, and came back the next day, and the lease (IP) was already assigned to another device at that moment, the portal starts to loose track of who is what when etc.

edit :

You don't see these "IDLE TIMEOUT" lines :

939affe0-3e4b-4d2c-abaf-1a0fdbbb9d0e-image.png

@sceptre357 said in Missing "Last Activity" for portal users - Idle timeout not working:

im using the "Idle Timeout" to clear

You've set the Idle timeout set to something like this :

c2495265-99e5-4faa-b18c-4bd669d76c66-image.png

What is the value you have set ?

@jarlel said in Captive Portal, MultiWAN and routing:

but unfortunately I don't see a way to assign different policys to different
accounts.

I'll see what I can find - gime a couple of days though, as this means some serious Googling.

@John-3 said in Captive Portal on 2.7 not redirecting to login page:

For starters DHCP Works fine and the client does get IP/Gateway and all the information from the DHCP Server.
I've already tested that dns answers my queries with pinging random addresses which of course doesn't reply to my pings because i haven't authenticated yet but resolves the addresses to Ip's and as i've mentioned if i enter the portal login page manually then everything works fine!

Ok. Good to know, and now this is out of the way, let's continue.

I'm using pfBlockerng, so I have a file I can use to test if DNS works :

If you haven't, switch the resolver to "Level 3" (query level) on the Services > DNS Resolver > Advanced Settings, and then Save + Apply.

I use

tail -f /var/unbound/var/log/pfblockerng/dns_reply.log

you can also use (I didn't test but sur ethat DNS requests will show up - do not forget to undo this "Level 3" setting as it will produce a huge log file) :

tail -f /var/log/resolver.log

As soon as I connect my 'iPhone' to the portal, before a browser pops up on my phone, showing the login page, I saw a lot of (20+) DNS requests flying by.
This is what I just saw :

...... DNS-reply,Nov 22 11:52:03,reply,A,CNAME,30,captive.apple.com,192.168.2.35,17.253.109.202,FR .....

This was the the OS of my phone that emitted a http (not https !!) request to a known web server (from Apple of course) and my device does this because it wants to test (all devices do this these days) if it can reach a 'test' site available on the internet.
Click to see the test.

This was my iPhone 'calling home' 😊
Androids don't call to apple, they use some other site.
Same thing for Microsoft device, they use a xxxx.microsoft.com http site.

If the resulting page contains the word (in my Apple case) 'Success' then the device knows it has a direct (non portal !) connection to the Internet. This is by far the most common case.
If it doesn't, (something else came back) then the device knows that a captive portal might be present.
It will fire up a 'browser', and repeat the same request.
On the pfSense side of things, a http request "with destination port 80 (http)" will get redirected by a captive portal firewall rule. To something like http://a.b.c.d:8002/xxxxxxx

Now, welcome that nice feeling : you start to understand how a portal works, that a 'captive portal' isn't actually a pfSense thing, but a BJOD device thing.
pfSense uses a rather simple firewall rule - and a web server to show a web (login) page if requested. Most of the heavy lifting is done by your device.