FreeRadius and quotas, doesn't work since 22.05

[marcosm]

@gertjan Maybe there's something different in your configuration - start with just the setup referenced on the redmine link and see if you can narrow down where it breaks for you. Regarding the log, that's specific to the FreeRADIUS package itself. Ideally all of its logs would go into its own package log.

[Gertjan]

@marcosm said in FreeRadius and quotas, doesn't work since 22.05:

start with just the setup referenced on the redmine link

pfSense+ 22.05 => Of course.

Configure Captive Portal on VLAN interface => I'm not using VLANs interface ifgc1 on my SG-4100.

Use FreeRADIUS auth backend => Of course. That what this is all about.

Check Reauthenticate Users, Session timeout, Traffic quota, Per-user bandwidth restrictions
Like :

login-to-view

Enable Send RADIUS accounting packets, select Stop/Start (FreeRADIUS) or Interim

As said, I'm using Iterim updating.

For me, in the function getVolume($ip) (/etc/inc/captiveportal.inc)

	$result = pfSense_pf_cp_get_eth_rule_counters("{$anchor}/{$ip}_32");

always returns an empty array - I test this with an 'else', and log $result ... it's empty.

The parameter "cpzoneid_2_auth/192.168.1.6_32" seems ok to me.

[marcosm]

@gertjan You can see the actual anchors by running "pfSsh.php playback pfanchordrill" - it's returning correctly when I test it here.

I have seen some odd behavior where bandwidth limits are not respected when configured in FreeRADIUS. Details here: https://redmine.pfsense.org/issues/13150#note-16

[Gertjan]

@marcosm said in FreeRadius and quotas, doesn't work since 22.05:

You can see the actual anchors by running "pfSsh.php playback pfanchordrill" - it's returning correctly when I test it here.

Two users are connected :

[22.05-RELEASE][admin@pfSense.mynetwork.net]/root: pfSsh.php playback pfanchordrill
......
cpzoneid_2_auth/192.168.2.161_32 rules/nat contents:
ether pass in quick proto 0x0800 from 14:c2:13:c9:1e:77 l3 from 192.168.2.161 to any tag cpzoneid_2_auth dnpipe 2010
ether pass out quick proto 0x0800 to 14:c2:13:c9:1e:77 l3 from any to 192.168.2.161 tag cpzoneid_2_auth dnpipe 2011

cpzoneid_2_auth/192.168.2.28_32 rules/nat contents:
ether pass in quick proto 0x0800 from d8:8f:76:02:32:87 l3 from 192.168.2.28 to any tag cpzoneid_2_auth dnpipe 2010
ether pass out quick proto 0x0800 to d8:8f:76:02:32:87 l3 from any to 192.168.2.28 tag cpzoneid_2_auth dnpipe 2011

.....

Note that pipes for both portal users 192.168.2.161 (my phone) and captive portal user 192.168.2.28 are identical : 2010 and 2011.
The pipes 2010 and 2011 are shared for all portal users ?

@marcosm said in FreeRadius and quotas, doesn't work since 22.05:

I have seen some odd behavior where bandwidth limits are not respected when configured in FreeRADIUS. Details here: https://redmine.pfsense.org/issues/13150#note-16

Btw : I'm not trying to limit bandwidth.
I use freeradius to set up a 'daily' amount of Mbytes.
From what I understand :
Freeradius isn't questioning pf at all. It calls back the pfSense portal code,
Interim During de 60 seconds update cycle, every connected user status is interrogated, and consumed bytes are returned.
Or, nothing - zero - get returned.
I can go down to this function : getVolume($ip) (/etc/inc/captiveportal.inc) dat doesn't return the array with this info : the array stays empty.
Result : quotas don't work 'for me'.

login-to-view

I know now pf does it's work :

[22.05-RELEASE][admin@pfSense.mynetwork.net]/root: pfctl -a cpzoneid_2_auth/192.168.2.161_32 -se -v
ether pass in quick proto 0x0800 from 14:c2:13:c9:1e:77 l3 from 192.168.2.161 to any tag cpzoneid_2_auth dnpipe 2010
  [ Evaluations: 2488      Packets: 1397      Bytes: 1641623   ]
ether pass out quick proto 0x0800 to 14:c2:13:c9:1e:77 l3 from any to 192.168.2.161 tag cpzoneid_2_auth dnpipe 2011
  [ Evaluations: 1091      Packets: 1089      Bytes: 110482    ]

I can see Packets and Bytes in both pipes = both direction grow rapidly while I do a speed test on my phone = "192.168.2.161".

Then why getVolume($ip) (/etc/inc/captiveportal.inc) always returns zero ?

[marcosm]

@gertjan If you run e.g. print_r(pfSense_pf_cp_get_eth_rule_counters("cpzoneid_2_auth/192.168.2.8_32")); from Diagnostics / Command Prompt // Execute PHP Commands, you should be seeing the data. If not, there's something else wrong. If you do see the counters from that, then you should also see the usage data being recorded (however often you have it configured in FreeRADIUS; default is 600 seconds) in the files under /var/log/radacct/datacounter/ where "max" is the traffic quota and "used" is the currently recorded usage.

Regarding the limiters, they can be shared across multiple clients, and each client will be limited accordingly. You can see them by going to Diagnostics / Limiters or by running dnctl pipe show.

[Gertjan]

@marcosm said in FreeRadius and quotas, doesn't work since 22.05:

If you run e.g. print_r(pfSense_pf_cp_get_eth_rule_counters("cpzoneid_2_auth/192.168.2.8_32")); from Diagnostics / Command Prompt // Execute PHP Commands, you should be seeing the data

Bingo ! Thanks.

login-to-view

With your proposal in mind, I've created :

login-to-view

and executed it.
In the logs, I saw :

2022-08-31 10:54:27.147981+02:00 	logportalauth 	8179 	Zone: cpzone1 - endx
2022-08-31 10:54:27.147946+02:00 	logportalauth 	8179 	Zone: cpzone1 - cpzoneid_2_auth/192.168.2.161_32 - 1006 - 169431 - 1405 - 1573888
2022-08-31 10:54:27.146714+02:00 	logportalauth 	8179 	Zone: cpzone1 - ends

This is promising. Traffic info was shown, using the getVolume($ip) function.

So I tried to find out why function getVolume($ip) regularly called from captiveportal_prune_old() return 'zero' ?

I found it (I'm pretty sure).

Line (around) 673, in the beginning of the function captiveportal_prune_old() :

			$lastact = captiveportal_get_last_activity($cpentry[2]);

gets called and has a side effect : things get zero'd out.

Here : https://github.com/pfsense/FreeBSD-ports/blob/e585da7c980bb3a47b021c597f6160959495a103/devel/php-pfSense-module/files/pfSense.c

		if (pfctl_get_eth_rule(dev, nr, info.ticket, path, &rule, true, anchor_call) != 0)

Parameter 6 = true and this means 'clear' is set. (traffic) Counters get reset !?!

A dirty patch :

//			$lastact = captiveportal_get_last_activity($cpentry[2]);

and now quotas start to work :

login-to-view

[marcosm]

@gertjan It seems like a copy/paste error to me and it should not be set to true. There are other ways that can be triggered though, so I would do this instead as a temporary work around (this breaks idle timeout and anything relying on last activity time):

diff --git a/src/etc/inc/captiveportal.inc b/src/etc/inc/captiveportal.inc
index db66cb8e7c..262a9f26e2 100644
--- a/src/etc/inc/captiveportal.inc
+++ b/src/etc/inc/captiveportal.inc
@@ -1154,7 +1154,7 @@ function captiveportal_get_last_activity($ip) {
 	$cpzoneprefix = CPPREFIX . $config['captiveportal'][$cpzone]['zoneid'];
 	$anchor = $cpzoneprefix . '_auth';
 
-	$active_times = pfSense_pf_cp_get_eth_last_active("{$anchor}/{$ip}_32");
+	//$active_times = pfSense_pf_cp_get_eth_last_active("{$anchor}/{$ip}_32");
 	$time = 0;
 	if (!empty($active_times)) {
 		foreach ($active_times as $active_time) {

[Gertjan]

@marcosm

I can live with the non working Idle timeout, I've also set a hard time, both are the same now.

I've got a bonus for you :

Take a look at how the array $result is filled in :

login-to-view

Now use these commands :

$result = array();
$result = pfSense_pf_cp_get_eth_rule_counters("cpzoneid_2_auth/192.168.2.6_32");
list($output_pkts, $output_bytes, $input_pkts, $input_bytes) = $result;
echo " ".$output_pkts;
echo " ".$output_bytes;
echo " ".$input_pkts;
echo " ".$input_bytes;

Where "192.168.2.6" is the IP to collect data from.

This came back for me :

login-to-view

Element [0] [1] and [6] [7] are 0 and should be discarded.

So getVolume($ip), around line 1691 :

	   list($output_pkts, $output_bytes, $input_pkts, $input_bytes) = $result;

With this :

	   list($discard, $discard, $output_pkts, $output_bytes, $input_pkts, $input_bytes, $discard, $discard) = $result;

Now I can see :

$result = array();
$result = pfSense_pf_cp_get_eth_rule_counters("cpzoneid_2_auth/192.168.2.6_32");
list($discard, $discard, $output_pkts, $output_bytes, $input_pkts, $input_bytes, $discard, $discard) = $result;
echo " ".$output_pkts;
echo " ".$output_bytes;
echo " ".$input_pkts;
echo " ".$input_bytes;

I see a

login-to-view

which looks good.

[marcosm]

@gertjan Thanks! I submitted a fix for that, unfortunately it will require a new build.

[heper]

@Gertjan

do you use these settings? ( i'm only using windows AD for cP-auth, not accounting)
login-to-view
login-to-view

i'm seeing odd behaviour.
this is supposed to provide x kb/s for EACH user. (it worked in previous versions)

now i am seeing that the sum of all client traffic combined on captive portal matches the speeds set in the "default download/upload".
so in my case it becomes a global limiter on the entire VLAN ....

can anyone confirm / deny if they can also observe this.

[Gertjan]

@heper

Your talking about bandwith restriction.
I'm (see subject thread) was talking about quotas.

For a 'test' FreeRadius user, I have

login-to-view

so : no bandwidth restrictions.

I've activated a 2 Mbit down for "everybody" :

login-to-view

Two active users are connected, both a clipping to the 2 Mbit down.
( two other users are just connected and not active).

login-to-view

With my two devices, I can see 2 x 2 Mbits = 4 Mbit.

edit :

When I clip a user with FreeRadius :

login-to-view

the bandwidth for this user is also respected. 1 Mbits down and 500Kbit up.
Other users can still access using all bandwidth available.

[heper]

@gertjan said in FreeRadius and quotas, doesn't work since 22.05:

as talking about quotas.

i realize that you were talking about quota's and not bandwidth limiting, but since i didn't find anyone with the same issue i hoped it might have been related.

i'll contact netgate support - perhaps they have more insight in the bandwidth-limiting issue i'm having, while yours seem fine on 22.05