...
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?
...
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!
...
Slaagt de authenticatie wel, maar krijgt de gebruiker toch geen verbinding met internet?
o Wordt de gebruiker (eigen of gast) in een correct VLAN geplaatst na authenticatie?
...
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.
Sharing is caring
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.