CP using IP address for radius session not username
-
Thanks, am on 2.6. I can't see how this isn't a bug. (ill try 2.7)
The issue is authentication using IP address - IP shouldn't have anything to do with auth.
I removed a section from line 99 of /usr/local/captiveportal/index.php and got past that page.
the CP now shows this:
Zone: guest - CONCURRENT LOGIN - REUSING IP 10.1.1.12 WITH DIFFERENT MAC ADDRESS 60:32:b1:2b:a5:42It didnt work as its not that sessions mac.
Why you would want to reuse a session due to a different mac same IP?.I checked captiveportal.inc and it shows that logic, no idea how it implements it
if ($cpentry[2] == $clientip) { captiveportal_logportalauth($cpentry[4], $cpentry[3], $cpentry[2], "CONCURRENT LOGIN - REUSING IP {$cpentry[2]} WITH DIFFERENT MAC -
@guntery said in CP using IP address for radius session not username:
Thanks, am on 2.6. I can't see how this isn't a bug.
If you use 2.6.0 : the portal is massively broken 'out of the box';
You need the System Patches package, and apply the patches listed. If not, it's game over right away.There is no need to use the old 2.6.0 these days: 2.7.0 is there to make live less hard.
-
@guntery said in CP using IP address for radius session not username:
IP shouldn't have anything to do with auth.
The captive portal uses sessions. They are IP+MAC+User name + password.
Or IP+MAC+Voucher code.The IP and MAC are used to identify a session.
The firewall uses the IP and MAC to accepts or refuse a connection (authorization). -
@guntery said in CP using IP address for radius session not username:
I checked captiveportal.inc and it shows that logic, no idea how it implements it
if ($cpentry[2] == $clientip) {
captiveportal_logportalauth($cpentry[4], $cpentry[3], $cpentry[2], "CONCURRENT LOGIN - REUSING IP {$cpentry[2]} WITH DIFFERENT MAC$cpentry[2] is the session's user IP.
If the IP of the client is the same as one in a current (open) session, then the MAC stored in the session is replaced by the current user's MAC.
Depending on your choice of "concurrent login, or not".Don't stay on 2.6.0, it's depreciated.
-
@Gertjan said in CP using IP address for radius session not username:
If the IP of the client is the same as one in a current (open) session, then the MAC stored in the session is replaced by the current user's MAC.
That makes no sense and it dosent actually work.
It's beyond me why a completely different device might take over that session just because of same IP.I'll check 2.7 but am dubious!
-
@guntery said in CP using IP address for radius session not username:
That makes no sense and it dosent actually work.
The thing is : you might be right.
IIRC : the "Concurrent user logins" was somewhat flawed.Check https://redmine.pfsense.org/projects/pfsense/issues?set_filter=1&tracker_id=1 and go back in time.
To the right, select all "2.6.0" issues or even before.
Then filter by category "captive portal" issues - get the open ones, and the closed ones.But as said : all this dates from way back. Up to you to decide if you want to deal with old issues, or new ones ^^
-
2.7 is also broken...
I guess as there isnt many google hits it hasnt come up much. I would have thought the CP was used a lot though so thats weird.
I'll increase the dhcp pool, make the lease times 30 days and add some remove session code in radius to workaround
cheers for the help
-
@guntery
No need to Google a potential issue.If there was an issue, you go here : Home > pfSense
Software > Captive Portal - if the captive portal was broken, you would see many post about it.Do you really need to "CP using IP address for radius session not username" ?
Does it work when you use the classic "pfSense user Manager" as the authorization source with a user (username and password) ?And when you use FreeRadius : stop Freeradius in the GUI.
Open the console/SSH, option 8 and thenradiusd -XUse the portal, and see what happens on the console.
True, I'm not using 2.7.0 but 23.05.1 I'm using FreeRadius, the classic way : with usernames and password. It works fine.
Btw : I've used Google and "CP using IP address for radius session not username" and that shows a potential issue. No one uses the portal like that. At least, very little is know.
I agree, it should work. But if it was never tested : stay away from it. -
nothing to do with radius or auth.
the CP uses that $cpentry[2] line in its redirect method and if a session already has that IP when you connect it thinks that's your session
it disregards mac and username
I can't believe no one has seen this. It would happen a lot less if you say used ideltimeout or had much smaller sessions.
-
I also have the same problem, I'm glad the production ones weren't updated, but in the laboratory, but the captive portal has several bugs that I detected, including this one with the release of the ips, I already reviewed the entire source code, but as a lot of changes were made to it, the only way now is for the developer to recognize and correct this error
-
@guntery said in CP using IP address for radius session not username:
nothing to do with radius or auth.
I agree.
@guntery said in CP using IP address for radius session not username:
it disregards mac and username
It looks like that portal_allow() returns with the $sessonid. Portal firewall rules are not modified, so, while the IP is the same, the MAC will be different. No login page is presented, and no "Internet access" : that's your issue ?
That is, I could not create a situation with my setup where another device (another MAC) was using an IP that had already a session.
Typically, for my usage, Idle timeout (Minutes) is set to 360 and Hard timeout (Minutes) is set to 720 or 12 hours. The latter will remove sessions.
My DHCP leases on my captive portal are set to 86400 sec or 24 hours.@serginho said in CP using IP address for radius session not username:
for the developer to recognize and correct this error
Feel free to enumerate.
And as you walked through the code, you should be able to add lots of details.
