Captive portal's session timeout
-
I've got a few questions regarding the operation of the captive portal in a hot-spot-like environment…
I'm using radius authentication using freeradius and I've added a user to the radcheck database.
I've configured the captive poral to use the radius server and authentication is indeed succesful.1. I've added an entry for session-timeout to my radius which I've tested with the radtest tool on linux that comes with freeradius and i see
that the attribute is returned succesfully.
i've tried both of these attributes:
Session-Timeout := 60
Session-Timeout == 60
just to be sure, they are both returned, and i ofcourse marked the 'session-timeout' option in the radius but users arent disconnected after this
60 seconds time-out period...can anyone shed some light on this very important issue?
2. Is it possible to somehow set-up pre-paid per-time accounts?
Meaning I'll setup an account which is only valid for 1 hour of surfing, which after that time period the user can't authenticate anymore...This is another important issue which I'm trying to resolve if anyone could please provide me with some more information.
Thanks alot
-
How are you setting your timeout on the pfrsense box? I've done extensive testing with the captive portal and never had any issues with the timeout. If you're using the session timeout within radius I don't think you'll get the desired effect because radius has to control over the ipfw rules that alloow and deny access through the box. As far as the pfsense box is concerned they'll be allowed through until the timeout specified in the captive portal conf is reached.
What are you trying to accomplish with #2? It seems like an administrative nightmare to have to keep adding new accounts every time someone wants to get on the net assuming they time out and aren't valid anymore. Writing a simple front end (that you can automatically redirect to via the portal) to your radius server that can generate temporary usernames and passwords seems like a more appropriate method. That's how I've done it in the past and it works swimmingly. The one problem that you'll run into is that users can just request another uid and pass. This could be alleviated by blocking their MAC for a short period, but that can get messy and the only way to do it would be ipfw since pf doesn't do layer 2.
nb
-
But the timeout in the captive portal is a global timeout for all users, and there's a special check-box for grabbing
the session-timeout attribute returned from the radius- if its there then it means it is supposed to work. -
Ah, that wasn't clear to me from your first post. I have not tried the radius provided session timeout. If I get some time maybe I can test it against my lab setup this week to see if I get the same results.
-
Thank you.
I very much appriciate it, it's an important feature for me which I need Pfsense to fully support. -
@lir:
Thank you.
I very much appriciate it, it's an important feature for me which I need Pfsense to fully support.I've been really busy this week and have yet to have a chance to try it out.
nb
-
Ok cool
I'm waiting for your reply on it. -
@lir:
But the timeout in the captive portal is a global timeout for all users, and there's a special check-box for grabbing
the session-timeout attribute returned from the radius- if its there then it means it is supposed to work.Actually, I think that might be part of the radius code that hasn't been backported from HEAD when we last merged in the m0n0 CP code. This may be a feature that's not supposed to work and needs to be stripped from 1.0. I'll try and confirm that shortly.
–Bill
-
Scott can probably add more, but the more I look at the code, the more I'm convinced that this feature slipped in during a merge of the CP code which requires the newer radius.inc and PECL RADIUS that's in HEAD.
–Bill
-
Could be. I don't know. Will check it out.
-
Cool.
Let me know what you find out… -
We havent changed RELENG_1's captive portal code in quite a while. That is not it.
-
Sorry but I'm a bit confused.
Is the 'session-timeout' attribute supported or not? -
Session timeout is working fine for me here. But I am in no way using radius.
-
Right.
When not using radius, it's working fine.Question is - what happens when using radius?
There's a special box to use Session-Timeout attribute received from the radius so why is that not functioning?Thanks.
-
-
No.
-
No.
I've been too busy to test this yet, sorry. I have a lot of travel in the next few weeks so it may be a little while.
nb
-
You might want to test this with m0n0wall and bring this to attention at the m0n0 list if it's the same there. pfSense's captive portal is a nearly exact copy of the m0n0 CP though it's not the version used in the latest m0n0wall.
-
Looks like m0n0wall's beta 1.23b1 has improvement on that issue:
hanges in captive portal (jdegraeve)
* fixed a bug in the way we handle authentication mechanisms (potentially allowing double logins and faulty locking)
* add support for different MAC address formatting styles
* add support for per-user bandwidth limitation (using well-known WISPr RADIUS attributes)
http://m0n0.ch/wall/beta.phpSo if you're really stuck, you might want to take a look at m0n0wall for the mean time.