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