Multiple login limits for captive portal voucher system

Gertjan

@Dmc said in Multiple login limits for captive portal voucher system:

Failed binding to auth address 127.0.0.1 port 18128 bound to server inner-tunnel-peap: Address already in use
/usr/local/etc/raddb/sites-enabled/inner-tunnel-peap[3]: Error binding to port for 127.0.0.1 port 18128

Initially i was getting this error on port 18127 - i reinstalled the freeradius package and then it shifted to 18128 .... any thoughts? :/

You've tried using plain default settings ?
Like :

And the client (pfSense user manager) side :

Btw : be ware that 10.10.10.1 is also use default by pfBlockerng - so be careful with that one.

Dmc

@Gertjan Auth Server.PNG

heres my settings - i believe they're identical.

So, i also attempted to delete the raddb files after uninstalling the package and reinstalling. the error moved to port 1812.... i reinstalled again and it moved to 18127 instead of 18128 port. i feel like im going in circles. is this even relevant?

Failed binding to auth address 127.0.0.1 port 18127 bound to server inner-tunnel-ttls: Address already in use
/usr/local/etc/raddb/sites-enabled/inner-tunnel-ttls[3]: Error binding to port for 127.0.0.1 port 18127

Gertjan

@Dmc said in Multiple login limits for captive portal voucher system:

Failed binding to auth address 127.0.0.1 port 18127 bound to server inner-tunnel-ttls: Address already in use

By who ? Ask pfSense ?!

[24.11-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4 | grep 'radiusd'
root     radiusd    33785 8   tcp4   192.168.1.1:14796     192.168.1.33:3307
root     radiusd    33785 11  tcp4   192.168.1.1:57128     192.168.1.33:3307
root     radiusd    33785 20  udp4   127.0.0.1:18128       *:*
root     radiusd    33785 21  udp4   *:1812                *:*
root     radiusd    33785 22  udp4   *:1816                *:*
root     radiusd    33785 23  udp4   *:1813                *:*
root     radiusd    33785 24  udp4   127.0.0.1:18127       *:*

Even if this port '18127' isn't set nowhere in the GUI - FreeRadius settings, it is used (hard coded) for the TLS 'inner' tunnel :

grep -R '18127' /usr/local/*

so if you use these also in your GUI settings then I can understand the error.

Also, your one and only different settings :

I have :

as 192.168.2.1 as the "Client IP" - an interface I used for my captive portal, the one using (indirectly) FreeRadius.
You have "127.0.0.1" there ... what happens when you use a LAN interface ?

Dmc

@Gertjan

So i did try using the LAN address in the past which did not appear to have made any impact. I also updated the NAS and Auth IP to 192.16.2.1 - same results. it appears to say 18128 is already bound.

Based on your recommendation on exploring the Radius files - i had also found it hardcorded in the peap files - thanks for pointing me in that direction.

when i run the stat command - i get the following:

Failed binding to auth address 127.0.0.1 port 18128 bound to server inner-tunnel-peap: Address already in use
/usr/local/etc/raddb/sites-enabled/inner-tunnel-peap[3]: Error binding to port for 127.0.0.1 port 18128
[2.7.2-RELEASE][admin@comencenet.comence.io]/root: sockstat -4 | grep 'radiusd'
root     radiusd    43508 14  udp4   127.0.0.1:18128       *:*
root     radiusd    43508 15  udp4   127.0.0.1:18127       *:*
root     radiusd    43508 16  udp4   *:1812                *:*
root     radiusd    43508 17  udp4   *:1813                *:*
root     radiusd    43508 18  udp4   *:1816                *:*

This is where im getting puzzled, i do not have anything bound to 18128 or 18127 anywhere in the GUI. I also ran the code to find any instances of 18128 within the firewall and it was only found once each in their respective peap files.

Now, im starting to wonder if i have two instances installed/running which is resulting in the conflict

Also, another thought - for my captive portal - should i have it First Login, Disabled or multiple? - Previously I had set as multiple and obviously the users were being permitted. So i thought next to set it to first and disabled.
Something interesting happened - i was not redirected to my "authentication failed" page - instead it was just a blank page. But internet access was not granted by the captive portal.

I had set the simultaneous connection as 1 on my radius, which granted a successful login despite being set to 1 connection. So, i suppose my Radius is the one that continues to fail ?

Also, assuming if it worked properly, should userlogin be set to multiple or first ?

Dmc

Based on your comment

I am suspecting that file-based accounting is not successful for FreeRadius on PfSense. I must use SQL?

https://forum.netgate.com/post/905308

Dmc

Alright, well i learned how to install SQL package directly on PfSense than installing it externally.

God bless this post:
https://forum.netgate.com/topic/96893/howto-captive-portal-freeradius-local-mysql-user-friendly-single-step/124

It walked me through how to enable it on the back-end and also provided the basic configurations and detailed steps

I have setup SQL and authentication appears to work, as well as all the attributes. However, im stil lgetting the 18128 error code when running the diagnostic on radiusd -X

AND, the accounting dosnt appear to be enforced...
sigh..

Dmc

@Gertjan

sockstat | grep 18128
netstat -an | grep 18128

When running these two, i always get the PID. its only one instance. I then proceed to kill the connection

kill -9 9765 (for example)

Afterwhich it appears that the radius starts running correctly as the diagnostic shows it listening every so seconds and updates the accounting.

However, if i restart or make changes to any antributes of the user then the error on port 18128 resurfaces

i also tried to change the port manually but then the error switches to whatever port number i use.

:(

Dmc

Hmm,

So based on reading other threadposts.

It appears the proper etiquette to run radius -X command would be to first stop the freeradius with the command service radiusd onestop and ONLY then initiate the diagnostic.

Else the error i was receiving is expected. I GUESS im back to square one, why isnt radius enforcing my stopaccounting.

Gertjan

@Dmc said in Multiple login limits for captive portal voucher system:

why isnt radius enforcing my stopaccounting.

You use this :

right ?

The interim option makes the pfSense side of the portal interrogating FreeRadius regularly.
After all, (Free)Radius is a server process = by itself, it dos nothing, until a client asks the server to do something.
The client is the pfSense software.
In the interim mode, and initial START access request is made, and when FreeRadius says "Ok, it's a pass" the user is logged in - access is granted.
Interim requests that follow (every 60 seconds I guess) the logged in user rights are re checked, and criteria can be : bytes used or time elapsed - FreeRadius can do much more, but the client, pfSense, is pretty dumb, and handle only these cases.

When you use "radius -X" on the command line, you can follow this process, you'll see that radius receives constant requests up until pfSense tells that the logged in user is termiantd (by the admin) or, from the Radius side, because a STOP event happened = access refused as the time elapsed (can be daily, weekly, monthly), or the max number of bytes consumed was reached.

Dmc

@Gertjan

Yes, i am using interim and also tested it with stop/start

I do not have the logs for the diagnostic mode but the outputs were as follows

concurrent connection limit was set to 1
Radius was aware that user4 was connected 4 times as the radius itself would show me connections
would always allow requests
stop was only sent if the credentials were incorrect

again, I am not sure if this helps but I was not using SQL. Instead the flatfile radutmp? i think is whats it called was being used. so perhaps that's why it wasn't being enforced properly

It says to read the documentation but where..? i went through it and only found this, the yellow box I think is referring to the captive portal configuration "first,last, multiple, disabled" so its implying it to be multiple

Source: https://docs.netgate.com/pfsense/en/latest/usermanager/index.html