Wi-Fi-roaming tussen individuele access points, en ook tussen complete Wi-Fi-netwerken of locaties, werkt op basis van het RADIUS protocol. Alle ‘enterprise’-netwerken maken daar gebruik van, want het is integraal onderdeel van de WPA2-Enterprise standaard. Dat protocol bestaat uit berichten waarmee de login van een eindgebruiker wordt doorgeleid naar de plek waar de login gecontroleerd wordt.

Dit protocol leunt op zijn beurt weer op het UDP-protocol, de basispakketjes voor verkeer dat snel afgewikkeld moet worden op het (inter)net. Niet alle RADIUS berichten passen in één UDP-pakket. Met name wanneer certificaten gebruikt worden voor authenticatie (EAP-TLS), of wanneer meer of langere attributen meegestuurd worden. Het RADIUS bericht wordt dan in UDP-fragmenten gehakt. Dat is een generiek mechanisme dat ‘UDP-fragmentatie’ heet.

En wat blijkt? Het tweede fragment wordt in sommige netwerken weggegooid. Het resultaat? Het RADIUS bericht raakt hierdoor verminkt en wordt verworpen. Een mislukte login en een gefrustreerde gebruiker. Gevallen waarin de UDP-fragmentatie niet goed gaat:

• Bij (RADIUS-) servers die in Azure gehost worden. Microsoft biedt de mogelijkheid om hierop een uitzondering aan te vragen maar wij zien in de praktijk dat die niet in alle gevallen wordt gehonoreerd.

• Verkeerd geconfigureerde load balancer. Het eerste fragment wordt één kant opgestuurd, het volgende wordt een andere kant opgestuurd en de fragmenten komen niet meer samen op de plaats van bestemming.

• Verkeerd geconfigureerde firewall. Leveranciers bieden de mogelijkheid om UDP-fragments te blokkeren om een specifieke aanval te blokkeren. Niet iets om gedachteloos aan te vinken, want dan gaat ook ‘legaal’ verkeer stuk.

Mitigatie

In het algemeen bestaan de volgende opties om UDP-fragmentatie te voorkomen:

• RADSEC gebruiken, afhankelijk van of de RADIUS server dat goed ondersteunt. RADSEC is TCP-gebaseerd; Azure wikkelt dit naar behoren af.

• Publiek IP-adres op de externe adapter van de RADIUS-server(s) configureren en met host based ACL’s werken.

• Een uitzondering aanvragen op de Azure subscription bij Microsoft

• hosten op een private cloud platform dat geen UDP fragmentatieproblemen heeft

• Een andere public cloud (alle andere Big Techs vertonen geen UDP-fragmenteringsproblemen, alleen Azure)

• RADIUS on prem. Het is een belangrijk onderdeel van het netwerk dus een logische plek, dus de meest voor de hand liggende optie.

• Geen RADIUS-server, de AP’s rechtstreeks hun RADIUS-verkeer naar onze nationale RADIUS-servers laten sturen. Vereist getgovroam als manier voor gebruikers om zelf (elders) in te kunnen loggen.

 Onbevestigd: een onderliggend site-to-site VPN tussen Azure VPN en onze VPN-servers lijkt het probleem binnen de tunnel te verhelpen. Is anno 2026 in onderzoek.

Overigens is het zaak NIET te load balancen op L4. Dat mechanisme introduceert een extra risico op het stukmaken van RADIUS verkeer. RADIUS fail over gebeurt op applicatieniveau tussen de IP-adressen van peers op de RADIUS-laag, en dient niet te gebeuren door een network load balancer, omdat die verschillende pakketten van een RADIUS-transactie naar verschillende RADIUS-servernodes kunnen sturen waardoor een transactie verstoord kan raken.