Encaminar Internet de una sucursal por la central mediante IPsec

Si el tráfico de Internet de una sucursal debe inspeccionarse de forma centralizada y salir por la conexión WAN de la central, Sophos Firewall puede utilizar un túnel Site-to-Site IPsec policy-based. Los clientes de la sucursal envían entonces el tráfico por el túnel en vez de directamente a la WAN local. En la central se aplican las reglas centrales de firewall, NAT y seguridad.

LAN de sucursal → Firewall de sucursal → IPsec policy-based → Central → MASQ → Internet

Este diseño requiere algo más que un túnel VPN verde. Route Precedence, Traffic Selectors, el orden de las reglas y la ruta de retorno deben funcionar conjuntamente. Si fallan el túnel o la central, la sucursal normalmente no dispone de salida local automática a Internet en este diseño.

⚠️ Este procedimiento se aplica exclusivamente a IPsec policy-based. El peer no puede ser route-based. Para diseños nuevos o en crecimiento, se recomienda route-based Any-to-Any: ambos peers usan selectores Any, cada uno recibe una interfaz XFRM y se necesitan rutas Static, SD-WAN o dinámicas explícitas. No se deben mezclar esos pasos con el procedimiento policy-based siguiente. La elección se explica en Configurar una VPN IPsec Site-to-Site.

Ejemplo y requisitos

El ejemplo utiliza la red de sucursal 10.20.0.0/24. La central dispone de una conexión WAN funcional y un túnel policy-based ya planificado. 10.20.0.0/24 es un valor de documentación y debe sustituirse por la red real de la sucursal.

Para este diseño, la Route Precedence global debe ser VPN, Static, SD-WAN. Antes de modificarla, hay que guardar el valor actual e identificar las demás rutas Static, VPN y SD-WAN afectadas. El proceso controlado se describe en Cambiar Route Precedence de forma segura.

El valor predeterminado de SFOS 22 es Static, SD-WAN, VPN. Este diseño difiere porque Remote subnet: Any crea en la sucursal una ruta VPN policy-based automática para todos los destinos. No se elimina la ruta predeterminada Static 0.0.0.0/0 hacia la WAN local: sigue disponible para el tráfico generado por el firewall cuando se desactiva el uso de VPN y para un rollback controlado. El valor actual se consulta en Device Console con system route_precedence show; el artículo sobre Route Precedence incluye el comando de cambio, el análisis de impacto y la recuperación.

Antes del cambio también deben estar preparados:

• un túnel IPsec policy-based funcional entre ambos firewalls;
• acceso administrativo probado a ambas sedes;
• capacidad suficiente de Internet y firewall en la central;
• DNS, Web Policies, IPS, Application Control y las excepciones previstas;
• una copia de seguridad actual de la configuración y un registro del cambio con los selectores originales, Route Precedence, la opción de tráfico del sistema y los ID de firewall y NAT;
• una ruta de retorno documentada y una ventana de mantenimiento.

En HA se documentan antes del cambio el nodo activo, el estado correcto del clúster y el acceso de administración al peer en cada sede. HA no sustituye una segunda WAN de la central ni una segunda sede. El failover se trata como una prueba independiente y no se deduce de un túnel verde.

Configurar los selectores IPsec

En la central se establece Local subnet en Any y Remote subnet en la LAN de la sucursal. En la sucursal se usan los valores opuestos: la red local de la sucursal y Any como remota.

A continuación se prueba el túnel con un destino interno de la central. La ruta de Internet solo se habilita cuando el tráfico entre sedes funciona en ambos sentidos. Así se puede distinguir un fallo de IPsec de un problema de NAT o reglas.

Crear las reglas de firewall y NAT

Las reglas se crean en Rules and policies > Firewall rules. Las reglas VPN generadas automáticamente no son un diseño completo para esta ruta de Internet.

Central: VPN a WAN

Una regla Branch_VPN_to_WAN permite el tráfico de la sucursal hacia Internet:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: solo los servicios realmente necesarios
• Log firewall traffic: activado
• Create linked NAT rule > Translated source (SNAT): MASQ

Web Policy, IPS, Application Control y TLS Inspection se seleccionan de forma consciente. La regla MASQ vinculada traduce los clientes de la sucursal a la dirección pública de la central. SFOS evalúa primero la regla de firewall y después SNAT para tráfico saliente, por lo que también debe comprobarse el orden de NAT: una regla NAT anterior que coincida prevalece sobre la vinculada. Además, NAT no crea una ruta y los cambios de NAT solo afectan a conexiones nuevas.

La ruta de retorno tiene dos partes: MASQ devuelve las respuestas de Internet a la dirección WAN de la central; después, la central usa su ruta VPN policy-based creada automáticamente para el destino traducido 10.20.0.0/24. Si la LAN de la sucursal está detrás de otro router, también deben documentarse y probarse sus rutas de ida y vuelta.

Sucursal: permitir LAN a VPN

La regla Branch_LAN_to_VPN se sitúa por encima de cualquier regla local que permita LAN a WAN:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: solo los servicios realmente necesarios
• Log firewall traffic: activado

⚠️ Aclarar previamente el bloqueo web: La documentación del fabricante sobre Drop, HTTP/HTTPS, autenticación y Web Exceptions es contradictoria. Por tanto, la regla Drop por sí sola no demuestra un bloqueo completo de la salida local a Internet. Antes de utilizarla en producción, obtener una aclaración escrita de Sophos o realizar una prueba aislada y expresamente autorizada para la versión, el build y la ruta de procesamiento exactos. Los casos de prueba y las condiciones para detenerse se describen en Action y registro de las reglas de firewall. Si el acceso web permitido es inesperado o no está claro, no desplegar en producción.

A continuación se añade una regla específica Branch_LAN_to_WAN_drop para la misma red de sucursal de LAN a WAN. Representa la lógica de bloqueo prevista contra una ruta local a Internet paralela al túnel; su efecto real debe confirmarse como se explica arriba. No se deben incluir accidentalmente otras redes o servicios locales planificados expresamente.

El orden forma parte de la seguridad: excepciones específicas, Branch_LAN_to_VPN, después Branch_LAN_to_WAN_drop y, por último, reglas más amplias. Las conexiones nuevas, no solo las sesiones existentes, se utilizan para la validación tras los cambios.

Crear reglas de firewall de forma segura explica cómo comprobar conjuntamente la posición, Rule ID y la regla NAT vinculada.

Decidir por separado sobre el tráfico generado por el sistema

Las reglas anteriores controlan el tráfico reenviado de los clientes. DNS, NTP, actualizaciones, Central y otras conexiones generadas por el propio firewall de la sucursal son tráfico generado por el sistema.

DNS también se separa por origen. Un cliente que usa un resolver público sigue la ruta de cliente por el túnel. Un resolver interno de la central requiere selector, regla de firewall y ruta de retorno. Solo las consultas DNS generadas por el propio firewall siguen la opción de tráfico del sistema. Por eso se prueban por separado una IP pública y un FQDN.

El valor predeterminado documentado es enable; no demuestra el estado real de una instalación existente. Para SFOS 22/23, confirmar el getter en la ayuda de la compilación instalada antes de utilizarlo. Por tanto, es solo una referencia para su confirmación, no una instrucción de lectura verificada: solo debe utilizarse si la ayuda de la CLI del build instalado o Sophos Support confirman la sintaxis y el significado de la salida para ese build. En caso contrario, no debe ejecutarse y debe utilizarse un método de lectura confirmado. Antes de realizar un cambio, hay que consultar el valor real de la opción con ese método y anotarlo en el registro del cambio; además, debe estar definido el procedimiento exacto de restauración mediante los comandos de asignación documentados para enable o disable. Sin un método de lectura confirmado, el valor anterior real y un procedimiento exacto de reversión, no se modifica la opción.

show routing policy-based-ipsec-vpn system-generate-traffic

Si solo el tráfico de clientes debe usar la central, el tráfico generado por el firewall puede salir directamente por la WAN de la sucursal:

⚠️ Este cambio reinicia todos los túneles IPsec del firewall. Antes hay que documentar el estado, la ventana de mantenimiento y la vía de recuperación. El comando no se ejecuta como simple prueba ni por sospecha.

set routing policy-based-ipsec-vpn system-generate-traffic disable

Inmediatamente después de establecer el valor, hay que volver a consultar el valor de la opción con el mismo método de lectura confirmado; debe ser disable. Esta comprobación del estado no sustituye las pruebas descritas a continuación de todos los túneles, los servicios necesarios del firewall y la ruta de datos local o central elegida. Si la salida no es inequívoca o no coincide con el valor objetivo, no deben realizarse más cambios por conjetura; hay que aclarar la discrepancia con Sophos Support.

Durante el rollback se restaura el estado anterior documentado. Restaurar la opción también reinicia todos los túneles IPsec; antes se aplican las mismas precauciones relativas al estado, la ventana de mantenimiento y la vía de recuperación. Si la opción estaba activada, se utiliza:

set routing policy-based-ipsec-vpn system-generate-traffic enable

Si el valor anterior registrado era disable, el rollback no debe establecer enable de forma indiscriminada. Si el valor actual de la opción ya coincide con el valor anterior, no es necesario volver a ejecutar un comando de asignación; en caso contrario, se restaura exactamente el valor anterior registrado con el comando de asignación documentado correspondiente. Después de cada cambio y de cada reversión, hay que volver a consultar el valor de la opción con el mismo método de lectura confirmado y compararlo con el valor objetivo correspondiente o con el valor anterior registrado, respectivamente. Por separado, se vuelven a comprobar todas las conexiones IPsec, los servicios necesarios del firewall y la ruta de datos local o central definida. Si la lectura de comprobación no es clara o muestra una discrepancia, no debe afirmarse que la restauración se ha completado correctamente y hay que recurrir a Sophos Support.

Validar la ruta de datos

Un cliente de 10.20.0.0/24 abre primero una dirección IP pública y después un FQDN por HTTPS. La prueba demuestra varias capas:

1. En la sucursal coincide Branch_LAN_to_VPN; la regla local LAN-to-WAN de descarte no coincide con este flujo correcto.
2. En la central coinciden Branch_VPN_to_WAN y la regla MASQ vinculada.
3. La dirección IP de origen visible públicamente pertenece a la central.
4. DNS, HTTPS y un destino bloqueado deliberadamente se comportan según la política central.
5. En Diagnostics > Packet capture, In interface, Out interface, Rule ID, NAT ID, Status y Reason muestran paquetes de ida y vuelta por el túnel y la WAN de la central.
6. El tráfico generado por el sistema utiliza la ruta local o central elegida previamente.
7. Current activities > IPsec connections permanece establecido durante la prueba y el Log viewer no muestra descartes inesperados.
8. En HA se realiza por separado un failover de nodo autorizado y se repite la prueba completa. Sin esa prueba no se afirma redundancia HA.

Un Speedtest por sí solo no basta. También deben probarse aplicaciones reales, DNS, registros de seguridad y una descarga prolongada. Para problemas de rendimiento existen los procedimientos de prueba de velocidad de Internet y MTU y MSS en VPN.

Errores habituales y rollback

• El cliente de la sucursal sigue usando la WAN local: comprobar el orden de reglas, la red de origen, la regla LAN-to-VPN y la regla de descarte. No añadir una excepción amplia como solución rápida.
• El túnel está verde, pero no hay Internet: comprobar en la central la regla VPN-to-WAN, Rule ID, MASQ, gateway WAN, DNS y ruta de retorno.
• Solo el propio firewall usa la ruta equivocada: comprobar policy-based-ipsec-vpn system-generate-traffic. No confundir el tráfico de clientes con el generado por el sistema.
• Otros túneles fallan tras el cambio CLI: el reinicio de todos los túneles IPsec es un comportamiento documentado. Restaurar el estado anterior y validar cada túnel por separado.
• Falla el túnel o la central: el diseño estándar no ofrece salida local a Internet. Ese fallback necesita una ruta separada de seguridad y routing planificada expresamente.
• Funciona una IP pública, pero no un FQDN: comprobar la dirección DNS del cliente, la regla DNS, la ruta al resolver central y las respuestas. La opción de tráfico del sistema solo importa si el firewall origina la consulta.

Para el rollback se prepara primero, por encima de Branch_LAN_to_WAN_drop, una regla LAN-to-WAN temporal limitada a un solo cliente de prueba. Después se restaura Route Precedence al valor registrado y se comprueba la ruta WAN local con una sesión nueva de ese cliente. Si la prueba falla, se restablecen de inmediato la precedencia y el estado de las reglas del full tunnel mediante un acceso de administración independiente. Solo tras una prueba correcta se activa la regla LAN-to-WAN habitual anterior, se desactiva Branch_LAN_to_WAN_drop y se elimina la regla temporal.

A continuación se restaura la opción de tráfico del sistema a su valor anterior y, dado que esto reinicia los túneles, se comprueban todas las conexiones IPsec. Branch_LAN_to_VPN, VPN-to-WAN y MASQ solo se desactivan o eliminan cuando Rule ID, NAT ID y uso confirman que ningún otro flujo depende de ellos. Por último, se restauran los selectores IPsec originales o se elimina el túnel creado exclusivamente para esta ruta. La copia de seguridad de la configuración y el acceso de administración independiente se mantienen disponibles hasta que funcionen sesiones nuevas de DNS, HTTPS y aplicaciones en ambas sedes.

Preguntas frecuentes