Configurar Site-to-Site RED entre dos Sophos Firewall

Un túnel Site-to-Site RED conecta directamente dos Sophos Firewall sin necesidad de instalar un dispositivo SD-RED en ninguno de los sitios. Una firewall actúa como Firewall RED server y acepta la conexión. La otra actúa como Firewall RED client y establece el túnel hacia el servidor.

Este flujo actual de SFOS 22 no debe confundirse con un modo de funcionamiento RED como Standard/Unified o Standard/Split. Esos modos corresponden a un SD-RED físico. En un diseño firewall a firewall se configuran interfaces RED, rutas estáticas y reglas de firewall adecuadas en ambos equipos.

⚠️ Antes del cambio se necesita una copia de seguridad actual de ambas firewalls, un acceso administrativo independiente y una vía de recuperación documentada. Siempre que sea posible, la dirección pública del Firewall RED server no debe traducirse mediante NAT, ya que la traducción puede interferir con las conexiones RED entrantes.

El proceso en ocho pasos

1. Planificar los roles, las IP RED, las redes de los sitios y una dirección de servidor accesible.
2. Activar el RED provisioning service en ambas firewalls y permitir la ruta de control RED.
3. Crear en la central la interfaz Firewall RED server.
4. Transferir de forma segura el archivo de aprovisionamiento generado al otro sitio.
5. Crear en la sucursal la interfaz Firewall RED client e importar el archivo.
6. Añadir en ambos lados una ruta estática hacia la LAN remota, con la IP RED del peer como gateway y sin seleccionar ninguna interfaz.
7. Permitir el tráfico de datos en ambas firewalls mediante reglas específicas con registro; no crear una regla NAT vinculada.
8. Comprobar por separado el túnel, la ruta, la coincidencia de reglas y tráfico bidireccional real.

Una interfaz RED en verde solo confirma que el túnel se ha establecido. No demuestra que el routing, las reglas de firewall y la ruta de retorno funcionen.

Planificación y diseño

Cuándo encaja Site-to-Site RED

Site-to-Site RED es una forma sencilla de conectar dos Sophos Firewall. El aprovisionamiento RED se encarga de parte de la negociación VPN clásica, mientras que las LAN remotas siguen utilizando routing y reglas de firewall normales.

En diseños nuevos hay que elegir conscientemente entre RED y Site-to-Site IPsec. IPsec ofrece más opciones de perfiles, routing, interoperabilidad y redundancia. Site-to-Site RED resulta atractivo cuando ambos extremos son Sophos Firewall y basta un túnel sencillo y específico de Sophos.

Un SD-RED físico se configura con Configurar y diagnosticar Sophos SD-RED. Los modos de funcionamiento RED no se aplican al túnel firewall a firewall descrito aquí.

Planificar la topología de ejemplo

El siguiente ejemplo utiliza deliberadamente direcciones de documentación. Todas deben sustituirse por las redes y direcciones reales de los dos sitios:

• Central, rol Firewall RED server: dirección pública 198.51.100.10, LAN 10.10.0.0/16
• Sucursal, rol Firewall RED client: dirección pública 203.0.113.20, LAN 10.20.0.0/16
• IP RED de la central: 10.255.100.1
• IP RED de la sucursal: 10.255.100.2

Las dos IP RED forman el par de direcciones entre las firewalls. No deben entrar en conflicto con una LAN de sitio ni con otra red de interfaz o VPN. La firewall cliente debe poder alcanzar de forma fiable la dirección IP pública o el FQDN del servidor.

El ejemplo usa 255.255.255.252 (/30) como RED netmask. Esta pequeña red de tránsito contiene exactamente el par necesario. Si se elige otra red libre, hay que sustituir de forma coherente ambas IP RED y la máscara. RED no resuelve LAN solapadas; el direccionamiento o NAT debe definirse antes del túnel.

Sophos describe expresamente las interfaces RED como túneles seguros y cifrados. Al registrar el RED provisioning service, SFOS utiliza los datos de registro para generar un certificado destinado a la comunicación RED segura. Por eso, el flujo documentado entre firewalls no pide seleccionar manualmente un PSK ni un certificado en la interfaz: el servidor genera un Provisioning file con los datos de configuración del cliente. El archivo debe transferirse únicamente por un canal protegido.

Configurar el túnel y el camino de datos

Crear el Firewall RED server

Primero se crea el servidor en la firewall con una dirección pública accesible de forma estable:

1. En System services > RED, activar el RED provisioning service.
2. Abrir Network > Interfaces.
3. Seleccionar Add interface > Add RED.
4. En Branch name, introducir por ejemplo RED-HQ-Branch.
5. Establecer Type en Firewall RED server.
6. Mantener Tunnel ID en Automatic.
7. Introducir 10.255.100.1 como RED IP.
8. Introducir 255.255.255.252 como RED netmask.
9. Asignar una zona elegida conscientemente; el ejemplo usa RED-S2S.
10. Dejar inicialmente Tunnel compression y MTU sin cambios y guardar.
11. En Network > Interfaces, elegir Download provisioning file en el menú de la nueva interfaz.

El archivo de aprovisionamiento pertenece a este túnel y debe tratarse como un artefacto de configuración sensible. Se transfiere a la sucursal por un canal protegido y, después de importarlo, no se deja en una carpeta de descargas o compartida de acceso general.

La zona influirá posteriormente en las coincidencias de reglas y Device Access. Es posible usar LAN, pero una zona dedicada suele crear un límite de seguridad más claro cuando existen varios sitios. Configurar zonas e interfaces en Sophos Firewall explica las relaciones generales.

Automatic evita reutilizar por error una Tunnel ID. Si debe configurarse manualmente, Sophos exige que no esté en uso en ninguno de los dos dispositivos. En el flujo de cliente documentado no se introduce una segunda Tunnel ID; el archivo de aprovisionamiento del servidor proporciona la asociación. Tunnel compression puede mejorar el rendimiento en conexiones lentas, pero consume recursos; solo debe cambiarse tras una medición antes/después reproducible. La MTU de la interfaz RED afecta a la fragmentación; por ello, un problema de MTU o fragmentación puede bloquear flujos con paquetes grandes aunque el túnel esté activo. Solo debe probarse una MTU menor cuando se haya demostrado fragmentación o un problema de Path MTU.

Crear el Firewall RED client

En el otro sitio se crea el cliente con el archivo generado por el servidor:

1. También aquí, en System services > RED, activar el RED provisioning service.
2. Crear una nueva interfaz en Network > Interfaces > Add interface > Add RED.
3. Usar un Branch name como RED-Branch-HQ.
4. Establecer Type en Firewall RED client.
5. En Firewall IP/hostname, introducir la dirección pública o el FQDN del servidor.
6. En Provisioning file, seleccionar el archivo de la firewall servidor.
7. Introducir 10.255.100.2 como RED IP.
8. Introducir también 255.255.255.252 como RED netmask.
9. Asignar RED-S2S, dejar Tunnel compression y MTU sin cambios y guardar.

Si el cliente solo puede alcanzar el servidor a través de una dirección traducida o cambiante, hay que probar con especial cuidado DNS, el NAT anterior y la ruta de retorno. Sophos recomienda que, siempre que sea posible, el servidor sea accesible directamente sin NAT.

El cliente inicia la conexión saliente, por lo que la sucursal no necesita una publicación entrante equivalente.

Añadir rutas estáticas sin interfaz

Una vez establecido, el túnel no conoce automáticamente las redes LAN detrás de las firewalls. Se crea una ruta unicast IPv4 en ambos lados:

• Central: destino 10.20.0.0/16, gateway 10.255.100.2
• Sucursal: destino 10.10.0.0/16, gateway 10.255.100.1

La excepción RED decisiva consiste en que no se selecciona ninguna interfaz para estas dos rutas. La firewall envía solicitudes ARP para determinar la interfaz RED accesible para la dirección del peer. Seleccionar después una interfaz puede interferir con este mecanismo y no supone una mejora.

La ruta se crea en Routing > Static routes > IPv4 unicast route > Add. La distancia administrativa y la métrica se eligen de forma consciente para que encajen con el resto del diseño de routing. Configurar y probar una ruta estática en Sophos Firewall explica la lógica general de los campos y la validación con Route Lookup.

Limitar el servicio RED y las reglas de firewall

Primero, el servicio RED local debe aceptar la conexión. En Administration > Device access, activar RED solo para la zona de llegada real. Si las direcciones públicas de origen son estables, crear en Local service ACL exception rule > Add una regla Accept específica con Source zone, Source Network / Host, la interfaz WAN como Destination host y Services: RED. Las reglas normales no controlan servicios locales. Device Access y Local Service ACL explica esta separación.

Después, en Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, el flujo iniciado en la central requiere: central LAN, origen 10.10.0.0/16, destino zona RED-S2S y red 10.20.0.0/16; sucursal origen zona RED-S2S y red 10.10.0.0/16, destino LAN y 10.20.0.0/16. Limitar Services a lo necesario.

Para conexiones iniciadas en la sucursal, añadir el par invertido. Activar Log firewall traffic, revisar la posición y dejar Create linked NAT rule desactivado. La conexión enrutada debe conservar direcciones reales y ruta de retorno; no sobrescribir una excepción NAT intencionada sin revisarla. Entender y configurar reglas de Sophos Firewall amplía la mecánica.

Validación, troubleshooting y rollback

Validar el túnel de forma controlada

La validación comienza con un único flujo de prueba cuya hora exacta queda documentada. Primero se comprueba que ambas interfaces RED están activas y que Route Lookup muestra la ruta esperada para una dirección de la LAN remota. Después, el flujo debe coincidir con la Rule ID prevista en ambas firewalls.

Un Packet Capture en Sophos Firewall muestra si el paquete entra en la interfaz RED del lado de origen, llega al otro extremo y se reenvía a la LAN de destino. La ruta de retorno se prueba por separado. Un ping no basta si la aplicación de producción utiliza TCP o UDP en otros puertos.

Por tanto, el éxito significa que se cumplen simultáneamente estos puntos:

• Las interfaces RED están activas en ambos lados.
• Route Lookup muestra la ruta planificada en ambas direcciones.
• La regla de firewall esperada coincide en las dos firewalls.
• Un flujo de aplicación real funciona de forma bidireccional.
• Las direcciones de origen y destino aparecen sin NAT no previsto.
• Tras un reinicio controlado se restablece un flujo nuevo; un clúster HA requiere además una prueba de failover independiente.

Para HA, Sophos documenta un retraso al reconectar los túneles RED con la Auxiliary Firewall tras el failover. Depende del número de interfaces y otros ajustes y también afecta a Site-to-Site RED. No debe prometerse recuperación inmediata: registrar el momento, el estado y el tiempo de reconexión y volver a probar el flujo.

Delimitar los errores de forma sistemática

El cliente no establece el túnel: Comprobar el RED provisioning service, la dirección del servidor, DNS, la accesibilidad, Device Access y el archivo de aprovisionamiento correspondiente al túnel. No combinar a ciegas un archivo nuevo con una configuración de cliente antigua.

Se rechaza el archivo de aprovisionamiento: comprobar que procede de la interfaz servidor actual y no cambió durante la transferencia. Conservar el estado previo antes de descargar otro archivo y recrear limpiamente el cliente durante mantenimiento.

El túnel está activo, pero la LAN remota no es accesible: Comprobar en ambos lados la red de destino y la IP RED del peer de la ruta estática. En esta ruta RED especial no debe seleccionarse ninguna interfaz. Después, verificar la coincidencia de reglas y la ruta de retorno.

Solo funciona una dirección: Normalmente falta una regla o ruta adecuada en una de las firewalls, o una red del sitio ya se alcanza por una ruta más específica o de mayor prioridad. Route Lookup, Packet Capture y el tráfico de retorno real deben coincidir.

La conexión es inestable: Correlacionar latencia, pérdida de paquetes, accesibilidad pública del servidor, NAT delante del servidor y cambios en la ruta WAN. Guardar los logs locales de cada nodo para la hora exacta de la prueba. Buscar y analizar los logs de servicio de Sophos Firewall explica los archivos de log y las vías de soporte.

El túnel está activo, pero los flujos con paquetes grandes se bloquean: revisar en Packet Capture ambas direcciones en busca de fragmentación y mensajes ICMP Path MTU. Comparar los valores MTU de ambas interfaces RED y probar distintos tamaños de paquete. Solo con estas pruebas debe ensayarse gradualmente la misma MTU en ambas interfaces. No cambiar compression y MTU a la vez.

Ninguna regla Any amplia, autorización WAN general, reinicio de servicio o cambio aleatorio de las IP RED y las rutas sustituye esta correlación. Si el error sigue sin estar claro pese a un diseño correcto, se recopilan para Sophos Support la copia de seguridad, el build de SFOS, la marca de tiempo, el estado de las interfaces, las rutas, las Rule IDs, el Packet Capture y los logs relevantes.

Revertir de forma segura

Si el piloto falla, desactivar primero las reglas y eliminar las rutas, después la interfaz cliente y por último la servidor. Restaurar Device Access/Local Service ACL y los valores MTU o compression; eliminar objetos nuevos solo si no los usa otra configuración.

No se elimina una vía de administración existente que utilice precisamente este túnel hasta haber probado correctamente un acceso alternativo. Tras la reversión, se vuelven a comprobar el routing normal, las reglas anteriores y la accesibilidad de ambas firewalls.

FAQ