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 8 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 over 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 about 7 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 about 7 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 about 6 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 about 6 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.