<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Cisco WLC EAP-TLS fragmentation issue in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3831112#M474216</link>
    <description>&lt;P&gt;We have an issue with EAP-TLS fragmentation on our wireless lan controllers.&lt;BR /&gt;The controller generates authentication packets which are to large (1631 bytes&lt;BR /&gt;of data, system mtu on the switch is 1500) and reports successful transmission.&lt;BR /&gt;In the packet log on the controller and in the tcpdump on the ISE we only see&lt;BR /&gt;the first fragment of the packet. The second part is missing. Despite the fact,&lt;BR /&gt;authentication on ISE succeeds. But we have some checkpoint firewalls between the&lt;BR /&gt;controllers and ISE, and in the new release (R80.20) fragmented packets are&lt;BR /&gt;dropped if they are not received completely by the firewall.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;On the WLCs we were running 8.2.160, but tried 8.2.170 and even 8.5.140, but&lt;BR /&gt;the problem persists. ISE version is 2.4.0.357, patch 6&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any ideas?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;debug aaa all (on WLC):&lt;/P&gt;&lt;P&gt;*aaaQueueReader: Apr 01 10:04:20.059: Found a server : xx.xxx.x.xxx from the WLAN server list of radius server index 2&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.059: xx:xx:xx:xx:xx:xx Send Radius Auth Request with pktId:45 into qid:4 of server at index:1&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.060: xx:xx:xx:xx:xx:xx Sending the packet to v4 host xx.xxx.x.xxx:1812&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.060: xx:xx:xx:xx:xx:xx Successful transmission of Authentication Packet (pktId 45) to xx.xxx.x.xxx:1812 from server queue 4, proxy state xx:xx:xx:xx:xx:xx-03:07&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.062: 00000000: 01 2d 07 4a b7 7c a4 76 20 44 21 4f 94 f4 9d e5 .-.J.|.v.D!O....&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.062: 00000010: 00 8d c9 9b 01 20 68 6f 73 74 2f FF FF FF FF FF ......host/XXXXX&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.062: 00000020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF XXXXXXXXXXXXXXXX&lt;BR /&gt;...&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.063: 00000630: 50 03 f7 c4 03 dd 57 5b a2 3c 3a 36 c9 57 da ad P.....W[.&amp;lt;:6.W..&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.063: 00000640: 0b 4c 72 04 c8 15 d4 fa 8a e5 82 76 44 db f6 62 .Lr........vD..b&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.063: 00000650: 04 a7 d8 83 28 b1 08 82 24 c1 e3 78 95 49 c0 a7 ....(...$..x.I..&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;data length: 0x65F -&amp;gt; 1631 byte&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;debug packet logging (on WLC):&lt;/P&gt;&lt;P&gt;tx len=1442, encap=n/a, port=1&lt;BR /&gt;0000 00 00 0C 9F F0 C0 84 78 AC B2 73 60 08 00 45 00 ....p@.x,2s`..E.&lt;BR /&gt;0010 05 94 36 2D 00 00 40 11 C1 CD 0A 0c 46 08 0A 64 ..6-..@.AM..F..d&lt;BR /&gt;0020 02 E7 80 06 07 14 07 50 51 23 01 1a 07 48 07 D6 .g.....PQ#...H.V&lt;BR /&gt;0030 CB 0F 13 6A 2D A9 E8 4B 48 0D 58 a5 17 60 01 20 K..j-)hKH.X%.`..&lt;BR /&gt;0040 68 6F 73 74 2F FF FF FF FF FF FF FF FF FF FF FF host/XXXXXXXXXXX&lt;BR /&gt;...&lt;BR /&gt;0580 65 3F 62 61 73 65 3F 6F 62 6A 65 63 74 43 6C 61 e?base?objectCla&lt;BR /&gt;0590 73 73 3D 63 65 72 74 69 66 69 63 61 74 69 6F 6E ss=certification&lt;BR /&gt;05A0 41 75 Au&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;packet length: 0x5A2 -&amp;gt; 1442 byte&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The packet has the ip header flag 'more fragmnets' set, but the second&lt;BR /&gt;fragment is never been sent. (Does not appear in the packet log on the&lt;BR /&gt;controller and does not appear in the tcpdump captured on ISE, too)&lt;/P&gt;&lt;P&gt;Wondering why ISE still accepts the packet and completes the authentication.&lt;/P&gt;</description>
    <pubDate>Wed, 03 Apr 2019 04:53:29 GMT</pubDate>
    <dc:creator>sturm62</dc:creator>
    <dc:date>2019-04-03T04:53:29Z</dc:date>
    <item>
      <title>Cisco WLC EAP-TLS fragmentation issue</title>
      <link>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3831112#M474216</link>
      <description>&lt;P&gt;We have an issue with EAP-TLS fragmentation on our wireless lan controllers.&lt;BR /&gt;The controller generates authentication packets which are to large (1631 bytes&lt;BR /&gt;of data, system mtu on the switch is 1500) and reports successful transmission.&lt;BR /&gt;In the packet log on the controller and in the tcpdump on the ISE we only see&lt;BR /&gt;the first fragment of the packet. The second part is missing. Despite the fact,&lt;BR /&gt;authentication on ISE succeeds. But we have some checkpoint firewalls between the&lt;BR /&gt;controllers and ISE, and in the new release (R80.20) fragmented packets are&lt;BR /&gt;dropped if they are not received completely by the firewall.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;On the WLCs we were running 8.2.160, but tried 8.2.170 and even 8.5.140, but&lt;BR /&gt;the problem persists. ISE version is 2.4.0.357, patch 6&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any ideas?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;debug aaa all (on WLC):&lt;/P&gt;&lt;P&gt;*aaaQueueReader: Apr 01 10:04:20.059: Found a server : xx.xxx.x.xxx from the WLAN server list of radius server index 2&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.059: xx:xx:xx:xx:xx:xx Send Radius Auth Request with pktId:45 into qid:4 of server at index:1&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.060: xx:xx:xx:xx:xx:xx Sending the packet to v4 host xx.xxx.x.xxx:1812&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.060: xx:xx:xx:xx:xx:xx Successful transmission of Authentication Packet (pktId 45) to xx.xxx.x.xxx:1812 from server queue 4, proxy state xx:xx:xx:xx:xx:xx-03:07&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.062: 00000000: 01 2d 07 4a b7 7c a4 76 20 44 21 4f 94 f4 9d e5 .-.J.|.v.D!O....&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.062: 00000010: 00 8d c9 9b 01 20 68 6f 73 74 2f FF FF FF FF FF ......host/XXXXX&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.062: 00000020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF XXXXXXXXXXXXXXXX&lt;BR /&gt;...&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.063: 00000630: 50 03 f7 c4 03 dd 57 5b a2 3c 3a 36 c9 57 da ad P.....W[.&amp;lt;:6.W..&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.063: 00000640: 0b 4c 72 04 c8 15 d4 fa 8a e5 82 76 44 db f6 62 .Lr........vD..b&lt;BR /&gt;*aaaQueueReader: Apr 01 10:04:20.063: 00000650: 04 a7 d8 83 28 b1 08 82 24 c1 e3 78 95 49 c0 a7 ....(...$..x.I..&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;data length: 0x65F -&amp;gt; 1631 byte&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;debug packet logging (on WLC):&lt;/P&gt;&lt;P&gt;tx len=1442, encap=n/a, port=1&lt;BR /&gt;0000 00 00 0C 9F F0 C0 84 78 AC B2 73 60 08 00 45 00 ....p@.x,2s`..E.&lt;BR /&gt;0010 05 94 36 2D 00 00 40 11 C1 CD 0A 0c 46 08 0A 64 ..6-..@.AM..F..d&lt;BR /&gt;0020 02 E7 80 06 07 14 07 50 51 23 01 1a 07 48 07 D6 .g.....PQ#...H.V&lt;BR /&gt;0030 CB 0F 13 6A 2D A9 E8 4B 48 0D 58 a5 17 60 01 20 K..j-)hKH.X%.`..&lt;BR /&gt;0040 68 6F 73 74 2F FF FF FF FF FF FF FF FF FF FF FF host/XXXXXXXXXXX&lt;BR /&gt;...&lt;BR /&gt;0580 65 3F 62 61 73 65 3F 6F 62 6A 65 63 74 43 6C 61 e?base?objectCla&lt;BR /&gt;0590 73 73 3D 63 65 72 74 69 66 69 63 61 74 69 6F 6E ss=certification&lt;BR /&gt;05A0 41 75 Au&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;packet length: 0x5A2 -&amp;gt; 1442 byte&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The packet has the ip header flag 'more fragmnets' set, but the second&lt;BR /&gt;fragment is never been sent. (Does not appear in the packet log on the&lt;BR /&gt;controller and does not appear in the tcpdump captured on ISE, too)&lt;/P&gt;&lt;P&gt;Wondering why ISE still accepts the packet and completes the authentication.&lt;/P&gt;</description>
      <pubDate>Wed, 03 Apr 2019 04:53:29 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3831112#M474216</guid>
      <dc:creator>sturm62</dc:creator>
      <dc:date>2019-04-03T04:53:29Z</dc:date>
    </item>
    <item>
      <title>Re: Cisco WLC EAP-TLS fragmentation issue</title>
      <link>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3899309#M474218</link>
      <description>&lt;P&gt;Post the step data of where ISE is authenticating this session.&amp;nbsp; I have dealt with fragmented packet issues many times and I have never seen ISE authenticate the session when fragments are dropped.&amp;nbsp; You will usually get the client restarted session errors in ISE because the certificate is never fully received from the client and the client perceives it as a timeout.&lt;/P&gt;</description>
      <pubDate>Mon, 29 Jul 2019 14:07:27 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3899309#M474218</guid>
      <dc:creator>paul</dc:creator>
      <dc:date>2019-07-29T14:07:27Z</dc:date>
    </item>
    <item>
      <title>Re: Cisco WLC EAP-TLS fragmentation issue</title>
      <link>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3912502#M474220</link>
      <description>&lt;P&gt;Our organization is experiencing something similar. I believe it's EAP fragmentation too from the behavior ISE displays below.&lt;/P&gt;&lt;P&gt;Driving us nuts! In our scenario we relay RADIUS to MS NPS servers.&lt;/P&gt;&lt;P&gt;The network device is a Cisco WLC using 802.1x EAP\TLS&amp;nbsp;&lt;/P&gt;&lt;P&gt;My question is at what points should I measure MTU and WLC to Switch? ISE o NPS?&amp;nbsp;&lt;/P&gt;&lt;P&gt;Our ISE nodes are VM so would there be values to tweak in the virtual switch?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-left" image-alt="1Capture.PNG" style="width: 999px;"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/43581iB73C593D1BA6957E/image-size/large?v=v2&amp;amp;px=999" role="button" title="1Capture.PNG" alt="1Capture.PNG" /&gt;&lt;/span&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-left" image-alt="2Capture.PNG" style="width: 534px;"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/43582iD5B650C9EB14EB36/image-size/large?v=v2&amp;amp;px=999" role="button" title="2Capture.PNG" alt="2Capture.PNG" /&gt;&lt;/span&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-left" image-alt="3Capture.PNG" style="width: 580px;"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/43583iDF528439BAFAEAB7/image-size/large?v=v2&amp;amp;px=999" role="button" title="3Capture.PNG" alt="3Capture.PNG" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 22 Aug 2019 17:55:34 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/cisco-wlc-eap-tls-fragmentation-issue/m-p/3912502#M474220</guid>
      <dc:creator>Galaga1981</dc:creator>
      <dc:date>2019-08-22T17:55:34Z</dc:date>
    </item>
  </channel>
</rss>

