Captive Portal Active Users After Firewall Reboot


  • Hello!!!  I'm wondering if there is a way of mantaining the captive portal active users' sessions open after a unexpected shutdown or reboot… so that the portal users don't have to log in again...

    the thing is that I'm using vouchers with captive portal... and it works perfect... but I dont give the vouchers to the clients... we log them in manually so they don't use the voucher on a different equipment other than the one they paid for...

    but when a power failure occurs the user have to log in again... and they have to come over to do it... wich is an inconvinece...

    thanks in advanced....!!!


  • Just a question back: I can't really imagine that I should ask to 'take' the device from the client so I type on HIS device the voucher code ….
    @hardy_rafael17:

    …. but I dont give the vouchers to the clients... we log them in manually so they don't use the voucher on a different equipment other than the one they paid for...

    But maybe you have different clients then I have ;)

    A simple solution with limited side effects: use an UPS. And your done.

    If an UPS isn't possible, well, you have to make YOUR solution for your special situation.
    This means: start coding.

    Like this:
    Consider start GIVING the voucher code to your clients.
    You will NOT have to trust your client because you'll be having 'tool' that enforces your network access rule: "don't share the code".

    Write a scripts that parses your Portal log file.
    This script should maintain a file that maintains a list with found (new) voucher code and a MAC (and the time the voucher code + MAC line entered in the list).
    Every time a NEW voucher code is found in the Portal log (a code that isn't in the list already) then its added with the MAC of the device that's using the voucher code.
    This script should also remove any voucher code that are in the list longer then the time duration of the voucher.
    So, right now, we have a list in a file that reflects the state of every used and active voucher code and MAC (== initial MAC == device) - this list is maintained - it will not grown indefinitely. It will zero length after all used vouchers expired, as the lines are wiped "after voucher expires time" (having all the vouchers the same time duration will simplify your coding)

    Now comes the trick: when a voucher code shows up that is still valid, and already present with another MAC in your list, then have yourself send a mail-telex-SMS,Fax,Twit,Push,whatever.
    You have the incriminating voucher code - you have the original MAC and 'new' MAC.
    So you will know for SURE which client communicated (shared) its voucher code with some else.
    Go torture this guy, and you quickly know who is the owner of that other 'new' MAC.
    Punish them both on a public place - make this happen every time at the beginning, so your simple usage 'rule' will be accepted very quickly. Voucher sharing sharing will stop. Because you will know it happens every time your rule isn't applied.

    Or, continue to automatize: make your script interact with pfSense, with some Portal code:
    If the script detect a second usage (another MAC) then block this session: call the already exiting pfSense code to break the session entirely (as a logout or time out). Think about 'logging out' also the initial owner of the voucher code. So he will pay the price right away when his voucher code is being reused.
    The voucher code can be used again, but following script rules above: only with the MAC (== device) that initially activated it will be allowed to use voucher code again.

    Nothing has to be done on a reboot:
    Your list will survive.
    Your clients should login again (all Portal sessions are lost).
    Voucher codes will be compared with what is already present in your list. If the MAC is corresponding, all is well.
    If not, another MAC was using that voucher code : logout the session.
    If the voucher code isn't in the list: add it with the "initial MAC" + time.

    Note:
    Vouchers will expire in xx seconds
    Your list file should be cleaned out every minute or so, so when a voucher code spent more then his their "voucher valid time" in the list, it will be removed. The expired voucher code could be retried by a user, but the Captive portal will reject it anyway.

    Voila, this is how I would handle the question (after 10 minutes reflexion while writing - trying to handle all possible situations).

    You have a "fixed price" solution (and no work to do except putting the UPS in place).
    A minimal "stand alone" script solution, with the main advantage that if your code doesn't work, the Portal will be up and functional. Some entertainment is guaranteed with this one.
    The fully automatic solution is there if you are more a coder as a judge and executioner.

    Up to you now ;)


  • It seems like you understand the situation very well…

    Yes I would love to just give them the voucher...  (and actually I don't mind them using the code for a different device) the problem is that I have a price for Desktops and Laptops and another different for mobile phones and tablets...

    I'm not a coder (I'm at the very begining of learning to code (I've been using pfsense for two and a half years now, and it's a complete system) so I'll go like this  ;) ...

    are you willing to code a script like that for me?
    how much would it cost me...?

    @Gertjan:

    If the script detect a second usage (another MAC) then block this session: call the already exiting pfSense code to break the session entirely (as a logout or time out). Think about 'logging out' also the initial owner of the voucher code. So he will pay the price right away when his voucher code is being reused.
    The voucher code can be used again, but following script rules above: only with the MAC (== device) that initially activated it will be allowed to use voucher code again.

    That's exactly what I want… Thanks in advance...


  • ;)

    Sorry, I have no test-environment to implement this.

    If your selling your access time you needed to offer some good quality code, which I couldn't provide you.

    Btw: your question is a very valid bounty request.


  • Yeah well…!!! I have posted it as a bounty... but so far no one has answered.... I´ll be a little bit more patient...

    Your advice about the script helped... at least now I have a better idea on how to do it...

    I already got the ups...  So I´ll wait for the bouty to be taken>>> and in the mean time I'll continue to learn how to code...

    Thank you for your attention and time!!!  ;D ...

    Link to the bounty !!! https://forum.pfsense.org/index.php?topic=78832.0