- Freeradius-Users - lists.freeradius.org

Freeradius logging problem
by Peter Hutchison 06 Jan '16

06 Jan '16

I was wondering if you could help use with our eduroam setup at the University of Huddersfield? We have set up Freeradius on Ubuntu 14.04 LTS but having trouble to get it to generating authorization logs for our 'eduroam' virtual server. It is generating logs ok for the default and inner-tunnel but not eduroam. I have checked and re-checked the configuration with no result. /etc/freeradius/radius.conf log section looks like this: prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct log { destination = files file = ${logdir}/radius.log requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log ... } And in our eduroam file in sites-available (with link file in sites-enabled) has 'auth_log' enabled to in the authorize section. It should create logs called radiusd-eduroam-20151217.log but nothing is being created. Logs are a requirement for a valid eduroam setup and this is the last thing needed before we can switch over to the new servers. Any ideas why the log isn't being generated when users connect to it? Peter Hutchison MCP Senior Network Systems SpecialistS S 01484 473716 Infrastructure Team University of Huddersfield | Queensgate | Huddersfield | HD1 3DH University of Huddersfield inspiring tomorrow's professionals. [http://marketing.hud.ac.uk/_HOSTED/EmailSig2014/EmailSigFooter.jpg] This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.

3 3

Thanks and goodbye
by Doug Hardie 06 Jan '16

06 Jan '16

Many years ago we started out with Cistron Radius and then migrated to FreeRadius when it became available. The only thing we have used radius for is dial-in authentication. While Cistron worked fine for that, I had to hack it numerous times to be able to support the local site policies. FreeRadius made that really easy. Modules are cool. However, we no longer have enough dial-in users to justify keeping the service and are doing away with it in a few weeks. So, I wanted to thank Alan and all the others who have provided help and information to us over the years. It's a great product. — Doug

1 0

[LDAP] access to attribut with unlang
by vince technical address 06 Jan '16

06 Jan '16

Hi, I currently use the rlm_ldap module to retrieve an entry corresponding to a filter defined in the authorize section. After (but always in section authorize) I would use the value of an LDAP attribute recovered with unlang. Is it possible ? Example : authorize { ldap if(attribute == "qwerty") { reject } } With "attribute"is the value of the attribute has been recovered with module ldap. (it is an idea to overcome the fact that xlat ldap does not enable failover). Thanks Vince

2 5

Radperf with EAP-TLS
by vince technical address 06 Jan '16

06 Jan '16

Hi, Do you know if radperf is compatible with eap-tls ? Thanks, Vince

2 1

Request logging mssing on Freeradius 2.1.12
by Peter Hutchison 06 Jan '16

06 Jan '16

What option(s) need enabling to log freeradius requests for a new service in /etc/freeradius/sites-enabled/servicename ? I have files, auth_log, redutmp and pre_proxy_log and post_proxy_log options enabled. No logs for the new service is being generated. Have I missed something? e.g. radius-servicename-2016-01-05.log in /var/log/freeradius folder. Log entries would look like: Mon Jan 4 00:10:04 2016 : Auth : Logon ok : [username(a)hud.ac.uk] (from client roaming.ja.net port 4 cli xx-xx-xx-xx-xx-xx-xx) Any ideas? Peter Hutchison MCP Senior Network Systems Specialist * 01484 473716 Infrastructure Team University of Huddersfield | Queensgate | Huddersfield | HD1 3DH University of Huddersfield inspiring tomorrow's professionals. [http://marketing.hud.ac.uk/_HOSTED/EmailSig2014/EmailSigFooter.jpg] This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.

3 3

RE: EAP-TLS context uninitialized
by Franks Andy (IT Technical Architecture Manager) 06 Jan '16

06 Jan '16

Hi, Yes, caching is switched on with both instances. Apt cache reports: Version: 1.0.1e-3ubuntu1 (FR reports 1.0.1e release) on both servers. If I disable caching on the newer, the issue goes away. I do remember being told to remove lifetime and caching options for the eap cache configuration when I compiled the newer version come to think of it, so I guess something has altered internally (read "made better/shinier/better mannered!") I'll have a look at what I'd need to do to get 1.0.2 openssl going on the server I've got. Thanks Andy > On Jan 5, 2016, at 2:28 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks(a)sath.nhs.uk> wrote: > > Hi Arran, > I'll check the NAS but am confused as it should (to me) have been a problem before. Pre-auth is turned on, but never caused a problem previously. That's different, you're talking about 802.11 PMK caching, this is TLS session resumption where the keys, certificates, and negotiated cipher suites from a previous TLS session are re-used. TLS session resumption controlled by the cache section in the eap configuration file. Should be a toggle. If it's not there try using an updated version of the mods-available/eap file, many settings for cache control have changed. > It seems to be generally worse when there are lots of auth requests, but then sometimes there's just one happening and it'll do it. It's not related to client detail, as sometimes a specific client is fine, and on another occasion it'll fail. > I've yet to check it in non-debug mode, which is a bit daft of me, it's obviously running single threaded and echoing to screen, maybe that's slowing it to "not coping" point. Not unless you're putting significant load on it. > I'll keep digging, guess there's nothing obvious between versions? No, and i've never seen that message before, but we have rewritten a lot of the EAP-TLS code in v3.1.x. Knowing OpenSSL version would be useful too (output at the top of the radiusd -X output), I mostly test with 1.0.2 Travis will probably be 0.9.8 so interactions with 1.0.0 and 1.0.1 are not well tested. -Arran

1 0

$INCLUDE path/ and filenames with spaces
by Stefan Winter 06 Jan '16

06 Jan '16

Hi, just a short note that I just tried that, but the file with spaces in its name did not get picked up at server start (while all the others in the same directory were). Not sure if this is known and maybe even intentional(?), but just in case others want to be just as fancy and have very nice filenames in your config... just don't :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

3 2

Re: FreeRADIUS allows connections locally, but not remotely
by Matthew Newton 06 Jan '16

06 Jan '16

On Fri, Jan 01, 2016 at 12:18:59AM +0000, Matthew Newton wrote: > Working fine here. Possibly driver issue with network hardware on > your machine? Debian security announcement for linux just came out, which included this at the end: > - ------------------------------------------------------------------------- > Debian Security Advisory DSA-3434-1 security(a)debian.org > https://www.debian.org/security/ Ben Hutchings > January 05, 2016 https://www.debian.org/security/faq > - ------------------------------------------------------------------------- > > Package : linux ... > Debian Bug : 808293 808602 808953 808973 ... > #808293 > > A regression in the UDP implementation prevented freeradius and > some other applications from receiving data. So looks like it was a bug that's now been fixed. Matthew -- Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk>

1 0

RE: EAP-TLS context uninitialized
by Franks Andy (IT Technical Architecture Manager) 05 Jan '16

05 Jan '16

Hi Arran, I'll check the NAS but am confused as it should (to me) have been a problem before. Pre-auth is turned on, but never caused a problem previously. It seems to be generally worse when there are lots of auth requests, but then sometimes there's just one happening and it'll do it. It's not related to client detail, as sometimes a specific client is fine, and on another occasion it'll fail. I've yet to check it in non-debug mode, which is a bit daft of me, it's obviously running single threaded and echoing to screen, maybe that's slowing it to "not coping" point. I'll keep digging, guess there's nothing obvious between versions? Thanks! Andy ________________________________________ From: Freeradius-Users [freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb(a)freeradius.org] Sent: 05 January 2016 18:06 To: FreeRadius users mailing list Subject: Re: EAP-TLS context uninitialized > On Jan 5, 2016, at 12:53 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks(a)sath.nhs.uk> wrote: > > Hi all, > I've a problem with FR3.1.0 git#f4d5ff6. This is on our test "wireless" radius server, and I'm looking to commission the configuration onto more production systems once it's certified. Basically the only changes are a newer version of FR, and some tidying of the config. The older version is git #390f216. When sending the same clients to both, very often the newer one complains with this issue and rejects the user: > > (85) # Executing group from file /usr/local/etc/raddb/sites-enabled/default > (85) Auth-Type eap { > (85) eap: Peer sent packet with method EAP TLS (13) > (85) eap: Calling submodule eap_tls to process data > (85) eap_tls: Continuing EAP-TLS > (85) eap_tls: Peer indicated complete TLS record size will be 131 bytes > (85) eap_tls: Got complete TLS record, with length (131 bytes) > (85) eap_tls: [eap-tls verify] = ok > (85) eap_tls: before/accept initialization > (85) eap_tls: TLS Accept: before/accept initialization > (85) eap_tls: <<< recv handshake [length 126], client_hello > tls: TLS Accept: Error in SSLv3 read client hello C > tls: TLS Accept: Error in SSLv3 read client hello C > (85) eap_tls: ERROR: TLS says: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized > (85) eap_tls: ERROR: TLS_read failed in a system call (-1), TLS session failed > (85) eap_tls: ERROR: TLS receive handshake failed during operation > (85) eap_tls: ERROR: [eap-tls process] = fail > (85) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed > (85) eap: Sending EAP Failure (code 4) ID 45 length 4 > (85) eap: Failed in EAP select > > The confusing thing is it's not consistent - sometimes it will be ok, I've not yet worked out the pattern: Do you have session resumption enabled? Could be an issue with that. -Arran

2 1

EAP-TLS context uninitialized
by Franks Andy (IT Technical Architecture Manager) 05 Jan '16

05 Jan '16

Hi all, I've a problem with FR3.1.0 git#f4d5ff6. This is on our test "wireless" radius server, and I'm looking to commission the configuration onto more production systems once it's certified. Basically the only changes are a newer version of FR, and some tidying of the config. The older version is git #390f216. When sending the same clients to both, very often the newer one complains with this issue and rejects the user: (85) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (85) Auth-Type eap { (85) eap: Peer sent packet with method EAP TLS (13) (85) eap: Calling submodule eap_tls to process data (85) eap_tls: Continuing EAP-TLS (85) eap_tls: Peer indicated complete TLS record size will be 131 bytes (85) eap_tls: Got complete TLS record, with length (131 bytes) (85) eap_tls: [eap-tls verify] = ok (85) eap_tls: before/accept initialization (85) eap_tls: TLS Accept: before/accept initialization (85) eap_tls: <<< recv handshake [length 126], client_hello tls: TLS Accept: Error in SSLv3 read client hello C tls: TLS Accept: Error in SSLv3 read client hello C (85) eap_tls: ERROR: TLS says: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized (85) eap_tls: ERROR: TLS_read failed in a system call (-1), TLS session failed (85) eap_tls: ERROR: TLS receive handshake failed during operation (85) eap_tls: ERROR: [eap-tls process] = fail (85) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (85) eap: Sending EAP Failure (code 4) ID 45 length 4 (85) eap: Failed in EAP select The confusing thing is it's not consistent - sometimes it will be ok, I've not yet worked out the pattern: (75) Auth-Type eap { (75) eap: Peer sent packet with method EAP TLS (13) (75) eap: Calling submodule eap_tls to process data (75) eap_tls: Continuing EAP-TLS (75) eap_tls: Peer indicated complete TLS record size will be 133 bytes (75) eap_tls: Got complete TLS record, with length (133 bytes) (75) eap_tls: [eap-tls verify] = ok (75) eap_tls: before/accept initialization (75) eap_tls: TLS Accept: before/accept initialization (75) eap_tls: <<< recv handshake [length 128], client_hello (75) eap_tls: TLS Accept: SSLv3 read client hello A (75) eap_tls: >>> send handshake [length 89], server_hello (75) eap_tls: TLS Accept: SSLv3 write server hello A (75) eap_tls: >>> send handshake [length 2344], certificate (75) eap_tls: TLS Accept: SSLv3 write certificate A (75) eap_tls: >>> send handshake [length 331], server_key_exchange (75) eap_tls: TLS Accept: SSLv3 write key exchange A (75) eap_tls: >>> send handshake [length 104], certificate_request (75) eap_tls: TLS Accept: SSLv3 write certificate request A (75) eap_tls: TLS Accept: SSLv3 flush data (75) eap_tls: TLS Accept: Need to read more data: SSLv3 read client certificate A (75) eap_tls: TLS Accept: Need to read more data: SSLv3 read client certificate A (75) eap_tls: In TLS handshake phase (75) eap_tls: In TLS accept mode (75) eap_tls: [eap-tls process] = handled (75) eap: Sending EAP Request (code 1) ID 71 length 1090 (75) [eap] = handled (75) } # Auth-Type eap = handled It doesn't happen on the older version (at all) and that has very similar config. Is there any known reason why this should be coming up? The NAS and clients are identical during each test, the older version is fine, the newer not. The host machines were built at the same time, so the dev libraries compiled against are likely the same versions. I'm stumped! Is it worth me moving to a newer build and trying again - any known issues? Thanks! Andy

2 1