@kramtw the reason : the captive portal can't redirect HTTPS redirection to the login page ( ..because HTTPS has been designed specifically to prevent that) Because nowaydays users don't browse non-https website anymore, captive portal detectors are essential. I woudnt recommend fooling mini web browser, because it will make all non-technical user complains about "the wifi isnt working". Instead, i would recommend you to debug why isnt your ad working on the browser Some interresting clue : https://divideandconquer.se/2017/01/26/limitations-of-apple-ios-captive-portal-web-browser/

@free4 Hi Augustin. I apologize for the delay but I have been quite busy. I created a test firewall and tried to apply the patch, but in testing (before installation) it gives me these errors. PfSense 2.4.4p3 Patch Test Output apply /usr/bin/patch --directory=/ -t -p2 -i /var/patches/5e2ab70eea69c.patch --check --forward --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: |diff --git a/src/etc/inc/auth.inc b/src/etc/inc/auth.inc |index 4139ad22b46..35e9e46ddae 100644 |--- a/src/etc/inc/auth.inc +++ b/src/etc/inc/auth.inc Patching file etc/inc/auth.inc using Plan A... Hunk #1 succeeded at 1370 (offset -1 lines). Hunk #2 failed at 1963. 1 out of 2 hunks failed while patching etc/inc/auth.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/etc/inc/ipsec.auth-user.php b/src/etc/inc/ipsec.auth-user.php |index 71ed2b6bcbc..cfd48cfc24d 100755 |--- a/src/etc/inc/ipsec.auth-user.php +++ b/src/etc/inc/ipsec.auth-user.php Patching file etc/inc/ipsec.auth-user.php using Plan A... Hunk #1 succeeded at 49 (offset -2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/etc/inc/openvpn.auth-user.php b/src/etc/inc/openvpn.auth-user.php |index 6bb059a458e..abd9accf92a 100644 |--- a/src/etc/inc/openvpn.auth-user.php +++ b/src/etc/inc/openvpn.auth-user.php Patching file etc/inc/openvpn.auth-user.php using Plan A... Hunk #1 succeeded at 51 (offset -2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/diag_authentication.php b/src/usr/local/www/diag_authentication.php |index 6bd0789441d..5ef3db69553 100644 |--- a/src/usr/local/www/diag_authentication.php +++ b/src/usr/local/www/diag_authentication.php Patching file usr/local/www/diag_authentication.php using Plan A... Hunk #1 succeeded at 38 (offset -2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/guiconfig.inc b/src/usr/local/www/guiconfig.inc |index b3b21dfdfee..00cb98b0e53 100644 |--- a/src/usr/local/www/guiconfig.inc +++ b/src/usr/local/www/guiconfig.inc Patching file usr/local/www/guiconfig.inc using Plan A... Hunk #1 succeeded at 142 (offset -2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/system_authservers.php b/src/usr/local/www/system_authservers.php |index 21d107ec03a..b68283f5ab6 100644 |--- a/src/usr/local/www/system_authservers.php +++ b/src/usr/local/www/system_authservers.php Patching file usr/local/www/system_authservers.php using Plan A... Hunk #1 succeeded at 159 (offset -2 lines). Hunk #2 succeeded at 332 (offset -5 lines). Hunk #3 succeeded at 765 (offset -6 lines). Hunk #4 succeeded at 989 (offset -5 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/wizards/openvpn_wizard.inc b/src/usr/local/www/wizards/openvpn_wizard.inc |index 5223ec8bad6..0a20b06f908 100644 |--- a/src/usr/local/www/wizards/openvpn_wizard.inc +++ b/src/usr/local/www/wizards/openvpn_wizard.inc Patching file usr/local/www/wizards/openvpn_wizard.inc using Plan A... Hunk #1 succeeded at 479 (offset -14 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/wizards/openvpn_wizard.xml b/src/usr/local/www/wizards/openvpn_wizard.xml |index e5d154a4693..30649a9cd2c 100644 |--- a/src/usr/local/www/wizards/openvpn_wizard.xml +++ b/src/usr/local/www/wizards/openvpn_wizard.xml Patching file usr/local/www/wizards/openvpn_wizard.xml using Plan A... Hunk #1 succeeded at 302 (offset -2 lines). done

@Gertjan thanks

Hi, Normally, trusted devices do not belong on a captive portal. Read also https://forum.netgate.com/topic/149514/intergrating-pfsense-with-a-payment-system ( use the PHP page/file Services > Captive Portal > CPZONE W MACs ) to add MAC's by your own script file.

@Gertjan thanks and noted sir!

thanks @Gertjan!! Sort of figured that out after posting. Made a custom captive-portal suit, which I'm going to put that in github, for anyone likes to replace the stock pages.

hi, I finally made a patch for it ! I am now looking for testers (even if you are not using High Availability). Could anyone install this patch on a development Server (2.5.0) and give me some feedback? Here is how to install it : Install the patch package Create a new patch. In "URL/Commit ID", enter https://patch-diff.githubusercontent.com/raw/pfsense/pfsense/pull/4150.diff . Let the default settings in the "Patch Application Behavior" section (Path Strip Count : 2, etc...) Fetch and apply the new patch. After installing, reboot your pfSense. After installing the patch, if you wish to use High Availability for captive portal : Configure High Availability normally using System->High Avail. Sync menu. Configure XMLRPC sync on the primary node only, as it would be done for a normal configuration on the secondary node, please go to Services->Captive Portal->(your zone)->High Availability and configure backward synchronization. How it works / Behavior When using HA, In normal situation (both nodes UP), captive portal users and vouchers are synchronized between nodes. If the primary node become unreachable, secondary node become master and continues to run the captive portal If the primary node switch back from backup to master, it tries to refresh connected users from the secondary (and now backup) node. If the secondary node leave then re-join the cluster, users will NOT be synchronized on the backup node. Users have to be manually synchronized from Captive Portal->Your CP zone->High Availability in such situation. What this patch is NOT / Limitations This patch aims to sync connected users, and in-use/expired vouchers. Allowed IP addresses/hostnames/MACs synchronization are out of scope. This patch is designed to handle a failure from the primary node, not from the secondary one. Because of the very way HA is implemented on pfSense, a failure on the secondary node would have some bad effects for the cluster. In the case of the captive portal, the effects would be some slowness when performing an user (dis)connection. This issue is not specific to captive portal, and is due to how how XMLRPC sync works in pfSense. The workaround to this issue is to manually un-check Captive Portal in HA settings when secondary node leaves the cluster. RADIUS accounting also works fine with HA, but per-user data consumption is not synchronized between nodes. Developer notes / technical info This patch implement a new XMLRPC endpoint, pfsense.captive_portal_sync. It was necessary to implement this endpoint because of bi-directional synchronization (using pfsense.restore_config_section is causing many problems, such as triggering a DHCP server restart every time an user get connected) Please don't hesitate to comment if you have questions/feedback to share !

@free4 i really appreciate your effort on this !

@chanrio13 please read my previous post I am myself using the captive portal in a multi wan configuration ...so..it's already supported

@rm I do see two"system_generate_nginx_config" nested ifs...

If its yours - I might steal it, I like it a lot ;) But it would sound better if said in French I think ;) Love to use it on a call when dealing with some of my French speaking colleagues ;)

@free4 thanks alot for this applying this patch has solved the issue https://github.com/pfsense/pfsense/compare/RELENG_2_4_4...Augustin-FL:fix-reconfig-for-2-4-4.diff

Hello sir @Gertjan, thank you so much. I it works really great. It saves my day :). VERY MUCH APPRECIATED.

sir @free4 thank you so much. Thumbs up

@phdemartin yes, given your usage, pfsense seems to not be the appropriate captive portal tool for your usage. pfsense does not support cross-vlan captive portal I would recommend you to look into other appliances dedicated to captive portal (such as PacketFence)

@Gertjan: Thanks, I'll try!

Are the devices that are going to use this captive portal under your control where they can bet set to trust your CA? If not this is good use of ACME certs.. Your own CA only makes sense when you control the devices that will be accessing the sites using certs signed by your CA. And yeah the mentioned new 825 day limit can bite you if your certs are newer..

@heper Faced this. There is user user1 who has access to the portal through the group Active Directory. So, if the browser’s registration page doesn’t enter the password, the user is successfully registered on the portal. On pfsense Diagnostics \ Authentication everything works correctly. What's wrong?

@virusbcn Instead of routers you could use vlans and managed switches. You can have all vlans coming in to pf (cluster?) and assigning them different subnets With one subnet assigned to each appartment its easier to log things. Otherwise, hunting mac addresses will become a nightmare. (unless you have an onboarding procedure where macaddresses are "let in" (and then you have win10 changing mac addresses randomly, for "security") So its dhcp and pflogs, probably logged to an external syslog.

@Gertjan Hello, could you give me an example php, I am not really an expert in php and html, tried in all cases and I can not get it. I look forward to your help. Thank you.