EAPoL Authentciation to ISE with network with Encryptors (MTU Issue?)

[khalid_mahmood]

Hi,

We have Cisco ISE v2.1 patch 3 across 2 datacenters (1 x admin, 1 x monitor, 2 x PSN per DC). The WAN is MPLS based but has WAN encryptors.

The Win10 client with Anyconnect v4.4 fails authentication with a Cisco ISE error "5440 Endpoint abandoned EAP session and started new".

The switches are Cisco catalyst 3560, 2960 and 3650, we think the issue is around MTU sizes reading articles on the packet size with EAP-TLS and EAPoL. To prove this we reduced the MTU on a Catalyst 3650 using "IP MTU 1360" on the Switch SVI interface from where the RADIUS source interface is used, and this worked. But we cannot use this approach or command on older Cat2960 and 3560 switches.

Is this 5440 error associated with a MTU issue? 

How do we reduce MTU using Cisco ISE, i.e. I've tried using the RADIUS Framed MTU attribute under authorisation, didn't work..

Any help with be much appreciated.

Thx Khalid

[paul]

Do you have your PSNs behind a F5 load balancers?  If so the issue on the F5 and has nothing to do with ISE.  The WAN network is probably fragmenting the EAP-TLS packets and the F5 by default doesn't handle the fragmented UDP packets to the VIP.  You can configure the F5 to handle this, but I can't remember how.  If you are behind an F5 I can reach out to one of my customers and asked how they solved this.

[khalid_mahmood]

Hi Paul, thanks for responding. yes we have 2 PSN's behind a pair of F5 Load balancers, so our switch on a remote site targets the F5 VIP, would really appreciate it if you could let me know how you handled fragmented packets on the F5's please.    Question you didn't need to change MTU's on the end switches?

[paul]

I will check with the other customer. No you don’t need to do any MTU modification on the switches.

I am assuming you are doing a DMVPN overlay on the MPLS cloud. If so as a short term fix you could change the MTU on the DMVPN tunnel interfaces or the interface going to the provider. It has been a while since I tested this, but you can get the router to fragment the GRE packets which forces the other side of the GRE tunnel to put the fragments back together. If you have ip tcp mss adjustment on the GRE interfaces you will only be fragmenting large UDP packets which unless you have a custom application or doing video should really only fragment the RADIUS packets.

The real fix is on the F5s though and I will let you know what I found out.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[khalid_mahmood]

Thanks Paul

Regards Khalid

Consultancy Practice – TA Secure Networking

M: +44 (0) 7801 452291

E: khalid.mahmood@computacenter.com

Planned Absences

None

[khalid_mahmood]

The fix on the F5’s was taken from the details contained in the thread below which also helped to resolve the issue...

“...This was our fix and after the change I believe it required a reboot as well. Let me know if this works as we are using EAP-TLS as well but our logs and statistics are still very muddy.

The datagram packets that were being fragmented were too small and being caught by a DoS protection DB variable and the F5 device was silently dropping these packets. The fix for this is to lower the threshold for this variable to allow these packets through the device to the server.

• Resolution lower the DoS protection variable from default of 556 to 24.

  [admin@f5-lb-01:Active:Changes Pending] ~ # tmsh list sys db tm.minipfragsize all-properties

  sys db tm.minipfragsize {

  default-value "556"

  scf-config "true"

  • value "500" <-- Changed to 24

  value-range "unsigned integer min:1 max:65515"

  #####no change...”

  Essentially I applied the following command on each LTM, followed by a reboot...

  #tmsh

  #modify sys db tm.minipfragsize value 24

  #save sys config

[paul · Accepted solution]

Here is what they sent me:

tmsh commands found here.

https://support.f5.com/csp/article/K17102<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.f5.com_csp_article_K17102&d=DwMGaQ&c=PzM68gSF_5r1R7BCE75oeA&r=FlZMTYu2-2fPE0nLUvI9rvtinNs9wKh5AZCqdoNT1Eg&m=c2M5-Yb4_FQeHEbxhjcMVpc5WbJY4cpAuaoh60GLaEM&s=wacqgOMNnkKbFLhuSOtF1bMexd6x_lDP4n5378bkvTA&e=>

What got us was knowing if it was the full fragment size that you needed to account for, vs the payload size. It is payload size so we set it lower, in our case 90. Started working great from there.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250