PEAP authentication problems

[stefaanbolle]

Hi,

I configured a Cisco AP 1200 IOS with PEAP.

Hereby the AP Config:

aaa new-model

!

!

aaa group server radius rad_eap

server 192.168.4.58 auth-port 1645 acct-port 1646

!

aaa group server radius rad_mac

!

aaa group server radius rad_acct

!

aaa group server radius rad_admin

!

aaa group server tacacs+ tac_admin

!

aaa group server radius rad_pmip

!

aaa group server radius dummy

!

aaa authentication login eap_methods group rad_eap

aaa authorization exec default local

aaa authorization ipmobile default group rad_pmip

aaa accounting network acct_methods start-stop group rad_acct

aaa session-id common

dot11 arp-cache optional

!

bridge irb

!

!

interface Dot11Radio0

no ip address

no ip route-cache

!

encryption vlan 184 key 1 size 128bit 7 xxxx transmit-key

encryption vlan 184 mode wep mandatory mic key-hash

!

encryption key 1 size 128bit 7 xxxxx transmit-key

encryption mode wep mandatory

!

broadcast-key vlan 184 change 3600

!

!

ssid test

vlan 184

authentication open eap eap_methods

authentication network-eap eap_methods

!

world-mode

speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0

rts threshold 2312

station-role root

dot1x reauth-period 1800

dot1x client-timeout 1800

bridge-group 1

bridge-group 1 subscriber-loop-control

bridge-group 1 block-unknown-source

no bridge-group 1 source-learning

no bridge-group 1 unicast-flooding

!

interface Dot11Radio0.184

encapsulation dot1Q 184

no ip route-cache

bridge-group 184

bridge-group 184 subscriber-loop-control

bridge-group 184 block-unknown-source

no bridge-group 184 source-learning

no bridge-group 184 unicast-flooding

bridge-group 184 spanning-disabled

!

interface FastEthernet0

no ip address

ip accounting output-packets

no ip route-cache

speed 100

full-duplex

!

interface FastEthernet0.3

encapsulation dot1Q 3 native

no ip route-cache

bridge-group 1

no bridge-group 1 source-learning

bridge-group 1 spanning-disabled

!

interface FastEthernet0.184

encapsulation dot1Q 184

no ip route-cache

bridge-group 184

no bridge-group 184 source-learning

bridge-group 184 spanning-disabled

!

interface BVI1

ip address 192.168.4.98 255.255.254.0

ip accounting output-packets

no ip route-cache

!

ip default-gateway 192.168.4.3

ip http server

ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag/ivory/1100

ip radius source-interface BVI1

radius-server local

!

radius-server host 192.168.4.58 auth-port 1645 acct-port xxxx key xxx

radius-server timeout 120

radius-server deadtime 1200

radius-server domain-stripping

radius-server attribute 32 include-in-access-req format %h

radius-server authorization permit missing Service-Type

radius-server vsa send accounting

bridge 1 protocol ieee

bridge 1 route ip

bridge 184 protocol ieee

W're using a Cisco Wireless client adaptor with the latest ACU version fully installed and configured my client for PEAP. I also configured the Windows XP network settings appropriately.

The RADIUS we are using is a Cisco ACS 3.2.1. We used a Microsoft certificate for the server that we issued ourselves.

Without configuring security, the client can associate with the AP, but when we enable PEAP and I open the ACU status screan, the client associates with the AP, but canot authenticate successfully. Status hangs on 'autenticating'. I don't see any traffic to the RADIUS server.

Who can help us?

Thanks in advance!

[#2]

Try installing the latest image for the AP 1200, if you have not already done this

[stefaanbolle]

Thanks for the reply!

We're already runing the latest image version of the AP.

[steve.deal]

1. You do not want to use windows to configure the adaptor if you are using ACU.

2. Make sure you install the certificate on the client machine.

I have had better luck using the XP client for peap than ACU.

[#5]

I know this doesn't help, but I have exactly the same problem and symptoms as your are experiencing.

I would be happy to hear about your resolution. I suspect that we will have better luck using the MS supplicant rather that the Cisco supplicant, but I have not been able to try this yet.

I will inform you if this approach works.

[jczaplewski]

Many things could be wrong unfortunately, so I'll list a few that I've had to trudge through in the hopes they help:

1) You're using ports 1646/1645 for RADIUS. Those are the older ports. Newer servers use 1812 (I think 1813 for accounting, I'd have to verify). Ensure your server is listening on 1645 as you have defined or you wont get any authentication.

2) Turn on dot11 debugging. The nice thing about new IOS APs is they give you the ability to see if you're even hearing your client. I'm still learning to use this tool but I use "debug dot11 aaa dot1x all" to see who's talking and when. The output is of course cryptic, but it's nice to see the output.

3) Lastly, once you're talking to the RADIUS server, use it's logs to determine the output error. I've found that with PEAP, depending on the client I use (I use a FUNK radius server, and FUNK Odysee Clients - thank you Cisco for ignore CF form factor wireless cards for 4 years ;p), the inner authentication protocal version 1 or 2 is the complaint from the RADIUS server.

[emcpherson]

I just opened a TAC case on this one whereby I have already installed the latest client, made sure PEAP is installed, had the latest WAP image, network security setup on the ACU as per the documentation to select the "host base EAP(802.1x) and select dynamic wep, then turned on debug options on the WAP to see the communication between the client and the WAP:

debug radius authentication

debug dot11 aaa dot1x process

debug dot11 aaa dot1x state-machine

Guess what... there is no communication between the client and the wap for authentication. You can see association and even get an ip address from dhcp but...

The advise as per the TAC engineer is to put in a Static WEP key for now and you should get the communication going. They have already noticed this on some calls and have not seen a bug case # assigned to it. They will be working a fix on the next release. Once you do that you should see the Raduis and 802.1x communication going on.

After doing this I can then concentrate on why I am not getting PEAP authenticated on our Funk Radius EE Server v4.7.

The other thing...remove the "authentication network-eap eap_methods" when you are doing PEAP. You enable that for LEAP so you have to create a different vlan for that.

I use 1812/1813 for the radius server.

:-) Ed