CP using IP address for radius session not username

[guntery]

Hi all,
We use an external radius server and have 30 day sessions so the user logs in once only.

When the session is online it keeps the last IP address used even when the client is offline.

I just found when a new client uses that IP the CP thinks its from that session so shows the status page rather than the captive portal login.

I can then click disconnect and it redirects correctly.

So it should not be using the IP right? It should be the username.

[Gertjan]

@guntery

You could use the IP, but be sure you the IP POOL of the DHCP is big enough.
Over a month, if there are more devices as IPs in the DHCP pool, in that month, an IP can get assigned to a device, and later on assigned to another device.

A User+Password combination is more adequate.

[guntery]

I mean the new client gets the same IP as a existing radius user session.

That IP is no longer in use.

But when the new clients (with that IP) redirect happens the code sees the same IP as a current session rather than using the username so it shows the status page ("portal is connected").

But it isn't connected as it hasn't logged in...

Any ideas on where the redirect logic is?

https://www.reddit.com/r/PFSENSE/comments/95bppt/captive_portal_shows_auth_success_page_instead_of/

[Gertjan]

@guntery said in CP using IP address for radius session not username:

I mean the new client gets the same IP as a existing radius user session.

That IP is no longer in use.

But when the new clients (with that IP) redirect happens the code sees the same IP as a current session

It's not the same session, as, yes, the IP is the same but the MAC addresses is different.

What happens depends on

@guntery said in CP using IP address for radius session not username:

https://www.reddit.com/r/PFSENSE/comments/95bppt/captive_portal_shows_auth_success_page_instead_of/

That redit is more then 5 years old.
If you use 2.6.0 or before (now all old), then your captive portal is based on ipfw.
ipfw is not pf.
ipfw uses it's own rule set, you can (could) only show them on the command line interface, SSH (or console).

pfSense 23.05.1 and 2.7.0 use the more modern approach : just one firewall, pf, for everything, captive portal included.

@guntery said in CP using IP address for radius session not username:

Any ideas on where the redirect logic is?

Sure. As me, you use pfSense. It's pretty 'open', so why not have a look ?

To see the rules : easy : forget the GUI, have a look at actual pf rules that are used right now.
This is the file : /tmp/rules.debug

Group all "# Captive Portal" together :

The captive portal interface IP put in a table (there can be more then one portal on a pfSense box ) :

# Captive Portal
table <cpzoneid_2_cpips> { 192.168.2.1}

Tag all traffic coming into the portal interface with the tag "cpzoneid_2_rdr"
Define 3 anchors (tables) which will contain authorized devices by MAC and/or IP

# Captive Portal
ether pass on { igc1  } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/*" on { igc1  }
ether anchor "cpzoneid_2_passthrumac/*" on { igc1  }
ether anchor "cpzoneid_2_allowedhosts/*" on { igc1  }

Redirect all traffic which is tagged "cpzoneid_2_rdr" with a non-portal IP destination and http(s) port to the portal IP, port 8003 or 8002.

# Captive Portal
rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8003
rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002

Permit traffic to and from the portal IP (port 8002 http or 8003 https)
And finally : block eveything else

# Captive Portal
pass in quick on igc1 proto tcp from any to <cpzoneid_2_cpips> port 8003 ridentifier 13001 keep state(sloppy)
pass out quick on igc1 proto tcp from 192.168.2.1 port 8003 to any flags any ridentifier 13002 keep state(sloppy)
pass in quick on igc1 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13003 keep state(sloppy)
pass out quick on igc1 proto tcp from 192.168.2.1 port 8002 to any flags any ridentifier 13004 keep state(sloppy)
block in quick on igc1 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13005

When a user/device is authorized, the pf GUI Portal rules still apply.
You can find your rules after

# User-defined rules follow

There is one other detail : see the portal login page web 'nginx' server setup file :

/var/etc/nginx-cpzone1-CaptivePortal.conf

( the file name depends on the name of your portal zone name)

You'll find :

		if ($http_host ~* 192.168.2.1) {
			set $cp_redirect no;
		}
		if ($http_host ~* portal.brit-hotel-fumel.net) {
			set $cp_redirect no;
		}

		if ($cp_redirect = '') {
			rewrite	^ /index.php?zone=cpzone1&redirurl=$request_uri break;
		}

This is where the "http" redirect happens.

There is also a https version of this file.

Keep in mind : https can't be redirected ( !! ) but this isn't an issue because there is one more player in the game : the device you use. Devices with a modern OS (last 10 years ?) use a captive portal detection method : they fire a 'hidden' http (not https !) request as soon as their interface (wifi or cable) comes up.
You can see this hidden http request in the Status > System Logs > System > GUI Service log file.

See also : Troubleshooting Captive Portal.

edit : remember : keep it simple.
Use unique 'login user names', every one with their password.

My user names are actually "hotel room numbers".
The password is shown on the wall in the room - and shown on the TV screen when the client puts on the TV.
The password is also shown in the room directoty, a PDF file the user gets thrown at as soon as he connects to the Hotel Wifi SSID "MyHotelWifi". This SSID is of course 'non secured', so no WPA2 or whatever. This is not an issue (again) as the access to my captive portal login page will happen over https:// !! ( so very secured ).
Pure BS of course, as why would I secure a users login, when he is using his room number as a user name, and a password that is the same for every user (please don't tell any one ).
As soon as the connection is granted, every other connection will be made over TLS (https). Mail, web pages, are all TLS these days. So, a non secured Wifi isn't a big deal.
Captive Portal users that have actually looked at the right Youtube video's will kick their VPN ISP after portal connection : now, everything will be hidden, DNS included, so I can't see anymore that they have visited gmail and facebook.

On my side, if I suspect that a (hotel/portal) client uses our Internet connection to get their hands on the launch codes of the governments nucks, I activate my own VPN, and route the entire captive portal over this VPN. I end-point it of course in the middle of Moscou or Pekin (or New York)

[guntery]

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:42

It 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

[Gertjan]

@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.

[Gertjan]

@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).

[Gertjan]

@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.

[guntery]

@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!

[Gertjan]

@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 ^^

[guntery]

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

[Gertjan]

@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 then

radiusd -X

Use 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.

[guntery]

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.

[serginho]

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

[Gertjan]

@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.