@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. [image: 1702930986144-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 : [image: 1701672932724-4b40d34c-6eef-4237-8df2-5548b292ee49-image.png] as this check box does this : /etc/inc/captiveportal.inc : [image: 1701672993662-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 : [image: 1701673105857-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 : [image: 1701078252476-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 : [image: 1701078347384-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.

@Gertjan Now is more clear for me : have to set the direction thank you ! Direction The direction to allow traffic matching this IP address. From Allow traffic sourced from this IP address through the portal, such as a local client IP address attempting to reach the Internet, or the IP address of a management client that must reach hosts on the portal network. To Allow traffic with this IP address as a destination, such as a local web server IP address that must be reached via port forward, or a remote web server IP address which clients must always reach. Both Allow traffic both to and from this IP address.

@ratcrow said in Captive portal login page not served: because the pfSense DNS Resolver did not seem to be working (is this a clue?). Yes, it the most common failure, see Troubleshooting Captive Portal. Typically, you include in the DHCP lease (server side !) the IP of the captive portal interface of pfSense. This is the case by default. Two conditions must be true : You have to allow traffic 'to port 53, protocol TCP and UDP where the IP is the IP of the captive ortal network. This is the case by default (see my firewall line below). Unbound has to listen to this interface. This is the case by default. @ratcrow said in Captive portal login page not served: I assume that there is a default captive portal page that will just come up and that I don't have to create a custom page to make this work. Exact. @ratcrow said in Captive portal login page not served: My firewall rules are about as simple as can be. It is possible that some other part of my configuration is to blame, but I don't know where to look This is the 'simple one' : only the last yellow line : [image: 1700565429673-95cf4987-eefa-4051-a76b-59ede42c6400-image.png] Afterwards you can add new, more specific 'block' rules above this line.

@Gertjan ok, then it seems things changed and i need to update all MAC settings. Thank You.

@dochy said in Windows RADIUS Server: we are still waiting for that manual please Like these : microsoft nps ? You'll find the Documentation under Additional resources. Remember : this isn't open source and a Microsoft product. Manuals are most probably copyrighted.

@extranjero A pfSense device that doesn't have access to the net ? That means : no dns. You saw the Troubleshooting Captive Portal : the very first "DNS resolution not functioning" will stop you right there. Device connecting to a (wifi) network will trow out a 'hidden' http request, right after the DHCP negotiation. This can be any host name (most are know, though), so DNS needs to work. But you have no WAN ..... So no auto captive portal login page opening. The user could still know that it is connected to a gateway/router, so they could enter http://a.b.c.d (where a.b.c.d) is the IP of the pfSense interface IP. That wouldn't make the portal login page showing up neither, as needed parameters are missing. Using a laptop for such experiments is making your live hard on yourself. Any sub 50 $ old PC, with at least 2 network interfaces will do the job. Throw in an AP, and your good. You can always add some rules on the portal interface that block traffic to the outside world (except DNS, right ?!)

@yogendraaa said in Captive portal making WAN gateway losses in 2.7.0: Please help I'd love to, as soon as I found out how to simulate what '5000' users can do when they discover that they need to logging again, and they all hit the pfSense captive portal web serer to login at the same time Your portal setup is not a, @home version, I tend to say : industrial ? So, good to know you use a Xeon and boat loads of memory, please share more info. For example : Here : /var/etc/ : look for the two files starting with "nginx-", these are the captive portal web server config files. The default worker_processes is "6". The number of max connections is "1000". With these numbers I suspect that their will be some "pushing-at-the-gates" and not everybody will make it. A less scientific approach of 5000 users number : not every device is fully "portal" aware, and will hammer the portal web server without doing an actual login ...... (less aware users makes things only worse ). Add to this : for every established connection, the portal login page wilml get spewed out, and this happens when nginx piped the request to PHP-(fpm), and got the parsed result back. PHP is a lot, but managing a stressed PHPP interpreter is ... a world apart. Take note : I'm not an nginx expert. When that login storm is over, and the firewall tables are all filled up with 5000 IP and 5000 MAC addresses, then these 5000 will generate 1 Mbits / sec per second ? That's already 5 gig .... Don't worry, I get it, even if 5000 portal users are realty connected, far from 5000 are actually active. @yogendraaa said in Captive portal making WAN gateway losses in 2.7.0: WAN gateway showing losses This doesn't say much. Losses = the gateway (WAN) monitoring tool sends a ping every 500 ms and checks if it gets back. If pings get lost, no big deal. If other, 'user' traffic gets lost, that indeed not good. But dpinger (the monitoring tool) can not know that. What does the Status > Monitoring (WAN) show you ? And sorry, I just gave you more questions, not really solutions.