Captive Portal Login Loop



  • Hi, I recently installed PFSense in a Hotel with about 145 rooms, it has been working great!  I have only one question about a issue that has just started happening.

    We have had in the last 2 days 4 guests who cannot get passed the login page on the captive portal, they click accept and the page reloads and asks them to accept again- This goes on over and over.  Everyone else has no complaints and there are about 90 active users ATM.   the 4 guests have nothing in common, different OSes, totally different PC's and they are all set to DHCP etc…  We have found that doing a ipconfig /release and then /renew  fixes the problem.   What would be causing this in the first place?

    We have the Hard Timeout on the portal set to 24hrs with no idle timeout, default DHCP lease time,  I have attached some of the logs from the portal.

    One thing I notice is that whenever this happens I get several of these:

    ogportalauth[46934]: CONCURRENT LOGIN - REUSING OLD SESSION: unauthenticated, MAC, IP

    Is this a problem?

    Thanks,

    I look foward to your replies.
    portal-log.txt



  • I too have the identical problem fresh load of PF V2 release x86 down to the looping issue to the same log results  :'(



  • interesting, So maybe this is a bug in the portal code?

    I am running x64 2.0.



  • Actually the one server in mind I have is a x86.  I have about 20 or so PFsense servers in the field but almost all of them dont hit the 150+ mark.    This one site as you described I hit a high mark 150-170s and thats when I start seeing the logs fill with CONCURRENT LOGIN - REUSING OLD SESSION: unauthenticated.

    Now I have kicked everyone one and I slowly watch the users sign back in.   I randomly see CONCURRENT LOGIN - REUSING OLD SESSION: unauthenticated messages in the logs.   they seem to happen more frequently as the user count grows.   I am at 89 logins and I can see several of those error messages build in my logs.

    I am at a loss and opened a ticket with support I will update if they reply to me *hopefully they do it here.

    **Note that majority of the servers I have are RC3 servers I only have 3 or so release servers (version 2) in the field



  • Getting some more info from deresistance on his instance of it happening via the ticket. Will keep this updated without sharing any of his specifics if that's ok with him.

    AwesomePilot: your DHCP lease time should be equal or higher than your hard timeout, to ensure no one is reassigned an IP that's allowed through captive portal. Otherwise you'll have issues with re-assigned IPs as CP enforces IP to MAC association. That may be the cause of the issues in both cases actually, deresistance please also fill in here how your lease time compares to your CP hard timeout.



  • I can confirm that my DHCP lease times are not correct.  I will apply and post results within a day or so once I see some heavy usage.  Share away on the forums any info you need I can provide.



  • Ok, that may be the only issue here then. That log message is probably misleading in this case, it's the fact it's a reassigned IP that causes issues because the IP to MAC association is no longer the same.

    We'll consider some alternatives to clarify that scenario. Maybe not just checking IP there, but checking IP and MAC and logging a more appropriate message if there is a problem because the hard timeout is longer than the DHCP lease. Open to other ideas if anyone has suggestions, we'll also discuss in more detail internally. Need something other than input validation/warnings in CP in comparison to the DHCP lease times since some installs do DHCP elsewhere.



  • your DHCP lease time should be equal or higher than your hard timeout, to ensure no one is reassigned an IP that's allowed through captive portal.

    How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?)

    AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.



  • @dhatz:

    your DHCP lease time should be equal or higher than your hard timeout, to ensure no one is reassigned an IP that's allowed through captive portal.

    How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?)

    AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.

    It is independent if you use vouchers or username/password. The HardTimeout works always the same way. But if you are logged into CP with IP: 1.2.3.4 and MAC: 11:22:33:44:55:66 (IP from DHCP with lease 12h) then it is probably possible that you get an different IP (2.3.4.5) from DHCP after 12h and then it conflicts with the login on the CP because the first login was with MAC: 11:22:33:44:55:66 IP: 1.2.3.4 and the second with with MAC: 11:22:33:44:55:66 IP: 2.3.4.5 but the HardTimeout didn't expire.

    The voucher time of 2 days is the totaly expiration time.

    In short: DHCP lease must be longer than hard timeout.



  • @Nachtfalke:

    @dhatz:

    AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.

    But if you are logged into CP with IP: 1.2.3.4 and MAC: 11:22:33:44:55:66 (IP from DHCP with lease 12h) then it is probably possible that you get an different IP (2.3.4.5) from DHCP after 12h and then it conflicts with the login on the CP because the first login was with MAC: 11:22:33:44:55:66 IP: 1.2.3.4 and the second with with MAC: 11:22:33:44:55:66 IP: 2.3.4.5 but the HardTimeout didn't expire.

    The voucher time of 2 days is the totaly expiration time.

    In short: DHCP lease must be longer than hard timeout.

    Supposing you have configured your CP with a 6hr DHCP lease and 2 day HardTimeout, in your example wouldn't dhcpd simply check the dhcpd.leases file and re-assign that client the same IP 1.2.3.4 (as long as his MAC stays the same 11:22:33:44:55:66)? Also, iirc a client will start trying to renew its lease at 50% of the lease time, so for a 6hr lease time it'd start trying to renew its lease at about 3hrs.

    It seems to me that these issues are much more likely to arise if the DHCP address pool is relatively small compared with the client population.



  • The chance that there will be a problem is higher if the DHCP address pool is small - you are correct.

    Perhaps the thread starter should think about the (high) hard Timeout. I do not think there are people in a hotel which are online 48hours without getting to sleep or something else.

    Further the hard timeout could be a possibility to protect against people which are using a continous high bandwidth. The Hardtimeout interrups this usage (downloading a large .iso file over night).
    I would think about a hard timeout of 6hrs.



  • @Nachtfalke:

    Perhaps the thread starter should think about the (high) hard Timeout. I do not think there are people in a hotel which are online 48hours without getting to sleep or something else.

    I think his 24hr hard timeout is reasonable, since he probably doesn't want to force his hotel guests to re-login every few hours.

    I'm still unclear about the nature of the problems arising from dhcp lease time < HardTimeout, but I guess I'll have to check the code.

    @Nachtfalke:

    Further the hard timeout could be a possibility to protect against people which are using a continous high bandwidth. The Hardtimeout interrups this usage (downloading a large .iso file over night).
    I would think about a hard timeout of 6hrs.

    Most big downloads are done with P2P … and limiting P2P traffic is quite difficult.
    Another option would be data transfer quotas, but pfsense's CP doesn't support it afaik.



  • I checked my lease times, they are set to default which it says is 7200s for lease time and 86400s for max lease time. Isn't this already the way it should be?

    As said above, I choose 24hrs timeout because it is annoying to have to click I agree again. But if this is the problem i will gladly adjust it.



  • @Nachtfalke:

    The chance that there will be a problem is higher if the DHCP address pool is small.

    I checked this setting and this may have been my problem, only time will tell.

    My address pool was set to 150 ips which is obviously too small for the hotel. I changed it to lease 10.58.185.100-10.58.187.250.

    It makes sense to me that this could be a ip pool related problem since in a couple of instances doing ipconfig / release and /renew fixed it. However we have had a couple that this did not work with but these seem to be in the evening when all the guests are in house. The fix for these guests has been to reset the captive portal thus emptying the lease table.  So maybe ipconfig /release /renew couldn't work because there wasn't enough ips available in the evening?

    We shall see.



  • Although I had a big DHCP pool it was not really that large.  I did notice in my logs DHCP server complain of no free IPs.  So I made a very large subnet and I will post feedback.    I think agreessive DHCP pools + captive portal = bad



  • Perhaps it would make sense to adjust min and max lease times:

    min 7200
    max 14400



  • According to the settings page for dhcp lease times are in seconds. Hence 86400 = 1440min. So I already have that setting in there.

    Thanks for the suggestion though.



  • So far so good!

    I wanted to post a little something I am noticing on my system, So far tonight we have not had any issues reported, and for the last 2 nights it has broken by this time- So I am hopeful that the issue is resolved-Wait and see on that one though.

    What I have noticed tonight is that the only 3 times I have seen the "CONCURRENT LOGIN" message in the logs has been on iPhone devices- coincidence or not?? Who knows…

    Also since increasing the size of the DHCP pool the only addresses being assigned are the new ones not the old ones with the exception of one of the iPhones that generated the CONCURRENT LOGIN message...Maybe thats the way its supposed to work- Just thought I would point that out. On my DHCP leases page if I show all leases there are a ton of expired leases from days ago, Should these be showing up?

    At this point I am wondering whats going to happen when it reaches the end of my new IP Pool.



  • @AwesomePilot:

    Also since increasing the size of the DHCP pool the only addresses being assigned are the new ones not the old ones with the exception of one of the iPhones that generated the CONCURRENT LOGIN message…Maybe thats the way its supposed to work- Just thought I would point that out. On my DHCP leases page if I show all leases there are a ton of expired leases from days ago, Should these be showing up?

    At this point I am wondering whats going to happen when it reaches the end of my new IP Pool.

    Expired leases will hang around in the leases file for a while (exact details on that I don't recall, but the dhcpd.leases man page for ISC dhcpd explains that IIRC if you're interested in details). Those IPs are available for assignment to a new device if/when needed.

    The phone you noted is just renewing its existing IP from the sounds of it. Everything else from your description was offline long enough that their lease expired, and they got the next available from the larger pool.



  • @dhatz:

    How would the DHCP lease time need to be configured when using vouchers? (e.g. would a 2 day voucher require a 2+ day DHCP lease?)

    AFAIK, if a client's MAC address is recorded in the …/var/db/dhcpd.leases file, this client should get the same IP address next time.

    That's not specific to using vouchers, or RADIUS, or no authentication, just make sure your DHCP lease lifetime is equal to or greater than your CP hard timeout in all cases.

    Clients will be re-assigned the same IP in most cases, but commonly not in environments like larger hotels where lots of devices come and go and you have a relatively small DHCP pool for the number of devices, so it has to reassign IPs whose leases have recently expired.


Locked