Feature #15854
open
Lost Captive Portal User Logins when DHCP Leases are Cleared
0%
Description
When DHCP Leases are cleared, Captive Portal User Logins may cease to be functional due to a change from the IP used when the authentication/login occurred. When the DHCP server assigns a new IP address to the same device on the next connection it will result in the device being presented with a new login screen and once logged in, a duplicate entry in the Captive Portal database for that Mac address, each with a different IP associated with it.
In addition, if the original IP is assigned to a different device/Mac the login screen will not be displayed for that user, instead they will receive the logout screen as Captive Portal will report a validated IP. Unless the device requests a disconnect from the logout screen, it will not be able to log in and in order to disconnect through status, captive portal, you must know which IP is assigned to the device you wish to disconnect as it will be associated with the wrong Mac address in the Captive Portal database. When this situation arises, the captive portal is expecting a login response but the captive portal will display the logout screen. No internet connectivity is enabled due to this conflict.
Proposal: When there are activated logins in Captive Portal, it would be useful to prompt as to this conflict or to offer to disconnect all Captive Portal logins when a DHCP Server request to Clear All DHCP Leases is initiated.
Alternatively, Captive Portal could check for a disassociation between IP/Mac in it's database and the actual IP/Mac of the device requesting the connection and send the login screen instead of logout. When a successful login occurs: disconnect all other associations where either the Mac or IP did not match the new credentials.
Files
Updated by Dale Harron 22 days ago
- File index-2411-Dec10.php index-2411-Dec10.php added
- File RFC8910-Dec10.php RFC8910-Dec10.php added
See Redmine #15904 Built-in Captive Portal Support for RFC8910, DHCP option 114 in Kea.
Note: this is a Kea upgrade issue with 24.11 Stable patched per Redmine #15321. Impacted are index.php and support for DHCP option 114, "v4-captive-portal" in Kea.
I repeat from REdmine #15904:
Support for Kea requires handling the Reclamation and reassignment of IPs which has changed dramatically from that implemented in the ISC DHCP server. Captive Portal tracks authentication by checking IPs when in actual fact the Captive portal authorization is associated with the MAC address, not the IP. This is an issue with Kea as the IP of authenticated users can change "over a lunch break" and when the device returns, it's IP may have been reassigned. Thus, RFC8910 DHCP option 114 support ("v4-captive-portal") must check the MAC address against the Captive Portal database and index.php in Captive Portal must re-associate the current IP with the already authorized MAC to avoid confusion when the IP address is checked by the Captive Portal code within pfSense.
To demonstrate one possible approach, I have attached a copy of a bench test file for both RFC8910.php and index.php that demonstrates how this might be achieved. These files are intended for use on pfSense 24.11 Plus (Stable) with Kea enabled and utilizing the patch from Redmine #15321 (https://redmine.pfsense.org/issues/15321) to support Smart devices through RFC8910, DHCP 114.
The attached files indicate how this concern can be addressed by emphasizing that it is the MAC address that identifies if a Captive Portal user is authenticated. If IP is used, the user idle timeout must be less than the DHCP IP lease duration. This creates many logins which did not occur in configurations using ISC due to the way leases are reclaimed and reallocated in Kea vrs ISC.
This will break many fully functional captive portal installations upon upgrading from ISC to Kea, despite the fact pfSense users were warned of the DHCP lease duration vrs idle timeout in the GUI. The simple fact is that this reliance on IP is unnecessary and using the MAC to validate authentication not only works around the issue but also drastically simplifies the upgrade ISC->Kea and improves the functionality of Captive Portal by a massive reduction in the require number of logins on the part of end users. The current Captive Portal code does not need to be modified, just index.php does.
The attached code demonstrates this principle and one approach to implementing it.
Updated by Dale Harron 21 days ago
- File index-2411-Dec11.php index-2411-Dec11.php added
I see in the RFC8910-Dec10.php file that there is a stupid commenting error, you have to remove the /*... */ from lines 153 and line 180 or it will give a crash report. I must have broken a “mixed comment symbols” rule.
Updated by Dale Harron 21 days ago
- File RFC8910-Dec11.php RFC8910-Dec11.php added
In order to fully support the assumption that it is the MAC address that authorizes the device through the captive portal, it was necessary to call index.php through the DHCP 114 JSON if the IPs didn't match, even if the MACs do match. This will result in the device being redirected to the logout screen in the temp browser on an iPhone for example if the IP has changed since their last connection.
A revised RFC8910.php file is attached that implements this as well.
Updated by Dale Harron 18 days ago
This issue does not solely occur due to Clearing of Leases through the GUI, it also occurs through normal lease expiry due to a change in the way Leases are reallocated in Kea. Although this can be avoided, any site that implemented Captive Portal with minimizing logins in mind and taking advantage of the way ISC allocates the oldest expired lease, resulting in the same IP being assigned nearly 100% of the time on lightly loaded networks. These will now break with Kea.
To ensure this is presented fully, I suggest you read https://kea.readthedocs.io/en/kea-2.4.0/arm/lease-expiration.html. In particular that Lease Reclamation occurs very soon after lease expiry as the default. In addition to this, Kea re-allocates the lower numbered IPs in the range as a priority. This results in a recently expired IP lease going to a new device. If Captive Portal has a longer timeout set for the Idle Timeout (or none set), the Captive Portal associates the authentication with the IP, not the MAC. If a login occurs, this will result in two devices authenticated with the same IP. Neither may work right or the second device may be assumed to already be authenticated and will not be able to login. The revised index.php fixes this by checking for authentication by MAC and if there is a conflict, will set the original, now expired, IP to "OFFLINE", thus retaining the authentication until that client connects with a new IP.
In order to accommodate this on smart devices using DCHP option 114, the RFC8910.php file was modified to return a "false" to the login state if both IP and MAC do not match that in the Captive Portal Database.
Updated by Dale Harron 16 days ago
- File index-2411-Dec17.php index-2411-Dec17.php added
Improved comments and removed test code from index.php Dec 17, 2024