Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Captive Portal+Idle timeout

    Captive Portal
    2
    9
    8.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      DN
      last edited by

      Hi everyone.
      I have a pfsense 2.0.1 installation with Captive+Squid and all was working fine, until my boss says to me to put an Idle timeout to 24 hours.
      When I put this time, I have to put the DHCP lease in 25 hours; but i begin to have troubles with the sessions, because when a user take an ip with an active session in another pc, he can´t log in at the portal.
      Then I disabled Mac Filtering, but now I see that the idle timeout isn´t working and the sessions are always active.
      What I have to do to solve this issue?
      Thanks for your help!

      1 Reply Last reply Reply Quote 0
      • N
        Nachtfalke
        last edited by

        Perhaps this will help - not sure if this is the same problem.
        http://forum.pfsense.org/index.php/topic,42944.0.html

        1 Reply Last reply Reply Quote 0
        • D
          DN
          last edited by

          Thanks Nachtfalke
          But this topic talk about Hard TimeOut…I have no limit for Hard and 24hrs for Idle..and additional I disabled Mac Filtering and with this I solve the loop trouble.
          What do you think?
          Thanks a lot!

          1 Reply Last reply Reply Quote 0
          • N
            Nachtfalke
            last edited by

            At least there is no difference if a user get disconnected by "Idle timeout" or by "Hard timeout". In both cases the user has to re-login.
            pfSense saves the IP address to the corresponding MAC address. If MAC <-> IP changes then there is a "double login". If you disable MAC address filtering then this check is disabled.

            I think it could help you with your problem if you read the complete thread - I do not know anymore what was the solution for that. I think it was about the size of the ip address pool which was to small and the DHCP lease times.

            How big is your IP pool and how many (different) clients connect there ?

            1 Reply Last reply Reply Quote 0
            • D
              DN
              last edited by

              I have a pool for 230 devices (192.168.1.20 to 192.168.1.250) and for now I can have normally 35/40 concurrent users.
              But by the lease time and the session idle timeout, I have 120/130 active sessions and 170/180 ips "taken".

              1 Reply Last reply Reply Quote 0
              • N
                Nachtfalke
                last edited by

                @DN:

                I have a pool for 230 devices (192.168.1.20 to 192.168.1.250) and for now I can have normally 35/40 concurrent users.
                But by the lease time and the session idle timeout, I have 120/130 active sessions and 170/180 ips "taken".

                Hmm. But then there should be enough space (IPs).

                But perhaps we can solve this in another way. What do your or your chef like to realize with the idle timeout of 24h ?
                If someone is using his PC one time a day then this time never expires.

                1 Reply Last reply Reply Quote 0
                • D
                  DN
                  last edited by

                  Yes, that´s the problem! If my DHCP assigns an Ip to a device, and this Ip have an active session, the user can access without cross the captive portal. And the session is still active because Mac filtering is off, doesn´t matters idle timeout is over (>24hrs).
                  The business is a small hotel, and we want a user can login only once for all time he stay at here.
                  I´m thinking to define my DHCP lease in 48hrs and maintain the idle timeout in 24hrs, to reduce the problem, and activate again Mac filtering, what do you think?
                  ..but a question, how it works if I set the idle and hard timeouts without limit?…I´ll have a problem with DHCP lease every day?...

                  1 Reply Last reply Reply Quote 0
                  • N
                    Nachtfalke
                    last edited by

                    @DN:

                    Yes, that´s the problem! If my DHCP assigns an Ip to a device, and this Ip have an active session, the user can access without cross the captive portal. And the session is still active because Mac filtering is off, doesn´t matters idle timeout is over (>24hrs).
                    The business is a small hotel, and we want a user can login only once for all time he stay at here.
                    I´m thinking to define my DHCP lease in 48hrs and maintain the idle timeout in 24hrs, to reduce the problem, and activate again Mac filtering, what do you think?
                    ..but a question, how it works if I set the idle and hard timeouts without limit?…I´ll have a problem with DHCP lease every day?...

                    In general the DHCP server will assign a client always the same IP. So if you have enough IPs than there should be no problem. But for example:
                    Day 1: You have 100 clients connected - 100 IPs assigned. The guests only stay in hotel for one night.
                    Day 2: You have another 100 clients connected - 100 new IPs assigned + the 100 IPs of the day before which have still a lease time left.

                    So if you do not have to take care about IP addresses and the user only should login one time per visit then deactive both timeouts, set DHCP lease to or 24h or 48h and if you do not have to take care about IP addresses just increase the subnet range from /24 to /22 or something higher.

                    I think this will be easier and less work instead of trying to find out why there is still an active session and how to solve this. Your WiFi for your guests should work - without interruptions - that's the goal.

                    1 Reply Last reply Reply Quote 0
                    • D
                      DN
                      last edited by

                      Ok, I made some changes over the configuration and until this moment is working:

                      • No timeouts (idle or hard)
                      • DHCP to /22
                      • DHCP Lease to 48 hours

                      For now, the DHCP server assigns new ips always, and still don´t assign a lease with a previous session opened in Captive Portal, then, all the sessions of old users are open yet. I´m waiting that when DHCP assign an ip previously used, and the users try to login in the CP, system automatically close the old session and open a new one. Are this a correct assumption?

                      Thanks for your help.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.