Aansluiten op govroam verloopt doorgaans soepel. We merken wel dat sommige ‘uitdagingen’ op het gebied van connectiviteit vaker terugkeren. De laatste tijd is dat met name een bekend probleem binnen Microsoft Azure wanneer een organisatie haar RADIUS-server(s) in die cloud plaatst. Om er als gemeenschap van te leren, hebben we de belangrijkste fenomenen (en hun oplossingen) voor u op een rij gezet. Lees vooral verder als u meer wilt weten over RADIUS, Load balancing, asymetrische NAT, Shared Secrets en certificaten en nog veel meer.
Steeds meer organisaties verhuizen (een deel van) hun serverpark naar een cloud en vaak is dat Azure. De organisaties die dat ook met hun RADIUS-server hebben gedaan (die met onze landelijke govroam RADIUS-servers communiceren), zijn al tegen een vervelende kwestie aangelopen. Sommige authenticatieverzoeken mislukken. In eerste instantie lijkt dit verschijnsel vrij willekeurig. Maar de verklaring is eenvoudig: in Azure wordt namelijk standaard geen ‘UDP-fragmentatie’ toegestaan. Soms is dit ook het geval in de eigen infrastructuur van een organisatie. Als gevolg daarvan worden langere RADIUS-authenticatieverzoeken die in meerdere pakketjes (fragments) worden gehakt na het eerste pakketje niet meer doorgelaten. Het resultaat is dat authenticatieverzoeken wel slagen als ze binnen één UDP-pakketje passen, maar niet als het verzoek groter is dan één pakket. De oplossing is ook eenvoudig: een service request indienen bij Microsoft met het verzoek om de ‘fragments’ alsnog door te laten. Ze zullen waarschuwen dat dit aanstaat als bescherming tegen een aanval met een bekende hack ‘FragSmack’, en verwijzen naar dit artikel:
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning#azure-and-fragmentation. Geen zorgen: deze kwetsbaarheid is niet van toepassing omdat die alleen misbruikt kan worden bij ‘packet reordering’ en dat is in het geval van keurig RADIUS-verkeer niet aan de orde.
Om de beschikbaarheid van de dienst te maximaliseren, draait govroam op twee RADIUS-servers, verspreid over twee datacenters, waarvan er eentje ook nog eens in hetzelfde datacenter redundant is uitgevoerd (2+1=3). Aangesloten organisaties kunnen hun authenticatieverzoeken naar de primaire server sturen, en als dat niet lukt, naar de tweede.
Het is wel de bedoeling dat alle RADIUS-pakketjes die bij één authenticatieverzoek horen, hetzelfde pad bewandelen. En dat gaat soms mis als er zich een zogenaamde ‘load balancer’ in het netwerk van de aangesloten organisatie bevindt. Die kunnen zodanig zijn geconfigureerd dat elk individueel RADIUS-pakketje over een verschillende route en soms ook beurtelings naar onze verschillende RADIUS-servers wordt gestuurd. Het gevolg is dat de RADIUS-communicatiestroom niet compleet is, omdat de onderdelen ervan naar verschillende RADIUS-servers zijn gestuurd. Het is dus nodig om rekening te houden met ‘session persistency’ wanneer deze loadbalancer(s) geconfigureerd worden. Load balancing op netwerkniveau is niet van toepassing op RADIUS verkeer want het terugvallen op andere servers wanneer iets mis zou gaan speelt zich af op RADIUS-niveau. Aangezien een load balancer eerder roet in het eten gooit dan goed doet, raden wij ten zeerste af deze in het pad op te nemen. Als zich toch een load balancer in het pad bevindt, laat dan deze niet op L3 (IP) of L4 (UDP) de load verdelen.
De meeste RADIUS-servers bij overheidsorganisaties hebben een adres dat niet op internet gebruikt wordt, en dat dan via Network Address Translation (NAT) moet communiceren met de landelijke govroam RADIUS-servers. Het wil nog wel eens gebeuren dat een ander publiek IP-adres wordt gebruikt bij het versturen van RADIUS vanuit de organisatie dan eerder afgesproken, namelijk een ‘default’ uitgaand adres dat voor alle uitgaande verkeer van de organisatie wordt gebruikt. govroam staat alleen communicatie toe van en naar strikt afgesproken adressen. Als we verkeer ontvangen van een onbekend adres wordt dit verkeer genegeerd, zelfs als alle andere zaken kloppen zoals het overeengekomen ‘shared secret’. Configureer NAT dus altijd consequent gelijk voor ingaand en uitgaand RADIUS-verkeer.
(Inderdaad is de term ‘asymmetrical NAT’ een specifieke NAT-configuratie waarbij inkomende en uitgaande poorten gelijk zijn, maar dat wordt hier niet bedoeld en deze NAT-vorm is overigens niet noodzakelijk).
Sommige organisaties willen het RADIUS verkeer over een Site-to-Site VPN tunnel transporteren. Uiteraard moet de VPN-tunnel goed werken. Bekende problemen: MTU sizes die te klein zijn, wederom de beruchte UDP-fragmentatie, aangepast secret of IP-adres zonder dat we dit tijdig te horen kregen enzovoorts. Meer weten over VPN en govroam, lees dan het artikel ‘VPN-tunnel: noodzaak of overbodig?’.
Verandering is een constante, en natuurlijk verandert ook de infrastructuur bij onze deelnemers geregeld. Een verhuizing naar de cloud is zo’n voorbeeld. Maar… wanneer govroam te laat verneemt dat een ander IP-adres in gebruik is genomen bij een organisatie, weten onze RADIUS-servers nog van niets en zal het RADIUS verkeer stilvallen. Soms blijkt dit pas nadat het adres al is aangepast bij die organisatie. De ambtenaren van de voortvarende organisatie kunnen niet meer roamen en gasten komen niet meer online. Een dergelijke onderbreking is onwenselijk, en kan eenvoudig voorkomen worden door tijdig aanpassingen in de infrastructuur aan ons door te geven. Dat kan door gerechtigden van de organisatie gedaan worden via ons klantportaal https://klantportaal.govroam.nl, liefst twee weken van tevoren (eerder mag ook).
Bij het opnieuw inrichten van het wifi-netwerk, de RADIUS-server of bij overdracht naar een andere beheerorganisatie wil ook nog wel eens blijken dat het ‘shared secret’ niet meer bekend is en moet dit opnieuw uitgewisseld worden, wat niet altijd meteen mogelijk is. We adviseren altijd om zo’n belangrijk secret zorgvuldig en veilig op te slaan. Hoe minder vaak gevoelige informatie getransporteerd hoeft te worden, hoe veiliger dat is.
Zie ons andere wiki-artikel voor meer informatie over change requests.
Het kan voorkomen dat een Shared Secret verkeerd wordt overgenomen. Als hierdoor het RADIUS verkeer niet slaagt zal de RADIUS server de oorzaak duidelijk aangeven. Let op dat er geen spaties zijn meegekopieerd, let op kleine en hoofdletters en het verschil tussen letters (en cijfers) die op elkaar lijken zoals de nul en de hoofdletter ‘O’ of het cijfer één en kleine letter ‘l’. Zelfs IT-experts zijn gewoon mensen die dit over het hoofd kunnen zien, zo blijkt. Tip: kopieer het secret naar een tekst-editor met een lettertype dat dit onderscheid duidelijk toont.
De keuze om een ‘wildcard servercertificaat’ op de RADIUS-server van de organisatie te gebruiken zal leiden tot problemen. Dit wordt door apparaten die op het netwerk willen aanmelden niet geaccepteerd (onderdeel van de WPA2-standaard).
Ook wil het voorkomen dat een server certificaat van een eigen Certificate Authority (CA) op de RADIUS server wordt gezet. Als het CA-certificaat bij eindgebruikers onbekend is, zal het apparaat van de gebruiker het RADIUS-servercertificaat niet vertrouwen. De organisatie moet dan haar eigen CA-certificaat eerst op de apparaten van de eindgebruikers zetten. Een lastige klus. Daarom adviseren we om een certificaat van een publieke CA in te zetten.
Zorg er voor dat de RADIUS-servernaam eindigt op hetzelfde domein als de gebruikersnamen gebruiken, of dat dit in elk geval in het SubjectAltName veld van het servercertificaat voorkomt. Als dat niet het geval is, zal een (Android) eindgebruiker zonder expliciete gebruikersinstructie niet online kunnen komen.
Zorg ook dat de APs en switches alle voor de hand liggende EAP-types (minstens EAP-TLS, EAP-PEAP en EAP-TTLS) ondersteunen. Een beheerder denkt soms dat deze uitgezet kunnen worden als de eigen organisatie deze protocollen niet gebruikt, maar het kan zijn dat ambtenaren van andere organisaties juist wel deze gebruikelijke standaarden gebruiken.
Werkt govroam niet of niet meer? We zijn trots dat onze dienst al jarenlang ononderbroken in de lucht is. We hebben in geval van problemen oorzaken gezien die doorgaans in de categorieën vallen die hierboven beschreven zijn en staan de deelnemers terzijde om hun probleem op te lossen. Door jarenlange ervaring van onze experts kunnen we aan onze kant van de verbinding vaak al een indicatie krijgen van wat er mogelijk aan de hand is kan zijn bij de aangesloten organisatie. Ook al kunnen we natuurlijk niet in de infrastructuur van onze deelnemers kijken, we kunnen wel tips geven en controleren of het gelukt is de zaak te herstellen.
Belangrijke tip: geef ook veranderingen in het monitoring-account dat bij ons bekend is tijdig door, zodat onze RADIUS-servers kunnen zien of uw RADIUS-servers bereikbaar zijn. Daarmee kunnen we u bij storingzoeken nog beter assisteren.
Om een probleem zo snel mogelijk op te lossen, is het zaak om een gestructureerde analyse uit te voeren. Wacht daarmee niet terwijl contact gezocht wordt met stichting govroam. De kans dat de govroam infrastructuur zelf oorzaak van het probleem is, is uitzonderlijk klein.
Probeer eerst de grote gemene deler in de problematiek te vinden. Meerdere keren per jaar escaleert een probleem bij een deelnemende organisatie tot bij govroam en na analyse blijkt het om een belangrijke doch individuele gebruiker te gaan die een typefout gemaakt heeft. Analyseer dus of het om een grote groep gaat met dezelfde kenmerken, bijv. werkzaam op één locatie, of die hetzelfde domein gebruikt, of waarvan de geldigheidsduur van het wachtwoord verloopt
Begin daarna stap voor stap te onderzoeken vanaf de client, door het netwerk heen tot en met het punt waarop RADIUS verzoeken het netwerk verlaten.
Hier enkele concrete vragen die kunnen helpen bij het analyseren van het probleem en aanknopingspunten geven voor mogelijke oorzaken:
Dat betekent dat ergens in het pad iets misgaat tussen het apparaat van de gebruiker en de gebruikersdatabase:
Apparaat van de gebruiker: betreft het sommige apparaten, of alle? Wanneer alleen sommige er last van hebben, controleer dan gebruikersnamen en wachtwoorden, geldigheid van het account. Controleer ook UDP-fragmentatie: langere RADIUS verzoeken kunnen misgaan, bijv. als gevolg van lange usernames.
wifi-access points (AP): zorg ook dat de APs en switches alle voor de hand liggende EAP-types (minstens EAP-TLS, EAP-TTLS en EAP-PEAP) ondersteunen. Is de authenticatie van de gebruikers zichtbaar op AP, switch en RADIUS server? Zijn de juiste VLAN’s beschikbaar tussen AP en switch?
Wanneer een Wireless LAN controller (WLC) gebruikt wordt: komt het authenticatieverkeer via de CAPWAP-tunnel aan bij de WLC? Kan de WLC goed communiceren met de (interne) RADIUS-server?
Tussenliggende WAN-aansluiting: als meerdere locaties via een WAN zijn aangesloten, werkt deze connectiviteit dan correct?
interne RADIUS-server: ontvangt deze correcte verzoeken en weet hij deze door te zetten naar de gebruikersdatabase? Is sprake van een cluster van RADIUS servers, check dan of alle nodes nog correct functioneren
interne gebruikersdatabase zoals Active Directory (AD): is het account geldig? Heeft het de juiste rechten of zit het in de juiste groep? Klopt de gebruikersnaam? Klopt het domein (in de vorm van organisatie.nl! dus geen .local bijv.)? Klopt het wachtwoord?
We adviseren om op elk van die punten de logging van die component te onderzoeken om te zien of een inlogpoging daarop succesvol was. Daarnaast is een packet sniffer zoals Wireshark erg behulpzaam, die laat zien of en hoe pakketjes over het netwerk reizen. Denk er ook aan om te ‘sniffen’ op alle switches, routers, load balancers (liefst geen!) en met name firewalls die zich in het pad bevinden. Vertrekt een pakketje uit een AP en komt het niet aan op de RADIUS server, analyseer dan de tussenliggende netwerkcomponenten.
Doorloop alle bovenstaande stappen en controleer bovendien:
Interne RADIUS server: stuurt deze verzoeken die niet intern moeten blijven wel daadwerkelijk door naar de govroam RADIUS-servers? Klopt de regular expression in de betreffende RADIUS policy hiervoor? Is er een andere routing policy die een hogere prioriteit heeft waardoor de routing policy nooit in werking treedt? Is er sprake van meerdere interne RADIUS-servers? Controleer dan al deze punten op alle RADIUS-servers in alle RADIUS-clusters.
Is de IP-connectiviteit tussen uw organisatie en govroam nog intact? Routeert uw ISP de RADIUS-verzoeken correct naar de door govroam gepubliceerde IP-reeksen?
Is sprake van symmetrisch NAT, ofwel: wordt voor uitgaand verkeer daadwerkelijk het bij govroam bekende IP-adres gebruikt (of een ander ‘default’ IP-adres)?
Indien Site2Site VPN gebruikt wordt: is dit ‘up’? Gaat de interne routing van/naar het encryption domein goed? Worden fragments correct doorgelaten? Indien sprake is van meerdere VPNs (t.b.v. redundantie), controleer dit voor alle VPN verbindingen.
Indien een netwerk load balancer wordt gebruikt: behoudt deze het afzender-IP-adres zodat de juiste policies in de RADIUS-server worden getriggerd (load balancer geconfigureerd als UDP proxy is dus niet mogelijk)? Is RADIUS sessie persistentie gegarandeerd (met andere woorden: worden alle UDP-pakketten gerelateerd aan een login sessie over dezelfde route gestuurd zodat niet sommige UDP-pakketten bij een verkeerde RADIUS server terechtkomen)? Bij voorkeur wordt geen netwerk load balancer toegepast, load balancing/fail over wordt door de RADIUS servers afgehandeld!
o Wordt de gebruiker (eigen of gast) in een correct VLAN geplaatst na authenticatie?
o Is DHCP werkzaam? Zijn er nog adressen beschikbaar in de DHCP pool?
o Is er een route beschikbaar naar internet (zoals uitgedeeld via DHCP)?
o Werkt DNS (zoals uitgedeeld via DHCP)? Werkt dit voor adressen op het internet (of wordt de set aan antwoorden beperkt tot bijv. interne adressen)?
o Is NAT correct ingesteld?
o Is een firewall of webproxy niet te restrictief? Let op: een ambtenaar mag van govroam veilige en open internet verwachten om zijn of haar werk te kunnen doen. Beperk het netwerk dus niet zodanig dat de ambtenaar die te gast is niet meer kan werken (zie ook ons artikel https://govroam.nl/open-maar-wel-veilig-internet/ )
Bij alle troubleshooting geldt: wireshark is your friend! Ofwel: maak packet dumps op de component waarop je een probleem vermoedt, maar ook tegelijk op de omringende componenten. Hanteer de ‘sandwich’-methode: begin met sniffen bij de ingang en de uitgang waarlangs een pakketje komt, en werk steeds een component verder ‘naar binnen’ tot duidelijk is welke component het pakketje niet doorlaat, fragmenteert, verminkt etc.
Wanneer we aangesloten Deelnemers assisteren met troubleshooting, vernemen we uiteenlopende typologieën en componenten in hun netwerk. Als stichting hebben we daar geen kijk op en kunnen en willen we niet ‘achter de voordeur’ kijken, dus het is zaak dat de netwerkbeheerder(s) (soms meerdere partijen) in kaart brengen welke componenten in het pad zitten en deze gestructureerd langslopen. Als willekeurig voorbeeld van componenten die we tegenkomen en de hoeveelheid ervan, toont onderstaand diagram het principe van de ‘sandwich’-methode, waarbij het probleem van buiten naar binnen geanalyseerd wordt.
LET OP: het bovenstaande diagram geeft een indicatie van mogelijke componenten in het pad. Bij kleinere organisaties zullen het er minder zijn, bij grote organisaties zullen nog meer componenten, met name extra switches en firewalls toegepast zijn in de basisinfrastructuur. Ook komt het veel voor dat verschillende functies zijn gecombineerd in één apparaat (bijv. een L2/L3 switch, router met firewall, firewall met VPN terminatie etc). Het diagram is geenszins een aanbeveling voor hoe het netwerkpad ontworpen moet worden. Hoe minder componenten in het pad, hoe sneller en betrouwbaarder govroam werkt.
Heeft u na deze ‘deep dive netwerkvalkuilen’ toch nog vragen of suggesties? Als stichting hebben wij niet de mogelijkheid om voor alle mogelijke leveranciers, types en versies van apparatuur en software de verschillende configuraties en bugs te documenteren. Graag maken we gebruik van kennis die onze community op doet, en die publiceren we graag (geanonimiseerd, uiteraard). Voor informatie die gedeeld mag worden of andere suggesties, stuur een mail naar technisch coördinator Erik Dobbelsteijn.