Captive portal's session timeout

lir · Jun 9, 2006, 5:09 PM

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

buraglio · Jun 10, 2006, 2:25 PM

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

lir · Jun 11, 2006, 5:05 AM

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.

buraglio · Jun 11, 2006, 3:18 PM

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.

lir · Jun 11, 2006, 4:11 PM

Thank you.
I very much appriciate it, it's an important feature for me which I need Pfsense to fully support.

buraglio · Jun 16, 2006, 1:50 AM

@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

lir · Jun 16, 2006, 4:01 PM

Ok cool
I'm waiting for your reply on it.

billm · Jun 17, 2006, 4:48 AM

@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

billm · Jun 17, 2006, 4:53 AM

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

sullrich · Jun 17, 2006, 6:52 AM

Could be. I don't know. Will check it out.

lir · Jun 18, 2006, 5:31 AM

Cool.
Let me know what you find out…

sullrich · Jun 18, 2006, 5:37 AM

We havent changed RELENG_1's captive portal code in quite a while. That is not it.

lir · Jun 18, 2006, 6:39 PM

Sorry but I'm a bit confused.
Is the 'session-timeout' attribute supported or not?

sullrich · Jun 18, 2006, 6:40 PM

Session timeout is working fine for me here. But I am in no way using radius.

lir · Jun 18, 2006, 8:38 PM

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.

lir · Jun 26, 2006, 3:32 PM

@sullrich:

Could be. I don't know. Will check it out.

Any new regarding this issue?

Thanks.

sullrich · Jun 26, 2006, 3:55 PM

No.

buraglio · Jun 27, 2006, 4:00 PM

@sullrich:

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

hoba · Jun 27, 2006, 4:27 PM

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.

namezero · Jun 29, 2006, 7:57 AM

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

So if you're really stuck, you might want to take a look at m0n0wall for the mean time.