- Freeradius-Users - lists.freeradius.org

is the book published?
by Spacelee 26 Sep '10

26 Sep '10

is the book for freeradius published? -- *Space Lee*

1 2

DHCP server does not process requests
by Alexander Shikoff 25 Sep '10

25 Sep '10

Hello, In my network there is Cisco ISG acting as DHCP relay. It relays requests from customers to DHCP server of freeradius: Sep 25 12:51:05.045: DHCPD: input i/f override GigabitEthernet0/1.33 for client Sep 25 12:51:05.045: DHCPD: Reload workspace interface GigabitEthernet0/1.33 tableid 0. Sep 25 12:51:05.049: DHCPD: tableid for 193.200.84.232 on GigabitEthernet0/1.33 is 0 Sep 25 12:51:05.049: DHCPD: client's VPN is . Sep 25 12:51:05.049: DHCPD: using received relay info. Sep 25 12:51:05.049: DHCPD: Sending notification of DISCOVER: Sep 25 12:51:05.049: DHCPD: htype 1 chaddr 00e0.9110.8347 Sep 25 12:51:05.049: DHCPD: remote id 000600226b2a8d52 Sep 25 12:51:05.049: DHCPD: circuit id 000400210103 Sep 25 12:51:05.049: DHCPD: interface = GigabitEthernet0/1.33 Sep 25 12:51:05.049: DHCPD: class id 4d53465420352e30 Sep 25 12:51:05.049: DHCPD: No internally specified class returned Sep 25 12:51:05.049: DHCPD: Looking up binding using address 193.200.84.232 Sep 25 12:51:05.049: DHCPD: Found previous binding with giaddr 193.200.84.232 Sep 25 12:51:05.049: DHCPD: Keeping state for received DHCPDISCOVER, from UNNUM-IF Sep 25 12:51:05.049: DHCPD: setting giaddr to 193.200.84.232. Sep 25 12:51:05.053: DHCPD: BOOTREQUEST from 0100.e091.1083.47 forwarded to 193.200.85.22. freeradius listens 67 port on 193.200.85.22: # sockstat |grep rad freeradius radiusd 94903 5 udp4 193.200.85.22:67 *:* I see incoming packets: # tcpdump -vvvni re0 port 67 tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes 16:05:23.403248 IP (tos 0x0, ttl 254, id 142, offset 0, flags [none], proto UDP (17), length 345) 193.200.84.232.67 > 193.200.85.22.67: BOOTP/DHCP, Request from 00:e0:91:10:83:47, length 317, hops 1, xid 0x4bb0c74b, Flags [none] (0x0000) Gateway-IP 193.200.84.232 Client-Ethernet-Address 00:e0:91:10:83:47 [|bootp] 16:05:26.404455 IP (tos 0x0, ttl 254, id 143, offset 0, flags [none], proto UDP (17), length 345) 193.200.84.232.67 > 193.200.85.22.67: BOOTP/DHCP, Request from 00:e0:91:10:83:47, length 317, hops 1, xid 0x4bb0c74b, secs 768, Flags [none] (0x0000) Gateway-IP 193.200.84.232 Client-Ethernet-Address 00:e0:91:10:83:47 [|bootp] But radiusd does not process them: I see no any debug output when running 'radiusd -X'. The dhcp configuration is default from raddb/sites-available, I only added 'detail' in every dhcp-section. Any ideas? Thanks in advance. -- MINO-RIPE

2 2

Re: Re: radius client / send NAS IP ?
by Michael Arndt 25 Sep '10

25 Sep '10

Alan, thx for answering at least the radclient of the installed version does not allow to add those attributes according to manpage if i read your hint right i should download an actual version and compile to get an radclient with enhanced abilities :-) TIA Micha ----- ursprüngliche Nachricht --------- Subject: Re: radius client / send NAS IP ? Date: Sa 25 Sep 2010 15:01:49 CEST From: Alan DeKok<aland(a)deployingradius.com> To: FreeRadius users mailing list<freeradius-users(a)lists.freeradius.org> Michael Arndt wrote: > is there a radtest client where i can send those attribute / value pairs > intentionally ? $ man radclient Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ---- ursprüngliche Nachricht Ende ----

2 1

radius client / send NAS IP ?
by Michael Arndt 25 Sep '10

25 Sep '10

Hello *, at the time beeing i have to use an old radius version for different reasons. freeradius-client-1.1.5-36 freeradius-devel-1.1.6-47 freeradius-1.1.6-47 freeradius-client-devel-1.1.5-36 freeradius-client-libs-1.1.5-36 for real logins at WLAN Hot Spot the DEFAULT NAS-IP-Address == "192.168.123.45" or DEFAULT Called-Station-Id =~ ".*:MYSSID" are part of the check ( via criteria in users ) is there a radtest client where i can send those attribute / value pairs intentionally ? else in my traces i will always see a refused as test result, since from localhost those parameters will not match Prio low, would just be nice for testing TIA Micha

2 1

rlm_exec: Wait=yes but no output defined
by Michael Arndt 25 Sep '10

25 Sep '10

Hello *, radiusd -X in different places announces rlm_exec: Wait=yes but no output defined. Did you mean output=none? Will freeradius fall back internally to output=none without inserting this attribut / value in the config ? Or should i mandatory add output=none ? TIA Micha

1 0

Last call for 2.1.10
by Alan DeKok 25 Sep '10

25 Sep '10

I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. The changelog is *extensive*. There are a large number of minor bugs fixed, and a lot of minor new features added. But the result is that the server has taken a significant step ahead in usability and functionality. Thanks to everyone for testing intermediate releases. Alan DeKok.

10 23

Multiple Databases
by sekchel lee 24 Sep '10

24 Sep '10

I want Multiple databases group1 ==> databases1 group2 ==> databases 2 .. .. Please Help me

2 1

Radius proxy - kind of
by Matija Levec 24 Sep '10

24 Sep '10

Hi everyone! First a little bit of explaining... - auth_server 1 client - fr_proxy -[ - auth_server 2 (client=random NAS, fr_proxy=freeradius, auth_server=two-factor auth server(s)) Currently we have clients authenticating directly to auth_server 1. We would like to gradually (and transparently) move users to new authenticators which use auth_server 2 Question What I would like to accomplish is: If auth_server 1 returns notfound or reject or fail, proxy request to auth_server 2 Is it possible to use 'configurable module fail over'-like syntax for configuring proxy (home)servers? I hopes this makes sense. Anyway... all ideas appreciated! Regards, Matija

1 0

Re: Session Resumption fails
by Alexander Clouter 24 Sep '10

24 Sep '10

Hi, * Panagiotis Georgopoulos <panos(a)comp.lancs.ac.uk> [2010-09-24 04:17:16+0100]: > > I am afraid your suggestion though to add the above in my inner-tunnel > virtual server didn't solve the problem. After having searched the archives > of the list, I found out that this is an OpenSSL bug and there is a fix in > FreeRadius 2.1.10 for it. > A quick history lesson of this... That bug was more linked to OpenSSL actually authenticating sessions it should not if I remember correctly. https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=15 https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=21 As a result, as the OpenSSL folk were being awkward and claiming without explaination that FreeRADIUS was at fault, Alan added a check to only accept session resumption if there is some cached information returned. Then, along came Andreas Hartmann, who in spite of us all saying "give up, it's openssl at fault and no one is helping out" stumbled upon: http://lists.freeradius.org/mailman/htdig/freeradius-users/2010-June/msg001… > I just compiled 2.1.10 and I verify that I don't see resuming sessions > failing with this no information in the cache : > > Info: [ttls] Skipping Phase2 due to session resumption > Info: [ttls] WARNING: No information in cached session! > > However, I am not seeing the correct behaviour either :-/ > > [snipped] > > Does anyone have any pointers/suggestions? Anyone who managed to do session > resumption with 2.1.10? > > Fri Sep 24 03:03:10 2010 : Debug: Module: Linked to module rlm_eap > Fri Sep 24 03:03:10 2010 : Debug: Module: Instantiating module "eap" from file /usr/local/etc/raddb/eap.conf > Fri Sep 24 03:03:10 2010 : Debug: eap { > Fri Sep 24 03:03:10 2010 : Debug: default_eap_type = "md5" > Fri Sep 24 03:03:10 2010 : Debug: timer_expire = 60 > Fri Sep 24 03:03:10 2010 : Debug: ignore_unknown_eap_types = no > Fri Sep 24 03:03:10 2010 : Debug: cisco_accounting_username_bug = no > Fri Sep 24 03:03:10 2010 : Debug: max_sessions = 4096 > Fri Sep 24 03:03:10 2010 : Debug: } > [snipped] > Fri Sep 24 03:03:10 2010 : Debug: Module: Linked to sub-module rlm_eap_ttls > Fri Sep 24 03:03:10 2010 : Debug: Module: Instantiating eap-ttls > Fri Sep 24 03:03:10 2010 : Debug: ttls { > Fri Sep 24 03:03:10 2010 : Debug: default_eap_type = "md5" > Fri Sep 24 03:03:10 2010 : Debug: copy_request_to_tunnel = no > Fri Sep 24 03:03:10 2010 : Debug: use_tunneled_reply = no > Fri Sep 24 03:03:10 2010 : Debug: virtual_server = "inner-tunnel" > Fri Sep 24 03:03:10 2010 : Debug: include_length = yes > Fri Sep 24 03:03:10 2010 : Debug: } > use_tunneled_reply = yes > Fri Sep 24 03:03:10 2010 : Info: Ready to process requests. > rad_recv: Accounting-Request packet from host 2001:db93::2 port 37783, > id=15, length=102 > Acct-Status-Type = Accounting-Off > Acct-Authentic = RADIUS > NAS-IPv6-Address = 2001:db93::2 > NAS-Identifier = "panosAP-MR2" > Called-Station-Id = "00-1C-F0-9D-22-FF:panos_secure2" > Acct-Terminate-Cause = NAS-Reboot > Fri Sep 24 03:03:21 2010 : Info: # Executing section preacct from file > /usr/local/etc/raddb/sites-enabled/default > Fri Sep 24 03:03:21 2010 : Info: +- entering group preacct {...} > Fri Sep 24 03:03:21 2010 : Info: ++[preprocess] returns ok > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute Client-IP-Address was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute NAS-IP-Address was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute Acct-Session-Id was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute User-Name was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] Hashing ',,,,' > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] Acct-Unique-Session-ID = "bfabf462b52fda97". > As a non-SSL resumption issue, this is going to cause you pain. I recommend in your 'acct_unique' module, the value of 'key' is changed to something like (obviously change to what you think is best): ---- acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port, NAS-IPv6-Address, Packet-Src-IP-Address, Packet-Src-IPv6-Address, Called-Station-Id, Calling-Station-Id" } ---- The use of 'Client-IP-Address' is actually a bug...in FreeRADIUS (as it is a depreated attribute). > Fri Sep 24 03:03:58 2010 : Debug: Going to the next request > Fri Sep 24 03:03:58 2010 : Info: Ready to process requests. > rad_recv: Access-Request packet from host 2001:db94::2 port 53023, id=1, > length=189 > User-Name = "anonymous" > NAS-IPv6-Address = 2001:db4::2 > NAS-Identifier = "panosAP-TD4" > NAS-Port = 1 > Called-Station-Id = "00-1B-2F-2C-AE-45:panos_secure" > Calling-Station-Id = "00-1B-2F-2C-AD-D9" > Framed-MTU = 1400 > NAS-Port-Type = Wireless-802.11 > Connect-Info = "CONNECT 54Mbps 802.11g" > EAP-Message = 0x02c6000e01616e6f6e796d6f7573 > Message-Authenticator = 0xbc939da0f8f0ae045e3b34aacc8b8f4e > A non-SSL issue again, you *MUST* make your username 'user@realm' (or for TTLS '@realm' for the outer layer, and you should *force* Reject now, before it is too late, 'realm-less' logins. I guess this is works-in-progress for an eduroam deployment? If you do not force a realm on the outer layer, your users locally will be able to use 'eduroam' but the moment they leave the campus it stops working. The simpliest solution and only solution is to reject realmless (NULL) EAP authentications *now*. > Fri Sep 24 03:05:03 2010 : Info: # Executing section post-auth from file > /usr/local/etc/raddb/sites-enabled/inner-tunnel > } # server inner-tunnel > Fri Sep 24 03:05:03 2010 : Info: [ttls] Got tunneled reply code 2 > Reply-Message = "Hello, bob" > MS-MPPE-Encryption-Policy = 0x00000001 > MS-MPPE-Encryption-Types = 0x00000006 > MS-MPPE-Send-Key = 0x0e862e8c86b378eefa940cf437a147f8 > MS-MPPE-Recv-Key = 0xd701a18f6107c06a01b07b6dd677f587 > EAP-Message = 0x03030004 > Message-Authenticator = 0x00000000000000000000000000000000 > User-Name = "bob" > Fri Sep 24 03:05:03 2010 : Info: [ttls] Got tunneled Access-Accept > Fri Sep 24 03:05:03 2010 : Info: [ttls] Saving response in the cache > Fri Sep 24 03:05:03 2010 : Info: [ttls] WARNING: No information to cache: session caching will be disabled for this session. > Fri Sep 24 03:05:03 2010 : Debug: SSL: Removing session 1d6029bbddba233cd443d692b968df093237d9ad982f9ccc8a2defcd3edeb243 from the cache > Yes, editing your 'eap' module so that 'use_tunneled_reply = yes' should solve all this. Cheers -- Alexander Clouter .sigmonster says: fortune: cpu time/usefulness ratio too high -- core dumped.

1 0

Configuring LDAP lookups for EAP and inner-tunnel
by Jeffrey Collyer 24 Sep '10

24 Sep '10

Using freeradius 2.1.7 to authenticate wireless users via eap, checking against an ldap server. Its working fine, but I'm seeing an ldap lookup for each part of the eap conversation. This leads to something like 13 LDAP lookups for each valid eap authentication sequence. I did check the archives and found one thread about this same topic from a user of freeradius 1.x, and the comments there were that it would be much better in 2.x. via the inner-tunnel stuff. And I see in the eap_modules_changes page on the wiki, that Autz caching should resolve this for me. So I moved my ldap lookup configuration from the authorize section of the sites-enabled/default file into the inner-tunnel file. But I still see the same number of ldap queries per eap session. Next I tried to enable the cache section in the eap.conf for tls, but I have not seen that make any difference in the ldap calls. And from the comments I assume that just for session resumption, not initial authentication. Could someone give me a pointer/hint as to how to configure eap/ldap to cut down on the number of ldap queries. Any help greatly appreciated. Jeff

3 4