topic For me, I got the same in Wireless

EAP-TLS authentication failure

joao.c.carvalho — Sun, 04 Jul 2021 02:39:48 GMT

We've been struggling with this problem for weeks without a solution yet. Maybe someone can help us.

Note: some information below has been redacted and the IP addresses are not the original ones. They have been changed to fictional IP addresses but they have been adjusted to reflect an equivalent situation.

This situation is as follows:

WLAN infrastructure with:

1 x AIR-WLC2112-K9 (IP address = 10.10.10.10)

8 x AIR-LAP1142N-E-K9

Data for the WLC:

Product Version.................................. 6.0.199.4

RTOS Version..................................... 6.0.199.4

Bootloader Version.............................. 4.0.191.0

Emergency Image Version................... 6.0.199.4

The WLC is connected to a switch, Cisco Catalyst model WS-C3750X-24, sw version 12.2(53)SE2.

The idea is to have the clients/supplicants (Windows XP), who have a valid certificate, authenticate against a RADIUS server. The authentication is configured as 802.1x over EAP-TLS.

The RADIUS server is a Windows 2003 Server with IAS (IP address = 15.15.15.15). This server is accessed via a WAN link. We don't manage this server.

The problem: no wireless client (Windows XP) is able to go past the initial authentication.

I should add that the WLC and the APs were working perfectly and clients were connecting correctly to them. However this setup was moved to a new building and, since then, nothing has worked. I must add that the configuration on the WLC and APs has not changed, since the network configuration (IP subnets, etc) was migrated from the previous building to this new one. But something has changed: the WAN router (connected to the Internet and with a VPN established to the corporate network) and the LAN equipment (switches), which are all brand new.

On the RADIUS side we find these error messages:

Fully-Qualified-User-Name = XXXXXXXXXXXX/XXXX/XXXXX/XXXX/XXXXX (it shows the correct information)
NAS-IP-Address = 10.10.10.10
NAS-Identifier = XX-002_WLAN
Called-Station-Identifier = f0-25-72-70-65-xx:WLAN-XX
Calling-Station-Identifier = 00-1c-bf-7b-08-xx
Client-Friendly-Name = xxxxxxx_10.10.10.10
Client-IP-Address = 10.10.10.10
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 2
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Wireless LAN Access
Authentication-Type = EAP
EAP-Type = <undetermined>
Reason-Code = 22
Reason = The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

On the WLC side, the error messages are:

TRAP log:

RADIUS server 15.15.15.15:1812 failed to respond to request (ID 42) for client 00:27:10:a3:1b:xx / user 'unknown'

SYSLOG:

Jan 06 10:16:35 10.10.10.10 XX-002_WLAN: *Jan 06 10:16:32.709: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx

Jan 06 10:17:05 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:02.960: %DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447 Authentication aborted for client 00:19:d2:02:76:xx

Jan 06 10:17:05 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:02.961: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx

Jan 06 10:17:36 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:34.110: %DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447 Authentication aborted for client 00:19:d2:02:76:xx

Jan 06 10:17:36 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:34.110: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx

WLC Debug:

*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Station 58:94:6b:15:f5:d0 setting dot1x reauth timeout = 1800

*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Connecting state

*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Sending EAP-Request/Identity to mobile 58:94:6b:15:f5:d0 (EAP Id 1)

*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Received EAPOL START from mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.709: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Connecting state

*Jan 07 19:31:42.709: 58:94:6b:15:f5:d0 Sending EAP-Request/Identity to mobile 58:94:6b:15:f5:d0 (EAP Id 2)

*Jan 07 19:31:42.710: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.710: 58:94:6b:15:f5:d0 Received EAP Response packet with mismatching id (currentid=2, eapid=1) from mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Received Identity Response (count=2) from mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 EAP State update from Connecting to Authenticating for mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Authenticating state

*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Entering Backend Auth Response state for mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.711: AuthenticationRequest: 0xd1bc104

*Jan 07 19:31:42.711: Callback.....................................0x87e1870

*Jan 07 19:31:42.712: protocolType.................................0x00140001

*Jan 07 19:31:42.712: proxyState...................................58:94:6B:15:F5:D0-9B:00

*Jan 07 19:31:42.712: Packet contains 12 AVPs (not shown)

*Jan 07 19:31:42.712: apfVapRadiusInfoGet: WLAN(1) dynamic int attributes srcAddr:0x0, gw:0x0, mask:0x0, vlan:0, dpPort:0, srcPort:0

*Jan 07 19:31:42.712: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 231) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00

*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Access-Challenge received from RADIUS server 15.15.15.15 for mobile 58:94:6b:15:f5:d0 receiveId = 155

*Jan 07 19:31:42.788: AuthorizationResponse: 0xa345700

*Jan 07 19:31:42.788: structureSize................................145

*Jan 07 19:31:42.788: resultCode...................................255

*Jan 07 19:31:42.788: protocolUsed.................................0x00000001

*Jan 07 19:31:42.788: proxyState...................................58:94:6B:15:F5:D0-9B:00

*Jan 07 19:31:42.788: Packet contains 4 AVPs (not shown)

*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Processing Access-Challenge for mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Entering Backend Auth Req state (id=3) for mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Sending EAP Request from AAA to mobile 58:94:6b:15:f5:d0 (EAP Id 3)

*Jan 07 19:31:42.805: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.805: 58:94:6b:15:f5:d0 Received EAP Response from mobile 58:94:6b:15:f5:d0 (EAP Id 3, EAP Type 13)

*Jan 07 19:31:42.806: 58:94:6b:15:f5:d0 Entering Backend Auth Response state for mobile 58:94:6b:15:f5:d0

*Jan 07 19:31:42.806: AuthenticationRequest: 0xd1bc104

*Jan 07 19:31:42.806: Callback.....................................0x87e1870

*Jan 07 19:31:42.806: protocolType.................................0x00140001

*Jan 07 19:31:42.807: proxyState...................................58:94:6B:15:F5:D0-9B:01

*Jan 07 19:31:42.807: Packet contains 13 AVPs (not shown)

*Jan 07 19:31:42.807: apfVapRadiusInfoGet: WLAN(1) dynamic int attributes srcAddr:0x0, gw:0x0, mask:0x0, vlan:0, dpPort:0, srcPort:0

*Jan 07 19:31:42.807: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00

*Jan 07 19:31:52.531: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 228) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00 ..

*Jan 07 19:31:52.808: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00

*Jan 07 19:32:02.531: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 228) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00

*Jan 07 19:32:02.808: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00

*Jan 07 19:32:12.532: 58:94:6b:15:f5:d0 Max retransmission of Access-Request (id 228) to 15.15.15.15 reached for mobile 58:94:6b:15:f5:d0

*Jan 07 19:32:12.532: 58:94:6b:15:f5:d0 [Error] Client requested no retries for mobile 58:94:6B:15:F5:D0

*Jan 07 19:32:12.533: 58:94:6b:15:f5:d0 Returning AAA Error 'Timeout' (-5) for mobile 58:94:6b:15:f5:d0

*Jan 07 19:32:12.533: AuthorizationResponse: 0xb99ff864

Finally, we've also done some packet sniffing, using Wireshark and Commview. These appear to suggest that something is wrong with one of the packets and this leads to the authentication process to fail and restart again and again:

******************** WIRESHARK CAPTURE ********************

No. Time Source Destination Protocol Info
1 0.000000 10.10.10.10 15.15.15.15 RADIUS Access-Request(1) (id=125, l=280)

Frame 1: 322 bytes on wire (2576 bits), 322 bytes captured (2576 bits)
Ethernet II, Src: Cisco_62:63:00 (f8:66:f2:62:63:00), Dst: Cisco_55:20:41 (1c:df:0f:55:20:41)
Internet Protocol, Src: 10.10.10.10 (10.10.10.10), Dst: 15.15.15.15 (15.15.15.15)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 308
    Identification: 0x501f (20511)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x4aee [correct]
    Source: 10.10.10.10 (10.10.10.10)
    Destination: 15.15.15.15 (15.15.15.15)
User Datagram Protocol, Src Port: filenet-rpc (32769), Dst Port: radius (1812)
    Source port: filenet-rpc (32769)
    Destination port: radius (1812)
    Length: 288
    Checksum: 0xe8e0 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Radius Protocol
    Code: Access-Request (1)
    Packet identifier: 0x7d (125)
    Length: 280
    Authenticator: 79b2f31c7e67d6fdaa7e15f362ecb025
    Attribute Value Pairs
        AVP: l=27 t=User-Name(1): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (username is correct!!!)
        AVP: l=19 t=Calling-Station-Id(31): 00-21-6a-29-80-xx
        AVP: l=27 t=Called-Station-Id(30): f0-25-72-70-65-c0:WLAN-XX
        AVP: l=6 t=NAS-Port(5): 2
        AVP: l=6 t=NAS-IP-Address(4): 10.10.10.10
        AVP: l=13 t=NAS-Identifier(32): XX-002_WLAN
        AVP: l=12 t=Vendor-Specific(26) v=Airespace(14179)
        AVP: l=6 t=Service-Type(6): Framed(2)
        AVP: l=6 t=Framed-MTU(12): 1300
        AVP: l=6 t=NAS-Port-Type(61): Wireless-802.11(19)
        AVP: l=89 t=EAP-Message(79) Last Segment[1]
            EAP fragment
            Extensible Authentication Protocol
                Code: Response (2)
                Id: 3
                Length: 87
                Type: EAP-TLS [RFC5216] [Aboba] (13)
                Flags(0x80): Length
                Length: 77
                Secure Socket Layer
        AVP: l=25 t=State(24): 1d68036a000001370001828b38990000000318a3088c00
        AVP: l=18 t=Message-Authenticator(80): 9fe1bfac02df3293ae2f8efc95de2d5d

No. Time Source Destination Protocol Info
2 0.060373 15.15.15.15 10.10.10.10 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=2935) [Reassembled in #3]

Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Cisco_55:20:41 (1c:df:0f:55:20:41), Dst: Cisco_62:63:00 (f8:66:f2:62:63:00)
Internet Protocol, Src: 15.15.15.15 (15.15.15.15), Dst: 10.10.10.10 (10.10.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x2935 (10549)
    Flags: 0x01 (More Fragments)
    Fragment offset: 0
    Time to live: 122
    Protocol: UDP (17)
    Header checksum: 0x58e0 [correct]
    Source: 15.15.15.15 (15.15.15.15)
    Destination: 10.10.10.10 (10.10.10.10)
    Reassembled IP in frame: 3
Data (24 bytes)

0000 07 14 80 01 05 69 e8 f5 0b 7d 05 61 6c 83 00 ae .....i...}.al...
0010 d0 75 05 c3 56 29 a7 b1 .u..V)..

No. Time Source Destination Protocol Info
3 0.060671 15.15.15.15 10.10.10.10 RADIUS Access-challenge(11) (id=125, l=1377)

Frame 3: 1395 bytes on wire (11160 bits), 1395 bytes captured (11160 bits)
Ethernet II, Src: Cisco_55:20:41 (1c:df:0f:55:20:41), Dst: Cisco_62:63:00 (f8:66:f2:62:63:00)
Internet Protocol, Src: 15.15.15.15 (15.15.15.15), Dst: 10.10.10.10 (10.10.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 1381
    Identification: 0x2935 (10549)
    Flags: 0x00
    Fragment offset: 24
    Time to live: 122
    Protocol: UDP (17)
    Header checksum: 0x73a4 [correct]
    Source: 15.15.15.15 (15.15.15.15)
    Destination: 10.10.10.10 (10.10.10.10)
    [IP Fragments (1385 bytes): #2(24), #3(1361)]
User Datagram Protocol, Src Port: radius (1812), Dst Port: filenet-rpc (32769)
    Source port: radius (1812)
    Destination port: filenet-rpc (32769)
    Length: 1385
    Checksum: 0xe8f5 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Radius Protocol
    Code: Access-challenge (11)
    Packet identifier: 0x7d (125)
    Length: 1377
    Authenticator: 6c8300aed07505c35629a7b14de483be
    Attribute Value Pairs
        AVP: l=6 t=Session-Timeout(27): 30
            Session-Timeout: 30
        AVP: l=255 t=EAP-Message(79) Segment[1]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[2]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[3]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[4]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[5]
            EAP fragment
        AVP: l=33 t=EAP-Message(79) Last Segment[6]
            EAP fragment
            Extensible Authentication Protocol
                Code: Request (1)
                Id: 4
                Length: 1296
                Type: EAP-TLS [RFC5216] [Aboba] (13)
                Flags(0xC0): Length More
                Length: 8184
                Secure Socket Layer
[Malformed Packet: SSL]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Message: Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

******************** COMMVIEW CAPTURE ******************

Packet #6, Direction: Pass-through, Time:11:27:35,251292, Size: 323
Ethernet II
    Destination MAC: 1C:DF:0F:55:20:xx
    Source MAC: F8:66:F2:62:63:xx
    Ethertype: 0x0800 (2048) - IP
IP
    IP version: 0x04 (4)
    Header length: 0x05 (5) - 20 bytes
    Differentiated Services Field: 0x00 (0)
        Differentiated Services Code Point: 000000 - Default
        ECN-ECT: 0
        ECN-CE: 0
    Total length: 0x0135 (309)
    ID: 0x2B26 (11046)
    Flags
        Don't fragment bit: 1 - Don't fragment
        More fragments bit: 0 - Last fragment
    Fragment offset: 0x0000 (0)
    Time to live: 0x40 (64)
    Protocol: 0x11 (17) - UDP
    Checksum: 0x6FE6 (28646) - correct
    Source IP: 161.86.66.49
    Destination IP: 15.15.15.15
    IP Options: None
UDP
    Source port: 32769
    Destination port: 1812
    Length: 0x0121 (289)
    Checksum: 0x5824 (22564) - correct
Radius
    Code: 0x01 (1) - Access-Request
    Identifier: 0x8D (141)
    Packet Length: 0x0119 (281)
    Authenticator: 60 4E A6 58 A8 88 A2 33 4E 56 D0 E9 3B E0 62 18
    Attributes
        Attribute
            Type: 0x01 (1) - User-Name
            Length: 0x1A (26)
            Username: XXXXXXXXXXXXXXXXXXXXXXX (username is correct!!!)
        Attribute
            Type: 0x1F (31) - Calling-Station-Id
            Length: 0x11 (17)
            Calling id: 58-94-6b-15-5f-xx
        Attribute
            Type: 0x1E (30) - Called-Station-Id
            Length: 0x19 (25)
            Called id: f0-25-72-70-65-c0:WLAN-XX
        Attribute
            Type: 0x05 (5) - NAS-Port
            Length: 0x04 (4)
            Port: 0x00000002 (2)
        Attribute
            Type: 0x04 (4) - NAS-IP-Address
            Length: 0x04 (4)
            Address: 10.10.10.10
        Attribute
            Type: 0x20 (32) - NAS-Identifier
            Length: 0x0B (11)
            NAS identifier: XX-002_WLAN
        Attribute
            Type: 0x1A (26) - Vendor-Specific
            Length: 0x0A (10)
            Vendor id: 0x00003763 (14179)
            Vendor specific:
        Attribute
            Type: 0x06 (6) - Service-Type
            Length: 0x04 (4)
            Service type: 0x00000002 (2) - Framed
        Attribute
            Type: 0x0C (12) - Framed-MTU
            Length: 0x04 (4)
            Framed MTU: 0x00000514 (1300)
        Attribute
            Type: 0x3D (61) - NAS-Port-Type
            Length: 0x04 (4)
            NAS port type: 0x00000013 (19) - Wireless - IEEE 802.11
        Attribute
            Type: 0x4F (79) - EAP-Message
            Length: 0x57 (87)
            EAP-Message
        Attribute
            Type: 0x18 (24) - State
            Length: 0x17 (23)
            State: 1F 38 04 12 00 00 01 37 00 01 82 8B 38 99 00 00 00 03 18 A6 82 B7 00
        Attribute
            Type: 0x50 (80) - Message-Authenticator
            Length: 0x10 (16)
            Message-Authenticator: 4F 13 92 9C 10 29 C5 3A B9 AE 92 CA 74 11 6C B5

Packet #28, Direction: Pass-through, Time:11:27:36,523743, Size: 62
Ethernet II
    Destination MAC: F8:66:F2:62:63:xx
    Source MAC: 1C:DF:0F:55:20:xx
    Ethertype: 0x0800 (2048) - IP
IP
    IP version: 0x04 (4)
    Header length: 0x05 (5) - 20 bytes
    Differentiated Services Field: 0x00 (0)
        Differentiated Services Code Point: 000000 - Default
        ECN-ECT: 0
        ECN-CE: 0
    Total length: 0x002C (44)
    ID: 0x4896 (18582)
    Flags
        Don't fragment bit: 0 - May fragment
        More fragments bit: 1 - More fragments
    Fragment offset: 0x0000 (0)
    Time to live: 0x7A (122)
    Protocol: 0x11 (17) - UDP
    Checksum: 0x397F (14719) - correct
    Source IP: 15.15.15.15
    Destination IP: 10.10.10.10
    IP Options: None
UDP
    Source port: 1812
    Destination port: 32769
    Length: 0x0569 (1385)
    Checksum: 0x2FE4 (12260) - incorrect

Re: EAP-TLS authentication failure

Stephen Rodriguez — Wed, 12 Jan 2011 13:42:08 GMT

The important piece of this is:

The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

This error message on the IAS/NPS server could indicate that the servers certificate has expired, that is coming from:

http://www.tech-archive.net/Archive/Internet/microsoft.public.internet.radius/2006-10/msg00014.html

I'd ask the group that manages the server to check the validity period of the certificate on the server, as well as check the certs on the clients, just to be sure.

Cheers,

Steve

Please remember to rate helpufl posts

Re: EAP-TLS authentication failure

joao.c.carvalho — Wed, 12 Jan 2011 14:15:20 GMT

Thanks for your reply.

Unfortunately, that is not the solution. This Radius server is used in a big enterprise, servicing WLANs from many locations. If that kind of thing (expired certificate) had ocurred, it would have been solved by now as a ton of people would have started complaining.

We've also been in contact with the Radius admins and they say that things are running fine for other locations.

Re: EAP-TLS authentication failure

Stephen Rodriguez — Wed, 12 Jan 2011 15:59:40 GMT

Have the server people check the client entry for this WLC. There is a check box for message authenticator, that should be unchecked. If that's doesn't work, you may need to get Microsoft involved, as the error appears to be on the IAS, from the information seen in this post.

Cheers,

Steve

Please remember to rate helpful posts

Re: EAP-TLS authentication failure

joao.c.carvalho — Wed, 12 Jan 2011 16:47:58 GMT

Thanks again.

We will ask the Radius admins to check that. However, I doubt that is the problem. This WLAN setup, with the exact same WLC and APs (and client PCs) worked perfectly at another location. A few days later, the same WLC and APs (and clients APs) were moved to another location. All the configurations, at the Radius server and at the WLC and APs side, are the same. However, at this other location the problem started and remains.

The only things that changed are:

- new router (and different type of WAN access)

- new switches (previously HP, now Cisco)

- on the previous building there were no VLANs defined; on this building there are VLANs defined.

All the rest (IP subnets, etc.) is the same.

Is it possible that, maybe due to some bug, the switch is mangling this packet, thus causing the packet invalid information we see on the packet sniffers? Looking at the packets, it clear that there's a proper exchange of information between WLC and Radius until, always at the same point, the Radius sends a fragmented packet that is identified, by both packet sniffers, as invalid and that stops the correct flow of message exchange between WLC and Radius.

Re: EAP-TLS authentication failure

Vinay Saini — Wed, 12 Jan 2011 18:30:07 GMT

Hii ,

You can try increasing the EAP timeout values as EAP-TLS is used over WAN connection and from WLC debugs it is clear that responce is not coming from RADIUS.

Good to give it a try

Thanks

Vinay

Re: EAP-TLS authentication failure

b.garczynski — Wed, 12 Jan 2011 22:02:11 GMT

As posted above I think this is an issue with the Windows IAS RADIUS settings. Could you have the remote admins remove and add the WLC back to the IAS configuration? Also, if you have a local Windows server it may be wroth it to config IAS/NPS on it just to test RADIUS on the local LAN. I have seen that same IAS error in many environments and it is almost always an issue with the IAS configuration.

Re: EAP-TLS authentication failure

Tiago Antunes — Fri, 14 Jan 2011 12:59:51 GMT

Hi Joao,

This looks like an issue on the client side configuration or on the AAA server.

1 - EAP type not supported/configured on the client side.

2 - The client wants to use an EAP method that the AAA server does not support.

HTH,
Tiago

If this helps you and/or answers your question please mark the question as "answered" and/or rate it, so other users can easily find it.

Re: EAP-TLS authentication failure

joao.c.carvalho — Sat, 15 Jan 2011 13:50:50 GMT

Thanks for all the replies.

Please take into consideration that this exact same Radius server + WLC + APs + clients + configuration was working perfectly. Then the WLC + APs + clients were moved to another place, where the only changes were a) new router and new WAN connection type b) new switches. Now it doesn't work at all.

Our latest developments tend to point to a problem on the WAN side, a fragmented packet is not being handled correctly during travel between Radius to WLC/AP. Thus the checksum invalid and packet invalid errors we see when we sniff the network.

When the issue is solved I will post here the solution.

Re: EAP-TLS authentication failure

joao.c.carvalho — Thu, 10 Feb 2011 11:20:49 GMT

SOLVED.

The solution was to change the MTU value on the RADIUS server. As soon as this was changed, everything started working perfectly.

Re: EAP-TLS authentication failure

wleppens82 — Wed, 27 Jul 2011 13:45:32 GMT

Hi Joao,

I have the more or less the same problem. Where do you change the MTU value on the radius server?

regards, wim

Re: EAP-TLS authentication failure

joao.c.carvalho — Thu, 28 Jul 2011 13:55:05 GMT

Hi,

I'm not sure, because I was not envolved on that particular change. Anyway, if we're dealing with a Windows server, I suppose it must be something like this:

http://support.microsoft.com/kb/826159

EAP-TLS authentication failure

mauricio.parra — Fri, 06 Jan 2012 16:15:52 GMT

I had the same problem and using this post I also find the solution and the explanation...

Explanation:

Configure the EAP Payload Size

http://technet.microsoft.com/en-us/library/cc755205(WS.10).aspx

Solution:

Configure the Framed-MTU Attribute

http://technet.microsoft.com/en-us/library/cc771164(WS.10).aspx

EAP-TLS authentication failure

Junior Taitt — Mon, 01 Jul 2013 00:09:15 GMT

Mauricio Parra wrote:

I had the same problem and using this post I also find the solution and the explanation...

Explanation:

Configure the EAP Payload Size

http://technet.microsoft.com/en-us/library/cc755205(WS.10).aspx

Solution:

Configure the Framed-MTU Attribute

http://technet.microsoft.com/en-us/library/cc771164(WS.10).aspx

Thanks for this, saved me a world of hurt, almost rebuilt my NPS and CA.

Chaning the Framed-MTU to 1344 is the answer.

EAP-TLS authentication failure

wilson.dale — Fri, 13 Dec 2013 00:01:34 GMT

Hi,

We spent many hours trying to solve this problem.

Our setup:

Cisco wireless setup, using windows NPS for 802.1x authentication.

Certificate base auth, with an internal PKI sending out client machine certs, and also the server cert.

Auth was failing with "reason code 22, The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server."

It turned out to be a GPO setting on the server, that was enforcing key protection.

There is this note on the below technet article:

Requiring the use of strong private key protection and user prompting on all new and imported keys will disable some applications, such as Encrypting File System (EFS) and wireless (802.1X) authentication that cannot display UI. For more information, see article 320828 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115037).

http://technet.microsoft.com/en-us/library/cc725621(v=WS.10).aspx

Hopefully this helps someone out, if you have the same annoying error.

I realize this is a little

Carl Duvall — Wed, 25 Feb 2015 16:32:18 GMT

I realize this is a little dated, but I wanted to let everyone know that I had these same errors/issues and we were able to correct it by updating the server certificate on the NPS server.

We recently saw something

brian.holmes — Fri, 25 Sep 2015 13:25:38 GMT

We recently saw something similar to this. Our Cisco WLC showed a message like this:

Thu Sep 24 15:16:54 2015

RADIUS server 1.1.1.1:1812 failed to respond to request (ID 217) for client f8:95:c7:a6:34:7c / user 'f8-95-c7-a6-34-7c'

We found the LG Phones were sending an illegal EAP code of 53 which was being silently ignored by our authentication server. According to RFC3748 the WLC should also drop this and not pass it to the authenticator in the first place.

Because the Auth server was silently ignoring the request, the WLC thought the auth server was dead and tried to switch to another one. The the WLC keeps flipping between auth servers, which also cuts off other client authentications that are in progress. This actually causes queuing issues on the auth server as well because it is waiting on the requests that got cut off by the WLC switching to another auth server.

Right now we are Blacklisting the MAC's of these phones as a workaround. We need a more permanent solution of course. It may be a while before the WLC follows the RFC and discards EAP frames with illegal codes.

Any suggestions?

The WLC is only forwarding

zdesignstudio — Wed, 14 Oct 2015 15:26:24 GMT

The WLC is only forwarding the packet and not inspecting it prior to sending it to the radius server. It unfortunately has no way to tell if the packet contains an invalid EAP type. Depending on your radius server, if you can posture you can possibly make a rule that has the radius server reply to the WLC with a "deny" even though this does not follow the RFC. You can then create a rule to automatically blacklist a device after X amount of unsuccessful login authentication attempts. Not the best solution but depending on your radius server it will automate the process of blacklisting those devices and end the issue with the DoS you have occurring with the timeouts.

Hi Guys,I know this quite old

ele203026 — Sat, 24 Oct 2015 11:24:02 GMT

Hi Guys,

I know this quite old but is it possible to change the framed mtu on Cisco ISE?

ISE always tries to send EAP

zdesignstudio — Tue, 03 Nov 2015 14:03:59 GMT

ISE always tries to send EAP-TLS fragments (usually Server Hello with Certificate) that are 1,002 bytes long (although the last fragment is usually smaller). It does not honor the RADIUS Framed-MTU. It is not possible to reconfigure it to send bigger EAP-TLS fragments.