Captive Portal Password-only Authentication Loop
-
I am completely wrong regarding the DHCP Lease timeout and the CP timeout.
logportalauth[1657]: CONCURRENT LOGIN - REUSING IP 10.10.0.144 WITH DIFFERENT MAC ADDRESS 40:b0:fa:7b:d2:b7: Guest, 40:b0:fa:7b:d2:b7, 10.10.0.144
That error is telling you that an existing session exists for 10.10.0.144/40:b0:fa:7b:d2:b7. That session remains active and the new logon attempting to also use 10.10.0.144 will just receive the logon page again.
I believe there should be a LOGIN attempt logged right before that detailing the same IP with the different MAC address. Yes. In your first screenshot the user with MAC address c8:bc:c8:34:26:96 was receiving the login page over and over again.
-
I believe there should be a LOGIN attempt logged right before that detailing the same IP with the different MAC address. Yes. In your first screenshot the user with MAC address c8:bc:c8:34:26:96 was receiving the login page over and over again.
Yes, I have gotten to that conclusion. I have been counting the DHCP leases and they surpass the amount of new logged in users (I measured this after a system reboot, so there was not enough time for leases to expire and consequentially be reused). There was about 50 new users and 70 DHCP leases used up within a day. My guess is that these are foreign devices to the hotel and are just connecting to any open network.
I did try to solve this lack of DHCP leases by extending the network to 10.10.0.0/23, but I ran into issues trying to communicate and authenticate in the 10.10.0.0/24 range. Therefore, I have given up that solution and will just try to work it out with lower lease and timeout times.
– UPDATE --
The current count of DHCP leases and Captive Portal logins are:- 204 active Leases (out of 250);
- 158 Logged in users;
Problem: I am getting the "logportalauth[1657]: CONCURRENT LOGIN - REUSING IP 10.10.0.144 WITH DIFFERENT MAC ADDRESS 40:b0:fa:7b:d2:b7: Guest, 40:b0:fa:7b:d2:b7, 10.10.0.144" error again (this one is just a template and there was only one occurrence so far).
What I have gathered is:
The MAC 58:… who had IP 10.10.0.132 and wanted to login was not able to do it (the IP lease was attributed one hour before attempting to login at 2AM and this is registered in the DHCP Lease table). I checked the Captive Portal entry for that IP address and it was attributed to MAC b4:... at 8 AM on the previous day. What this strange this time is that the MAC that is logged in on the Captive Portal, b4:... (with the IP 10.10.0.132), has no entry on the DHCP table.
The DHCP lease default and hard timeouts are 90000 (25 hours) and 90100 seconds, respectively.
The Captive Portal timeout is 1440 minutes (24 hours).
At the time of the event the system had an uptime of 20 hours.
The Captive Portal table table was empty at the time of boot.
The DHCP table had no more than 10 entries at the time of boot.
I find this all very puzzling. I will wait to confirm that this was due to a partial use of the DHCP table at the time of boot. Otherwise, I will have to again try to make it into a /23 sized network.
One other thing... there seem to 5 leases at the bottom of the DHCP table that have expired. Neither of the have a time between Start and End superior to 40 minutes and 2 of them have a difference of 3 minutes. Is this to be expected?
This is the actual "OS version: 2.1.4-RELEASE (amd64)
built on Fri Jun 20 12:59:50 EDT 2014
FreeBSD 8.3-RELEASE-p16"Thank you.
-
Don't forget that everyone walking by MIGHT get a DHCP lease or two or three even if they don't go through the portal.
Also remember that the DHCP server can enforce a MAXIMUM lease time. Client devices can request and receive a shorter lease.
I have come to the conclusion that it really isn't the lease timeout that matters. It's a matter of having a large enough DHCP pool that the same address is not given out until after the portal timeout occurs.
I think you have two choices: Increase the pool size or decrease the portal timeout. And best practices say the DHCP default lease and max lease time should be longer than the portal timeout.
Also, you're probably going to need external logging of DHCP and CP to see what's really going on. My
-
The issue persists. I have gone and replaced the older hardware so now I have only the same kind of Access Points.
I have also successfully expanded the network into 10.10.0.0/23 and the DHCP server is issuing addresses between 1 and 250 on both intervals.I have noticed a pattern in the first "CONCURRENT LOGIN - REUSING IP <ip_address>WITH DIFFERENT MAC ADDRESS <mac_address>". This error has appeared on 3 out of the 6 days the system has been up. The error always occurred after an uptime of 18 to 19 hours.
The values for DHCP and Captive Portal timeouts have stayed the same as the above posts. This time there were about 130 registered users through the Captive Portal and 150 DHCP leases at the time of the error.
Since this is my first experience with pfSense I am wondering if I should file a bug report or not.</mac_address></ip_address>
-
It's not a bug. There's a CP entry for the same MAC with a different IP. That is, by design, an error.
You need a good DHCP log that doesn't wrap around as quickly as the one on the firewall. You'll see the IP being reassigned.
Sounds like you've made two DHCP pools. I wouldn't. I'd make one from, say, 10.10.0.17 - 10.10.1.254
-
It's not a bug. There's a CP entry for the same MAC with a different IP. That is, by design, an error.
I see, but that is not immediately troublesome. The strangest part seems to be the reassignment of the leased IP to another device or does it expire? Is it normal for a lease to expire before it's default timeout? I have not understood this yet I guess then the solution would imply greatly reducing the Captive Portal's timeout, which I was requested to keep reasonably high.
Alternatively, would the issue be resolved by enabling the "Disable MAC filtering" option in the Captive Portal's configuration page?
-
Personally, I think your timeouts are (or at least were) far too long for your DHCP pool size. Take, for example, your hard timeout. Do you really care if someone has to re-navigate the portal after they have been idle for a day and a half? And idle means idle - zero packets to the internet. Basically they'd have to be off property or have the device turned off. I would think for a hotel, something like an idle timeout of 12-18 hours would be reasonable. Remember, worst case they get the portal and enter the password again. A far sight better than not being able to get on at all.
And if they are staying for a week and not triggering the idle timeout, what's the point of kicking them off after a set time?
The trick is making the portal session timeout before the DHCP lease address is reissued to a new device.
Eliminating MAC filtering will, I believe, fix this.
Makes it a lot easier for someone to hijack a dormant session. All they have to do is assume the IP addresses in sequence and try to get out.
Also, given the same circumstances producing the error, the user in question will, instead, be through without the portal.
-
Eliminating MAC filtering will, I believe, fix this.
Makes it a lot easier for someone to hijack a dormant session. All they have to do is assume the IP addresses in sequence and try to get out.
Thank you for reminding me of this.
I will have a go with less conservative timeout values during this week.
-
I have done some testing and I had complete success with the following timeout values:
13 hours default DHCP lease (and 13 hours + 100 seconds)
12 hours Captive Portal Timeout (idle)17 hours default DHCP lease (and 17 hours + 100 seconds)
16 hours Captive Portal Timeout (idle)The first combination was running for 3 days and the second one for 2 days. I will keep pushing the values up without rebooting until I get to where I was asked to and see if it works.
Thank you for all your help.
-
Good to hear.
Those pushing for a higher timeout know they're talking about absolutely zero internet traffic for 16 hours right? It means the device is either powered off or is off the property. All it takes is one internet packet to reset the 16-hour timer.
That setting should allow the VAST majority of multi-day guests to only have to navigate the portal once during their stay. And, worst case, they have to navigate it again.
-
Those pushing for a higher timeout know they're talking about absolutely zero internet traffic for 16 hours right? It means the device is either powered off or is off the property. All it takes is one internet packet to reset the 16-hour timer.
Oh, I see how I was not clear enough. I meant the management.
That setting should allow the VAST majority of multi-day guests to only have to navigate the portal once during their stay. And, worst case, they have to navigate it again.
Yes, this was what I was aiming for. I see a lot less logins during the morning period.
Everyone is satisfied.
