...

• 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.