Project

General

Profile

Actions

Bug #8251

open

Captiveportal + FreeRadius "Last activity" resets to Session start

Added by Frotty Zaoldyeck almost 7 years ago. Updated over 5 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
FreeRADIUS
Target version:
-
Start date:
01/01/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:

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) 

Actions #1

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
Actions #2

Updated by Frotty Zaoldyeck almost 7 years ago

Any help?

Actions #3

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.

Actions #4

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.

Actions #5

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..

Actions #6

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.

Actions #7

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.

Actions

Also available in: Atom PDF