Idle Time Accounting or Idle timeout ?
-
Does Idle Time Accounting work the same as Idle timeout? In other words, the DHCP lease time must be respected in both cases?
-
@ivanildolb said in Idle Time Accounting or Idle timeout ?:
Idle timeout?
This one :
?
The manual says : if a captive portal connected device didn't 'consume' any traffic since moment X, and X is more then "Idle time out" in the past, then disconnect the client.
@ivanildolb said in Idle Time Accounting or Idle timeout ?:
Idle Time Accounting
The Radius "Idle-Timeout" ?
https://freeradius.org/rfc/rfc2866.html
You probably have to use / enter it into "Additional RADIUS Attributes (CHECK-ITEM)" at the bottom of the Users page (FreeRadius package)
If set, it overrides the pfSense 'global' Idle time out.
( dono if the "pfSense FreeRadius" supports it, better check upfront )
/rfc/rfc2866.html
@ivanildolb said in Idle Time Accounting or Idle timeout ?:
the DHCP lease time
Has nothing to do with the portal or FreeRadius, or 'account' or what so ever.
DHCP traffic always (should always) pas through.
As long as the logical connection is 'UP', DHCP keepots care of the addressing and network aspect.
If DHCP fails or get blocked, the device can't even use the network anymore. -
@gertjan I understand these concepts, but what I need to know is whether the RADIUS Idle Time Accounting option behaves the same as Idle timeout. Because if I define Idle timeout I need to respect the DHCP lease time, as it says in the manual. My question is whether RADIUS Idle Time Accounting also has this limitation or not?
Just to make it clearer, here's the excerpt from the manual that talks about Idle timeout.
"If a timeout value is set, the timeout must be less than the DHCP lease time or captive portal sessions can remain active for IP addresses that have switched to different devices. Setting the timeout lower will ensure that the portal sessions end before the lease would be reallocated to a new client"
-
I use a captive portal, that is, I've loads of 'victims', also called client of our hotel, that use the captive portal all the time.
I'm also using FreeRadius for the accounting, and that is only the login, the rest, like bandwidth, consummation etc, I don't care.I've set the DHCP server default lease duration of the captive portal to a 8 hours or so.
Now, a question :
When you check carefully your firewall rules used for your captive portal, you'll notice that you probably didn't create any DHCP related firewall rules.
So, how do they the client device initiated DCP REQUESTS (DISCOVER, RENEW, etc) reach the DHCP server ?Answer : your looking at the wrong rule set.
Look at /tmp/rules.debug ( and come back here when you fully understood what that file tells you ;) )
The answer was : DHCP traffic is passed by the firewll by default.And that's all there is to make DHCP work.
It has nothing to do with the Portal, or Radius.My idle time (general captive portal setting) is set to 60 minutes. Hard time out is 10 hours.
@ivanildolb said in Idle Time Accounting or Idle timeout ?:
"If a timeout value is set, the timeout must be less than the DHCP lease time or captive portal sessions can remain active for IP a
Normally, the DHCP lease time is hours or more. If you only have a network like me, 192.168.2.0/24 then you can create a pool of about 253 IPs.
If your portal needs more IPs because you have lots of captive portal visitors, then go for a /23, a /22 or, why not, a /16 (65000+ portal devices)What not should happen is that devices have to 'fight' for an IP. That happens when the number of active portal users start to close into the number of available IPs in the DHCP pool.
Like : at a certain moment, device A was using 192.168.2.10/24. Then it goes out of SSID range for a while, and furthermore, some time later, even the lease for this device expires. Take note that normally, the device would start to renew when half the lease duration is expired.
When device A comes back, it will recognize the SSID/MAC of the portal and ask for the same IP again.
But : it was already handed out to another device ..... and that's where things becomes messy.
Because devices are recognized by de IP/MAC pair. And that changed : so, a new portal logging has to be made."Idle time outs" should be an order of magnitude smaller as DHCP lease duration to circumvent the issue stated above, and probably others that I'm even not aware of.
Btw : reallocation of a "portal session" does not depends on a DHCP lease.
But for the portal session to be created, the device should maintain the same IP. It will do so automatically, while it is SSID connected.
Then, after a Idle timeout (first), and hard time out (second) or whatever radius condition you've set (like : Bytes used used) the user can get disconnected from the portal.
It will still have the same IP, though, as long as DHCP keeps working == as long as the device is in SSID range of the captive portal.
The client of the device has to re authenticate to the portal, of course.Get the picture ?
-
@gertjan You said it all at this point: "What should not happen is that devices have to 'fight' for an IP. That happens when the number of active portal users start to close into the number of available IPs in the DHCP pool". This is exactly what I want to avoid! My scenario is as follows:
I manage a school wireless network, everyone authenticates through the captive portal using the RADIUS server. The problem is that all sessions remain open, and that number has been growing a lot each semester. However, I don't want the sessions to end in a few hours, I need it to last at least 15 days.
That's why my question, I'm not sure of the implications that can occur on the network if I leave sessions open for so long...
-
Schools are a bit like hotels : people don't stay over for the night (hotels : the day).
So, next day : login again for everybody.
But, like I did the counting 32 rooms x 3 devices a room max = about 100 IP so a /24 will do it for me.
A school is probably 10+ times bigger : so, take a 192.168.0.0/24 and you'll be good.I would test with a 8 hours idle time out (global pfSense portal page parameter) , and a 12 hours hard time out to start testing. Initially, I don't see the need to use Freeradius for this.
DHCP could be left 'default' or something like 12 hours lease, probably less.This way, the session list will grow rapidly in the morning, and go back to zero in the evening.
@ivanildolb said in Idle Time Accounting or Idle timeout ?:
I need it to last at least 15 days
Why ? The login is hard ?
Btw : DHCP clients can still do what they want with a DHCP OFFER lease time from the DHCP server : accept the 30 days lease, or just start to renew offer a 'several hours' anyway : they can have their own min and max ceilings. They will, after a SSID signal loss, ask (REQUEST) for a new lease anyway - they will indicate that they prefer the previously used IP, though.
-
@gertjan I understand. When I mentioned that I preferred a minimum downtime of 15 days, it is because I see no sense in users logging in daily, since they already belong to the institution. In the case of a hotel it is different, because people stay for a few days and leave. In my case, I wanted sessions to be disconnected only when users took vacations or I no longer belong to the institution.
Anyway, now I understand the process. Now I'm just going to decide which way to go. Thank you very much for the clarification !!!
