@gertjan said in Captive portal, certificates and chrome-Edge: @jperezme said in Captive portal, certificates and chrome-Edge: When I connect via Wi-Fi to the captive portal, it automatically opens the browser, Using what URL ? Before i got http:\172.30.0.1 but then i have added portal.mydomain.local on host overrides in dns resolver. A final solution would need a real domain name (you have to rent one). Then use the pfSense acme package, and get certificates for free, these will be accepted by any browser. This solution is not needed when you as the admin visit the pfSense https GUI ones in a while. You know why and what to do. But if you use a captive portal and you want to use the https portal access, you have to have a certificate that is trusted 'out of the box' by everybody, as you can't ask to everybody upfront "whatever you see when you connect to our wifi, accept it". Why would they, the unknown to you portal users, trust you ? Forgive my ignorance, but I don't understand how I can configure an external domain for my captive portal to work if my local network is internal.

Not yet, we are still looking at this.

@iahmad Why would a user want to type in that URL ? The (a) captive portal is detected by every OS these days. I use the captive portal for a hotel, and I do not publish any URL, an certainly not an IP based URL. Still, everybody can login without any assistance from me, or some printed help. I use https://portal.hotel.tld as the URL that points to the IPv4 of my captive portal interface. I have to own (rent actually) the domain hotel.tld so I can get a certificate that is trusted by every browser and every device. All OSs these days do a hidden http (not https) request to a know URL that should return a page that says "Succes". If it doesn't, it kicks of the default browser with the same URL again. The web request gets intercepted a second time, and the result will be the default login page. The user can interact with that page : he/she can login. For all this to work : You use https : you need a certificate signed by a trusted source (ie Letensrypt). Otherwise most browsers, if not all, will just don't want to load the page. DNS on the captive portal interface should work. On the Services > DNS Resolver > General Settings page I declared a Host Override : Host : portal Domain : hotel.tld IP : the IP of the captive portal Nothings stops you from declaring something like : Host a Domain b.c So know the user can type in https://a.b.d:800x/index.php?zone=yourzone The "index.php?zone=cpzone1" part can't be "shortcut".

@skilledinept A 'captive portal' needs a IPv4 IP and network - and a running DHCP server for that interface. Unbound needs to listen on that interface. Because you use VLAN : the device at the other end of the 'LAN' cable (over which the VLAN "5" is running) need to handle VLAn's and set up to sift out this VLAN5. That could be your AP's), or, by default, a VLAN capable smart switch.

@07stuntar1 The 'portal' should have access to the clients IP and MAC as these two determine what client has access. So L2 ok, not L3, as a down stream router would hide the IP and MAC. The client should use the DNS of pfSense. @07stuntar1 said in Captive Portal over L3 link: Currently when enabled the captive portal cuts off network access to the client. That's what a portal does. A portal interface is typically a second or third LAN type network to which non trusted devices can connect. Most, if not all, devices these days detect the portal, and the login page will auto load. DNS should work to make this happen. https access is advised.

@esojmc https://docs.netgate.com/pfsense/en/latest/captiveportal/index.html#not-capable-of-reverse-portal A reverse portal, requiring authentication for traffic coming into a local network from the Internet, is not possible.

@Gertjan @free4 The radius server is served via the internet. Its not LAN based. Does that matter? Re authentication does not take that long at normal operation.

@sujith34 said in Captive Portal Voucher PDF & QRCode Generator webservice: knobelbecher.net has already site issues to works on .... Solutions that 'hook' into pfSense directly are always doomed to be abandoned.

@amitaussie any solution ?

@mohamed-elkhateeb Has been published here on the (this) forum. Sorry, my search button is out for the day. edit : and repaired. Here it is : #!/usr/local/bin/php -q <?php /* Disconnect all clients on all captive portal instances */ require_once("/etc/inc/util.inc"); require_once("/etc/inc/functions.inc"); require_once("/etc/inc/captiveportal.inc"); global $g, $config, $cpzone, $cpzoneid; /* Are there any portals ? */ if (is_array($config['captiveportal'])) { /* For every portal (cpzone), do */ foreach ($config['captiveportal'] as $cpkey => $cp) /* Sanity check */ if (is_array($config['captiveportal'][$cpkey])) /* Is zone enabled ? */ if (array_key_exists('enable', $config['captiveportal'][$cpkey])) { $cpzone = $cpkey; $cpzoneid = $cp['zoneid']; captiveportal_disconnect_all(); } } ?> Place the file with extension php in, for example, /root/ Make a cron entry like [image: 1638531129957-59ff7d41-7aca-437c-82ac-c241dfa27e20-image.png] Pick time entries as you wish. "pkg_check.php" must be the name of the file you created above. Start by installing the pfSense cron package.

@gertjan said in Pfsense captive portal does not show on IPhone !!: They don't care about de local castle from the 14 century. heheh - I don't know when I was on business trips my favorite part was taking in the local history and stuff to do. This was mostly the local tavern ;) But still - hehehe I spent a bit of time in Tulle on multiple occasions.. I had a couple of fav watering holes there.. One of my favorite spots was a little place tucked away on a side street, loved to sit outside and just watch the people going about their business and enjoy a few beers.. It was across from the cathedral there, and believe that was from the 14th century ;)

@gertjan thank u man, for your reply...i'll see with dev team if we can work on it beacause i´m just the infra guy and maybe i´m doing the wrong questions...

Xiami devices ? You mean Xiaomi devices ? These are based on the Android OS, right ? So, they should work. I see the connected don my captive portal.

@kelvinmurik Correct. "mysqli" requires "mysqli" support, which is different from the older "mysql" (-connect) library.