topic Re: EAP-TLS Authentication failure over WiFi in Wireless

EAP-TLS Authentication failure over WiFi

HAT — Tue, 29 Nov 2022 11:27:11 GMT

Hi All

I have been trying to deploy a wireless solution but been stuck with appears to be an authentication failure with the Radius Server . The device is an Intune laptop attempting to connect to a Meraki managed SSID but every attempt has been unsuccessful so far . I m using Meraki APs connected over a trunk to a Meraki switch that eventually traverses the Wan to the target radius server . All the required routing is in place to ensure the 802.1x messages can reach ISE , can also confirm the device and CA root certificates on the test device have been properly configured and that the correct policy is being hit on ISE

EAP-TLS is being used as the authentication method in this scenario

Any help will be greatly appreciated

Please find below the ISE logs for the failed authentication

Steps

	11001	Received RADIUS Access-Request
	11017	RADIUS created a new session
	11117	Generated a new session ID
	15049	Evaluating Policy Group
	15008	Evaluating Service Selection Policy
	15048	Queried PIP - Network Access.UserName
	15048	Queried PIP - Radius.Called-Station-ID
	11507	Extracted EAP-Response/Identity
	12500	Prepared EAP-Request proposing EAP-TLS with challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12502	Extracted EAP-Response containing EAP-TLS challenge-response and accepting EAP-TLS as negotiated
	12800	Extracted first TLS record; TLS handshake started
	12545	Client requested EAP-TLS session ticket
	12805	Extracted TLS ClientHello message
	12806	Prepared TLS ServerHello message
	12807	Prepared TLS Certificate message
	12808	Prepared TLS ServerKeyExchange message
	12809	Prepared TLS CertificateRequest message
	12810	Prepared TLS ServerDone message
	12505	Prepared EAP-Request with another EAP-TLS challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12504	Extracted EAP-Response containing EAP-TLS challenge-response
	12505	Prepared EAP-Request with another EAP-TLS challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request ( Step latency=2588 ms)
	11018	RADIUS is re-using an existing session
	12504	Extracted EAP-Response containing EAP-TLS challenge-response
	12505	Prepared EAP-Request with another EAP-TLS challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12504	Extracted EAP-Response containing EAP-TLS challenge-response
	12505	Prepared EAP-Request with another EAP-TLS challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12504	Extracted EAP-Response containing EAP-TLS challenge-response
	12505	Prepared EAP-Request with another EAP-TLS challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12504	Extracted EAP-Response containing EAP-TLS challenge-response
	12505	Prepared EAP-Request with another EAP-TLS challenge
	11006	Returned RADIUS Access-Challenge
	12935	Supplicant stopped responding to ISE during EAP-TLS certificate exchange ( Step latency=120000 ms)
	61025	Open secure connection with TLS peer
	5411	Supplicant stopped responding to ISE

Re: EAP-TLS Authentication failure over WiFi

Mark Elsen — Tue, 29 Nov 2022 11:56:27 GMT

- Check the logs on the radius server for this particular authentication (too).

Re: EAP-TLS Authentication failure over WiFi

HAT — Tue, 29 Nov 2022 17:37:32 GMT

Hi .

Thanks for the reply , not sure what you mean , ISE is the radius server and the above is the 802.1x sequence for the failed authentication . Also attaching additional information .

Thanks in advance

Re: EAP-TLS Authentication failure over WiFi

Mark Elsen — Tue, 29 Nov 2022 18:24:27 GMT

- Ok , check these threads for hints : https://community.cisco.com/t5/network-access-control/some-win-10-clients-get-quot-12935-supplicant-stopped-responding/td-p/4031608
https://community.cisco.com/t5/network-access-control/12935-supplicant-stopped-responding-to-ise-during-eap-tls/td-p/4577834
https://community.cisco.com/t5/network-access-control/5411-supplicant-stopped-responding-to-ise-quot-use-eap-tls-for/td-p/4084578

Re: EAP-TLS Authentication failure over WiFi

HAT — Wed, 30 Nov 2022 08:10:48 GMT

Thanks . I will check the links

Re: EAP-TLS Authentication failure over WiFi

Wes Schochet — Wed, 30 Nov 2022 21:27:38 GMT

My guess is that the client is not trusting the cert from ISE so it stops responding.

Re: EAP-TLS Authentication failure over WiFi

HAT — Thu, 01 Dec 2022 11:39:57 GMT

Thanks for the feedback , I did suspect a certificate trust issue but the certificate chain between the client and server appears to be correct since similar devices can connect fine on the same SSID Onprem.

I m now looking some timeout or MTU related issues as traffic traverses the Wan for the client to authenticate on the OnPrem radius server ( ISE)

Any further help will be greatly appreciated

Re: EAP-TLS Authentication failure over WiFi

HAT — Mon, 19 Dec 2022 11:36:29 GMT

Hi All .

I have lowered the MTU onto the switch the APs are connected to but that hasn't made a difference .However, I just noticed that that the APs Radius requests are experiencing some packet drops as they hit our Onprem firewall ( yes there s a firewall indeed ).

Any idea why ?

The packet capture in attachment has been obtained from the firewall.

Thanks in advance for all you input

Re: EAP-TLS Authentication failure over WiFi

Scott Fella — Mon, 19 Dec 2022 16:14:03 GMT

I have similar issues with EAP-TLS, but its only to our ISE 3.2 PSN's in Azure. Our issue is a mtu mismatch between our tunnel from our DC to Azure which I think is the issue. Folks suggested to look at all the mtu configurations on the path and see if you have a mismatch. Typically some FW's will drop fragmented packets which I think you are seeing. Also ISE 3.1, you can define the mtu on Gig 0, but before that, look at the mtu configuration on all devices along the path to ISE.

Re: EAP-TLS Authentication failure over WiFi

HAT — Tue, 20 Dec 2022 10:57:18 GMT

Thanks for the feedback . The devices MTU along the path are configured as follow

Client MTU : 1500

Meraki Switch ( Remote site ) : 9578

Wan Router MTU ( Remote site) : 1500

Wan Router MTU ( Head Office) : 1500

Firewall ( Head Office ) : 1500 ( this s where we are seeing some packet drops)

Re: EAP-TLS Authentication failure over WiFi

Scott Fella — Tue, 20 Dec 2022 15:54:18 GMT

What you have to look at is the overhead that might be added between the Wan and the FW. If you are seeing the FW dro the packets, its most likely because of fragmentation, so you might have to drop the mtu more that what you have. I'm no expert in mtu, but since I have similar issues, folks are guiding me to change the mtu or make sure it isn't fragmenting EAP packets. Have you tried to set the mtu on the client or the Meraki Switch lower than 1500?

Re: EAP-TLS Authentication failure over WiFi

HAT — Tue, 20 Dec 2022 17:01:45 GMT

Hi Scott

Thanks for advising , 1500 is the lowest the Meraki switch can be lowered to . Tried that but no luck . Will test locally so I can determine whether this is Wan related or not .

Re: EAP-TLS Authentication failure over WiFi

Scott Fella — Tue, 20 Dec 2022 17:16:50 GMT

In my case, any ISE instance that is not going over our tunnel to Azure Virtual Gateway works fine. for us, it is a possible mtu mismatch. I think if you have an ISE node locally that doesn't hit your Fw, you will be fine as switches and routers will reassemble the packets.

Search online, "firewall droping eap-tls"

Re: EAP-TLS Authentication failure over WiFi

HAT — Sun, 22 Jan 2023 22:10:26 GMT

Hi All

Just to let you know the matter is now solved . Our on Prem Firewall had a Zone protection profile with a setting instructing the firewall to drop fragmented traffic .

Once that setting was updated it worked .

Thanks all for your contributions