Session-Timeout Problem

[Brian Candler]

On 02/02/2017 12:48, Selahattin Cilek wrote:
> I don't believe FreeRADIUS is supposed to send Session-Timeout messages the to NAS, but the other way around.
The AP sends an Access-Request, FreeRADIUS responds with Access-Accept.

The Session-Timeout attribute appears in the Access-Accept response.

>
> > However, I would point out that there are much better ways of achieving your goal than kicking off users every 10 minutes, which is highly disruptive.
> No, it is not disruptive. The NAS is not supposed to first disconnect and then reconnect the user every 10 minutes,

Unfortunately, that's what you've told it to do with the Session-Timeout 
attribute. See RFC 2865, section 5.27

"     This Attribute sets the maximum number of seconds of service to be
       provided to the user before termination of the session or prompt.
...
       The field is 4 octets, containing a 32-bit unsigned integer with
       the maximum number of seconds this user should be allowed to
       remain connected by the NAS."

So the user will be kicked off and required to re-authenticate. If 
everything's working well, it may only be a second or two's loss of 
service, but that's what's happening.

>
> A NAS based solution will not work because I will have to configure each and every NAS on each and every site.
Nope. The API request goes into the Unifi controller. It will 
automatically work out which AP the user is on, and kick them off it.

(And you don't have to use their scripts; it's a simple JSON over HTTP 
POST which you can generate yourself. The script just gives you an 
example of the payload)


>   What if I'd like to use some other NAS some other day?
Then indeed this approach won't work any more - but you did say you were 
using Unifi.

There is no standard way to kick off a user mid-session. Some devices 
might support a RADIUS CoA packet, some devices might support a SNMP set 
operation, some devices might have their own controller you can interact 
with, and some might have no way to do this at all.


>
> > 2. The Unifi controller's mongodb database tracks how much bandwidth every user has consumed. So you could just periodically query that and kick off the abusers.
>
> I cannot have a separate machine for Unifi controller on the site. Besides, I might someday wanna keep track of network usage in a centralised database.

The unifi controller gives you exactly that centralised database of 
usage. And it doesn't have to exist in the site. The software can run 
wherever you like, as long as it is reachable over the network.

The software is free, and runs under Linux, Windows or OSX. It doesn't 
carry the user traffic, so if the controller shuts down for any reason, 
it doesn't affect the users. Neither does it affect authentication.

You can even use Unifi's own cloud-hosted version of the service, if you 
buy one of their dongles:

https://store.ubnt.com/unifi/unifi-cloud-key.html

>
> 3. Use the Unifi's built-in bandwidth control features (User Groups / bandwidth limits). That's at the level of kbps not total GB per week.  Still, people who have exceeded their quota could have a very low bandwidth limit applied.
>
> That will not work because it is not centralised. I have 30 APs on one site and the user can log in to any one of them.
On the controller, you set the limits at the user level. It doesn't 
matter which AP the user logs into, the controller takes care of it.

I'm just saying: you've got a very nice product, you might want to use 
the capabilities it already has!

Regards,

Brian.