- Freeradius-Users - lists.freeradius.org

tls tunnel stability fr 3.0.x git
by Polish 05 Jun '14

05 Jun '14

Hello, tls tunnel break after day of running FR. Wed Jun 4 13:58:15 2014 : Auth: (23774) Login OK: [pokuston(a)mendelu.cz] (from client ermon port 0 cli 70-6F-6C-69-73-68) Wed Jun 4 13:58:24 2014 : Info: ... shutting down socket auth from client (195.113.187.22, 40442) -> (*, 2083, virtual-server=default) Wed Jun 4 13:58:29 2014 : Info: ... adding new socket auth from client (195.113.187.22, 48832) -> (*, 2083, virtual-server=default) Wed Jun 4 13:58:33 2014 : Info: ... shutting down socket proxy (195.113.136.14, 56948) -> home_server (195.113.187.22, 2083) Wed Jun 4 13:58:33 2014 : Info: ... shutting down socket auth from client (195.113.187.22, 48832) -> (*, 2083, virtual-server=default) Wed Jun 4 13:58:35 2014 : Info: ... adding new socket auth from client (195.113.187.22, 57602) -> (*, 2083, virtual-server=default) Wed Jun 4 13:58:40 2014 : Info: ... shutting down socket auth from client (195.113.187.22, 57602) -> (*, 2083, virtual-server=default) Wed Jun 4 13:58:40 2014 : Info: ... adding new socket auth from client (195.113.187.22, 33406) -> (*, 2083, virtual-server=default) Wed Jun 4 13:59:03 2014 : Info: Home server tls has too many open connections (16) Wed Jun 4 13:59:03 2014 : Error: Failed to insert request into the proxy list Pavel Polacek

2 1

VMPS only
by Edik Mkoyan 04 Jun '14

04 Jun '14

Hi, I have multivlan wide l2 network and need to implement vmps. I made server work for single vlan, but I need to make it work with many vlans and mac2vlan file(I have about 300 hosts). Tell me how to enable mac2vlan module(if that is a module), when I remove the # sign from the mapping example line, server crashes with parse error, after the mac address. Here is the debug output that works for a single vlan Waking up in 4.9 seconds. Cleaning up request 19 ID 10529 with timestamp +1165 Ready to process requests. VMPS-Packet-Type = VMPS-Reconfirm-Request VMPS-Error-Code = VMPS-No-Error VMPS-Sequence-Number = 10545 VMPS-Client-IP-Address = 192.168.10.218 VMPS-Port-Name = "Fa0/16" VMPS-VLAN-Name = "default" VMPS-Domain-Name = "vivaro" VMPS-Unknown = 0x01 VMPS-Cookie = f4:6d:04:48:36:5f Doing VMPS +- entering group vmps {...} expand: %{VMPS-Mac} -> ++[reply] returns noop Done VMPS VMPS-VLAN-Name = "default" VMPS-Cookie = 00:00:00:00:00:00 Finished request 20. Going to the next request Waking up in 4.9 seconds. Cleaning up request 20 ID 10545 with timestamp +1225 Ready to process requests. and here is the configuration prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = /usr/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct log_file = /var/log/radius/vmpsd.log log_destination = files libdir = @libdir@ pidfile = ${localstatedir}/run/vmps.pid max_request_time = 30 cleanup_delay = 5 listen { ipaddr = * port = 1589 type = vmps interface = eth1 } hostname_lookups = no allow_core_dumps = no log { syslog_facility = daemon } thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } $INCLUDE clients.conf vmps { update reply { VMPS-Packet-Type = VMPS-Join-Response VMPS-VLAN-Name = "default" VMPS-Cookie = "%{VMPS-Mac}" } } Best, Edik.

2 1

FreeRADIUS v2.2.5 and v3.0.3 packages updated
by Nikolai Kondrashov 04 Jun '14

04 Jun '14

Hi everyone, I've updated Fedora 19 [1] and 20 [2] FreeRADIUS packages to explicitly require the OpenSSL version with fixed Heartbleed bug and to have OpenSSL vulnerabilities marked as fixed in radiusd.conf. So, the upgraded server will continue to start. Thanks to Fedora Updates user westford for the suggestion! The updated packages are now available via corresponding updates-testing repos. Please test and leave karma feedback [3]. Nick [1] https://admin.fedoraproject.org/updates/freeradius-2.2.5-2.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2014-6698/freeradius-3.0.3-2… [3] http://fedoraproject.org/wiki/How_to_test_updates

1 1

OT, but relevant: Managing Certs
by Brendan Kearney 04 Jun '14

04 Jun '14

i am starting to read up on implementing .1x, and want some feedback on how others are managing certs. my questions are not specific to freeradius, but being that many of the .1x auth methods use certificates, i am hoping to find a pool of folks that manage certificates, pki and / or ca's, to enlighten me. i have an openvpn instance that leverages certs. i will adding certs to openldap for client connections over tls, and certs for replication between masters. then there is www and proxy. even dns can get in the certificate game. with all of these services leveraging certificates, how do folks avoid "cross pollination"? i dont want an openvpn client certificate used to authenticate a .1x session, for example. i dont want my ldap replication to be subject to interception by a client that has a cert signed by the same ca, thereby allowing unintended access or the ability to decrypt the traffic because the same trust structure is in place for all of the services. i am wondering if using a separate intermediate ca for each infrastructure service is worth the effort, and if it would provide the means to isolate the different technologies from each other so the encrypted communications are not trivially intercepted because the same ca signed all the certs. aside from the isolation of signing, what can be done to prevent unintended cross authentication when certs are leveraged? thanks in advance, brendan kearney

3 2

Re: Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0
by Rui Ribeiro 03 Jun '14

03 Jun '14

Hi, About this issue, I remember we having problems in the past with some Android and Linux devices where in the configuration you had to fill up the anonymous login field, or else it would not authenticate if that field was blank. At that time, I instructed our helpdesk to fill it up with the login of the user. I just mention this, because could be due to some configuration in the inner/outer tunnel, or a change of the default protocols. For instance, I already helped in a case where the FreeRadius admin was telling me he only used PEAP, but after an upgrade the Apple devices starting using the default TTLS configuration. Regards, Rui Ribeiro > Message: 7 > Date: Mon, 2 Jun 2014 10:47:48 +0100 > From: Robert Franklin <rcf34(a)cam.ac.uk> > To: Alan Buxey <A.L.M.Buxey(a)lboro.ac.uk> > Cc: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: Android 2.3.5 supplicants failing after upgrade to > FreeRADIUS 2.2.5 from 2.2.0 > Message-ID: <25867EE6-3519-4698-97B7-7B174A8AB152(a)cam.ac.uk> > Content-Type: text/plain; charset=us-ascii > > On 31 May 2014, at 10:35, Alan Buxey <A.L.M.Buxey(a)lboro.ac.uk> wrote: > > > So not just FR update but also the OS updated too...so possible eg samba > upgrade too > > I don't think anything majorly -- nothing like OpenSSL changing beyond > some patches SuSE would have backported. Our password backend is a > PostgreSQL server with Cleartext-Password being store; there is no Samba > involved. > > > > If the RPM blatted your config like that then it may also have done > something to your EAP config too - eg certificates (especially if the debug > shows the clients failing at that point) . Did your windows client have > correct/secure EAP settings or was it just 'user/password don't care about > cert details' mode? > > I think the certs are all the same and being referenced the same -- we use > a signed cert from the Janet Certificate Service and the chain all looks to > be there (checking 'radiusd -X' output to see which files are read). > > My Windows 7 PC to test the same credentials is configured with the full > 802.1X security setup - it only has the 'AddTrust External CA root' ticked, > as well as the server name for the certificate as ' > network.tokens.csx.cam.ac.uk'. If I change these settings on the PC to > deliberately break them (such as ticket a different CA, or change the > server name to 'network2.tokens.csx.cam.ac.uk') then the authentication > fails (I do re-enter the credentials following this). So I think > everything is being checked correctly. > > > Also, that all the users of other platforms (>13,000 last week) are > getting on without issue makes me think there's something odd here, like a > chain certificate issue. > > I'm trying to lay my hands on a 2.3.5 device I can muck about with but > it's proving tricky. > > > Is there anything that can be determined from the raddebug output I sent > (in terms of which end is stopping the EAP dialogue) or do I need to get > more or a different type of output? > > - Bob > > > -- > Bob Franklin rcf34(a)cam.ac.uk / +44 1223 748479 > Networks, University Information Services, University of Cambridge >

7 12

SQL Auth Logging
by Kev Pearce 03 Jun '14

03 Jun '14

Hi all, I'm sure this has been asked many times before but I can't seem to find an answer to it. Is it possible to log to an SQL server when an unknown client attempts to authenticate against a virtual server and also to log then a good client tries but with an incorrect secret? I've got good and bad auth attempts logging to SQL nicely with (to my own postauth_table) and a bit of decoration in my UI: postauth_query = "INSERT INTO ${postauth_table} \ (src_ip_address, nas_ip_address, dest_port, username, password, \ reply, reason, auth_timestamp) \ VALUES \ ('%{Packet-Src-IP-Address}', \ '%{NAS-IP-Address}', \ '%{Packet-Dst-Port}', \ '%{User-Name}', \ '%{%{User-Password}:-%{Chap-Password}}', \ '%{reply:Packet-Type}', \ '%{Module-Failure-Message}', \ '%S')" I'm trying to do this so the users of my web interface can spot incorrectly configured clients/client entries. I'm not just trying to trouble shoot just one particular client. I'm trying to create a fully web interfaced system to manage and troubleshoot FreeRADIUS clients and users, Great product by the way, keep it up, Cheers Kev/.

2 1

Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0
by Robert Franklin 02 Jun '14

02 Jun '14

Hello, We've suddenly started having reports of problems authenticating to our eduroam 802.1X service from users with Android 2.3.5 phones since an upgrade of FreeRADIUS on Tuesday morning this last week. As far as we're aware, no other body of users are affected, including newer Android devices: our Service Desk are just noticing this OS as a significant pattern. We were running FreeRADIUS 2.2.0, running on SLES 11 SP2, but upgraded to 2.2.5 and SLES 11 SP3, as far as we're aware, no other changes were made to the configuration, nor certificates. This is aside from a period of about 45 minutes following the upgrade where a mistake in the RPM caused the sites-available/default and inner-tunnel files to be overwritten with the default ones, before our local copies were reinstated. This obviously trashed much of our local configuration, causing authentication to fail for a period. We know at least one user affected tried to connect during this time but are unsure if all the affected users also did so, nor if other Android 2.3.5 users are successful (I'm trying to lay my hands on one which didn't). This situation may have upset the phones but we've tried removing the configuration from them, restarting them and then re-entering everything, but still they cannot connect. I have tried the same username/password on a Windows 7 laptop, also using EAP/PEAP and that connects fine. Looking at the debug (with raddebug on the Calling-Station-Id of an affected device's MAC address; a '-X' is a little busy) it seems to engage in an EAP dialogue with FreeRADIUS but then stops partway through. I've attached a gzipped copy of the raddebug -- I could send "radiusd -X" but I don't think there'll be anything pertinent in there as all the other supplicants are working, but I'm happy to, if necessary. The big lumps of hex in the EAP stuff doesn't make sense to me (I'm hoping it does to someone else!) but I have compared it with a successful device (an iPhone with a different username) to see where they differ. Everything seems OK up to request 21021170 (which finishes on line 646 of the file), where an Access-Challenge goes back to the supplicant. The following Access-Request has a very short EAP-Message compared to the successful iPhone, which makes me think EAP is aborting/restarting or broken somehow. On the iPhone, after two more packets, peap reports that TUNNEL ESTABLISHED, whereas the Android device never does. Please let me know if you need anything else. There may be something else that has broken on the server, or a bit of configuration that has been corrupted, but it's odd it's just (apparently) affecting this class of device, but we don't think we've changed certificates or anything else. The weird thing here is why just Android 2.3.5 (or possibly everything < version 3?) is failing, following the upgrade. I can't spot anything has changed in the FreeRADIUS release notes that I might need to change, nor any reports of similar problems. Thanks in advance for any help, - Bob -- Bob Franklin rcf34(a)cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge

4 5

Reply attribute in access-accept while doing eap-mschapv2
by free.aaa 02 Jun '14

02 Jun '14

Hi all! It seems like a missed some basic concepts about eap in freeradius. How to make freeradius return attribute for a specific user? I'm using freeradius-3.0.3. I created user in mysql (radcheck) as usual: test Cleartext-Password := test And add to radreply table: test Class = temp_class And when I do eap-mschapv2 I did not receive Class attribute. I need help to clarify this concept and advice how to include this attribute in the reply. PS: As one try I added to my default config in the post-auth section the following: update reply { Class = "%{Class}" } and after that the Class attribute appeared in the access-accept but it was empty. Thanks in advance! Best regards, Alex

5 14

[ANN] Release 3.0.4 rc1
by Arran Cudbard-Bell 02 Jun '14

02 Jun '14

A preview release of 3.0.4 is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_4_rc1.t… We’re creating a second release candidate for 3.0.4 to verify defects in the last release candidate have been fixed, and that no new issues have crept in. Some changes since the last RC: Compile time type checking ------------------------------------- In response to the particularly nasty subtle corruption of memory in FreeRADIUS 3.0.3 caused by mismatched variable/configuration directive types and the configuration parser, we’ve added compile time checking. https://github.com/FreeRADIUS/freeradius-server/blob/master/src/include/con… This has involved a large amount of code churn as field types in module configuration structs have been altered to match exactly the configuration directive type. The most use visible part of these changes is that integer type configuration directives will, in most cases, no longer accept negative values. If you find a particular integer type configuration directive that you feel should accept negative integers, let us known and we'll correct it. Client / homeserver / listener changes ------------------------------------------------- One of the other changes forced by compile time type checking was for IP/IPv4/IPv6 types. All addresses and prefixes in modules and the server core, are now represented as fr_ipaddr_t. This means some places which would only accept IPv4 addresses before now accept IPv4 prefixes and IPv6 addresses/prefixes. Internal attribute numbering ------------------------------------- Following the same theme of preventing mismatches within the server, the internal macros used for attribute numbering are now auto-generated at build time. This should prevent mismatches occurring between the shipped dictionary and the header files, and allows users building from src to renumber internal attributes (if they really want to) by editing the share/dictionary.freeradius.internal dictionary and recompiling. rlm_cache behaviour changes ---------------------------------------- One of the things that has prevented people using the rlm_cache module is it’s perceived complexity. To make things similar we’ve introduced a couple of behaviour changes. Firstly the module will consume any of the control attributes used to configure it after each call. The second change was to add the Cache-Read-Only attribute, which will allow merging of existing cache entries but will prevent new ones being created. For caching attributes from LDAP you’d now do something like: update control { Cache-Read-Only := yes } cache # Consumes Cache-Read-Only if (notfound) { ldap cache } Which is a little simpler than: update control { Cache-Status-Only := yes } cache update control { Cache-Status-Only := no } if (notfound) { ldap } cache It’s also more efficient as for cached entries there’s only a single lookup. This shouldn’t affect the majority of installations already using rlm_cache, for most, it will just make some update blocks redundant. If you run into any issues log a report at http://bugs.freeradius.org, or post to the list. -Arran

4 4

Problems building 2.2.5
by Jonathan Gazeley 02 Jun '14

02 Jun '14

I'm trying to build a 2.2.5 RPM on and for CentOS 6 x86_64 using the spec file included in the source distribution. Build always fails at the end when packaging the files with this error: RPM build errors: Installed (but unpackaged) file(s) found: /etc/raddb/panic.gdb The file /etc/raddb/panic.gdb contains the following: [jg4461@build64 raddb]$ cat panic.gdb info locals info args thread apply all bt full quit I can't find any other reference in the output from the build process that would seem to explain this. Anyone got any pointers (no pun intended) for tracking this one down? I'm a sysadmin, not a developer, and I'm not particularly familiar with C or gdb. Thanks, Jonathan

3 3