FreeRADIUS 3.x package coming - BETA for TESTING

Hugovsky

Thanks you all for your work on freeRadius 3. It's really appreciated.

jimp

@Hugovsky:

Thanks you all for your work on freeRadius 3. It's really appreciated.

You're welcome! It's been a lot of work but ultimately everything is better off.

jimp

0.4.1 is coming with a few fixes:

Fixed mOTP
Fixed PEAP
Fixed MAC auth

Also confirmed that both time and data counters work, trouble I had was due to not having the correct config setup. Matching everything against the docs I found a setting I had missed. Once that was set, both counter styles worked well.

Raul Ramos

With 0.4.1, PEAP is working with unifi AP and Android 7.0.1 device.

reggie14

This is great news! I'm glad FreeRADIUS 3 support is well on its way.

Any chance we can get some sort of "Advanced" tab in the webGUI to override the webGUI settings in the config files? In particular, I'd like to set up different certificates for PEAP and EAP-TLS (as described here). That sort of thing could plausibly be configured in the webGUI itself, but I recognize it may be of niche interest.

jimp

@reggie14:

This is great news! I'm glad FreeRADIUS 3 support is well on its way.

Any chance we can get some sort of "Advanced" tab in the webGUI to override the webGUI settings in the config files? In particular, I'd like to set up different certificates for PEAP and EAP-TLS (as described here). That sort of thing could plausibly be configured in the webGUI itself, but I recognize it may be of niche interest.

Not currently on my to-do list.

I do need to add some extra cert options as I plan on allowing MySQL+TLS and PostgreSQL+TLS so maybe I'll make separate TLS sections for EAP TLS/TTLS/PEAP while I'm at it.

Hugovsky

I think I might have found a bug.

/usr/local/etc/raddb/users

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

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

Shouldn't that end with a comma?

EDIT: or end-of-line?

Hugovsky

another:

"isola" Cleartext-Password := "12345678", Simultaneous-Use := "2"

Session-Timeout := 3600
,
blablabla

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.