Bug #8251
openCaptiveportal + FreeRadius "Last activity" resets to Session start
0%
Description
Hi again.
I still have the exact same problem I reported before since moving to 2.4: https://redmine.pfsense.org/issues/8058
I thought it was resolved because some users didn't get the problem, but most users still permanently have to re-log, me included.
After several updates of pfsense base and the radius package, nothing has improved and this is really a huge issue for me. Any help would be appreciated.
The only thing left I haven't done so far is a complete pfsense reinstall without restoring config or going back to 2.3
My Setup: I have a captive portal with username/pw login using freeradius which also runs on the pfsense machine.
I have accounting and re-authentication set up:
Here the whole config:
/usr/local/etc/raddb/radiusd.conf prefix = /usr/local exec_prefix = ${prefix} sysconfdir = ${prefix}/etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = ${localstatedir}/log raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct name = radiusd confdir = ${raddbdir} modconfdir = ${confdir}/mods-config certdir = ${confdir}/certs cadir = ${confdir}/certs run_dir = ${localstatedir}/run db_dir = ${raddbdir} libdir = /usr/local/lib/freeradius-3.0.15 pidfile = ${run_dir}/${name}.pid max_request_time = 60 cleanup_delay = 5 max_requests = 2048 hostname_lookups = no regular_expressions = yes extended_expressions = yes log { destination = files colourise = yes file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = yes auth_badpass = no auth_goodpass = no msg_goodpass = "" msg_badpass = "" msg_denied = "You are already logged in - access denied" } checkrad = ${sbindir}/checkrad security { allow_core_dumps = no max_attributes = 200 reject_delay = 1 status_server = no # Disable this check since it may not be accurate due to how FreeBSD patches OpenSSL allow_vulnerable_openssl = yes } $INCLUDE clients.conf thread pool { start_servers = 5 max_servers = 64 min_spare_servers = 3 max_spare_servers = 10 max_queue_size = 65536 max_requests_per_server = 0 auto_limit_acct = no } modules { $INCLUDE ${confdir}/mods-enabled/ } instantiate { exec expr expiration logintime ### Dis-/Enable sql instatiate #sql daily weekly monthly forever } policy { $INCLUDE policy.d/ } $INCLUDE sites-enabled/
/usr/local/etc/raddb/clients.conf client "NAS" { ipaddr = 192.168.1.1 proto = udp secret = 'xxx' require_message_authenticator = no nas_type = other ### login = !root ### ### password = someadminpass ### limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } }
When users first log in, "Last Activity" updates fine:
But then, randomly after some time, the "Last Activity" of any user is just set to session start. It doesn't even stay at last "Last Activity", it gets completely reset:
Even though in radius.log I receive "Login OK" every minute
Mon Jan 1 15:10:37 2018 : Info: Debugger not attached Mon Jan 1 15:10:37 2018 : Warning: [/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay" found in filter list for realm "DEFAULT". Mon Jan 1 15:10:37 2018 : Warning: [/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay-USec" found in filter list for realm "DEFAULT". Mon Jan 1 15:10:37 2018 : Info: Loaded virtual server <default> Mon Jan 1 15:10:37 2018 : Info: Loaded virtual server default Mon Jan 1 15:10:37 2018 : Warning: Ignoring "sql" (see raddb/mods-available/README.rst) Mon Jan 1 15:10:37 2018 : Warning: Ignoring "ldap" (see raddb/mods-available/README.rst) Mon Jan 1 15:10:37 2018 : Info: Loaded virtual server inner-tunnel-ttls Mon Jan 1 15:10:37 2018 : Info: Loaded virtual server inner-tunnel-peap Mon Jan 1 15:10:37 2018 : Info: Ready to process requests Mon Jan 1 15:10:40 2018 : Auth: (0) Login OK: [xx] (from client NAS port 2014 cli yy) Mon Jan 1 15:10:52 2018 : Auth: (2) Login OK: [xx] (from client NAS port 2016 cli yy) Mon Jan 1 15:10:57 2018 : Auth: (5) Login OK: [xx] (from client NAS port 2010 cli yy) Mon Jan 1 15:10:58 2018 : Auth: (8) Login OK: [xx] (from client NAS port 2012 cli yy) Mon Jan 1 15:11:00 2018 : Auth: (11) Login OK: [xx] (from client NAS port 2014 cli yy) Mon Jan 1 15:11:01 2018 : Auth: (14) Login OK: [xx] (from client NAS port 2016 cli yy) Mon Jan 1 15:11:03 2018 : Auth: (17) Login OK: [xx] (from client NAS port 2018 cli yy) Mon Jan 1 15:11:04 2018 : Auth: (20) Login OK: [xx] (from client NAS port 2020 cli yy) Mon Jan 1 15:11:06 2018 : Auth: (23) Login OK: [xx] (from client NAS port 2022 cli yy) Mon Jan 1 15:11:07 2018 : Auth: (26) Login OK: [xx] (from client NAS port 2024 cli yy) Mon Jan 1 15:11:09 2018 : Auth: (29) Login OK: [xx] (from client NAS port 2026 cli yy)
Updated by Frotty Zaoldyeck almost 7 years ago
I also get these errors when the times reset, but I'm not certain if they're related yet. I have reported them all via error reporter as well:
PHP ERROR: Type: 1, File: /usr/local/www/diag_edit.php, Line: 57, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 495845217 bytes) @ 2018-01-01 15:09:53
Updated by Frotty Zaoldyeck almost 7 years ago
Still an issue. I noticed that with "Interim" accounting mode, the "Last Activity" seems to work.
However simultaneous/concurrent usage limiting still doesn't.
Updated by A FL over 6 years ago
This issue is likely comming from the way pfSense and FreeRadius are talking to each other when performing accounting updates (i mean Stop/Start and Interim method).
Please see https://github.com/pfsense/docs/issues/43#issuecomment-414126063 for more information
As a temporary workaround you could use an external FreeRadius server which use sql
and sqlcounter
modules.
This issue is known since a while, but making a fix isn't trivial since it's not planed to install an SQL server on pfSense (and it will probably never be).
The best way to resolve this issue would probably to make FreeRadius package use the sql
module with an SQLlite database, but so far nobody has worked on a fix yet.
Updated by Frotty Zaoldyeck over 6 years ago
Thanks for the reply Augustin.
I'm still having this issue, perhaps I will try your idea when I upgrade the next time.
Which method do I have to use with the external radius server then?
At least the problem is acknowledged now..
Updated by Jim Pingle over 5 years ago
- Category set to FreeRADIUS
- Status changed from New to Feedback
There have been lots of Captive Portal changes since this was opened, you should re-test on a 2.5.0 snapshot to see if the behavior persists.
Updated by Frotty Zaoldyeck over 5 years ago
Really? I checked the changelogs before and didn't see anything too interesting.
Also since I am somewhat afraid of other stuff breaking with 2.5.0, I'm not to keen about updating right now.
But thanks for the heads up and your continued improvement efforts.