Captive Portal Timeouts and DHCP Lease Times

richardsago

Good day. I know the Captive Portal Idle and Hard Timeouts should be lower than the DHCP Default Lease Time and Maximum Lease Time. For a small school with dorm that has visitors (speakers, curriculum accreditors, etc) who stay at the dorm for 1 day up to three weeks, will there be any issues if these will be the settings?

DHCP Default Lease Time - change to 86400 seconds (24 hours)
DHCP Maximum Lease Time - leave at default of 86400 seconds (24 hours)
Captive Portal Idle Timeout - change to 720 minutes (12 hours)
Captive Portal Hard Timeout - change to 720 minutes (12 hours)

EDaleH

Officially your lease time is longer than your timeouts so Captive Portal clients will timeout before their lease expires as specified.

Now there is a lot more to this question than initially meets the eye. Captive portal keeps track of authenticated users by their Mac address. The database includes the IP so if an authenticated Mac shows up with a different IP (because the old DHCP lease expired), Captive Portal will be unstable and neither the currently authenticated Mac nor the unfortunate new device (that eventually gets that IP from the DHCP server) will work at all. I leave it to you to decide if this is by design or...

Along came the Kea DHCP Server, eventually replacing the ISC Server and another wrench is thrown into the works.

The ISC server recycles IP addresses based on age and it will reassign an IP to the same Mac every time if it is in the Configured Leases list, independent of how long ago it expired (this is "lease affinity"). If your DHCP pool is cycled on average every 30 days for example, you could break the Lease Time rule and set your Captive Portal timeouts to the 30 days but if the leases cycle in less than that, it will break as described above. If you have a low turnover in clients, you could go even longer. We have sites running a season (6 months) with only one login per client for that entire time as their client turnover is almost nill. This allows them to come and go, reconnecting without a login. Their entire business model is dependent upon that capability.
Next you have the new Kea server which is very different. It is flawed in that the "configured leases" are only valid until a reboot or reset of Kea. When this happens Kea reassigns IPs over top of configured leases and does not respect any "lease affinity" times beyond the original lease duration. Only active leases remain valid after a restart and all those that do not have a current active lease will be scrambled, thoroughly breaking Captive Portal. Thus, it is critical you follow the Captive Portal timeout < Lease Time rule.

To handle (work around) this with Kea, we use custom software modifications to test the Mac/IP pair in index.php and if they no longer match we enable a place holder , "NOIP", in place of the original IP used by Captive Portal (thus retaining the authenticated state) and pass through the new client Mac/IP to enable the captive portal timeout to exceed the dhcp lease time for all authenticated users. This requires a re-index of the captive portal database every time and can be cpu intensive. The RFC8910.php must also be modified to detect if the database lists a different Mac for the IP connecting and it will call index.php instead of passing them through if there is no match. See Redmine #15934 and Redmine #15904 if you want a more detailed discussion of this issue. Note that in #15904, the modified index.php has to be made specifically for each release of pfSense where the original index.php has changed and that the modified RFC8910.php must be used as well. One advantage of this approach is that you can have Captive Portals where the Captive Portal authenticated client logs in only once until the account itself expires, or until you delete the account. This dramatically increases the quality of the user experience.

So follow the rule to be safe or, if you are adventurous, use ISC server and set the timeouts to a safe value less than the time it takes to cycle through the entire DHCP pool. I you need to use Kea, you have to run modified index.php/RFC8910.php per Redmine #15904 and re-modify index.php for each release by comparing the previous index.php to the new index.php and moving any changes over to your modified file. (usually only one or two lines of code).

So either follow the CP timeout < Lease duration rule or if you need to reduce login frequency, be aware of what you are getting into in advance.

richardsago

Thank you @EDaleH for the reply. Just to be safe we will follow the captive portal timeouts should be less than the DHCP lease times.