ISE 2.3.1 fragmentation issue eap-tls

[omer shtivi]

Greetings everyone!

We are running ISE v2.3.1 and want to deploy wired eap-tls authentication.

When we enable the authentication we see the error "client abounded eap session and started a new one"

We did a sniffer and after the server key exchange the client tries to send the switch the client key exchange.

We see that the client tries to fragment the packet, it sends the first fragment and wait for eap-ack that never comes.

after 18 seconds it gives up and starts a new session.

We did a few tests:

PEAP-MSCHAPv2 is working for both machine and user authentication.

We tested with a certificate that works on another radius deployment and we see the same issue.

We tried to use WIFI for the same scenario and we still see the same result.

We did a packet capture both on the computer and on the switch and all the packets that the computer sends the switch receives and vice-versa (suspected MTU size or some packet-loss)

A few questions:

Does anyone encountered the same issue and knows how to resolve? (:

Does anyone knows how can we correlate between the EAPoL packets and the radius packets?

We tried to use the ISE logs from the documentation we modified the runtime-AAA to debug and we looked at prrt-managment.log (where it should be based on documentation) and at prrt-server.log (where we see some, but not as good as we saw on 2.2 where we saw step-by-step)

does anyone knows where we can see a step-by-step what the ISE thinks he is doing and what it receives?

Thanks!

Omer Shtivi

[Octavian Szolga]

Hi,

Had same issue some years ago and it was the MTU.

The switch was Layer3 so it had L2 MTU and L3 MTU. Don't remember which one was to blame, but that was the issue. The symptoms were identically. PEAP MSCHAP working, EAP-TLS didn't.

Anyway, in case you suspect any packet loss/fragmentation issues between NAD and ISE, you can try a ping with DF set or a packet capture on ISE with a host filter matching on NADs IP.

Regards,

Octavian

[dawid.karol.bednarczyk]

We just solved similar issue. If client certificate chain is size of ~4000 he needs to fragment it at RADIUS level.

We have choose to send first packet of size something around ~1400. When packet come to WLC, WLC encapsulated EAPOL within RADIUS and added RADIUS overhead ( with all the additional attributes ) was around 300.
This makes a packet of ~1800, with MTU 1500 towards RADIUS , there is IP fragmentation happening. In our case Firewall (PaloAlto )was dropping fragmented traffic.
Additionally he was showing that the traffic is allowed, because he allowed big part of conversation ( he just dropped the fragment silently )

The issue did not happen in initial phase when Radius send its certificate chain, because Cisco ISE sends RADIUS fragments of size ~1000 , which did not lead to fragmentation on IP level.

[Starfish]

I have similar issue, how did you fix this issue?

[dawid.karol.bednarczyk · Accepted solution]

We convinced our Security department that fragmented traffic is not pure evil and can be allowed :)

Otherwise we would need to replace all our devices to ones capable of jumbo MTU and convince our Service Provider to do the same thing ( so nearly impossible ).

It would be nice to have some paramenter in protocol Like Framed-MTU to be configured but on Client Side instead of Server. Or some other mechanism that would check the MTU + Radius overhead.