Refus de géolocalisation du Firebox : trouvez d'abord l'étape d'entrée VPN

Quelqu'un dans un autre pays ne peut pas se connecter, et le premier réflexe est de regarder la règle qui accorde l'accès aux ressources internes. Cette règle s'exécute après l'admission, elle ne peut donc pas être ce qui rejette le tunnel. L'étape qui bloque se trouve quelque part dans le chemin d'entrée, et le Firebox possède plus d'un chemin d'entrée selon le service VPN. Faites les vérifications dans l'ordre et arrêtez-vous dès que l'une d'elles explique le refus.

Vérification 1 : nommer le service entrant

Pour Mobile VPN avec SSL, Access Portal et BOVPN sur TLS, l'entrée entrante est la stratégie WatchGuard SSLVPN. Appliquez-y la restriction prévue, sur le service réellement configuré, plutôt que de la déduire d'une règle d'accès utilisateur qui s'exécute plus tard.

IPsec emprunte un autre chemin. La stratégie IPSec intégrée autorise le trafic IPsec externe vers le Firebox pour les services de branche et VPN mobile concernés, et elle prime sur une stratégie IPSec créée manuellement. Si votre client est IKEv2, vous êtes sur ce second chemin, et la stratégie SSLVPN n'a aucune importance.

Se tromper ici est l'après-midi le plus souvent perdu dans ce domaine : modifier une stratégie qui ne voit jamais le paquet, puis conclure que la restriction ne fonctionne pas.

Vérification 2 : lire le refus, pas la théorie

Faites une tentative autorisée et contrôlée et corrélez quatre éléments : l'adresse source publique du client, le service d'entrée atteint, la stratégie qui a correspondu et tout motif de refus dans le journal. Le guide de dépannage IKEv2 de WatchGuard indique que la géolocalisation et le traitement par défaut des paquets peuvent refuser le trafic avant l'admission de la stratégie intégrée, ce qui signifie que le refus que vous voyez peut nommer une étape que vous n'aviez pas envisagée.

La classification du pays suit la source réseau observée. Un utilisateur en itinérance, un NAT en amont ou un autre chemin approuvé peuvent changer ce que le Firebox voit, alors confirmez l'adresse plutôt que la description par l'utilisateur de l'endroit où il se trouve. Demandez l'adresse publique que voit le client et comparez-la à la source du journal du Firebox. Lorsqu'elles diffèrent, la classification suit un chemin que personne n'a mentionné.

Vérification 3 : la stratégie intégrée est-elle toujours propriétaire ?

Si une stratégie IPSec manuelle semble ignorée, vérifiez si l'intégrée est toujours activée. Une règle manuelle masquée par une règle intégrée de priorité supérieure et une règle manuelle qui constitue la seule admission sont des configurations différentes avec une interface d'apparence identique.

Décidez laquelle doit posséder le chemin. Si c'est la stratégie manuelle, l'intégrée doit être désactivée pour ce trafic, et c'est là que commence la vérification suivante.

Vérification 4 : planifier le remplacement avant de désactiver

Désactiver la stratégie IPSec intégrée supprime son admission pour les services VPN concernés. Cela inclut des tunnels de branche auxquels vous ne pensez peut-être pas pendant que vous réparez la connexion d'un utilisateur mobile.

Planifiez d'abord le remplacement complet : quels services ont besoin d'admission, quelles plages sources ils obtiennent et comment vous gérerez l'équipement si le changement tourne mal. Gardez un chemin de gestion et de récupération indépendant ouvert, car une erreur ici peut supprimer le tunnel que vous utiliseriez pour la corriger. Notez les étapes de récupération dans le journal des changements, y compris comment atteindre l'équipement si le chemin VPN a disparu. Testez ensuite le renouvellement, pas seulement la première connexion.

La connectivité active et la renégociation ultérieure peuvent toutes deux dépendre de l'admission. Un changement qui fonctionne pour la session testée et échoue au changement de clé suivant est un résultat classique du remplacement de l'admission sans tester le renouvellement.

Vérification 5 : garder l'identité séparée de l'emplacement

La géolocalisation ajoute du contexte à une décision d'entrée. Elle n'établit pas qui est l'utilisateur et ne doit pas remplacer les contrôles d'identité de la passerelle, l'autorisation du compte ou le MFA.

Si l'exigence métier se limite à des utilisateurs approuvés depuis des lieux approuvés, il vous faut les deux contrôles. Une règle de localisation qui admet un pays entier ne remplace pas l'authentification, et un utilisateur authentifié dans un pays bloqué est une question de stratégie, pas un bogue.

Vérification 6 : consigner et vérifier les deux chemins

Notez le service, la stratégie d'entrée, la portée de localisation prévue, les exceptions et le responsable de la récupération. Testez ensuite le chemin mobile et au moins un chemin de site après le changement, afin que la restriction reste attachée au service qu'elle doit contrôler.

Enfin, relisez le refus par lequel vous avez commencé. S'il est passé d'un refus de localisation à un échec d'authentification ou d'autorisation, le problème d'entrée est résolu et un autre est désormais visible. Guide WatchGuard des refus IKEv2 est la référence pour l'ordre des étapes décrit ci-dessus.