NEW Package: freeRADIUS 2.x

Nachtfalke

Hi,

if you select the CA and server cert on freeradius2 GUI -> EAP and the click save then the CA and server certifficate will be placed here:

/usr/local/etc/raddb/certs/

So if you just delete the CA and/or server cert on the pfsense built-in cert manager this does NOT mean it will be deleted in freeradius2 folder.
I know this is not an elegant solution but till now and until someone adds some more code this will not change.

After deleting the CA and/or the cert in the built-in manager you have to go to freeradius2 GUI -> EAP and and chose the new CA. The problem is - if you are not using any CA and server cert - freeradius2 will not start. (That is the reason why by default the not recommended freeradius2 cert manager is enabled).

The same is with the Certificate revocation List. The CRL on the pfsense built-in cert-manager will not be recognized by freeradius2 at the moment. This feature needs some more code.

When using only TLS then you should set the option "disable weak EAP types" on freeradius2 GUI -> EAP.
Further you can try to use "Check Cert Issuer"

Check this for more information:
http://doc.pfsense.org/index.php/FreeRADIUS_2.x_package#EAP-TLS

I was editing my reply when you posted :)

Thanks for the information. I didn't actually actually try to remove the CA but that's definitely good to known. I'll have a look at the certificate in /usr/local/etc/raddb/certs/ out of curiosity.

I did disable weak EAP types. I still not sure about the difference between PEAP and TTLS. It seems PEAP also uses some kind of TLS tunnel.

I've head about MS-CHAP v2 being vulnerable (https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/). With "disable weak EAP types" checked, Freeradius doesn't allow plain ms-chap-v2 right? Only in a TLS tunnel if I understood correctly ?

It would be great to be able to use Certificate revocation List. I guess there has to be some way to manually create a Certificate revocation List for Freeradius? Any pointer is welcome.
That would certainly be better than nothing if I were to misplace one of my certificate/device. Having to start a fresh CA would take some time, even if it's only for my home network.

Ok I figured out how to use crl… it's manual and clearly a hack but it does work. :)
This for when using Freeradius with the Pfsense cert manager.
EDIT: Actually it doesn't work properly... it actually reject all connection.

1. Go to the Pfsense Cert manager and create en internal Certificate Revocation List for the CA used for Freeradius2. (if not already created)

2. Edit the Certificate Revocation List and revoke a certificate.

#Because Freeradius has no idea about this Certificate Revocation List you will still be able to use the certificate a this point.

3. Export the Certificate Revocation List.

4. Edit /usr/local/etc/raddb/certs/ca_cert.pem and append the Certificate revocation list at the end.

5. Edit /usr/local/etc/raddb/eap.conf and uncomment the line "check_crl = yes"

6. Restart the Freeradius2 server (There is probably a better way to reload the configuration file but I simply stoped it and restarted it from the Pfsense web interface)

Now try to connect with the revoked certificate. You shouldn't be able to connect. Look at /var/log/radius.log for more info.

You should have something like this:

Error: --> verify error:num=12:CRL has expired
....
Auth: Login incorrect (CRL has expired)

IMPORTANT: By going to the Freeradius2 eap preference page and clicking on save, the package will generate a new eap.conf with the crl line commented out! Have to be careful !

If someone knows of a better way to edit the default configuration, I'll be interested.

Nachtfalke

@arekkusu:

Ok I figured out how to use crl… it's manual and clearly a hack but it does work. :)
This for when using Freeradius with the Pfsense cert manager.

1. Go to the Pfsense Cert manager and create en internal Certificate Revocation List for the CA used for Freeradius2. (if not already created)

2. Edit the Certificate Revocation List and revoke a certificate.

#Because Freeradius has no idea about this Certificate Revocation List you will still be able to use the certificate a this point.

3. Export the Certificate Revocation List.

4. Edit /usr/local/etc/raddb/certs/ca_cert.pem and append the Certificate revocation list at the end.

5. Edit /usr/local/etc/raddb/eap.conf and uncomment the line "check_crl = yes"

6. Restart the Freeradius2 server (There is probably a better way to reload the configuration file but I simply stoped it and restarted it from the Pfsense web interface)

Now try to connect with the revoked certificate. You shouldn't be able to connect. Look at /var/log/radius.log for more info.

You should have something like this:

Error: --> verify error:num=12:CRL has expired
....
Auth: Login incorrect (CRL has expired)

IMPORTANT: By going to the Freeradius2 eap preference page and clicking on save, the package will generate a new eap.conf with the crl line commented out! Have to be careful !

If someone knows of a better way to edit the default configuration, I'll be interested.

Hi arekkusu,

you can edit the "freeradius.inc" in /usr/local/pkg/freeradius.inc on line 1022. This will make the changes permanent even if you click "save" on freeradius -> EAP GUI.
What I would prefer is if there is a way to select the CRL on the freeradius GUI like it is possible with the CA and the other certificates but I do not have the php skills to solve this :-(

So my intention is that the user generates all CAs, certificates and CRLs on pfsense cert-manager, then go to freeradius and just select them. If something on the CRL has changed the user just has to go to the freeradius GUI and re-save the EAP part to generate the new CRL for freeradius.

The check_crl part on eap.conf - I will try to add this as an option to the GUI. But this will not avoid to do your steps 1 - 4
Can you please explain me a little bit more in detail what you did on step 4 and where you found the description for that on the internet ?

Thank you for your help!

My how-to actually doesn't work. I though it was working but I latter realized it wasn't accepting any connection. It seem the "(CRL has expired)" in the logs is Freeradius not being happy abou the CRL / not finding it.

About step4, I did read this somewhere on the Internet, I just can't find the link. I actually seem that putting it in a separate "crl.pem" might be the standard way though. ???

I've found some interesting information here: http://www.breezy.ca/?q=node/223

I've tried to add the crl_file = ${raddbdir}/certs/crl.pem in eap.conf and createated crl.pem but it still won't use the certificate revocation list (it reject everything). I know little about openssl so I am not sure if the crl is in the good format.

Altercation

The freeradius2 wiki page is one of the better doc pages I've read for pfsense. I wanted to point out a minor error (or rather a possible point of confusion) in the wiki page:

Where the initial localhost radtest is performed, the sample command includes "username password" and, while this should be clear enough to anyone setting up RADIUS, the command should be correct from:

radtest username password 127.0.0.1:1812 0 testing123

to:

radtest testuser testpassword 127.0.0.1:1812 0 testing123

Nachtfalke

@Altercation:

The freeradius2 wiki page is one of the better doc pages I've read for pfsense. I wanted to point out a minor error (or rather a possible point of confusion) in the wiki page:

Where the initial localhost radtest is performed, the sample command includes "username password" and, while this should be clear enough to anyone setting up RADIUS, the command should be correct from:
radtest username password 127.0.0.1:1812 0 testing123
to:
radtest testuser testpassword 127.0.0.1:1812 0 testing123

Fixed.
Thanks :-)

I agree the freeradius2 wiki page is really useful. I wouldn't have managed to made freeradius work without it.

I still haven't managed to get a Certificate revocation list working with freeeradius2. I've basically abandoned using EAP-TLS and I am only using EAP-TTLS with MSChapv2 inner authentication.

I got it working fine on Ubuntu (network manager), Android 4, Nokia n900 and windows. Figuring how to add the certificate and use it in windows is the most complicated by far. And EAP-TLS seems even more complicated (I tried but didn't manged to get the client certificate to work).

EAP-TTLS should be fine in term of security if used properly (with good password of course). The only (huge) problem seem to be devices that don't properly check the CA certificate… either because they were badly configured, the user ignored a warning or are just plain broken.

Sailorsknot

I've setup a user with a "download limit" and set cron jobs to reset each night. I set "$PORTAL_MESSAGE$" on captive portal Authentication error page. When user reaches the "download limit" user is presented the captive portal logon page, and after user enters valid username/password, the captive portal error pages replies "invalid user credentials". Anyway to change this to change this? (ie: download limit reached, etc.)?

I don't known about the captive portal, I don't use it. Hope you can figure something out.

Personally I've tried setting using the account expiration (at a specific date) feature in Freeradius2 and it doesn't seem to work. If I put a date in the past (using the format "Jan 01 2012") the account seems to still be valid. If I put the date of tomorrow and wait until the next day the account is still valid.

I would really like to make this feature work to create guest account valid for a few days. Anyone using it? According to the Freeradius2 package wiki page this feature should work.

Alternatively if I could could do a script that would enable me to add/remove user account this could work too. Just changing the configuration file manually doesn't seem to reflect the change in Freeradius even after restarting the service.

Nachtfalke

@arekkusu:

(…)
Personally I've tried setting using the account expiration (at a specific date) feature in Freeradius2 and it doesn't seem to work. If I put a date in the past (using the format "Jan 01 2012") the account seems to still be valid. If I put the date of tomorrow and wait until the next day the account is still valid.

I would really like to make this feature work to create guest account valid for a few days. Anyone using it? According to the Freeradius2 package wiki page this feature should work.
(...)

This feature is not described on freeradius2 wiki page. Here is a description of how it should work:
http://lists.freeradius.org/pipermail/freeradius-users/2009-December/043702.html
Check the users file if the syntax is correct after you entered that in the GUI.

Not sure if it will work if you set a "Session-Timeout" on freeradius GUI, too. It could be possible that "Session-Timeout" and "Expiration" will not work correctly when used together because "Expiration" sends a Session-Timeout to CP and "Session-Timeout" will be, too. This could be a conflict.

But to make sure that CP understands Session-Timeout you have to enbale it on CP page.

 	Use RADIUS Session-Timeout attributes
When this is enabled, clients will be disconnected after the amount of time retrieved from the RADIUS Session-Timeout attribute.

itbit

Hi,
I've been looking into the freeradius and the XMLRPC part of it
I ran into certain issues because I'm trying to replicate with mobile networks that might be within internet range or not (trucks and boats…)

during my tests the XMLRPC seems to hang when the device it is trying to replicate to does not responds (not sure what is the time out period if any)

I looked at the code... but with my limited knowledge what I figure out I could do is actually to select the destination servers before I do the changes
to have that ability I modified the package the following way.

in
/usr/local/pkg/freeradiussync.xml
I added a check box for each destination server so we can choose which one we want to syn at that moment

<field><fielddescr>Destination Server</fielddescr>
<fieldname>none</fieldname>
<type>rowhelper</type>
<rowhelper><rowhelperfield><fieldname>varsyncdestinenable</fieldname>
<type>checkbox</type></rowhelperfield>
<rowhelperfield><fielddescr>GUI Protocol</fielddescr>
<fieldname>varsyncprotocol</fieldname>
<description>http or https]]></description>
<type>select</type>
<default_value>HTTP</default_value>
<options><option><name>HTTP</name><value>http</value></option>
<option><name>HTTPS</name><value>https</value></option></options></rowhelperfield>
<rowhelperfield><fielddescr>GUI IP-Address</fielddescr>
<fieldname>varsyncipaddress</fieldname>

<type>input</type>
<size>15</size></rowhelperfield>
<rowhelperfield><fielddescr>GUI Port</fielddescr>
<fieldname>varsyncport</fieldname>

<type>input</type>
<size>3</size></rowhelperfield>
<rowhelperfield><fielddescr>GUI Admin Password</fielddescr>
<fieldname>varsyncpassword</fieldname>

<type>password</type>
<size>20</size></rowhelperfield></rowhelper></field>

–---------------------------------------------
in
/usr/local/pkg/freeradius.inc

I updated freeradius_sync_on_changes() so it would look at the check box and execute the line if it is enable for that server

function freeradius_sync_on_changes() {
global $config, $g;
$varsyncenablexmlrpc = $config['installedpackages']['freeradiussync']['config'][0]['varsyncenablexmlrpc'];

// if checkbox is NOT checked do nothing
if(!$varsyncenablexmlrpc) {
return;
}

log_error("FreeRADIUS: Starting XMLRPC process (freeradius_do_xmlrpc_sync).");

// if checkbox is checked get IP and password of the destination hosts
foreach ($config['installedpackages']['freeradiussync']['config'] as $rs ){
foreach($rs['row'] as $sh){
// if checkbox is NOT checked do nothing
if($sh['varsyncdestinenable']) {
$varsyncprotocol = $sh['varsyncprotocol'];
$sync_to_ip = $sh['varsyncipaddress'];
$password = $sh['varsyncpassword'];
$varsyncport = $sh['varsyncport'];
if($password && $sync_to_ip && $varsyncport && $varsyncprotocol)
freeradius_do_xmlrpc_sync($sync_to_ip, $password, $varsyncport, $varsyncprotocol);
}
}
}
log_error("FreeRADIUS: Finished XMLRPC process (freeradius_do_xmlrpc_sync).");
}
–-------------------------------------------

Can anyone validate that these changes make sense and that I'm not breaking something else by doing this?
also if helpful for anybody else can it be committed to future releases of the package?

Cheers,

marcelloc

Did you tested it? For me it looks fine.

Nachtfalke

Not sure if it makes sense to select the hosts you want to sync. If you do not want to sync a host just delete it. Why using an extra checkbox for that ?
I do not think this is really usefull because in general you want to have the same content everywhere.

Perhaps another/better option could be to make the timeout editable. I am not familar with XMLRPC code but it seems to be at 150s (2m30s).
Try to change the value on this lines in "freeradius.inc" to al value of - lets say - 20s

The lines

Marcello, can you confirm that these are the values for the XMLRPC timeout ?

marcelloc

@Nachtfalke:

Not sure if it makes sense to select the hosts you want to sync. If you do not want to sync a host just delete it.

Sometime admin wants just to disable sync host instead of delete it. sarg schedule tab has this checkbox too.

@Nachtfalke:

Marcello, can you confirm that these are the values for the XMLRPC timeout ?

Following code comment, it looks like a timeout

/* send our XMLRPC message and timeout after 150 seconds */
		$resp = $cli->send($msg, "150");

itbit

Hi marcelloc and Nachtfalke,

thanks for the follow up,
I'm currently testing and so far so good
I think adjusting the timeout will meet my needs in a better way
I still like the idea of having the option of disabling a server without having to delete it as in my case I'm managing about 7 mobile networks that are installed in boats and usually go out of range
hence there is a big chance that at least four or of them will not be available when i do a new entry on the radius server (that is where the time out helps)
but sometimes some of this boats are down for maintenance for a few month and in that case I would like to stop the replication to them without having to delete the entry (that is where the check box for the Destination server helps)

So far I have check the backup file for the pfsense settings and the entry for the check box is there :)
I also added an extra line to the function freeradius_sync_on_changes() so it will log the servers that are disable
(not a big deal, but it is nice to double check that it is actually doing what it is supposed to be doing)

–-----------------------------------------------------------------------------------------------------------
function freeradius_sync_on_changes() {
global $config, $g;
$varsyncenablexmlrpc = $config['installedpackages']['freeradiussync']['config'][0]['varsyncenablexmlrpc'];

// if checkbox is NOT checked do nothing
if(!$varsyncenablexmlrpc) {
return;
}

log_error("FreeRADIUS: Starting XMLRPC process (freeradius_do_xmlrpc_sync).");

// if checkbox is checked get IP and password of the destination hosts
foreach ($config['installedpackages']['freeradiussync']['config'] as $rs ){
foreach($rs['row'] as $sh){
// if checkbox is NOT checked do nothing
if($sh['varsyncdestinenable']) {
$varsyncprotocol = $sh['varsyncprotocol'];
$sync_to_ip = $sh['varsyncipaddress'];
$password = $sh['varsyncpassword'];
$varsyncport = $sh['varsyncport'];
if($password && $sync_to_ip && $varsyncport && $varsyncprotocol)
freeradius_do_xmlrpc_sync($sync_to_ip, $password, $varsyncport, $varsyncprotocol);
}
else {
log_error("FreeRADIUS: Sync with {$sh['varsyncipaddress']} is disable");
}
}
}
log_error("FreeRADIUS: Finished XMLRPC process (freeradius_do_xmlrpc_sync).");
}
–---------------------------------------------------------------------------------------------------

Cheers,

Nachtfalke

Hi itbit,
Hi marcello,

I am going to be on holliday the next two weeks. I don't want to add some code which could (but probably will not) cause a problem with the package. If you are able to do some tests please feel free to add these changes to the package on github. I think the both options - change the timeout value and to disable/enable temporarily some hosts will be a good improvement.

Thanks for your help!

itbit

Hi Nachtfalke and Marcelloc,

I have updated both freeradius.inc and freeradiussync.xml to allow the modification of the default XMLRPC timeout from the GUI
I also added the checkbox option for selecting to which servers we want to sync

both files have been attached to this post.

I also tried (but failed) to include an option to specify the user name for the account that will sync because in some of my Pfesnses I changed the default username from 'admin' to something else
but it works out that 'admin' is hardcoded in several places including xmlrpc.inc…

hopefully this all looks right to you, so far I have tested and is working as expected.

Cheers,

freeradius.inc.txt
freeradiussync.xml.txt

marcelloc

itbit,

push it via github.

It will be easier to check changes and commit on current code.

https://github.com/bsdperimeter/pfsense-packages

itbit

Well… It took me a bit to figure it out
but I think I got it.
i proposed the changes at
https://github.com/bsdperimeter/pfsense-packages/tree/master/config/freeradius2

Cheers,

NEW Package: freeRADIUS 2.x

in /usr/local/pkg/freeradiussync.xml I added a check box for each destination server so we can choose which one we want to syn at that moment

I updated freeradius_sync_on_changes() so it would look at the check box and execute the line if it is enable for that server

in
/usr/local/pkg/freeradiussync.xml
I added a check box for each destination server so we can choose which one we want to syn at that moment