- Freeradius-Users - lists.freeradius.org

user from particular NAS-IP-Address
by Pete Ashdown 26 May '13

26 May '13

I'm trying to restrict a guest user from a single NAS-IP-Address via "users" and I can't get it to work. Doesn't work: test NAS-IP-Address == "127.0.0.1" Auth-Type := Accept test NAS-IP-Address == "127.0.1.1" Auth-Type := Accept Works, but it isn't restricted by NAS: test Auth-Type := Accept I've also tried "Calling-Station-ID == 127.0.1.1" to no avail. Also, how would I do this for a group of NAS IP addresses? Is it possible to assign them to a group in "clients.conf" that can be later checked against in "users"? Where is the documentation of what can be tested against in the "users" file?

4 5

Re: Auth-Type = Reject not being obeyed
by Matthew Melbourne 26 May '13

26 May '13

I think Phil's diagnosis is correct; 'Auth-Type := Reject' requires the ':=' operator to reject a CHAP authentication. Unfortunately, it's not always easy to place a live production system in debug mode, hence the initial "is this something stupid" question :) (And apologies for the lack of a subject line in the original post). Cheers, Matt -----Original Message----- Date: Fri, 24 May 2013 17:31:29 +0100 From: Phil Mayers <p.mayers(a)imperial.ac.uk> To: freeradius-users(a)lists.freeradius.org Subject: Re: Auth-Type = Reject not being obeyed Message-ID: <519F95E1.6010100(a)imperial.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 24/05/13 17:19, Alan Buxey wrote: > The only difference I can see is that the first example uses a > plain-text password, and the RADIUS on the LNS is using CHAP? > > The backend database has "=" in the 'op' field (and not ":="), so the > returned attribute is "Auth-Type = Reject" and not "Auth-Type := > Reject", but it is correctly rejected using radtest/radclient, and I > believe the "=" operand to be correct. You might have this: authorize { ... chap sql ... } ..and Auth-Type is already set by chap, hence "=" doesn't overwrite it. Anyway, you're not correct that "=" is the right operator; ":=" means "force" i.e. set this attribute to this value, always, and that's what you want to do here, right? "=" means "set if unset" As has also been pointed out - show "radiusd -X" for a problem auth (and set a subject line...)

2 1

Error: rlm_sql_unixodbc: SQL down 08S01 [unixODBC][FreeTDS][SQL Server]Unable to connect: Adaptive Server is unavailable or does not exist
by Bill Grant 26 May '13

26 May '13

I am having trouble starting freeradius at boot on CentOS 6.4. It starts, but it does not connect to my database; however, if run it manually from the command the it works fine. I think there is permission issue somewhere. See the log below: when I run following command as root it works # radiusd Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Driver rlm_sql_unixodbc (module rlm_sql_unixodbc) loaded and linked Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Attempting to connect to radius@EBHorizon:5000/Horizon Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #0 Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Connected new DB handle, #0 Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #1 Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Connected new DB handle, #1 Sat May 25 10:26:20 2013 : Info: rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #2 Sat May 25 10:26:21 2013 : Info: rlm_sql (sql): Connected new DB handle, #2 Sat May 25 10:26:21 2013 : Info: rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #3 Sat May 25 10:26:21 2013 : Info: rlm_sql (sql): Connected new DB handle, #3 Sat May 25 10:26:21 2013 : Info: rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #4 Sat May 25 10:26:21 2013 : Info: rlm_sql (sql): Connected new DB handle, #4 Sat May 25 10:26:21 2013 : Info: Loaded virtual server <default> Sat May 25 10:26:21 2013 : Info: Loaded virtual server inner-tunnel Sat May 25 10:26:21 2013 : Info: ... adding new socket proxy address * port 35688 Sat May 25 10:26:21 2013 : Info: Ready to process requests. When I run the command below it does not connect. #service radiusd start Sat May 25 10:29:05 2013 : Info: rlm_sql (sql): Driver rlm_sql_unixodbc (module rlm_sql_unixodbc) loaded and linked Sat May 25 10:29:05 2013 : Info: rlm_sql (sql): Attempting to connect to radius@EBHorizon:5000/Horizon Sat May 25 10:29:05 2013 : Info: rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #0 Sat May 25 10:29:05 2013 : Error: rlm_sql_unixodbc: SQL down 08S01 [unixODBC][FreeTDS][SQL Server]Unable to connect: Adaptive Server is unavailable or does not exist Sat May 25 10:29:05 2013 : Error: rlm_sql_unixodbc: Connection failed Sat May 25 10:29:05 2013 : Error: rlm_sql (sql): Failed to connect DB handle #0 Sat May 25 10:29:05 2013 : Info: Loaded virtual server <default> Sat May 25 10:29:05 2013 : Info: Loaded virtual server inner-tunnel Sat May 25 10:29:05 2013 : Info: ... adding new socket proxy address * port 59524 Sat May 25 10:29:05 2013 : Info: Ready to process requests. Any help would be greatly appreciated.

2 3

Re: Issue with radius accounting
by Arvind Bahuguni 25 May '13

25 May '13

Hi Alan, I am suspecting some radius setting on my server because free radius on other server is responding and authentication and accounting is successful. On May 24, 2013 7:56 PM, <freeradius-users-request(a)lists.freeradius.org> wrote: > Send Freeradius-Users mailing list submissions to > freeradius-users(a)lists.freeradius.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freeradius.org/mailman/listinfo/freeradius-users > or, via email, send a message with subject or body 'help' to > freeradius-users-request(a)lists.freeradius.org > > You can reach the person managing the list at > freeradius-users-owner(a)lists.freeradius.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeradius-Users digest..." > > > Today's Topics: > > 1. AES-GCM (Pieter Hulshoff) > 2. Re: AES-GCM (Phil Mayers) > 3. Re: AES-GCM (Pieter Hulshoff) > 4. Re: AES-GCM (Phil Mayers) > 5. Re: AES-GCM (Pieter Hulshoff) > 6. Re: issue with radius accounting (Alan DeKok) > 7. Re: Failure authenticate using IPv6 (Alan DeKok) > 8. Re: Retrieving eDirectory VLAN attributes (Alan DeKok) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 24 May 2013 12:44:02 +0200 > From: Pieter Hulshoff <phulshof(a)xs4all.nl> > To: freeradius-users(a)lists.freeradius.org > Subject: AES-GCM > Message-ID: <2687107.xyZuJZ1fbJ@spaceballsml> > Content-Type: text/plain; charset="us-ascii" > > Hello all, > > Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in the > documentation, the wiki or the mailinglist archives, but perhaps I'm > looking > in the wrong place? > > Kind regards, > > Pieter Hulshoff > > > > ------------------------------ > > Message: 2 > Date: Fri, 24 May 2013 12:21:47 +0100 > From: Phil Mayers <p.mayers(a)imperial.ac.uk> > To: freeradius-users(a)lists.freeradius.org > Subject: Re: AES-GCM > Message-ID: <519F4D4B.4080000(a)imperial.ac.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 24/05/13 11:44, Pieter Hulshoff wrote: > > Hello all, > > > > Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in > the > > documentation, the wiki or the mailinglist archives, but perhaps I'm > looking > > in the wrong place? > > Typically this is down the TLS libraries; it's not usually the case that > the application needs to do anything. > > That said, EAP-TLS is typically TLS 1.0. AIUI, AEAD ciphers require TLS > 1.2 - see section 4 of RFC 5288. But again, FreeRADIUS doesn't involve > itself in this level of detail - that's an aspect of the TLS library > (OpenSSL) we use, and whatever the EAP-TLS client is using. > > Note also that EAP-TLS (unlike other TLS-based EAP methods, such as PEAP > or TTLS) never actually sends any data over the TLS session; > essentially, it consists solely of the handshake. In TLS terms, EAP-TLS > never sends any TLS records of type=23 (application data). So, the > negotiated cipher is not used for very much. > > PEAP and TTLS have "inner" EAP exchanges, that are protected with the > TLS session, and sent as TLS type=23 records. > > Slightly OT, there seems to be some degree of uncertainty about GCM in > general, and whether it's a sensible cipher mode - for example, see > http://www.imperialviolet.org/2013/01/13/rwc03.html > > > ------------------------------ > > Message: 3 > Date: Fri, 24 May 2013 13:47:36 +0200 > From: Pieter Hulshoff <phulshof(a)xs4all.nl> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: AES-GCM > Message-ID: <2024766.p6x3QSbeB1@spaceballsml> > Content-Type: text/plain; charset="us-ascii" > > On Friday, May 24, 2013 12:21:47 PM Phil Mayers wrote: > > On 24/05/13 11:44, Pieter Hulshoff wrote: > > > Hello all, > > > > > > Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in > > > the > > > documentation, the wiki or the mailinglist archives, but perhaps I'm > > > looking in the wrong place? > > > > Typically this is down the TLS libraries; it's not usually the case that > > the application needs to do anything. > > It seems I have a lot to learn yet about what is and is not a part of > FreeRADIUS. My apologies for pushing (slightly) OT subjects onto the > mailinglist. > > > That said, EAP-TLS is typically TLS 1.0. AIUI, AEAD ciphers require TLS > > 1.2 - see section 4 of RFC 5288. But again, FreeRADIUS doesn't involve > > itself in this level of detail - that's an aspect of the TLS library > > (OpenSSL) we use, and whatever the EAP-TLS client is using. > > I guess that if we want to use AEAD cyphers we'll need to find another TLS > library or adapt/contribute to OpenSSL? > > > Note also that EAP-TLS (unlike other TLS-based EAP methods, such as PEAP > > or TTLS) never actually sends any data over the TLS session; > > essentially, it consists solely of the handshake. In TLS terms, EAP-TLS > > never sends any TLS records of type=23 (application data). So, the > > negotiated cipher is not used for very much. > > The EAP-TLS Finished (type=20) are secured/signed with this negotiated > cipher > though, correct? > > > Slightly OT, there seems to be some degree of uncertainty about GCM in > > general, and whether it's a sensible cipher mode - for example, see > > http://www.imperialviolet.org/2013/01/13/rwc03.html > > Interesting article nontheless. I guess I've been working as a hardware > engineer for too long; I haven't been bothered by timing side-channel > attacks > too much. :) It's something to take into consideration though. > > Kind regards, > > Pieter Hulshoff > > > > ------------------------------ > > Message: 4 > Date: Fri, 24 May 2013 13:06:11 +0100 > From: Phil Mayers <p.mayers(a)imperial.ac.uk> > To: freeradius-users(a)lists.freeradius.org > Subject: Re: AES-GCM > Message-ID: <519F57B3.9030800(a)imperial.ac.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 24/05/13 12:47, Pieter Hulshoff wrote: > > I guess that if we want to use AEAD cyphers we'll need to find another > TLS > > library or adapt/contribute to OpenSSL? > > I think they're supported as of OpenSSL 1.0.1, so merely compiling > against that should be sufficient, but both ends then need to use TLS > v1.2 and, as I say, most do not. > > (I'm also not sure if FreeRADIUS explicitly forces a specific TLS > version - it might, check the source code) > > > The EAP-TLS Finished (type=20) are secured/signed with this negotiated > cipher > > though, correct? > > Off the top of my head, everything after the change cipher spec is > encrypted with the negotiated symmetric cipher, yes. > > > ------------------------------ > > Message: 5 > Date: Fri, 24 May 2013 14:09:35 +0200 > From: Pieter Hulshoff <phulshof(a)xs4all.nl> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: AES-GCM > Message-ID: <4017853.IFDhid4HjM@spaceballsml> > Content-Type: text/plain; charset="us-ascii" > > On Friday, May 24, 2013 01:47:36 PM Pieter Hulshoff wrote: > > I guess that if we want to use AEAD cyphers we'll need to find another > TLS > > library or adapt/contribute to OpenSSL? > > It seems some people are way ahead of me: > > http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Encryption_A… > Support for AES-GCM was added in v1.0.1 > > Kind regards, > > Pieter Hulshoff > > > > ------------------------------ > > Message: 6 > Date: Fri, 24 May 2013 09:53:08 -0400 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: issue with radius accounting > Message-ID: <519F70C4.7060604(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Arvind Bahuguni wrote: > > Hi, > > Need help in resolving radius issues. My radius server is not > > processing accounting packets, radius server is sending access-accept > > but not proceeding further with accounting, it will send access-accept > > and start waiting for another request. > > This is in the FAQ. Read it. > > > Looks like some radius server setting issues, please help me . > > So... the RADIUS server doesn't receive packets, and you blame it? > > How about blaming the system which *sends* the accounting packets? > > Alan DeKok. > > > ------------------------------ > > Message: 7 > Date: Fri, 24 May 2013 09:56:59 -0400 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: Failure authenticate using IPv6 > Message-ID: <519F71AB.6090407(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Stefan Winter wrote: > > I don't *know* why this doesn't work, but it does with our global-scope > > addresses just fine, so I'm guessing it's the address type. > > > > Especially since link-local addresses are only valid with an interface > > scope. > > Exactly. > > > is the valid address. I don't know if the FreeRADIUS address parser is > > prepared to handle such interface-scoped addresses. There's not much use > > case for this. > > FreeRADIUS calls getaddrinfo, which *should* parse link-local > addresses. I guess... > > Alan DeKok. > > > ------------------------------ > > Message: 8 > Date: Fri, 24 May 2013 10:17:33 -0400 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: Retrieving eDirectory VLAN attributes > Message-ID: <519F767D.5030704(a)deployingradius.com> > Content-Type: text/plain; charset=UTF-8 > > Dan Lietz wrote: > > I?m pretty much a noob when it comes to freeradius as I still don?t > > completely understand what files are used for authorization and > > authentication and where to put different certain pieces of > configuration. > > Rule 1: don't touch anything. The configuration is complicated, but > it mostly works. > > The "files used for authorization" are the virtual servers. See > raddb/sites-enabled. Those files reference other configuration. But > it's all reasonably well abstracted. > > i.e. you don't need to know anything about the "mschap" module > configuration to use it. You don't even need to know *where* its > configuration lives. But if you run the server in debugging mode, it > will tell you. > > The "where to put configuration" issue largely depends on what you > want to do. Edit a virtual server? See raddb/sites-enabled. A module? > raddb/modules. > > > I?m trying to set up dynamic vlans for a wireless network with a Ruckus > > Zone Director backend and a freeradius backend authenticating via LDAP > > to eDirectory running on the same box. So far I?ve managed to configure > > 802.11x authentication using PEAP and that is working well. > > That's good. > > > Now I want to be able to retrieve the radius attribute in eDirectory for > > the vlan tag so the Ruckus Zone Directory will automatically place the > > user on the correct vlan once they are authenticated. > > OK. > > > I did some initial testing without using LDAP by adding the following > > lines to my users file: > > > > > > > > DEFAULT > > Tunnel-Type = VLAN, > > Tunnel-Medium-Type = 802, > > Tunnel-Private-Group-ID = 85, > > Fall-Through=Yes > > Yes, that works. It's a good first step. > > > By changing the value of ?Tunnel-Private-Group-ID? (set to 85 in the > > above example) the Zone Director will move users to the vlan ID I > > specify here, but it is obviously static and does not change based on > > the user. The next step is to configure FreeRadius to pull the info from > > eDir via LDAP and that?s the part I?m not getting. > > The "ldap.attrmap" file is in the "raddb" directory. It contains > mappings from LDAP to RADIUS. It's also documented in the comments at > the top of the file. > > > Part of my problem is that I don?t know which attributes mappings are > > built in and which aren?t. > > See ldap.attrmap. > > > According to this document: Integrating > > Novell eDirectory with FreeRadius > > < > https://www.netiq.com/documentation/edir_radius/radiusadmin/?page=/document… > > > > the listed radius attributes are available for use, but does that mean I > > don?t need to add them to ldap.attr or the dictionary file at all? Or > > that I don?t need to add an LDAP attribute map to the LDAP Group object > > in iManager? > > The LDAP to RADIUS map is defined in ldap.attrmap. And ONLY in > ldap.attrmap. Go look there. If a mapping isn't there, it isn't > mapped. If it is there, the LDAP attribute (if any) is mapped to the > RADIUS equivalent. > > > The other thing I don?t understand is where (i.e. what file) to put the > > ldap call for said attributes and what the syntax would look like. > > See raddb/sites-available/inner-tunnel, and "default". Look for > "ldap". Read the comments there. > > > > I?ve configured my eap.conf to include ?copy_request_to_tunnel = yes? > > and ?use_tunneled_reply = yes? > > That's correct for your setup. > > Alan DeKok. > > > ------------------------------ > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > End of Freeradius-Users Digest, Vol 97, Issue 80 > ************************************************ >

2 1

(no subject)
by Matthew Melbourne 24 May '13

24 May '13

Hi, I have an interesting scenario where a broadband user has "Auth-Type=Reject" configured as an attribute in the back-end database of FreeRADIUS, and this sppears to be working, as radtest and radclient confirm (the Access-Reject packet is received): [root@radius-one radius]# echo "User-Name=mmelbourne@realm,Password=mypassword,Framed-Protocol=PPP" | radclient -x -s 127.0.0.1 auth radius_secret Sending Access-Request of id 45 to 127.0.0.1 port 1812 User-Name = "mmelbourne@realm" Password = "mypassword" Framed-Protocol = PPP rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=45, length=73 Reply-Message = "Your account has been disabled, please call support" Total approved auths: 0 Total denied auths: 1 Total lost auths: 0 However, on the NAS (LNS), a radius debug shows that the authentication succeeds with an Access-Accept, even though the "account disabled" Reply-Message is received: May 23 14:12:28.076: RADIUS(00011A84): Send Access-Request to 213.x.x.x:1812 id 21793/12, len 107 May 23 14:12:28.076: RADIUS: authenticator 70 A9 8C A5 A8 79 A8 61 - 4D F6 99 37 F7 63 FE A5 May 23 14:12:28.076: RADIUS: Framed-Protocol [7] 6 PPP [1] May 23 14:12:28.076: RADIUS: User-Name [1] 21 "mmelbourne@realm" May 23 14:12:28.076: RADIUS: CHAP-Password [3] 19 * May 23 14:12:28.076: RADIUS: NAS-Port-Type [61] 6 Virtual [5] May 23 14:12:28.076: RADIUS: NAS-Port [5] 6 826 May 23 14:12:28.076: RADIUS: NAS-Port-Id [87] 17 "Uniq-Sess-ID826" May 23 14:12:28.076: RADIUS: Service-Type [6] 6 Framed [2] May 23 14:12:28.076: RADIUS: NAS-IP-Address [4] 6 88.x.x.x May 23 14:12:28.084: RADIUS: Received from id 21793/12 213.x.x.x:1812, Access-Accept, len 157 May 23 14:12:28.084: RADIUS: authenticator 79 6C DA EB 1A CC AD CA - BB E3 C9 CE D1 C3 AC 47 May 23 14:12:28.084: RADIUS: Reply-Message [18] 53 May 23 14:12:28.084: RADIUS: 59 6F 75 72 20 61 63 63 6F 75 6E 74 20 68 61 73 [Your account has] May 23 14:12:28.084: RADIUS: 20 62 65 65 6E 20 64 69 73 61 62 6C 65 64 2C 20 [ been disabled, ] May 23 14:12:28.084: RADIUS: 70 6C 65 61 73 65 20 63 61 6C 6C 20 73 75 70 70 [please call supp] May 23 14:12:28.084: RADIUS: 6F 72 74 [ ort] May 23 14:12:28.084: RADIUS: Framed-IP-Address [8] 6 77.x.x.x May 23 14:12:28.084: RADIUS: Framed-IP-Netmask [9] 6 255.255.255.255 May 23 14:12:28.084: RADIUS: Framed-Protocol [7] 6 PPP [1] May 23 14:12:28.084: RADIUS: Service-Type [6] 6 Framed [2] May 23 14:12:28.084: RADIUS: Vendor, Cisco [26] 54 May 23 14:12:28.084: RADIUS: Cisco AVpair [1] 48 "ip:dns-servers=213.x.x.x 213.x.x.x" May 23 14:12:28.084: RADIUS: Idle-Timeout [28] 6 28800 The only difference I can see is that the first example uses a plain-text password, and the RADIUS on the LNS is using CHAP? The backend database has "=" in the 'op' field (and not ":="), so the returned attribute is "Auth-Type = Reject" and not "Auth-Type := Reject", but it is correctly rejected using radtest/radclient, and I believe the "=" operand to be correct. Has anyone seen anything similar; the NAS is a 7206VXR running 12.2(31)SB2 and the backend is FreeRADIUS 1.1? -- Matthew Melbourne

3 2

Failure authenticate using IPv6
by Michael Sherman 24 May '13

24 May '13

HI All, I'm testing freeradius server version 2.2.0. Worked fine using IPv4. When I switched to IPv6 I got the following error: Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 41189 Here is the entry from the clients.conf: client goya { ipv6addr = fe80::215:17ff:fed0:d278 # netmask = 128 secret = test shortname = test-net } Radtest command used with output: radtest -6 test test fe80::21b:78ff:fe40:1de1 0 test Sending Access-Request of id 143 to fe80::21b:78ff:fe40:1de1 port 1812 User-Name = "test" User-Password = "test" NAS-IPv6-Address = ::1 NAS-Port = 0 Message-Authenticator = 0x00000000000000000000000000000000 Tcpdump on server: [root@jackass ~]# tcpdump -i eth0 host fe80::21b:78ff:fe40:1de1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 16:40:27.693362 fe80::21b:78ff:fe40:1de1 > fe80::215:17ff:fed0:d278: icmp6: neighbor adv: tgt is fe80::21b:78ff:fe40:1de1 16:40:27.693704 fe80::215:17ff:fed0:d278.48743 > fe80::21b:78ff:fe40:1de1.radius: RADIUS, Access Request (1), id: 0x20 length: 86 16:40:32.692677 fe80::21b:78ff:fe40:1de1 > fe80::215:17ff:fed0:d278: icmp6: neighbor sol: who has fe80::215:17ff:fed0:d278 16:40:32.694009 fe80::215:17ff:fed0:d278 > fe80::21b:78ff:fe40:1de1: icmp6: neighbor adv: tgt is fe80::215:17ff:fed0:d278 16:40:32.697159 fe80::215:17ff:fed0:d278.48743 > fe80::21b:78ff:fe40:1de1.radius: RADIUS, Access Request (1), id: 0x20 length: 86 16:40:37.702304 fe80::215:17ff:fed0:d278.48743 > fe80::21b:78ff:fe40:1de1.radius: RADIUS, Access Request (1), id: 0x20 length: 86 Ifconfig on server: [root@jackass ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:78:40:1D:E1 inet addr:10.10.20.208 Bcast:10.10.20.255 Mask:255.255.255.0 inet6 addr: fe80::21b:78ff:fe40:1de1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11032790 errors:0 dropped:0 overruns:0 frame:0 TX packets:282990 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2421527725 (2.2 GiB) TX bytes:116875391 (111.4 MiB) Interrupt:209 Here is the related logs from radius -X: radiusd: #### Loading Clients #### client 127.0.0.1 { require_message_authenticator = no secret = "testing123" shortname = "localhost" nastype = "other" } client 10.10.0.0/16 { require_message_authenticator = no secret = "test" shortname = "test-net" } client goya { ipv6addr = fe80::215:17ff:fed0:d278 IPv6 address [fe80::215:17ff:fed0:d278] require_message_authenticator = no secret = "test" shortname = "test-net" } ... radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "acct" ipv6addr = :: IPv6 address [::] port = 0 } listen { type = "control" listen { socket = "/usr/local/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 53193 Listening on authentication address :: port 1812 Listening on accounting address :: port 1813 Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address :: port 1814 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 43140 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 43140 Ready to process requests. Ignoring request to authentication address :: port 1812 from unknown client fe80::215:17ff:fed0:d278 port 43140 Thanks in advance, Mike

5 6

issue with radius accounting
by Arvind Bahuguni 24 May '13

24 May '13

Hi, Need help in resolving radius issues. My radius server is not processing accounting packets, radius server is sending access-accept but not proceeding further with accounting, it will send access-accept and start waiting for another request. Looks like some radius server setting issues, please help me . Thanks, Arvind

2 1

AES-GCM
by Pieter Hulshoff 24 May '13

24 May '13

Hello all, Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in the documentation, the wiki or the mailinglist archives, but perhaps I'm looking in the wrong place? Kind regards, Pieter Hulshoff

2 4

RE: Global variables
by Franks Andy (RLZ) IT Systems Engineer 24 May '13

24 May '13

Ah, I forgot about rlm_cache. The primary group will always be the same strangely enough, so I only need to look it up once. I'll look into the cache Thanks Andy -----Original Message----- From: freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu s.org] On Behalf Of Phil Mayers Sent: 24 May 2013 08:35 To: freeradius-users(a)lists.freeradius.org Subject: Re: Global variables On 05/23/2013 07:43 PM, Franks Andy (RLZ) IT Systems Engineer wrote: > Seems a bit excessive to do it each request. I know it's not something > likely to changegidoften but would like to not have to update itat all > should it change. We have an "over zealous" AD administrator.. But primary group is per-user, so you have to look it up per-request. You do for other groups too; aside from Microsofts irritating schema decision, this is no different. You could probably play with rlm_cache to cache either the lookup, or better yet the higher-level "decision" result, keyed by username. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

1 0

EAP-TLS and TLS record protocol
by Pieter Hulshoff 24 May '13

24 May '13

Hello all, I'm new to the list, relatively new to authentication, and I'm trying to figure out some details regarding the RFCs. I was hoping some of you might be able and willing to help me out here. As I understand it, using TLS you can authenticate the server and optionally the client, negotiate the encryption/signing algorithm(s) for the TLS record protocol, and exchange the key information before switching to the selected encryption/signing algorithm(s) for secure data transport. EAP-TLS however seems focused on authorization and exchanging the key information, leaving the actual data encryption to be determine by other means (e.g. IEEE 802.1X MKA i.c.w. MACsec). My questions: 1. Is this understanding correct? 2. Does this imply that the negotiated encryption/signing algorithm(s) are only used for the EAP-TLS Finished messages? Any and all insights would be most welcome. :) Kind regards, Pieter Hulshoff

2 1