ISE 802.1X Reauthentication and client dropped packets

[Tony M]

Greetings ISE People,

We have been using reauthentication on our desktop/user ports (on Catalyst 9348 switches) running Fuji (16.9.4). ISE is at version 2.4, patch 8.

The problem we've been seeing is that, upon expiration of the reauthentication timer, the client's connection appears to drop until the reauthentication happens. Here is an example of the loss:

                             Packets               Pings
 Host                      Loss%   Snt   Rcv  Last   Avg  Best  Wrst StDev
 1. 10.100.14.2              0.0%  1019  1019   1.3   3.4   0.1  85.5  10.2
 2. 10.100.23.226            0.0%  1018  1018   9.9   9.9   9.8  55.9   1.6
 3. 10.100.148.1             0.0%  1018  1018  10.9  10.8  10.7  29.0   0.8
 4. 10.100.10.45             0.8%  1018  1010  12.1  10.8  10.3 110.8   3.3

As you can see, there is a difference of 8 packets on the last hop (the endpoint machine). These dropped when the reauthentication timer expired. This is despite the following access-session state:

The9348#sho access-session int tw1/0/11 details
            Interface:  TwoGigabitEthernet1/0/11
               IIF-ID:  0x1838D073
          MAC Address:  0024.9b44.ffff
         IPv6 Address:  Unknown
         IPv4 Address:  Unknown
            User-Name:  username.redacted.com
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  multi-host
     Oper control dir:  both
      Session timeout:  1800s (server), Remaining: 1319s
       Timeout action:  Reauthenticate
    Common Session ID:  01F8380A0000120359B25642
      Acct Session ID:  0x00001f5d
               Handle:  0xb200023e
       Current Policy:  CONCURRENT_AUTH


Server Policies:
      Session-Timeout: 1800 sec
            SGT Value:  4


Method status list:
       Method           State
        dot1x           Authc Success
          mab           Stopped

My understanding is that, with ISE sending the Reauthenticate value for the Timeout Action, we should not see this behaviour. Since the output above shows that the Reauthenticate timeout action is applied to this session and it is also using the timer value we push via the ISE policy, I am surprised to see these drops. This is also causing much consternation with management, as users are becoming disconnected while they are trying to work and I am unable to explain why the configuration is not working according to documentation.

Has anybody encountered this before? Is there any way to resolve it?

Port configuration:

interface TwoGigabitEthernet1/0/11
 description Desktop
 switchport mode access
 load-interval 30
 authentication periodic
 authentication timer reauthenticate server
 access-session host-mode multi-host
 access-session closed
 access-session port-control auto
 no snmp trap link-status
 mab
 storm-control broadcast level 3.00
 storm-control multicast level 3.00
 storm-control action shutdown
 storm-control action trap
 dot1x pae authenticator
 auto qos trust dscp
 spanning-tree portfast
 spanning-tree bpduguard enable
 service-policy type control subscriber CONCURRENT_AUTH
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy

Thank you!

[Francesco Molino]

Hi

On your authorization profile, in common tasks, you have a reauthentication option where you define the session timeout and the termination action. Make sure it is configured as radius-request to maintain the connectivity.
As a side node, 30 minutes is a bit agressive. best practice recommend at least 2h of session timeout.

[Tony M]

Yes Francesco, that is set. You can tell by the word server in braces in the following output:

      Session timeout:  1800s (server), Remaining: 1319s
       Timeout action:  Reauthenticate

The problem, again, is that with that set and the switch accepting both the timeout value and the timeout action, we are still dropping packets upon reauthentication. This is not supposed to happen with Reauthenticate turned on, so we have a huge problem.

[hslai]

If IPv4 and IPv6 addresses are truly unknown, there seems an issue with device tracking. If you are unable to debug this yourself, please open a TAC case.

A reauth timer of 30 minutes is too short. I would suggest to do it only once a day at most. Additionally, ISE is not currently supporting concurrent authentications. Not clear why you would use multi-host.

[Francesco Molino]

My message was to validate the termination-action was setup and not left by default.
Can you share a screenshot of your authorization profile?

[Tony M · Accepted solution]

Thanks for the responses. Working with Cisco TAC, we've discovered that several other Cisco customers are experiencing the same problem. Thankfully it has nothing to do with switch or ISE configuration. Rather, it has to do with new functionality in Windows 10 v1809: Interface Quarantining. Basically, upon any change to an interface, including 802.1X re-authentication, the Windows 10 firewall will disallow any new TCP connections and any UDP traffic for eight seconds:

Interface quarantining is intended to secure network communications for non-classified networks. The idea is that once network interface changes network connection (connects to another network) it must be restricted for inbound connections (quarantined) until it gets classified and firewall engine sets a proper active profile. After applying of the active profile filters quarantining restrictions must be removed (interface is un-quarantined).

Here's one page I found that describes the situation in a bit more detail (see the Additional Information / Explanation section at the end)

http://wiki.webperfect.ch/index.php?title=Hyper-V:_LiveMigration_cause_network_problems_(Windows_Firewall_%22InterfaceQuarantine%22)

It seems strange the MS would introduce a change that causes a denial of service without announcing it loudly first, but this is really the only web resource I've found on the topic. A quick search of Microsoft's own support site turned up nothing. From my perspective, this is a huge issue that would have been a lot easier to resolve if Microsoft had documented it somewhere easy to find.

In any event, there is a work-around in the link above:

• Add a RegKey (IntfQuarantineEnabled)

HKLM\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy
IntfQuarantineEnabled
DWORD  Value data: 0

• Reboot

As TAC confirmed this is affecting more than just my organization, it might be useful if this post could somehow be made more visible in the community.

[csatola]

After months of troubleshooting, I've finally come across this post and sure enough, solved it instantly. Thanks!