@stephenw10
fantastic it works perfectly!
then ... in CP ALLOWED HOSTNAMES I added the destination www.salini-impregilo.com
in freeradius I removed the e.tomei user
in / var / log / radacct / datacounter / daily I have eliminated max-octets-e.tomei and used-octets-e.tomei
in freeradius the user was recreated with a 10IMG_2362_resize.JPG Mb quota

I am attaching some screenshots they are not well ordered but they serve the purpose

first test with a virgin phone
access to wifi-koysha OFFICE without entering credentials
the salini-impregilo.com website is perfectly accessible and accessible

second test with the same phone
I opened the android alert and completed logging into the SSID
I opened youtube and started a video ... which after 61 seconds stopped ... with 3Mb of share quite difficult
I reopened www.salini-impregilo.com and I can consult it and open the links within the domain!IMG_2356_resize.JPG IMG_2357_resize.JPG IMG_2358_resize.JPG IMG_2359_resize.JPG IMG_2365_resize.JPG IMG_2366_resize.JPG IMG_2364_resize.JPG

Yes you can still use Stripe payments, however, it has changed and you will have to click a box in your Stripe account to make it work. The tick box is you agreeing to be fully liable legally and financially for the unencrypted untokenized credit card details that you are passing to them, and thus you are taking on the full force of the compliance regulations.

If you are setup to do this, or are happy to pay a lot of money to make it happen, it will work.

Both Paypal and Stripe give you options that allow you to send the user to put credit card details directly on their sites thus removing any handling of credit card information by you. Unfortunately the Unifi system has not been updated for a long time and I wouldn't hold my breath on it.

I have looked at combinations of pfsense, coovachilli, freeRadius, with openwrt firmware and openwisp for management, but this time round I am now too short of time. Maybe work towards the next one . . .

@kiokoman said in Missing 29 February:

with squid and captive portal installed

Some how, it was pretty sure that @ilarioQ isn't using the captive portal.
He is probably ( ;) ) using DNS, so he could have post it's question also in the DNS sub forum ... or DHCP or ....
Anyway, not an issue.

It's squid that handles the name of its files.

@roundcube222 said in captive portal and no internet after authentication.:

I am using VMware with 2 NIC

Ah.
That just doubles the list with possible issues. And isn't something you should not omit to mention when asking question.
It , a VM, can works of cours,I use a pfSense from a Hyper-V VM, build into Windows Pro right out of the box. I had some virtual NIC issues at first (sound familiar ?), though, at first, mostly because I didn't RTFM first.
If you have a spare drive - some small 10+ Gbytes disk size will do, take the actual disk out of your PC, install the spare (to be emptied) disk into your system, and install pfSense bare-bone, from scratch.
It's worth a try.

Because you know it : it's not pfSEnse, your issue.

And which VoIP provider do you use? I would recommend Hottelecom to you, they have excellent customer support and will help you in all matters.

@newmem11 said in Check duplicate mac function!:

duplicate mac address is detected

The problem isn't "Voucher" in that case.
You've got someone on your network trying to mess things up.

Set the time-out to a higher value. People tend to disconnect / shut down their device every day or so. This will enable OS support to kick in when re activating the connection.

Hi,

Indeed, the captive portal is not compatible with transparent proxy

The reason why all traffic is allowed, is that all incoming traffic is redirected through squid before reaching ipfw

The best way to resolve this issue would be to have to pfsense

One hosting the captive portal and open acting as transparent proxy

Well, for some reason that I can't understand, there was a MAC address on the MAC's bypass list. It was a MAC unrelated to anything but a client device on our network.

All I know is that once that MAC was removed, CP started to work again. The problem is solved, but I'm not fully convinced I about the reasons that generated this problem.

Sir @Gertjan my bad it supposed to posted in in routing and multi wan. Anyway thanks.

@kiokoman thank you sir it works. Re-installed done. Thumbs up sir 👊

Hello, here is my version of the script :

<?php require_once("/etc/inc/util.inc"); require_once("/etc/inc/functions.inc"); require_once("/etc/inc/captiveportal.inc"); /* read in captive portal db */ /* determine number of logged in users */ $count_cpusers = 0; /* Is portal activated ? */ if (is_array($config['captiveportal'])) { //only one zone if(isset($_GET["cpzone"])){ $cpzone=$_GET["cpzone"]; $count_cpusers = count(captiveportal_read_db()); } else { /* For every zone, 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; /* Zone selected -> count users and add */ $count_cpusers += count(captiveportal_read_db()); } } } } echo $count_cpusers; ?>

Here is how i check it with centreon :

#!/bin/bash url=$1 libelle=$2 warningvalue=$3 criticalvalue=$4 if [ $# -eq '4' ] then #get the value value=$(curl -sk $url) # UNKNOWN if [ -z "$value" ] then echo "UNKNOWN - unable to establish the value returned" exit 3 # OK elif [ $value -lt $warningvalue ] then echo "OK - $value $libelle| value=$value" exit 0 # WARNING elif [ $value -gt $warningvalue ] && [ $value -lt $criticalvalue ] then echo "WARNING - $value $libelle| value=$value" exit 1 #CRITICAL else echo "CRITICAL - $value $libelle| value=$value" exit 2 fi else echo "Usage $0 url \"description of the value\" warningvalue criticalvalue" exit 1 fi

this script is used like this :

check_http_value https://10.11.0.1:8005/captiveportal-count-online-users.php?cpzone=captive_portal_r "users connected" 150 200 OK - 127 users connected| value=127

maybe it is possible to improve this with using the $HOSTADRESS$...

and here is the final result in centreon :
c72b9eb7-9918-4ca8-8ebb-dc293d957f71-image.png

@Gertjan

Thank you for this! I am not at home now, but will definitely check this when I return and report in with my findings. Appreciate the assistance.

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