Duplicate Captive Portal Sessions after Upgrade from 23.05 to 23.09.1
-
Earlier this week I upgraded my Netgate 6100 from 23.05 to 23.09.1 and captive portal sessions are no longer working correctly. Every day the connected devices are now prompting the user to re-authenticate. Before the update, once a device signed in, it wasn't prompted to authenticate again.
When I look at the captive portal status page, I can see multiple sessions per MAC address for many of the devices. I've attached a screenshot with colored lines to make it easy to see multiple sessions exist per MAC address.
Any tips or advice would be much appreciated.
-
The portal's session is based on "identical IP and MAC" pair.
If a device goes away from the network, comes back next day, but can't get the same IP, and gets another IP, the connection can't be reused, and another one has to be created.
Strange, though, as a device will recall the network, and 'prefer' the IP it had before. For some reason, the DHCP server won't (can' ?) give t the same IP again.
And another IP means : another session ?Try this :
also have a look at your DHCP server pool : is it big enough ?
Why would the same device (determined by : the seame MAC) get another IP the next day ?
You can inspect the DHCP server's memory/scratchpad : its a file : /var/dhcpd/var/db/dhcpd6.leasesI presume your hard time out is set (is it set ?) to a high value. As soon as the hard time is reached, devices are removed from the 'connected' table. Users have to re login, of course.
There is also the this mode :
= ones logged in, the MAC will be approved 'forever'.
Or are you working with vouchers ?
Btw : I'm using 23.09.1 myself for the last xx months now, and the portal is used as I run a hotel.
I'm using the classic "user + password" system and the FreeRadius only because I can do so (not really needing it). I've have not seen more then 15 devices connected at the same time, and clients don't stay very long. My hard time out is set to 8 hours - the DHCP lease time is set to 86400 or 1 day, already very high, but this helps in giving the same device the same IP if he stays more then one night.
My pool is 10->254 = 244 in size. -
@Gertjan Thank you for the detailed response. Your comments about the DHCP server reminded me that I had changed the DHCP server backend from ISC to KEA due to the deprecation warning in pfSense after the upgrade to 23.09. I've reverted it back to ISC to see if that resolves the issue.
The DHCP pool is 151 IPs and the number of clients is around 30 so I don't think I'm running out of IP space.
I saw the pass-through option but don't really want to use it. Our authentication for the captive portal uses LDAP (username + password) to our Windows DC, and users who are members of a specific AD group are allowed to connect to the WiFi.
The hard timeout is set to 6 months since the same employees use the network every day. This worked as expected before, but after the upgrade users were prompted to re-authenticate to the portal almost every day.
-
@njm135 said in Duplicate Captive Portal Sessions after Upgrade from 23.05 to 23.09.1:
I had changed the DHCP server backend from ISC to KEA due to the deprecation warning in pfSense after the upgrade to 23.09. I've reverted it back to ISC to see if that resolves the issue.
Because 'some one' says that ISC is depreciated doesn't means something changed.
I was test driving KEA for a while, and I didn't not rely on any special options, just the bare DHCP server, so there was no issue for me.
I had to go back, as I'm testing right now DHCP + a special DHCP option, and KEA doesn't support options yet.
That is : KEA supports them very well for years now, bit the pfSenbse front end isn't created yet.@njm135 said in Duplicate Captive Portal Sessions after Upgrade from 23.05 to 23.09.1:
The hard timeout is set to 6 months since the same employees use the network every day
IMHO, (build upon reading and posting during 12 years on this forum) : !!! Do not do that !!!
Your session database might get huge.Btw : the captive portal scripts that handles the login, the local "connected" users database and all that didn't chance since 22.xx.
And I don't want to say "I know it all", as I'm still learning today, but I can assure you that I know every line of pfSense portal code out of my head by now.I could consider "employees" as non trusted users, that's ok, I get that. I've a company to.
But I would use a captive portal for them.
The captive portal was invented for the people that walk into your place, you don't know them, they want an 'Internet' access as they, as usual, sucked up all their roaming data already. "Tourist" are a good example of this kind of users.
The captive portal can work just fine with 'thousands' of users, but, believe me, make that time out 'small' like several hours or a day. The pfSense portal has been build for those short lived, temporary connections. Not more.
The underling needed software can not be modified to make it faster, and now I'm not talking about the pfSense portal scripting part, but the addition and removal of firewall (pf) rules, pipes etc.So : what about using a MAC access based wifi for your employees network ? Or something like that.
Make something for those people that isn't a trusted network - although, you'll still share company resources, but isn't really a purely non trusted network (portal) neither ?All this said, a portal with a couple of hundred semi permanent users should work just fine.
As you use LDAP etc, can't you use that to control access on a AP level ? So you don't have the need to 'portal' users ? -
@Gertjan Thank you for all of the info regarding the captive portal. The APs in the facility don't support LDAP authentication, hence the use of the captive portal. They do support Radius, but I don't have a Radius server running/integrated with AD at this time, so the captive portal was a quick way to get something working with LDAP. Management doesn't want all employees to have access to the WiFi, and since the password on the WiFi can be easily shared and is cumbersome to change, the captive portal is the current solution. We do use MAC address access control for company devices, but not for personal devices of employees who are authorized to use the WiFi. I'll probably look into adding a Radius server so we can just perform the authentication at the AP level instead of the captive portal.