Hi Alan, May you elaborate a bit more on Access-Reject? Do I still set it in /etc/freeradius/3.0/sites-enabled/default like this? authorize { update control { &Current-Timestamp := "%l" } update request { &Expires-Timestamp := "%{sql:SELECT UNIX_TIMESTAMP(expires_at) FROM main_db.`user` WHERE main_db.`user`.username ='%{User-Name}'}" } if (&control:Current-Timestamp > &request:Expires-Timestamp) { * always reject {* * rcode = reject* * }* } Many Thanks, Houman On Tue, 15 Oct 2019 at 18:03, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 15, 2019, at 10:08 AM, Houman <houmie@gmail.com> wrote:
Thank you very much for all your help on this. I got in touch with the NAS makers (StrongSwan) and did some analysis together. Essentially the NAS only needs the User-Name for the disconnect request, which I'm already providing. The reason why it sends a NAK is that no IKE_SA was found with a matching remote identity. This is what happens on the NAS side in the log file:
Ok.
It's a bit of a dilemma. I have a reason to disconnect the user based on a condition. But the user can still reconnect and I won't be able to disconnect him straight away.
You should be able to save the condition in a DB, and then *reject* the next connection attempt by the user.
I have to wait until the next Acct-Interim-Interval kicks in before I can actually disconnect him again. Since the authentication happens through Freeradius, is there a way to reject the user immediately during authentication other than sending disconnect requests?
Return Access-Reject.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html