FreeRADIUS 3.x package coming - BETA for TESTING

johnpoz

Ok looks good! I uninstalled 2 and installed 3 (0.3.4) running on my 2.4 snap dated Mon Jun 12 09:21:37 CDT 2017

My eap-tls clients are authing just fine.. Have not time to try changing anything.. And have not upgraded pfsense snap or rebooted it yet, anything like that - but looks like its workable for eap-tls for sure.

freerad3working.png_thumb

jimp

Great!

I'm still fighting the counter module(s), but other tests have been positive so far. I still expect some trouble from corner cases that aren't so commonly used.

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.