@michmoor @Gertjan

Thanks for the answers, it's clear.
However, while you still have squid in the PFSense 2.7.2 package, I would like to continue using squid, in the meantime I gain time to think about something or leave it without squid and follow the recommendations.
As there is still squid in the package, is there no rule I can apply to block 443 HTTPS access before authentication on the captive portal?
thank you all

@jenyabutakov said in Wireguard and Captive portal:

@Gertjan thanks!
It is definitely a shift to a positive direction. Now this error (noclientmac) has gone, but I still have no redirection to portal page.

PS: Tested the same with LAN interface - working like a charm

@yogendraaa it seems issue is related to FreeBSD (Maybe) not only Nginx but the queues from NIC also have issue. with 2.6 as i mentioned all okay. but same hardware switching to 2.7.2, got CPU0 @ 100% which slow down everthing & then 502 & 504 errors occur. I am specific to Captive Portal implementation. attached image for reference.
platinum issue.png

Thank you for your help.

Digging a bit deeper and watching what is actually going on, it turns out the issue might not be what is being reported by our users.

A reboot seems to have settled things down, but while watching what happens during a time when users should be getting disconnected shows an odd behaviour....

At 21:45, a bunch of students had access switched off through AD Radius. What is happening is that only one user out of the bunch gets disconnected approximately every 10 seconds, even although the changes to their account in AD were all made at the same time.

The logs for Authentication...Captive Portal Auth near the time when the last of the users being disconnected looks like this.....

Feb 6 21:59:28 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user137, da:dd:f4:f7:db:XX, 172.10.7.77
Feb 6 21:59:18 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user143, 5e:57:bf:01:bd:XX, 172.10.7.137
Feb 6 21:59:09 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user125, ee:fe:dc:b5:f0:XX, 172.10.0.62
Feb 6 21:59:00 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user920, fa:46:4e:f5:8b:XX, 172.10.7.3
Feb 6 21:58:51 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user027, ba:9a:fa:6f:d2:XX, 172.10.6.134
Feb 6 21:58:42 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user126, f2:0f:33:86:86:XX, 172.10.0.145
Feb 6 21:58:33 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user158, d2:fc:85🆎d4:XX, 172.10.8.93
Feb 6 21:58:24 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user941, 0a:e4:5f:fa:d8:XX, 172.10.6.12
Feb 6 21:58:15 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user048, 52:e6:00:7d:97:XX, 172.10.0.135
Feb 6 21:58:05 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user231, ea:04:0d:80:09:XX, 172.10.1.98
Feb 6 21:57:56 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user193, aa:4e:7e:c1:4b:XX, 172.10.7.15
Feb 6 21:57:47 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user159, 2e:8f:c0:63:f6:XX, 172.10.7.113
Feb 6 21:57:38 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user079, 2e:f8:4f:7b:4c:XX, 172.10.0.16
Feb 6 21:57:29 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user797, da:d8:50:ad:73:XX, 172.10.6.178
Feb 6 21:57:20 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user153, fa:49:df:d4:23:XX, 172.10.0.220
Feb 6 21:57:11 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user841, f6:e5:29:59:94:XX, 172.10.7.71
Feb 6 21:57:02 logportalauth 45147 Zone: captiveportal - DISCONNECT - REAUTHENTICATION FAILED: user101, 9e:85:cf:5f:fb:XX, 172.10.7.107

As you can see there is approx. 9-10 seconds delay between each DISCONNECT.

Then, only after all of the users who should have been disconnected at 9:45 are actually disconnected, does the CP report the correct number of users still connected.

Does anyone know if this is by design? Or am i missing a setting somewhere?

I found the issue is related to http://connectivitycheck.gstatic.com/generate_204 being blocked on PFblocker. I heard I can make my own 204 page and redirect devices to that. I am not sure on the best way to go about doing it.

@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.