FreeRADIUS 3.x package coming - BETA for TESTING

jimp

How did those look in FreeRADIUS 2.x?
What specific settings are in place for those users in the GUI?

Hugovsky

I have vlan assigned by radius.

In 2.x it was like this:

"tosh" Cleartext-Password := "asdadadada", Simultaneous-Use := "1"

Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = "3"

I have it working by editing /usr/local/etc/raddb/users by hand and correcting those errors above. Removed the ; and
Session-Timeout := 3600,

Restarted the service in GUI without saving and voilá. It worked.

EDIT: I use unifi APs and controller and have it configured so users get vlan assigned by the radius.

jimp

OK I think I got those formatting issues fixed, whenever 0.5.1 shows up give it a shot.

Hugovsky

Thanks jimp. It's working now.

jimp

Great!

I think at this point it's passed all of the tests that I had written down. I'd still like to see some more feedback though before I declare it ready for general use. Definitely progressed past Alpha and into Beta territory though at least.

Hugovsky

That's good news. I think it's ready at least to beta. I even solved a problem I had with my mpower strip not authenticating.

Hugovsky

Jun 16 11:13:41 	radiusd 	31670 	Ready to process requests
Jun 16 11:13:41 	radiusd 	31670 	Loaded virtual server default
Jun 16 11:13:41 	radiusd 	31670 	Loaded virtual server inner-tunnel-peap
Jun 16 11:13:41 	radiusd 	31670 	Loaded virtual server inner-tunnel-ttls
Jun 16 11:13:41 	radiusd 	31670 	Ignoring "ldap" (see raddb/mods-available/README.rst)
Jun 16 11:13:41 	radiusd 	31670 	Ignoring "sql" (see raddb/mods-available/README.rst)
Jun 16 11:13:41 	radiusd 	31670 	Loaded virtual server <default>Jun 16 11:13:41 	radiusd 	31670 	[/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay-USec" found in filter list for realm "DEFAULT".
Jun 16 11:13:41 	radiusd 	31670 	[/usr/local/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay" found in filter list for realm "DEFAULT".
Jun 16 11:13:40 	radiusd 	30527 	Debugger not attached
Jun 16 11:13:25 	php-fpm 	49443 	[pfBlockerNG] Starting cron process.
Jun 16 11:13:25 	php-fpm 	49443 	/rc.start_packages: Restarting/Starting all packages.
Jun 16 11:13:24 	check_reload_status 		Starting packages
Jun 16 11:13:24 	check_reload_status 		Reloading filter
Jun 16 11:13:22 	pkg 		pfSense-pkg-freeradius3 upgraded: 0.5.1 -> 0.6_4</default>

Where's that error coming from?

EDIT: Might not be a real error. Just a warning. What do you think, jimp?

johnpoz

Seems to be cosmetic

https://github.com/FreeRADIUS/freeradius-server/pull/1216#issuecomment-138924345

http://lists.freeradius.org/pipermail/freeradius-users/2015-October/080219.html

Short version: that warning is harmless. If you want to get rid of it,
just remove the two lines from attr_filter/access_reject, there will be
no behaviour changes.

Longer version: The check you're seeing tries to warn us that we allow
an attribute in the reply-list that we cannot send in an Access-Reject.
The functionality has been added in PR #1216 to allow packet specific
overrides of the reject_delay, so in this case we're not adding the
attribute to send it to the client, but we're adding it to change
something inside FreeRADIUS.

I guess there are two simple options to remove this warning:

Set those attributes in another list than reply

Remove the warning from rlm_attr_filter

Hugovsky

:D You beat me to it. I was just adding that to my previous post. Thanks for checking.

jimp

Yeah that seems completely cosmetic, it doesn't actually say "error"/"warning"/"failure" like some other messages do.
I'm not terribly worried about it, I'd just let it go.

johnpoz

Would seem simple enough to make it go away if you want.. I don't normally like stuff like that in a boot/start of a application ;) Prob fix it up at some point - the edit seems easy enough..

"just remove the two lines from attr_filter/access_reject, there will be no behaviour changes."

jimp

It is not as simple as that. Easy to say, but not easy to do from a package standpoint. We don't put those lines in and the file is part of the stock package. So we couldn't just edit the lines out. We'd either have to write out our own local copy of the file and overwrite that one each time, or concoct some scheme to remove the lines with sed, etc.

Since it's harmless, for now I'll just let it be.

johnpoz

oh not talking about in the package - I am talking for the user to edit out those if they don't like the the info.

I agree doing such a thing programmatically in the package script bit more difficult ;)

jimp

FYI- The package is now up for 2.3.4 users to test out, too.