EAP on Cisco Cat2960 & Aironet1200: TLS Fails
Hi, I'm setting up a secure authenticated wired and wireless network for a client of mine, closely following the following HOWTO documents:- http://vuksan.com/linux/dot1x/802-1x-LDAP.html integrating latest FreeRADIUS 1.1.4 with recently purchased (end 2006) Cisco Catalyst 2960 and Cisco Aironet 1200. We're attempting to do PEAP authentication with a mix of WinXP and MacOS X as supplicants. Details of each component:- 1. FreeRADIUS v1.1.4 - Running on FreeBSD 6.2-RELEASE, compiled via FreeBSD ports. The raddb config diffs comparing to sample configs:- http://absolute-p.ath.cx/Debug/DIFFS.txt - Nothing out of the ordinary (i.e. standard EAP-PEAP config, using simple users file for now) - The certs in certs directory are recreated as per FAQ item (i.e. via CA.all script + xpextensions). 2. Cisco Catalyst 2960 (show ver):- Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Fri 28-Jul-06 04:33 by yenanh 3. Cisco Aironet 1200 (show ver):- Cisco Internetwork Operating System Software IOS ™ C1200 Software (C1200-K9W7-M), Version 12.3(2)JA6, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by cisco Systems, Inc. Compiled Fri 31-Mar-06 13:44 by pwade The Cisco Aironet 1200 configs closely follow this PDF document:- http://blog.segfault.be/Documentation/Wireles%20802.1x%20+%20PEAP%20with%20W... resulting in this config:- http://absolute-p.ath.cx/Debug/aironet1200-config.txt (The author of the above document shared his working Aironet IOS version: c1200-k9w7-mx.123-8.JEA : I am planning to get hold of this and repeat tests). Problem: EAP Fails (Doesn't even get to TLS negotiation). In both cases, we get perpetual "Access-Challenge" messages sent by FreeRADIUS, at a very early stage — even before / during the initial TLS negotiation in EAP. Some FreeRADIUS debugging logs (radiusd -X):- I. Problematic Authenticators:- 1. Aironet 1200:- http://absolute-p.ath.cx/Debug/freeradius1.1.4-users-aironet1200-c1200-k9w7-... 2. Cisco Catalyst 2960:- (I will update this post once I get hold of Cisco Catalyst 2960 debug info, which is similar to what I'm seeing with Aironet 1200). II. Working Authenticators:- Meanwhile, I also tested the same environment with the following authenticators, and got it working with no changes:- 1. Linksys WRT54GS (firmware v4.71.1 + hyperwrt-2.1b1-thibor15c):- All works OK with WPA Enterprise, as shown here:- http://absolute-p.ath.cx/Debug/freeradius1.1.4-users-linksyswrt54gs-4.71.1-h... 2. Older Cisco Catalyst 2950:- I managed to get hold of an older Cisco 2950 model, with an earlier IOS version, and tested the same environment on it, this time it works! (I will update this post once I get its details and debugging output). This leads to a conclusion that something might be up with latest Cisco IOS implementation i.e. not playing nice with FreeRADIUS. Aside from expressing this issue with our local Cisco support (which I feel will be like barking to the right (but apathetic) tree , since I would think they only support Cisco / MS RADIUS products) ;-) ), I would appreciate if anybody here with experience with such equipment can shed some light on this issue. Thanks in advance! :) p.s. longer and constantly updated version of this post is in my blog:- http://absolute-p.ath.cx/2007/02/12/freeradius-vs-certain-recent-cisco-ios-v... --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..")
Senandung Mendonan wrote:
Problem: EAP Fails (Doesn't even get to TLS negotiation). In both cases, we get perpetual "Access-Challenge" messages sent by FreeRADIUS, at a very early stage — even before / during the initial TLS negotiation in EAP.
No... the NAS isn't seeing the response of the RADIUS server, so it re-sends the Access-Request, the server notices the duplicate request, and re-sends it's response. Since the NAS isn't seeing the response of the server, it doesn't see the duplicate response, either. So it starts over from scratch. i.e. RADIUS is driven by the NAS, not by the RADIUS server. Saying "perpetual Access-Challenge" means you're thinking that the server is somehow in charge of the conversation flow. It's not. If the server is sending perpetual Access-Challenges, it's because the client is sending perpetual Access-Requests, and ignoring the challenge responses. Since the same IOS version seems to work for someone else, the problem is local to you. Please see the FAQ for what to do when the NAS never sees the response from the server. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 2/13/07, Alan DeKok <aland@deployingradius.com> wrote:
Senandung Mendonan wrote:
Problem: EAP Fails (Doesn't even get to TLS negotiation). In both cases, we get perpetual "Access-Challenge" messages sent by FreeRADIUS, at a very early stage — even before / during the initial TLS negotiation in EAP.
No... the NAS isn't seeing the response of the RADIUS server, so it re-sends the Access-Request, the server notices the duplicate request, and re-sends it's response.
Yes, I believe so as well.
Since the same IOS version seems to work for someone else, the problem is local to you. Please see the FAQ for what to do when the NAS never sees the response from the server.
Your phrase "NAS never sees the response" helped me focus on that problem (previously I thought something wrong with my config). Finally, after hours of troubleshooting, the root cause was found: as Mr Alan DeKok pointed out it was the environment:- 1. For the Cisco Catalyst 2960: all it needed was another hard reset! Somehow one of the config lines (source port 1645…) didn't get activated until a hard reset. 2. For the Cisco Aironet 1200: Something else (a router) was blocking the Access-Challenge packet from reaching port 1645 on the Aironet. Fixed the rules. So now we get the following working as expected:- 1. Authenticating a user in users file. 2. Authenticating a user in LDAP. However, we are unable to get through one last hurdle:- 3. Authenticating a user in LDAP, then VLAN information passed back to NAS via cisco-avpair settings in LDAP. Somehow, when we add radiusReplyItem containing the desired cisco-avpairs, we get back the same Access-Challenge loop at the early EAP stage. Here are the debug outputs for comparison:- 1. For LDAP entry 'testuser', as follows:- dn: uid=testuser,ou=People,dc=company,dc=net sambaPrimaryGroupSID: S-2-3-8-1040 sambaAcctFlags: [U ] shadowLastChange: 13525 sambaPwdLastSet: 1168566854 sambaLMPassword: 94918E8B0385E0A9AAD3B435B51404EE sambaPwdCanChange: 1168566854 sambaNTPassword: 25AF711D2C13E00B6AB7DD4DE11B7136 cn: Company Test User mailRoutingAddress: testuser@mail.company.net uidNumber: 1003 gecos: Company Test User mail: testuser@company.net krbName: testuser@COMPANY.NET uid: testuser homeDirectory: /home/testuser objectClass: posixAccount objectClass: shadowAccount objectClass: inetLocalMailRecipient objectClass: person objectClass: organizationalPerson objectClass: top objectClass: kerberosSecurityObject objectClass: radiusprofile objectClass: sambaSamAccount objectClass: inetOrgPerson mailHost: mail.company.net gidNumber: 20 givenName: Company Test sn: User loginShell: /bin/sh radiusReplyItem: cisco-avpair += "tunnel-type=VLAN" radiusReplyItem: cisco-avpair += "tunnel-medium-type=802 media" radiusReplyItem: cisco-avpair += "tunnel-private-group-ID=110" userPassword: mangkuk sambaSID: S-1-5-21-2238693525-531040028-2956884036 Authentication fails with Access-Challenge loop in EAP (at rlm_tls, similar to what I'm seeing before), as shown here:- http://absolute-p.ath.cx/Debug/freeradius-1.1.4-cat2960-with-ldap.txt However, as soon as I remove all radiusReplyItem attributes from the same entry, the authentication succeeds, and I get connected. Any help is welcome — thanks. -- --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..")
Senandung Mendonan wrote:
radiusReplyItem: cisco-avpair += "tunnel-type=VLAN" radiusReplyItem: cisco-avpair += "tunnel-medium-type=802 media" radiusReplyItem: cisco-avpair += "tunnel-private-group-ID=110"
That's wrong. It should just be: radiusReplyItem: tunnel-type=VLAN radiusReplyItem: tunnel-medium-type=802 radiusReplyItem: tunnel-private-group-ID=110
participants (3)
-
Alan DeKok -
Phil Mayers -
Senandung Mendonan