Captive Portal - Cron - Authentication issues

uggiz

Hi! I have a Netgate 7100, running pfsense 23.09.1. I have setup a Captive Portal, Freeradius for authentication/traffic quota, and Cron to reset/delete the used-octets files once every 24 hours (Quota is 1gb pr. 24hours) This works fine until the cronjob runs, then the freeradius needs to be reset for the used-octets files to regenerate and allow the users to login. What am I doing wrong?

Gertjan

@uggiz said in Captive Portal - Cron - Authentication issues:

then the freeradius needs to be reset for the used-octets files to regenerate

According to the cron, it just deletes all files that start with "used-octets-*" in the "/var/log/radacct/datacounter/daily/" folder.

Mine are deleted at noon every day :

I have a test user with login 'x' : after :

I found these two files in the /var/log/radacct/datacounter/daily/ folder :

Where "used-octets-x" contains '0' and "max-octets-x" contains "1048576000" == 1000 Mbytes.

You saw the "Accounting Interim Interval" ? It's set to 600 so the captive portal (a freeradius client actually) should consult (update) FreeRadius server every 600 seconds, and while doing so, it also send the used octets for this user.

These are my Captive portal's settings related to Freeradius :

Among others, the Interim mode is selected (because needed).

After 10 minutes or so, the content of my "used-octets-x" was still "0", but a new file was created :

and extra user x session file contains the number of octets used up until the last interim update.
This "used-octets-x-a4c3749d490ab69a" exists as a user can have multiple portal session open.
AFAIK, these "max-used session files" are added to the main "used-octets-x"when the session stops.

See also : /usr/local/etc/raddb/scripts/datacounter_acct.sh ( and also /usr/local/etc/raddb/scripts/datacounter_auth.sh

According to /usr/local/etc/raddb/scripts/datacounter_acct.sh, when I stop my portal sessions, because of a soft tie out, or hard time out, or a admin disconnect, the "used-octets-x-a4c3749d490ab69a" will get added to the "used-octets-x".
And it did : I stopped the 'x' user session, the "used-octets-x-a4c3749d490ab69a" was gione, and its content was added to "used-octets-x".

FreeRadius itself will handle, also during the interim update, the case of IF ("used-octets-x" > "max-octets-x") THEN "disallow connection" => the over quota event happened.

As the "used-octets-x" gets deleted every day, and the "/usr/local/etc/raddb/scripts/datacounter_acct.sh" script will create it on every interim event, counting just continues, comparing with max quota goes on.

To see all this happen in front of your own eyes :
Stop FreeRadius on the pfSense dashboard.
Open a SSH or console, use option 8.
Type :

radiusd -X

and observer what happens. Don't worry, it will all make sense after a while (took me months ...).
( yep, you wanted FreeRadius, now you see FreeRadius )

uggiz

@Gertjan
Thank you for the reply, your setup looks similar to mine, but I will review some of the settings and see if there could be an issue with some of them.

But I have a question about a setting in the FreeRADIUS setup, the "Client IP Address" should this be 127.0.0.1 or should it be the IP of the interface on the Firewall?

Gertjan

@uggiz said in Captive Portal - Cron - Authentication issues:

the "Client IP Address" should this be 127.0.0.1

My portal interface is 192.168.2.1/24 (192.168.1.1/24 is my LAN).

So I set it to :

because that is what the portal video's told me to do : https://www.youtube.com/@NetgateOfficial/videos

edit : btw : 127.0.0.1 might work, I didn't test that.

uggiz

@Gertjan
I tried setting all ip`s to the portal interface (same as you did), and it looks like things are working so far.

But when I have a look in the shell using the radius -X command I see an error in the log:

Have you seen this before? Is there a setting I'm missing? Have done some searching in forums, but I can`t seem to find much about it, other than it can have something to to do with VPN. (VPN is not setup in my system)

Gertjan

@uggiz

Don't worry about that one :

I'm seeing it also .... for a decade or so ^^

uggiz

@Gertjan
Things were looking good up to the cronjob running, then the problem returned.
I setup the cronjobs according to a tip in this forum somewhere, but I am starting to wonder if the max-octets-* should be there?

Gertjan

@uggiz said in Captive Portal - Cron - Authentication issues:

but I am starting to wonder if the max-octets-* should be there?

The max-octest-.... files shouldn't be deleted.
They are created when pfSense creates the config of FreeFradius when it starts FreeRadius. And only at that moment.

I'm curious : who/what (where ?) told you to wipe these 'max' files ?

All is is very 'AFAIK' of course.

edit : https://forum.netgate.com/topic/155445/freeradius-daily-reset-using-cron

I thought it was a simple question : where did these 3 cron liens come from ? Didi I put them there ? (back in 2014 or even before ?) Was I told to create them ? Even Google can't show me anything useful.

Maybe this : before using FreeRadius, I watched the 3 (?) Netgate pfSense Freeradius Videos (Youtube Netgate channel) as these are not 'optional' (Radius is and stays no easy to master). I'll advise you to do the same.
Since then, I use pfSense FreeRadius for the portal authentication and accounting. It just 'works'.

uggiz

@Gertjan said in Captive Portal - Cron - Authentication issues:

I'm curious : who/what (where ?) told you to wipe these 'max' files ?

That I don`t remember, it could be that I just assumed that all files in the folder should be removed.

But anyhow, thanks to your expertise the system seems to be working as it should.

You dont happen to know if its possible to get a "Quota used" message when the users gets logged out? Now they only get a authentication failed message.

Gertjan

@uggiz said in Captive Portal - Cron - Authentication issues:

its possible to get a "Quota used" message when the users gets logged out?

A browser getting a none solicited message from a web server with info ?
Noop. Never seen that before. Browers can connect to web server, get the file (page) they are looking for, and bye bye the connection.
It is possible to have a "logout" or "you are connected" browser windows open, and have that windows load some Jave stuff that questions the current status. if it was possible to get the "max allowed" and "current" bytes used .... but .....

See for yourself :

#!/usr/local/bin/php -q
<?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 for all zones */
        $count_cpusers = 0;
        /* Is portal activated ? */
        if (is_array($config['captiveportal']))
                /* 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 */
                                        $cpdb = captiveportal_read_db();
                                        foreach ($cpdb as $cpent) {
                                                print_r($cpent);
                                                echo date("m/d/Y H:i:s\n", $cpent[0]);
                                        echo "---------------\n";
                                        }
                                }
?>

Create a file called /root/cap.php and put the above content in it.
Now call it :

php -q /root/cap.php

and you see : no 'used' info is avaible in the pfSense portal session database.
The max quota is :

[traffic_quota] => 104857600

= 100 Mbytes in my test case = Ok.

Ok ... you could, on the web server java side, get the max and used info from these files directly.

Another info source is :

as the main log will be bombarded with these message (imho : they do not belong there - call me and I'll tell you how to ditch them).

edit :

Another way to have the user have page where you control the info :
Have seat-belts ? Put them on.
Read this close the initially irrelevant forum thread : captive portal is not working on mobiles
But in that forum thread I discovered something : the future of the captive portal ( ! )
It already exist, and you add it easily.
One condition : don't use KEA as your DHCP (portal ) server, you have to use ISC. because you have ti create a DHCP option for the HCP portal server.
Instructions are present in the forum thread.
You need to create one file (content of this file : see thread):

and now, if you have an Apple device, you can test : connect to the portal - and notice is connects faster - and when connected, tap on the SSID of the portal, and you'll see something new.
Open the new suggestd link called "Portal" and the text "This network proposes a portal page".
The page you now open - the "You are connected page" is the future "portal status page".
Btw : I've also see (real) Samsung devices using this new RFC 8910. Others devices : dono ...

Why I'm telling all this ?
The page you saw is created here :
/usr/local/captiveportal/index.php
That where uyour changes go with the info you want to show - if the user wants to see it (and if they know how to request the info, because again, this is "portalling" as it will be done in the future ...)

Btw : I've this method running for several month now. Works great. Doesn't interfere with the existing capture method at all, it completely bypasses it. The device will know where to go as soon as DHCP request has been answered. No more DNS hassle, web interception. Just plain KIS.
Read the RFC and you'll get the picture.

edit : sorry : I went way to far again / was ranting. Sorry.