Firebox-geolocatieweigering: vind eerst de VPN-toegangsfase

Iemand in een ander land kan geen verbinding maken, en de eerste reflex is kijken naar de regel die toegang geeft tot interne bronnen. Die regel draait pas na toelating, dus kan het niet datgene zijn wat de tunnel weigert. De blokkerende fase zit ergens in het toegangspad, en de Firebox heeft meer dan één toegangspad afhankelijk van de VPN-dienst. Werk de controles op volgorde af en stop zodra een ervan de weigering verklaart.

Controle 1: benoem de inkomende dienst

Voor Mobile VPN met SSL, Access Portal en BOVPN over TLS is de inkomende toegang het WatchGuard SSLVPN-beleid. Pas de bedoelde beperking daar toe, op de daadwerkelijk geconfigureerde dienst, in plaats van die af te leiden uit een gebruikerstoegangsregel die later draait.

IPsec neemt een ander pad. Het ingebouwde IPSec-beleid staat extern IPsec-verkeer naar de Firebox toe voor de betreffende branch- en mobiele VPN-diensten, en het heeft voorrang boven een handmatig aangemaakt IPSec-beleid. Is uw client IKEv2, dan zit u op dat tweede pad, en het SSLVPN-beleid is irrelevant.

Dit fout doen is de meest verspilde middag in dit gebied: een beleid bewerken dat het pakket nooit ziet, en dan concluderen dat de beperking niet werkt.

Controle 2: lees de weigering, niet de theorie

Doe één gecontroleerde toegestane poging en correleer vier dingen: het openbare bronadres van de client, de toegangsdienst die werd geraakt, het beleid dat overeenkwam, en een eventuele weigeringsreden in het log. De IKEv2-probleemoplossingshandleiding van WatchGuard merkt op dat geolocatie en standaard pakketafhandeling verkeer kunnen weigeren vóór de toelating door het ingebouwde beleid, wat betekent dat de weigering die u ziet een fase kan noemen die u niet hebt overwogen.

Landclassificatie volgt de waargenomen netwerkbron. Een roaming gebruiker, een upstream NAT of een ander goedgekeurd pad kunnen veranderen wat de Firebox ziet, dus bevestig het adres en niet de beschrijving van de gebruiker waar hij is. Vraag om het openbare adres dat de client ziet, en vergelijk het met de bron in het Firebox-log. Als die verschillen, volgt de classificatie een pad dat niemand noemde.

Controle 3: is het ingebouwde beleid nog de eigenaar?

Als een handmatig IPSec-beleid genegeerd lijkt te worden, controleer dan of het ingebouwde nog is ingeschakeld. Een handmatige regel die wordt overschaduwd door een ingebouwde regel met hogere prioriteit en een handmatige regel die de enige toelating is, zijn verschillende configuraties met een gelijk uitziende interface.

Bepaal welke het pad moet bezitten. Is het het handmatige beleid, dan moet het ingebouwde voor dat verkeer worden uitgeschakeld, en daar begint de volgende controle.

Controle 4: plan de vervanging voordat u uitschakelt

Het uitschakelen van het ingebouwde IPSec-beleid verwijdert de toelating voor de betrokken VPN-diensten. Dat omvat branch-tunnels waar u misschien niet aan denkt terwijl u de verbinding van één mobiele gebruiker repareert.

Plan eerst de volledige vervanging: welke diensten toelating nodig hebben, welke bronbereiken ze krijgen, en hoe u het apparaat beheert als de wijziging misgaat. Houd een onafhankelijk beheer- en herstelpad open, want een fout hier kan de tunnel verwijderen die u zou gebruiken om het te repareren. Noteer de herstelstappen in het wijzigingsrecord, inclusief hoe u het apparaat bereikt als het VPN-pad weg is. Test daarna de vernieuwing, niet alleen de eerste verbinding.

Actieve connectiviteit en latere heronderhandeling kunnen beide van toelating afhangen. Een wijziging die werkt voor de sessie die u testte en faalt bij de volgende sleutelwissel is een klassiek resultaat van het vervangen van toelating zonder de vernieuwing te testen.

Controle 5: houd identiteit gescheiden van locatie

Geolocatie voegt context toe aan een toegangsbeslissing. Het stelt niet vast wie de gebruiker is, en het mag gateway-identiteitscontroles, accountautorisatie of MFA niet vervangen.

Als de zakelijke eis alleen goedgekeurde gebruikers van goedgekeurde locaties is, hebt u beide controles nodig. Een locatieregel die een heel land toelaat is geen vervanging voor authenticatie, en een geauthenticeerde gebruiker in een geblokkeerd land is een beleidsvraag, geen bug.

Controle 6: leg het vast en verifieer beide paden

Noteer de dienst, het toegangsbeleid, het beoogde locatiebereik, de uitzonderingen en de eigenaar van het herstel. Test daarna na de wijziging het mobiele pad en ten minste één sitepad, zodat de beperking verbonden blijft met de dienst waarvoor die bedoeld is.

Lees ten slotte de weigering opnieuw waarmee u begon. Is die veranderd van een locatieweigering in een authenticatie- of autorisatiefout, dan is het toegangsprobleem opgelost en is nu een ander zichtbaar. WatchGuard-handleiding over IKEv2-weigeringen is de referentie voor de fasevolgorde die hierboven is beschreven.