NAC - Endpoint abandoned EAP session

[bgoulet00]

we have an issue where some clients are authenticating fine and some are not and reported as client abandoning the sessions, even on the same exact switch.  this is not intermittent, clients that work always work and clients that fail always fail.

despite the error from ISE, it isn't the client that is abandoning the session.  from the packet capture on the port the transaction starts out fine, ISE sends its data and the client acknowledges each packet.  when it comes the client's turn it sends its first packet and never gets an acknowledgement so it doesn't send anymore.  eventually the session times out and everything starts over.

all ports on the switch are configured identically and all MTUs are default 1500.  All clients are getting identical 802.1x configs from GPO and are also assigned corporate CA signed certs for their EAP-TLS identity.  the clients are configured to NOT verify the server cert.

TAC has said they don't see anything in the ISE client debugs, from its perspective the client abandoned the session because it never heard anything more from the client.  They believe the client has an issue and is sending a bad packet that the switch is dropping and that's why there is no acknowledgement.  They can't explain why however and are trying to dismiss this as a client issue.  i wouldn't doubt there is a problem with the client but we can't figure out what that is and from the clients perspective, it did its part and is waiting for an acknowledgement.  how do we figure out what is wrong with the client's packet and why it is not being acknowledged?  if the network is receiving this data and determining something is wrong with it there must be a way to identify what that determination was.  

pcap file attached 

[Massimo Baschieri]

Hope it helps, I had a similar issue some time ago on some wireless hosts and it turned out to be an mtu issue, TLS seems very sensitive to mtu.

If you have the chance to try with peap and it works most probably the issue is with mtu.

Can't figure out why this happen on some hosts only, maybe some software which tricks with mtu, like vpn clients? 

[bgoulet00]

i don't have the option of trying with PEAP.  what did you end up doing as a fix for the MTU issue?

[Massimo Baschieri]

It turned out to be an mtu issue at sd-wan level, before the isp fixed the issue I applied a simple workaround, I lowered the mtu on the access points management vlan, forcing this way the access points to send smaller frames to the remote wlc and then to ise.

Also switching to peap could have been a solution, most probably because peap sends smaller frames by itself, but usually it's not an option as for your case, except for confirming that mtu is the issue.     

[Nancy Saini]

From the pcaps, after client receives the server certificate, it responds with it's own certificate (client certificate is not visible in the captures but EAP-TLS-Length equals 3551, so assuming that client is sending it's certificate)

Post packet #16, the switch is requesting for identity again.

I would suggest you to collect EAP and RADIUS debugs from the switch and collect simultaneous captures on ISE and client and correlate with the debugs. Check if ISE has received the client certificate and what is the response from ISE to the switch.

[bgoulet00]

yes, the client is sending its certificate, or part of it, just the first fragment of a larger payload.  1492 bytes of the 3551 total.  that fragment is never acknowledge so it doesn't send anymore.  the ISE debugs show ISE receives nothing and why the error there is that the client abandoned the session.  on the switch the dot1x and radius debugs show essentially the same thing.....Authentication failed for client  with reason (No Response from Client). this first packet really seems to be getting dropped right at the interface and not being processed anymore.

[adamscottmaster2013]

@bgoulet00:  Please clarify this statement "the ISE debugs show ISE receives nothing".  Is that from the tcpdump on the ISE server or the span port that the ISE server is connected to?

[hslai]

@bgoulet00 Please compare and contrast the working clients on the same switch and the not-working ones. And, you should take captures at different hops between ISE and the clients, unless ISE and the clients are on the same switch and the same subnet.

[bgoulet00]

Just to close this out, after months of working with Cisco and Microsoft no answer was ever found other than to re-image all clients having the issue