Multiple sessions with the same MAC require re-authentication
-
This is new for me in 2.7.2. Prior to 2.7.2, captive portal was set up with ISC DHCP to allow multiple sessions per user. Everything worked great and users had an idle timeout of 1 month before the portal had them disconnected.
With the upgrade, I switched to Kea DHCP and that was the only change. Now in Captive Portal status, I notice several entries with the same MAC address and different IP. Users now complain that when they connect to the network, it requires re-authentication again, but if they access the portal login page, it says "you are already connected" and in the same time no Internet access is allowed.
Has anyone experienced this in the latest upgrade?
I'm thinking to revert back to ISC DHCP, but it's not clear why this should be the culprit at the moment. So far, my notion was that captive portal was checking MAC addresses only, but I may be wrong.
-
@salousama said in Multiple sessions with the same MAC require re-authentication:
captive portal was set up with ISC DHCP to allow multiple sessions per user. Everything worked great and users had an idle timeout of 1 month before the portal had them disconnected.
You better be sure that over one month, the same device (same MAC) will get always the same lease (IP).
@salousama said in Multiple sessions with the same MAC require re-authentication:
With the upgrade, I switched to Kea DHCP and that was the only change.
This suggests strongly that you know what to do to get the old behavior back ^^
@salousama said in Multiple sessions with the same MAC require re-authentication:
I notice several entries with the same MAC address and different IP .....
So far, my notion was that captive portal was checking MAC addresses only, but I may be wrong.These are different portal clients, and need individual logins.
A portal session = the same MAC and the same IP. -
@Gertjan Thank you for the response! You practically confirm my "fear" as well, that portal session = the same MAC and the same IP, I was under the impression that only MAC was used..
What is odd, is that with the ISC DHCP, I hadn't seen such occurrences and was wondering if anyone had an insight in the implementation of Kea, let alone this behavior..
TBH, I feel pretty uncomfortable with increasing a DHCP lease e.g. to one month, so I may be reverting back to ISC until we are forced to switch :P
One approach also would be to have Pass-through MAC Auto Entry enabled.
Anyway, apologies for the brainstorming, just trying to make it less "painful" for the users, while keeping a certain degree of security.
-
@salousama said in Multiple sessions with the same MAC require re-authentication:
TBH, I feel pretty uncomfortable with increasing a DHCP lease e.g. to one month,
Good feeling.
I've got no reel nice scientific story for you to say : make it 12 hours, or 24 max.
The client device, if it looses the connection (SSID goes out of range, client goes home, etc), and comes back next day, the Lease will be renewed and if the IP is available at that moment, the DHCP server will 'remember' that device with MAC aa:bb:cc:dd:ee:ff had an IP, and try to give it the same IP (again, if avaible)).
The DHCP client device will also send a request, and ask for the IP it had before (if the device wasn't rebooted, or did store the previous lease somewhere in a file). It will recognize the DHCP server because : same SSID and the same MAC of the DHCP server (I guess).@salousama said in Multiple sessions with the same MAC require re-authentication:
while keeping a certain degree of security.
A portal is 'secure' : the client can only go there where you allow them. Normally, that is the "Internet" only. The devices by themselves are already in 'public' mode so they only can communicate with the gateway == pfSense and nit with other devices on the same portal network. You can often enforce this with your access points.
The only real 'danger' is that portal clients can go hunting for the access codes to launch all the nukes, or start to download all the available Disney movies while using your WAN IP. As soon as you see black helicopters above you, and blacb vans around the building, its time to run. Remember : your are responsable for your connection, your ISP (and gouvernement) probably doesn't care that you decided to share your connection with some strangers ^^
In a worse situation : route your captive portal out over a VPN connection with an end point in Russia or Peking, and now you'll be save. -
Thanks again @Gertjan for the great response! For starters, I will tweak the DHCP lease to 12-24 range and keep an eye. Then we'll see I guess :P
BTW, now that I think of the session pfSense assumes, perhaps it's a ticket for the dev team to investigate that even though the client IP changes (MAC stays the same), the portal session is detected by the server and the portal login page prompts for a "Disconnect" ("you are already connected"). Then the clients press "Disconnect" and log in again, of course. I would expect from what we established above that pfSense would create a new session (MAC / IP mismatch) and prompt for login immediately.
