12-28-2017 11:45 AM - edited 02-21-2020 10:42 AM
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
Solved! Go to Solution.
08-24-2018 05:41 AM
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.
01-09-2018 07:50 AM
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
06-05-2018 08:06 AM
08-23-2018 08:07 AM
I have similar issue, how did you fix this issue?
08-24-2018 05:41 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide