January 2016 - Freeradius-Users - lists.freeradius.org

$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

Assigning Users to Groups Dynamically
by J Kephart 01 Jan '16

01 Jan '16

Hi! I've been looking through the wiki, but thus far, I've not found anything that describes what I'd like to be able to do. We manage on-site hardware for our clients, and that hardware includes routers, gateways, switches, etc. What I'd like to be able to do is assign a user to a group dynamically, based on some identifying parameter received in the access request, and then have the group's attributes passed back in the access accept packet. So, for example, if any user wants to connect to Vendor A's gateway, we might have a group defined for that type of device containing: vendor_a_gateway Idle-Timeout = 900 vendor_a_gateway VSA_1 = xxx vendor_a_gateway VSA_2 = xxx vendor_a_gateway VSA_3 = xxx Likewise, for Vendor B, we might have the following: vendor_b_switch Idle-Timeout = 600 vendor_b_switch VSA_1 = xxx vendor_b_switch VSA_2 = xxx vendor_b_switch VSA_3 = xxx Ultimately, then, if a user logs on to a device that we can categorize as being Vendor A's gateway, we'd automatically associate that user with the group "vendor_a_gateway", and so on. In that way, we hope to limit the number of attributes we need to manage for each user, instead having a short list of groups with attributes that can be assigned on the fly. I don't know if I've explained this in a way that makes sense (I hope it makes sense to someone!), but I wonder if there's a way to do what I've described. Hopefully, Jim

3 5

Proxying with radsec/TLS, Access-Reject leads to "spoofed proxy reply"
by Susan Barnes 01 Jan '16

01 Jan '16

Hello, I am playing with radsec. I have set up a proxy-connection between our staging server and an additional testserver to act as homeserver. Both servers are v3.0.10. What I have managed so far is: The staging-server can contact the homeserver and establish a TLS-secured connection. The staging server sends a request to the homeserver and the homeserver will process it. The homeserver replies. If the homeserver rejects the Request, the staging-server will not accept the reply, but discards it with "Ignoring spoofed proxy reply. Signature is invalid" If the homeserver sends an Access-Accept, the staging-server will accept the reply. I have tried the proxy setup without radsec/TLS. In that case both Accept and Reject work. On the homeserver's side I have: client radiustest { ipaddr = $STAGING proto = tls secret = radsec } On the staging-server's side I have: home_server radiusdevel { ipaddr = $HOME port = 2083 type = auth secret = radsec proto = tcp status_check = none tls { ... } } In debug output I first see on HOME: (0) SSL Connection Established on STAGING: (0) (other): SSL negotiation finished successfully I assume, that means that I set up the TLS-part correctly. Then I see on STAGING: Listening on proxy (STAGING, 46303) -> home_server (HOME, 2083) Waking up in 0.2 seconds. (0) Proxying request to home server HOME port 2083 (TLS) timeout 10.000000 (0) Sent Access-Request Id 239 from STAGING:46303 to HOME:2083 length 137 on HOME (0) tls_recv: Access-Request packet from host STAGING port 46303, id=239, length=137 (0) <running>: Received Access-Request Id 239 from STAGING:46303 to HOME:2083 length 137 (0) Sent Access-Reject Id 239 from HOME:2083 to STAGING:46303 length 49 And then on STAGING: "Ignoring spoofed proxy reply. Signature is invalid" 10 seconds later: (0) No proxy response, giving up on request and marking it done (0) ERROR: Failing proxied request for user "radtest(a)testrealm.de", due to lack of any response from home server HOME port 2083 I have poked around with gdb on the staging server a bit. Within rad_verify() at the point of calc_replydigest() we get to the point of "Received %s packet from home server %s port %d with invalid Response Authenticator! (Shared secret is incorrect.)", (did not appear anywhere in the Debug Output). Does anyone have an idea what the problem could be? Regards and Thanks Susan -- S.Barnes Cologne University IT/Networking Dept.

3 5

FreeRADIUS allows connections locally, but not remotely
by Ernie Dunbar 01 Jan '16

01 Jan '16

Hi everyone. I have a difficult problem that appears to have come out of the blue. After rebooting the Debian Wheezy server that hosts our RADIUS authentication this morning, suddenly FreeRADIUS v2.1.12+dfsg-1.2 is no longer working. I can successfully test the connection locally using 'radtest' like this: # /usr/bin/radtest customer password localhost:1812 5 localsecret -4 127.0.0.1 Sending Access-Request of id 218 to 127.0.0.1 port 1812 User-Name = "customer" User-Password = "password" NAS-IP-Address = 127.0.0.1 NAS-Port = 5 Message-Authenticator = 0x00000000000000000000000000000000 Framed-Protocol = PPP rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=218, length=38 Framed-Protocol = PPP Service-Type = Framed-User Framed-Compression = Van-Jacobson-TCP-IP I get the rad_recv response right away. When I test it from the same machine, but *saying* I'm connecting remotely, it apparently times out: www:/etc/freeradius# /usr/bin/radtest customer password localhost:1812 5 remotesecret -4 XXX.XXX.XXX.254 Sending Access-Request of id 34 to 127.0.0.1 port 1812 User-Name = "customer" User-Password = "password" NAS-IP-Address = XXX.XXX.XXX.254 NAS-Port = 5 Message-Authenticator = 0x00000000000000000000000000000000 Framed-Protocol = PPP Sending Access-Request of id 34 to 127.0.0.1 port 1812 User-Name = "customer" User-Password = "password" NAS-IP-Address = XXX.XXX.XXX.254 NAS-Port = 5 Message-Authenticator = 0x00000000000000000000000000000000 Framed-Protocol = PPP ^C The connection evidently times out and radtest retries, at which point I hit Ctrl-C. I get the same results when I actually test the connection from a remote site as when I pretend to make the connection from a remote site with -4 XXX.XXX.XXX.254. I can't really test *from* that site, since it's a Cisco AS5300. The only thing I can think of that *might* have changed was the Debian package version, but I can't even confirm that really, and it's in the old stable branch, which I believe is no longer supported with new patches. Nothing has changed in the FreeRADIUS configuration since about 2010. Any assistance would be appreciated!

3 9