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

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. Impide que una regla local de Internet demasiado amplia evite la ruta planificada por el túnel. No se deben incluir accidentalmente otras redes o servicios locales necesarios.

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 es enable. Como un sistema existente puede tener otro valor, primero se muestra el estado actual con este comando de solo lectura de Device Console:

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:

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

⚠️ 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.

Durante el rollback se restaura el estado anterior documentado. Si la opción estaba activada, se utiliza:

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

Después de cualquier cambio se vuelven a probar todas las conexiones IPsec y los servicios necesarios del firewall.

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