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 a IPsec policy-based. Para diseños nuevos o en crecimiento, route-based Any-to-Any con XFRM y routing explícito suele ser más flexible. 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.

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 ruta de retorno documentada y una ventana de mantenimiento.

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. Sin ruta de retorno y NAT correctos, el túnel puede estar verde y las conexiones de Internet no recibir respuesta.

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
• 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.

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.

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. Packet Capture muestra 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.

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.

Para el rollback, primero se desactiva Branch_LAN_to_WAN_drop y se restaura de forma controlada la salida local anterior. Después solo se eliminan la regla VPN-to-WAN y MASQ si ningún otro flujo las necesita. Route Precedence y la opción de tráfico del sistema se restauran exactamente a sus valores anteriores documentados y se vuelven a probar ambas sedes.

Preguntas frecuentes