Denegación por geolocalización del Firebox: encuentre primero la etapa de entrada VPN

Alguien en otro país no puede conectarse, y el primer instinto es mirar la regla que concede acceso a los recursos internos. Esa regla se ejecuta después de la admisión, así que no puede ser lo que rechaza el túnel. La etapa que bloquea está en algún punto de la ruta de entrada, y el Firebox tiene más de una ruta de entrada según el servicio VPN. Haga las comprobaciones en orden y deténgase en cuanto una de ellas explique la denegación.

Comprobación 1: nombre el servicio entrante

Para Mobile VPN con SSL, Access Portal y BOVPN sobre TLS, la entrada entrante es la política WatchGuard SSLVPN. Aplique allí la restricción prevista, sobre el servicio realmente configurado, en lugar de deducirla de una regla de acceso de usuario que se ejecuta más tarde.

IPsec sigue otra ruta. La política IPSec integrada permite el tráfico IPsec externo hacia el Firebox para los servicios de sucursal y VPN móvil aplicables, y tiene precedencia sobre una política IPSec creada manualmente. Si su cliente es IKEv2, está en esa segunda ruta, y la política SSLVPN es irrelevante.

Equivocarse aquí es la tarde más comúnmente perdida en este ámbito: editar una política que nunca ve el paquete y luego concluir que la restricción no funciona.

Comprobación 2: lea la denegación, no la teoría

Haga un intento permitido y controlado y correlacione cuatro cosas: la dirección de origen pública del cliente, el servicio de entrada al que llegó, la política que coincidió y cualquier motivo de denegación en el registro. La guía de solución de problemas de IKEv2 de WatchGuard señala que la geolocalización y el tratamiento predeterminado de paquetes pueden denegar tráfico antes de la admisión de la política integrada, lo que significa que la denegación que ve puede nombrar una etapa que no había considerado.

La clasificación del país sigue el origen de red observado. Un usuario en itinerancia, un NAT anterior o una ruta aprobada distinta pueden cambiar lo que ve el Firebox, así que confirme la dirección y no la descripción del usuario sobre dónde está. Pida la dirección pública que ve el cliente y compárela con el origen del registro del Firebox. Cuando difieren, la clasificación sigue una ruta que nadie mencionó.

Comprobación 3: ¿sigue la política integrada siendo la propietaria?

Si una política IPSec manual parece ignorada, compruebe si la integrada sigue habilitada. Una regla manual tapada por una regla integrada de mayor prioridad y una regla manual que es la única admisión son configuraciones distintas con una interfaz de aspecto idéntico.

Decida cuál debe poseer la ruta. Si es la política manual, la integrada debe deshabilitarse para ese tráfico, y ahí empieza la siguiente comprobación.

Comprobación 4: planifique el reemplazo antes de deshabilitar

Deshabilitar la política IPSec integrada elimina su admisión para los servicios VPN afectados. Eso incluye túneles de sucursal en los que quizá no piense mientras arregla la conexión de un usuario móvil.

Planifique primero el reemplazo completo: qué servicios necesitan admisión, qué ámbitos de origen reciben y cómo gestionará el equipo si el cambio sale mal. Mantenga abierta una ruta de gestión y recuperación independiente, porque un error aquí puede eliminar el túnel que usaría para arreglarlo. Anote los pasos de recuperación en el registro de cambios, incluido cómo llegar al equipo si la ruta VPN ha desaparecido. Después pruebe la renovación, no solo la primera conexión.

La conectividad activa y la renegociación posterior pueden depender ambas de la admisión. Un cambio que funciona para la sesión probada y falla en el siguiente cambio de clave es un resultado clásico de reemplazar la admisión sin probar la renovación.

Comprobación 5: mantenga la identidad separada de la ubicación

La geolocalización añade contexto a una decisión de entrada. No establece quién es el usuario y no debe sustituir las comprobaciones de identidad de la puerta de enlace, la autorización de la cuenta ni el MFA.

Si el requisito de negocio es solo usuarios aprobados desde lugares aprobados, necesita ambos controles. Una regla de ubicación que admite un país entero no sustituye la autenticación, y un usuario autenticado en un país bloqueado es una cuestión de política, no un error.

Comprobación 6: anótelo y verifique ambas rutas

Anote el servicio, la política de entrada, el ámbito de ubicación previsto, las excepciones y el responsable de la recuperación. Después pruebe la ruta móvil y al menos una ruta de sitio tras el cambio, para que la restricción siga ligada al servicio para el que se diseñó.

Por último, relea la denegación con la que empezó. Si ha pasado de una denegación por ubicación a un fallo de autenticación o autorización, el problema de entrada está resuelto y ahora se ve otro. Guía de WatchGuard sobre denegaciones de IKEv2 es la referencia para el orden de etapas descrito arriba.