Clients silently de-authenticated on any link flap when a VMware SD-WAN Edge is configured with 802.1x (RADIUS Authentication)
search cancel

Clients silently de-authenticated on any link flap when a VMware SD-WAN Edge is configured with 802.1x (RADIUS Authentication)

book

Article ID: 312344

calendar_today

Updated On:

Products

VMware

Issue/Introduction

This KB article documents an issue seen when 802.1x is configured and enabled on a routed interface.

The issue is being tracked under ID #70586.



    Symptoms:

    On a routed interface configured for 802.1x, clients connected to that interface get silently de-authenticated whenever any other interface flaps (link down/up), leading to all traffic from those users being dropped.

    Example of an impacted configuration:

    RADIUS settings:
    image.png

    Interface settings:

    image.png


    Environment

    VMware SD-WAN

    Cause

    After a link flap on the Edge the authenticated MAC addresses get deleted from the cache, The WPA supplicant believes it is authenticated so it does not attempt to re-authenticate, but the Edge does not believe it to be authenticated so it drops all traffic from the client.

    On an Edge where RADIUS authentication is used, there are two potential methods after an interface flap on any link to ensure client connectivity:
    1. Inform the supplicant to re-authenticate
    Or
    2. Retain the authenticated MAC addresses if they belong to an interface that was not affected by the flap.

    The first method results in a short downtime while re-authentication is completed. The second method has no impact to clients. VMware SD-WAN has elected to resolve this issue using the second method.

    Resolution

    Through internal ticket #70586, the fix for this issue adds extra checks on the Edge which avoids flushing the MAC addresses after an interface flap and ensures that authenticated users are retained with no impact.

    The fix for Issue #70586 is included in the following Edge software releases:

    • For 4.2.x, issue #70586 is resolved beginning with 4.2.2 Edge build R422-20220310-GA which was released on March 16th, 2022. 4.2.2 Release Notes.
    • For 4.3.x, issue #70586 is resolved beginning with 4.3.1 Edge build R431-20220316-GA which was released on March 23rd, 2022. 4.3.1 Release Notes


    Workaround:
    If a customer experiences this issue they need to force the affected client devices connected to the Edge to re-authenticate in order to resume communicating.  There are two options:
    1. The most direct way to force client devices to re-authenticate is to restart the Edge service through Remote Actions > Restart Service. Any action that results in an Edge Service restart like disabling/enabling an Edge interface would have the same effect. An Edge Service restart would disrupt all customer traffic at the site for 10-15 seconds.
    2. The alternative is to reboot the affected client devices as that will force them to re-authenticate allowing them to communicate through the Edge normally again.