Configurar y solucionar problemas de Sophos SD-RED

Con un Sophos SD-RED se pueden conectar sucursales, oficinas o pequeñas ubicaciones de teletrabajo a un Sophos Firewall. El RED establece un túnel cifrado con el firewall y proporciona una red en la ubicación remota que se gestiona centralmente a través del firewall.

La ventaja práctica: normalmente no se necesita una configuración VPN compleja en el lugar. El SD-RED se conecta a Internet, descarga su configuración a través del Sophos RED Provisioning Service y luego establece el túnel con el Sophos Firewall. Sin embargo, el túnel por sí solo no resuelve todo. También deben coincidir las zonas, reglas de firewall, DHCP, VLANs, enrutamiento, DNS y el estado del firmware.

El modo de funcionamiento debe decidirse antes de la configuración propiamente dicha. Determina DHCP, la puerta de enlace, la ruta de internet, el control central y el comportamiento durante una interrupción del túnel. Elegir el modo de funcionamiento correcto de Sophos RED explica las diferencias y los criterios de decisión.

Planificación y requisitos

Clasificación: SD-RED y RED entre firewalls

En RED existen dos casos de uso actuales que deben mantenerse separados. Este artículo trata un SD-RED 20 o SD-RED 60 físico en una sucursal. SFOS 22 también sigue siendo compatible con un túnel Site-to-Site RED entre dos Sophos Firewall, donde una actúa como Firewall RED server y la otra como Firewall RED client.

El segundo caso no necesita hardware RED. Configurar Site-to-Site RED entre dos Sophos Firewall explica el archivo de aprovisionamiento, las rutas estáticas sin una interfaz seleccionada, las reglas en ambos lados y el servicio RED. Los modos de funcionamiento de SD-RED no se aplican a este diseño.

Requisitos en la ubicación principal

Antes de conectar el RED, estos puntos deben estar claros en el Sophos Firewall:

• El servicio RED está activado en el firewall.
• La dirección IP pública o el nombre DNS/DynDNS del firewall es accesible.
• Las conexiones RED al firewall están permitidas en el lado WAN.
• RED está permitido bajo Administration > Device access para la zona WAN adecuada o se ha habilitado específicamente a través de Local Service ACL.
• La interfaz RED, la zona y la configuración IP están planificadas.
• Se han previsto reglas de firewall desde la red RED hacia las redes de destino.
• Se ha aclarado DHCP, DHCP Relay o direccionamiento estático para los clientes detrás del RED.
• El patrón de firmware RED en el firewall está actualizado.
• Se ha documentado la copia de seguridad y el estado del firmware del firewall antes de realizar cambios importantes.

Para la comunicación RED, son especialmente relevantes TCP 3400, UDP 3410 y NTP 123. Estas conexiones no deben ser bloqueadas en el camino por routers de proveedores, firewalls intermedios o gateways de seguridad.

Requisitos en la ubicación remota

En la ubicación remota, el SD-RED necesita una conexión a Internet limpia. No solo es importante el ancho de banda, sino sobre todo la estabilidad, latencia, pérdida de paquetes y si el proveedor permite las conexiones necesarias.

Se debe verificar:

• La conexión a Internet es estable.
• El puerto WAN del RED recibe una dirección por DHCP o tiene una configuración estática correcta.
• El gateway estándar es accesible.
• DNS funciona.
• NTP es accesible.
• TCP 3400, UDP 3410 y NTP 123 no están bloqueados.
• El router del proveedor o el firewall intermedio no realiza un filtrado inesperado.
• En caso de VLANs, está claro qué puerto funciona como etiquetado, no etiquetado o híbrido.

Para ubicaciones simples, a menudo basta con una conexión pequeña. En la práctica, sin embargo, la pérdida de paquetes, routers de consumo inestables, CGNAT, problemas de DNS o firewalls restrictivos del proveedor son más a menudo la causa que el mero ancho de banda.

Provisioning y puesta en servicio

Aprovisionar automáticamente mediante Sophos Provisioning Service

Para el aprovisionamiento en línea normal, la firewall y el SD-RED necesitan acceso a Internet. En el primer arranque, el SD-RED debe obtener una dirección WAN por DHCP para descargar su configuración. Por tanto, una configuración WAN estática requiere aprovisionamiento manual mediante USB. En la firewall se activa el servicio de aprovisionamiento RED en System services > RED, se introducen los datos de contacto y se aceptan las condiciones de uso de Sophos.

Después se crea una interfaz en Network > Interfaces > Add interface > Add RED. Se configuran Branch name, tipo de dispositivo, Automatically via provisioning service, dirección de la firewall, uplink, modo de funcionamiento, red RED, zona y DHCP para la sede. En un RED que se utiliza por primera vez, Unlock code se deja vacío. Después de guardar, la firewall carga la configuración en el servicio de aprovisionamiento. El SD-RED la descarga, abre el canal de control en TCP 3400 y después establece el túnel de capa 2 en UDP 3410.

Para la zona RED propia, introduzca un nombre como RED-Branch en Network > Zones > Add, establezca Type en LAN o DMZ y seleccione en Device access solo los servicios realmente necesarios. Guarde con Save y seleccione esta zona en RED network settings de la interfaz RED. En Administration > Device access, en cambio, habilite el servicio RED para la zona desde la que la RED llega al firewall, normalmente WAN; aplique con Apply. La zona de clientes detrás de la RED y la zona de entrada del túnel RED no son lo mismo.

Al guardar la configuración por primera vez, el servicio de aprovisionamiento genera un código de desbloqueo específico del dispositivo. Aparece en WebAdmin y se envía a la dirección de correo configurada en System services > RED. El código debe guardarse de forma segura porque se necesita al trasladar el RED a otra firewall. WebAdmin vuelve a mostrarlo al eliminar la interfaz. Si no está disponible, se debe contactar con Sophos Support.

Configurar conscientemente las opciones de protección globales de RED

Durante la activación inicial en System services > RED, SFOS crea un certificado para la comunicación RED a partir de Organization name, City, Country y Email. Por tanto, Organization name y City no deben contener diéresis ni caracteres especiales. La dirección de correo debe permanecer accesible porque Sophos envía allí los nuevos códigos de desbloqueo.

Para SD-RED 20 y 60 actuales, TLS v1.2 (strict) and later es el punto de partida recomendable. Esta selección solo utiliza los cifrados TLS 1.2 recomendados por Sophos. TLS v1.2 and later incluye además cifrados que Sophos no recomienda y no debe elegirse sin una necesidad de compatibilidad comprobada. Después de cambiar esta opción, hay que volver a conectar y probar de forma controlada todos los túneles RED de producción.

Automatic device deauthorization evita que un RED desconectado durante mucho tiempo permanezca autorizado indefinidamente. El plazo debe ajustarse al proceso propio de incidencias y sustitución: al vencer no se elimina el dispositivo, pero la interfaz RED debe volver a activarse expresamente en Network > Interfaces. Por ello, la supervisión y la documentación del código de desbloqueo forman parte de esta protección.

En SD-RED 20 y 60 se mantiene activado RED unified firmware. Un nuevo patrón de firmware RED se instala conscientemente en Backup & firmware > Pattern updates y no se aplica automáticamente. Hay que planificar una ventana de mantenimiento y comprobar después el túnel y un cliente.

Para configurarlo, active Automatic device deauthorization, indique el plazo y seleccione Apply. Vuelva a activar una RED desautorizada al vencer el plazo en Network > Interfaces, mediante el Menu situado a la derecha del dispositivo afectado. La función de protección también se aplica a un Firewall RED Client. RED unified firmware está seleccionado de forma predeterminada; sin embargo, en una migración del firewall se conserva la configuración existente. Tras un restablecimiento de fábrica, la opción vuelve a estar seleccionada. Por ello, compruebe el valor real después de una migración o un restablecimiento, en lugar de limitarse a asumir el valor predeterminado.

Conectar el SD-RED

Procedimiento típico:

1. Conectar el puerto WAN del SD-RED al router del proveedor o módem.
2. Conectar el puerto LAN a un cliente de prueba, switch o red local.
3. Alimentar el SD-RED con energía.
4. Esperar a que el RED arranque, verifique el gateway e Internet, cargue la configuración y establezca el túnel.
5. Verificar en el Sophos Firewall si la interfaz RED está activa.
6. Conectar un cliente de prueba detrás del RED y verificar IP, DNS, gateway y acceso a destino.

Si todos los LEDs relevantes están en verde, el túnel técnico está establecido. Luego comienza la verdadera verificación de la red: zona, DHCP, reglas de firewall, enrutamiento de retorno, DNS y, si es necesario, VLANs.

Provisioning manual con memoria USB

Normalmente un SD-RED se provisiona mediante Sophos RED Provisioning Service. El provisioning manual con memoria USB es útil cuando el dispositivo está en una red privada o muy restringida, necesita una configuración WAN estática o el camino de provisioning automático no es fiable.

La fuente horaria del firewall y el suministro de hora a la RED no son lo mismo: La guía de RED manual para SFOS 22 y 23 describe la selección de Use custom NTP server en Administration > Time, la propia IP del firewall en Search/Add, y Add y Apply como configuración de un servidor NTP para la RED. Sin embargo, la documentación de los ajustes horarios describe este campo como una fuente horaria previa para el reloj del firewall. Por tanto, las funciones no encajan de forma inequívoca; este procedimiento no es un requisito incondicional ni demuestra que el firewall proporcione NTP a la RED. Sin una vía de sincronización horaria confirmada y admitida para la versión instalada, la configuración NTP que funciona debe permanecer sin cambios. Planificar primero cada cambio confirmado tomando como referencia el estado inicial documentado: cambiar los servidores NTP vuelve a conectar todas las conexiones IPsec. Si se ven afectadas conexiones de producción, garantizar una ventana de mantenimiento y acceso de administración local o alternativo.

El proceso es más preciso que solo copiar un archivo de provisioning a USB:

1. Antes del aprovisionamiento manual, aclarar la vía de sincronización horaria admitida para la versión instalada y documentar los ajustes NTP que funcionan, así como la hora y el estado de sincronización del firewall. No cambiar la fuente horaria global a la propia IP del firewall únicamente por esta configuración de RED; la restricción y la comprobación NTP/HTTPS se indican más abajo.
2. En Network > Zones, crear para las sedes RED una zona dedicada de tipo LAN o DMZ. Una zona separada evita que las reglas LAN generales se apliquen involuntariamente a la sede remota. Si se utiliza en cambio la zona VPN, la firewall no responde por sí misma a las consultas DNS de los clientes RED; DHCP debe distribuir otro servidor DNS accesible.
3. En System services > RED, activar el RED Provisioning Service.
4. En Network > Interfaces > Add interface > Add RED, crear la interfaz RED.
5. En Device deployment, seleccionar Manually via USB stick.
6. Introducir RED ID, Unlock Code, uplink, RED network settings, zona, DHCP y VLANs según la sede.
7. En Network > Interfaces, abra el Menu de la interfaz RED y descargue el archivo de aprovisionamiento correspondiente a esta interfaz, generado tras Save.
8. Copiar el archivo al directorio raíz de la memoria USB.
9. Apagar el RED, insertar la memoria USB y volver a encender el RED.
10. Tras el arranque, comprobar interfaz, LEDs, IP del cliente, DNS, regla de firewall y acceso a destinos.

Después de un cambio horario confirmado, actualizar WebAdmin y comprobar el reloj del firewall en Administration > Time, el estado de sincronización y las conexiones IPsec. Comprobar también la vía de sincronización horaria de la RED, el handshake TLS y el establecimiento del túnel. Si falla la sincronización horaria o se produce una regresión, restaurar las fuentes horarias y los ajustes anteriores que funcionaban en Administration > Time y repetir las mismas comprobaciones; esta reversión también puede restablecer las conexiones IPsec.

Si el lado WAN del RED usa DHCP, en la sede remota debe responder realmente un servidor DHCP. Si el RED no recibe dirección, puede entrar en un bucle de reinicio. Con configuración WAN estática, IP, gateway, DNS y NTP deben revisarse con especial precisión.

Incluso una RED aprovisionada sin conexión necesita una hora válida dentro del período de validez del certificado para el handshake TLS. Para la sincronización horaria directa, debe poder resolver de 0.sophos.pool.ntp.org a 3.sophos.pool.ntp.org y acceder a ellos mediante UDP 123. Si no lo consigue, intenta sincronizar la hora con el firewall mediante HTTPS en TCP 4444. Si el servicio de administración HTTPS no está permitido para WAN en Administration > Device access, esta alternativa puede fallar sin una excepción específica. No habilitar HTTPS de forma general para la zona WAN con este fin: la excepción también permite el servicio de administración HTTPS y debe estar estrictamente limitada.

Antes de realizar un cambio, documentar los ajustes existentes de Device Access y ACL y comprobar si ya existe una excepción adecuada. Determinar con Diagnostics > Packet capture la dirección de origen de la conexión RED realmente observada en el firewall. Detrás de un router NAT, normalmente es la dirección pública de salida NAT de la sucursal, no la dirección WAN privada de la RED. Utilizar únicamente un host IP claramente conocido y lo más estable posible; si la dirección NAT es compartida, el permiso también se aplica a otros dispositivos detrás de esa dirección. No sustituir un origen cambiante o desconocido por un permiso Any.

1. Abrir Administration > Device access > Local service ACL exception rule > Add y asignar un nombre único.
2. Establecer Source zone en WAN. En Source network or host, seleccionar el host IP correspondiente a la dirección de origen realmente observada; si es necesario, crear un host IP adecuado mediante Add.
3. Establecer Destination host en el puerto WAN previsto del firewall, Services en HTTPS y Action en Accept. Guardar con Save.
4. Comprobar la restricción de origen guardada y el host de destino. Después, probar la sincronización horaria de la RED, el handshake TLS y el establecimiento del túnel, y comprobar que no se hayan permitido otros orígenes WAN para HTTPS.

Si una excepción recién creada solo es necesaria temporalmente, eliminarla tras la prueba o tras restablecer la vía NTP directa. Eliminarla también si no surte efecto o permite un acceso no deseado; si se modifica una excepción existente, restaurar su estado inicial documentado. A continuación, volver a comprobar la restricción de origen, la accesibilidad HTTPS y el túnel RED. Documentar toda excepción necesaria de forma permanente, incluida la dirección de origen NAT, y revisarla periódicamente.

Estado, actualizaciones y migración

Entender el estado de los LED

Los LEDs de estado son a menudo la entrada más rápida para la solución de problemas del RED, ya que indican en qué punto se detiene el proceso de inicio.

Leyenda:

• ⚫ apagado
• 🟢 encendido verde
• 🟢 parpadea verde
• 🔴 encendido rojo
• 🔴 parpadea rojo

Dependiendo del ángulo de visión, foto o luz ambiental, un LED puede parecer amarillento o naranja. Para el diagnóstico, lo que importa es principalmente qué LED está encendido o parpadeando y si es verde o rojo.

Proceso de arranque normal

Si los cuatro LEDs están en verde, pero no funciona el tráfico, el problema generalmente ya no está en el establecimiento del túnel. Entonces, las reglas de firewall, DHCP, VLANs, DNS, NAT o enrutamiento son más probables.

Códigos de error

Conmutación por error 3G/4G

En modelos SD-RED con conmutación por error 3G/4G o módulo correspondiente, pueden ocurrir patrones adicionales.

Controlar actualizaciones de firmware

Si los LED parpadean juntos, la RED puede estar instalando firmware. Durante esta fase, no se debe apagar el dispositivo ni desconectarlo de Internet. Una actualización puede tardar unos minutos. La interpretación debe corresponder al patrón de LED y al modelo concretos; el parpadeo simultáneo por sí solo no constituye un diagnóstico inequívoco de firmware, como también muestran los patrones de failover.

En el Sophos Firewall, también se debe verificar:

Backup & firmware > Pattern updates

Allí, el patrón de firmware RED debe estar actualizado. Según Sophos, la descarga y la instalación tardan entre cinco y diez minutos. Si un RED está en un bucle o no arranca correctamente después de una actualización del firewall, un patrón de firmware RED obsoleto es un paso de verificación sensato. Configurar y comprobar los patrones de Sophos Firewall explica cómo se combinan los estados, la descarga automática y la instalación consciente.

Un deseo operativo relacionado se describe en Solicitud de características de Sophos Firewall 2024: En las actualizaciones de firmware de RED y puntos de acceso, a menudo faltan notas de lanzamiento visibles directamente en el backend. Para entornos productivos, las actualizaciones deben planificarse conscientemente y no instalarse de manera no coordinada durante tiempos críticos de operación.

Verificar interfaz RED, zona y reglas

Después de establecer con éxito el túnel, el RED necesita una configuración de firewall limpia.

Puntos de verificación típicos:

• La interfaz RED está activa en Network > Interfaces.
• La interfaz está en la zona correcta.
• El servidor DHCP o el relé DHCP están configurados correctamente.
• Los clientes reciben dirección IP, gateway y DNS.
• Las reglas de firewall solo permiten los destinos necesarios.
• El enrutamiento de retorno a la red RED funciona.
• NAT solo se utiliza si está planificado conscientemente.
• La configuración de VLAN coincide con el modo RED y el puerto del switch.

Para la primera prueba funcional basta con una regla muy restringida en Rules and policies > Firewall rules: establecer Source zone en la zona dedicada RED-Branch, indicar la red de clientes RED en Source networks and devices y permitir como destino únicamente la red interna de prueba necesaria. El acceso a Internet requiere una regla separada con la zona WAN como destino y el tratamiento NAT previsto. Después, limitar destinos y servicios a las necesidades de producción. Así se comprueba la ruta deseada sin conceder a la sede acceso a todas las redes internas.

Para las bases de las reglas, consulte Entender y configurar correctamente las reglas de Sophos Firewall. Si el túnel está establecido pero el tráfico no fluye, se debe combinar Log Viewer y Packet Capture.

La opción MAC filtering type puede aplicar una lista de permitidos o bloqueados, limitada según el dispositivo, en la red RED, pero no sustituye una regla de firewall. Remote IP assignment tampoco es un valor predeterminado: asigna mediante DHCP o de forma estática una dirección al bridge con el túnel RED en el lado WAN y solo se investiga cuando los dispositivos detrás del RED no responden a solicitudes ARP. Ninguna de las dos opciones debe activarse como solución general de rendimiento o conectividad.

Trampas de actualización y migración

No confundir Site-to-Site RED con SD-RED

Un túnel RED entre firewalls sigue siendo un diseño independiente compatible con SFOS 22. No utiliza ninguno de los cuatro modos de funcionamiento de SD-RED y no se define mediante DHCP ni los puertos LAN de un SD-RED. Por tanto, durante la actualización se crea un inventario de ambos tipos de RED y después se comprueba cada tipo con su correspondiente prueba funcional adecuada.

Para una planificación de actualización más amplia, consulte Planificar correctamente la actualización de firmware de Sophos Firewall. El proceso completo entre firewalls se encuentra en Configurar Site-to-Site RED entre dos Sophos Firewall.

Eliminar Firewall RED heredado y dispositivos RED antiguos antes de SFOS 22

SFOS 22.0 y versiones posteriores ya no admiten Firewall RED Server Legacy ni Firewall RED Client Legacy. Mientras exista una configuración de este tipo entre UTM y SFOS, se bloquean la actualización, la restauración y la importación de configuraciones en SFOS 22. Esto no afecta a los tipos actuales Firewall RED server y Firewall RED client. Antes de actualizar, se sustituyen todas las dependencias de las interfaces heredadas, se eliminan las interfaces y después se crea una nueva copia de seguridad de la configuración.

RED 15, RED 15w y RED 50 también han llegado al final de su vida útil. Sus túneles dejaron de conectarse a partir de SFOS 20.0 MR1. Tras una actualización o restauración en SFOS 22, la configuración antigua sigue visible, pero no se aplica y solo puede eliminarse. No se puede importar. Estas sedes deben migrarse a SD-RED 20 o SD-RED 60 antes de la actualización y probarse con su flujo de datos real.

Máscara /32 corregida para los RED system hosts

Sophos corrigió a /32 la máscara de subred de los RED system host objects generados automáticamente en SFOS 21.0 MR2 y 21.5 MR1. Si antes se utilizaban estos objetos en reglas u otras configuraciones para varias direcciones de host, las reglas pueden coincidir con el tráfico de forma distinta después de la actualización.

Compruebe las dependencias en Hosts and services > IP host ya antes de la actualización: Abra Usage para cada host de sistema RED y sustituya el host de sistema por el host IP o Network adecuado en las reglas de firewall, rutas y demás configuraciones enumeradas. Ejemplo: Para la dirección RED 192.168.1.1/24, el host de sistema antes era 192.168.1.1/24; ahora es 192.168.1.1/32. Por tanto, una regla o ruta para toda la red debe utilizar un host Network explícito; el host de sistema ahora solo abarca la IP configurada de la interfaz. Tras la actualización, vuelva a probar las coincidencias de las reglas y la ruta de datos.

Después de una actualización, se debe verificar:

• ¿Se utilizan hosts del sistema RED en reglas de firewall?
• ¿Una regla espera erróneamente una red en lugar de un solo host?
• ¿Deben reemplazarse objetos de IP Host o Network Host?
• ¿Las coincidencias de reglas en el Log Viewer aún son correctas?

RED y failover HA

En entornos HA, las sedes RED deben probarse de forma consciente después de un failover. Sophos indica que los túneles RED no siempre se reconectan inmediatamente al dispositivo auxiliary tras un failover HA. La duración depende, entre otros factores, del número de interfaces y de la configuración.

Para sedes críticas no basta con revisar el estado HA de la firewall. También se debe comprobar:

• estado de la interfaz RED tras el failover
• acceso de clientes detrás del RED
• matches relevantes de reglas de firewall
• DNS y DHCP detrás del RED
• alertas de monitoring ante interrupciones largas del túnel

Comprobar el rendimiento del RED

Sophos especifica un rendimiento máximo del túnel de 250 Mbit/s para SD-RED 20 y de 850 Mbit/s para SD-RED 60. Son valores máximos de la plataforma, no una garantía para una transferencia SMB individual, una prueba de velocidad en el navegador o un único flujo TCP. También influyen los endpoints, el almacenamiento, la ventana TCP, la latencia real entre sedes, la pérdida de paquetes, la ruta del proveedor, la carga del firewall y los perfiles de seguridad.

Un ping de, por ejemplo, 8 ms a un servidor público de pruebas de velocidad no describe necesariamente la latencia entre las dos sedes RED. Una prueba de velocidad en cada conexión a Internet tampoco comprueba la ruta cifrada de extremo a extremo a través del túnel RED. Para responder a esta pregunta se necesita un servidor de prueba en una LAN y un cliente de prueba en la LAN de la otra sede.

Probar el túnel RED con iPerf3 en ambos sentidos

Antes de probar el túnel, se debe obtener una referencia local con los mismos endpoints conectados por cable. Después se ejecuta iPerf3 a través del túnel RED, primero con un flujo TCP, luego en sentido inverso y finalmente con cuatro flujos paralelos:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 es solo una dirección de ejemplo y debe sustituirse por la IP del servidor iPerf3 de la LAN remota. La prueba genera carga deliberadamente y debe realizarse en una ventana adecuada. Probar correctamente el rendimiento de Sophos Firewall con iPerf3 explica la instalación, la regla temporal de firewall, las pruebas UDP y el análisis completo de los resultados.

Los tres resultados responden a preguntas diferentes:

• Si la referencia local ya es lenta, comprobar primero endpoints, NIC, controladores, cables, switches y almacenamiento.
• Si un flujo es considerablemente más lento que -P 4, es más probable que limiten la latencia, la ventana TCP o el flujo individual de la aplicación. Esto todavía no demuestra un límite del RED.
• Si uno y cuatro flujos se detienen en el mismo límite en ambos sentidos, investigar los enlaces físicos, la ruta del proveedor, la pérdida de paquetes, la configuración RED y la carga del firewall.
• Si solo un sentido es lento, comparar las velocidades de subida correspondientes, los contadores de interfaz, los errores, los drops y la ruta de retorno.

Un patrón práctico típico sería de unos 400 Mbit/s con un flujo y de entre 700 Mbit/s y 800 Mbit/s con -P 4. Esto sugiere que la ruta puede transportar una capacidad agregada considerablemente mayor, aunque un único flujo TCP o SMB no pueda aprovecharla por completo. No garantiza que todas las aplicaciones alcancen el mismo resultado con varios flujos.

Durante cada ejecución se deben documentar el tiempo real de ida y vuelta y la pérdida de paquetes entre las sedes, las retransmisiones de iPerf, la Firewall Rule ID, los perfiles de seguridad, la CPU del firewall y los contadores de los puertos implicados. Los enlaces WAN y LAN deben funcionar realmente a 1 Gbit/s, Full Duplex y sin contadores de errores o drops crecientes. Conviene mantener velocidad y dúplex en auto-negotiation en ambos extremos, en lugar de forzar gigabit solo en uno.

No se deben desactivar IPS u otros perfiles de seguridad de forma general. Para una prueba A/B se utiliza, como máximo, una regla temporal limitada al origen, destino y servicio iPerf3 concretos, y se elimina inmediatamente después. Si el resultado no cambia sin IPS, es menos probable que IPS sea la causa en esa ruta de prueba concreta.

Desactivar realmente 802.3az o EEE

Para obtener un rendimiento óptimo, Sophos recomienda desactivar 802.3az en los switches conectados a un SD-RED 20 o SD-RED 60. Se refiere a Energy Efficient Ethernet, abreviado EEE. EEE pone partes del PHY Ethernet en el estado Lower Power Idle cuando la utilización del enlace es baja y así ahorra energía. No es lo mismo que PoE ni que 802.3x Flow Control.

El ajuste no se encuentra en WebAdmin ni en la CLI de Sophos Firewall, tampoco en una pantalla documentada del SD-RED. Se modifica en el puerto del switch conectado directamente. Esto se aplica a las conexiones LAN utilizadas por el RED y, si interviene un switch o router gestionable, también al enlace WAN físico. En dispositivos de otros fabricantes, la opción puede llamarse EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az o Power Saving. No existe una CLI universal.

En un Sophos Switch se utiliza la página Port settings:

1. Seleccionar el puerto conectado directamente al SD-RED.
2. Abrir Edit.
3. Establecer EEE status en Off.
4. Guardar con Apply.
5. Comprobar el estado del enlace, la velocidad negociada, el dúplex y los contadores de errores, y repetir la misma prueba iPerf3.

En un Sophos Switch actual, el estado puede mostrarse de forma read-only en la CLI:

show eee

Para el puerto de ejemplo 0/1, EEE se desactiva así:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 debe sustituirse por el puerto conectado realmente al RED. no eee modifica la configuración del puerto. Si solo se puede acceder al switch a través de esta ruta RED, hace falta una ventana de mantenimiento y un acceso de gestión local o alternativo. Según el switch y el firmware, el cambio puede provocar una nueva negociación del enlace.

Para volver al estado anterior en un Sophos Switch, se utiliza eee en lugar de no eee en el mismo Interface Configuration Mode:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Desactivar EEE no desactiva Ethernet ni gigabit. La contrapartida es que el PHY deja de ahorrar la misma cantidad de energía durante los periodos de inactividad, por lo que el puerto consume algo más y puede generar más calor. No hay garantía de un aumento concreto del rendimiento. Lo decisivo es una prueba reproducible antes y después. En un switch no gestionable sin opción EEE no se puede cambiar el ajuste de forma fiable; para la prueba hay que puentearlo o utilizar temporalmente un switch gestionable.

Cambiar Tunnel compression y MTU solo de forma controlada

La interfaz RED se edita en Network > Interfaces. Allí aparecen Tunnel compression y MTU. Sophos describe Tunnel compression como una forma de comprimir el tráfico RED y aumentar el rendimiento, especialmente en conexiones lentas. Los datos ya comprimidos o cifrados apenas pueden reducirse más, mientras que la compresión añade trabajo de procesamiento. Por eso no existe un ajuste correcto para todas las sedes.

Para una prueba A/B, primero se documentan el estado inicial y las mediciones. Después se cambia únicamente Tunnel compression, se guarda y se repite exactamente la misma serie de iPerf3. A continuación se restaura el estado inicial o se documenta de forma consciente la variante que haya demostrado ser mejor. Guardar puede interrumpir brevemente el túnel RED, por lo que son convenientes una ventana de mantenimiento y un acceso alternativo.

MTU no es un control general de velocidad. Solo se investiga cuando los paquetes pequeños funcionan pero las transferencias grandes se detienen, se observa fragmentación o iPerf3 muestra muchas retransmisiones. Comprobar MTU y MSS de Sophos Firewall para problemas de VPN explica la prueba DF segura, los tamaños de paquete y la vuelta al estado anterior. Sin un hallazgo de MTU reproducible, se mantiene el valor inicial documentado.

Solución de problemas

No se puede crear o editar la interfaz RED

Si ya falla la creación o el guardado de una interfaz RED, compruebe primero los permisos de administrador, las configuraciones contradictorias, el ID de RED y el Unlock Code. El propio firewall debe poder acceder al Provisioning Server; una prueba realizada solo en la red WAN de la RED no basta para determinarlo. Se puede comprobar el establecimiento de la conexión en 5. Device Management > 3. Advanced Shell del firewall:

telnet red.astaro.com 3400

Una conexión establecida correctamente solo confirma la resolución DNS y TCP 3400 desde este firewall. No confirma ni el registro ni el Unlock Code. Si falla, compruebe la ruta de salida del firewall; si la prueba tiene éxito, siga investigando los permisos y la configuración concreta. No elimine precipitadamente una interfaz existente.

No se puede cambiar la IP RED en SFOS 22.0 MR2

En SFOS 22.0 MR2 Build 546, al cambiar la IP de una interfaz RED existente puede aparecer el mensaje Failed to update RED interface. Lo engañoso es que WebAdmin puede mostrar ya la nueva IP aunque el firewall siga utilizando internamente la dirección anterior. Por tanto, la IP visible por sí sola no confirma que el cambio se haya aplicado correctamente.

El workaround documentado por Sophos también cambia el nombre de la sucursal y vuelve a guardar la interfaz:

1. Documentar la IP RED actual, la máscara de red, el Branch Name y cualquier rango DHCP RED existente.
2. En Network > Interfaces, abrir la interfaz RED afectada e introducir la IP deseada.
3. Si aparece Failed to update RED interface, volver a abrir la interfaz.
4. Cambiar realmente Branch Name, por ejemplo de Branch-Zurich a Branch-Zurich-01, y volver a guardar con Save.
5. En 5. Device Management > 3. Advanced Shell, utilizar el comando de solo lectura ifconfig para comprobar si la nueva dirección está activa en la interfaz RED:

ifconfig

El nombre de la interfaz depende de la configuración y puede identificarse en Network > Interfaces. Reiniciar el firewall o un servicio, o eliminar la interfaz RED, no forma parte de este workaround.

Si la nueva IP RED se encuentra en una red distinta a la del rango DHCP RED anterior, SFOS desactiva el servidor DHCP RED. Se trata de un comportamiento normal del producto, independiente del mensaje de error. En Network > DHCP, se debe adaptar el servidor existente a la nueva red o crear un nuevo servidor DHCP. El rango de leases, las asignaciones MAC estáticas, el gateway y DNS deben corresponder al nuevo direccionamiento.

Por último, renovar el lease DHCP en un cliente situado detrás del RED y comprobar la dirección IP, el gateway, DNS, el estado del túnel y el acceso previsto. En Log Viewer, el tráfico debería volver a coincidir con la regla de firewall esperada. Si la IP del backend sigue siendo la anterior después de volver a guardar, actualmente no hay ningún fix de producción publicado para NC-184971. No se deben eliminar reglas o interfaces dependientes por sospecha; se debe hacer una copia de seguridad de la configuración y recurrir al soporte de Sophos.

RED no recibe dirección IP

Si el RED se detiene en el paso del router o el código de error indica DHCP o gateway, la causa generalmente está en la ubicación remota.

Verificar:

• ¿El router del proveedor asigna una dirección IP por DHCP?
• ¿El cable de red está correctamente conectado al puerto WAN?
• ¿El gateway estándar es accesible?
• ¿Se ha ingresado completamente una dirección IP estática?
• ¿Coinciden la dirección IP, máscara de subred, gateway y DNS?
• ¿Un dispositivo intermedio bloquea el tráfico?

Si DHCP no funciona en la ubicación remota, el RED puede entrar en un bucle de reinicio.

RED no alcanza Internet

Si el router o gateway es accesible, pero el LED de Internet no se vuelve verde permanentemente, el problema generalmente está detrás del router local.

Verificar:

• ¿Funciona la conexión a Internet con un cliente normal?
• ¿Funciona DNS?
• ¿Es accesible NTP?
• ¿Se bloquean TCP 3400, UDP 3410 o NTP 123?
• ¿Hay un proxy o firewall entre el RED e Internet?
• ¿La conexión del proveedor es lo suficientemente estable?
• ¿Es accesible el servicio de aprovisionamiento mediante HTTPS por TCP 443?

Para el aprovisionamiento RED, el RED debe alcanzar el Sophos Provisioning Service. Sophos documenta *.astaro.com mediante TCP 3400 y UDP 3410; los demás destinos del fabricante y los límites de validación están en Comprobar servicios y puertos salientes de Sophos Firewall.

Un cliente de la misma red que el puerto WAN del RED puede ejecutar telnet red.astaro.com 3400 para comprobar la resolución DNS y el establecimiento de una conexión TCP. Una conexión correcta solo confirma la accesibilidad de TCP 3400; no aporta información sobre UDP 3410, el aprovisionamiento, la autenticación ni el túnel RED.

Si la conexión TCP se establece correctamente pero el registro sigue fallando, Sophos también menciona una carga de red elevada como posible causa. Tras comprobar el acceso a Internet, DNS y HTTPS saliente en TCP 443, se puede volver a intentar el registro más tarde. Una prueba TCP correcta no demuestra ni una carga de red elevada ni un registro correcto; si los errores persisten, siga investigando las demás causas.

RED no alcanza el Sophos Firewall

Si Internet es accesible pero no se establece el túnel, se debe verificar el lado del firewall.

Verificar:

• ¿Está activado el servicio RED en el Sophos Firewall?
• ¿Está correctamente configurado el RED?
• ¿Coinciden la ID del RED y el código de desbloqueo?
• ¿Es accesible la IP pública o el FQDN del firewall?
• ¿Está permitido Administration > Device access para RED en la zona WAN adecuada?
• ¿Permite una Local Service ACL el acceso desde la ubicación remota?
• ¿Llegan TCP 3400 y UDP 3410 al firewall?
• ¿La hora del RED es válida para el TLS handshake durante el provisioning manual?
• ¿Puede un RED offline acceder a NTP o a la excepción Local Service ACL prevista?

En la Advanced Shell, se puede verificar si llega tráfico RED:

tcpdump -ni any port 3400 or port 3410

Si no llega nada, el problema generalmente está antes del firewall: router del proveedor, NAT, firewall intermedio, IP pública incorrecta, FQDN o bloqueo de puertos.

RED se reinicia constantemente

Un bucle de reinicio puede tener varias causas:

• suministro de energía inestable
• adaptador de corriente defectuoso
• no se recibe dirección IP por DHCP
• configuración IP estática incorrecta
• puertos bloqueados
• patrón de firmware RED obsoleto
• código de desbloqueo incorrecto
• configuración RED dañada o incorrecta

Primero, comprobar la alimentación, los cables y DHCP. Después, revisar el patrón de firmware RED, la accesibilidad de los puertos y la configuración. Solo se debe plantear un Factory Reset si las comprobaciones anteriores no revelan la causa. Antes hay que guardar el RED ID, el Unlock Code y la configuración de la interfaz. Si faltan estos datos, la nueva autorización puede requerir la intervención de Sophos Support.

El túnel está verde, pero no fluye tráfico

Este caso es especialmente común. El RED está conectado, pero los clientes no alcanzan sistemas internos ni Internet.

Posibles causas:

• Falta una regla de firewall o está demasiado baja.
• La interfaz RED está en la zona incorrecta.
• DHCP distribuye un gateway o servidores DNS incorrectos.
• Falta el enrutamiento de retorno a la red RED.
• NAT traduce el tráfico inesperadamente.
• El etiquetado VLAN no coincide.
• Una función de seguridad bloquea el tráfico.

Orden de verificación:

1. Verificar IP del cliente, gateway y DNS.
2. Filtrar en Log Viewer por la IP de origen del cliente RED.
3. Verificar coincidencia de regla de firewall.
4. Ejecutar Packet Capture en la interfaz RED y la interfaz de destino.
5. Verificar el camino de retorno desde el sistema o red de destino.
6. Controlar NAT y enrutamiento.

Para coincidencias de reglas poco claras, consulte Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture.

Si el fallo aparece inmediatamente después de un restablecimiento con nuevo aprovisionamiento, también es relevante NC-181808. Según las notas de versión, SFOS 22.0 MR3 Build 576 del 16 de octubre de 2026 corrige un bloqueo del tráfico causado por entradas RED_DEVICE_DROP residuales. Esto no explica todos los casos de túnel en verde sin tráfico de usuarios. Guardar el momento del restablecimiento y del aprovisionamiento, el build de SFOS y los registros de RED y paquetes correspondientes a la prueba, y contrastarlos con Sophos Support si los indicios coinciden. No eliminar entradas internas por iniciativa propia ni restablecer repetidamente; tras una corrección controlada, volver a probar las mismas rutas de ida y vuelta.

Los LED verdes no descartan un bloqueo de la ruta de datos UDP. En este caso, compruebe específicamente el tráfico del túnel en 5. Device Management > 3. Advanced Shell:

tcpdump -ni any port 3410

Durante una prueba controlada de cliente, utilice también Diagnostics > Packet capture y determine si el proveedor o un dispositivo situado antes de la RED bloquea UDP 3410. Un paquete visible en una dirección no confirma todavía que funcionen las rutas de ida y vuelta; la ausencia de paquetes por sí sola no identifica el punto de bloqueo.

El tráfico VLAN no funciona

En SD-RED 60, los escenarios VLAN son posibles, pero el modo de puerto, la ID de VLAN y el modo RED deben coincidir.

La ayuda de Sophos para la resolución de errores en SFOS 22 y 23 limita expresamente el tráfico VLAN a standard/unified. Además, las VLAN también deben crearse en el dispositivo RED y los modos de los puertos LAN de la RED deben configurarse adecuadamente. Por tanto, no compruebe la asignación de VLAN únicamente en el firewall o en el switch. No deduzca las capacidades VLAN de otros modos de funcionamiento a partir de una prueba untagged correcta; compruebe el modo de funcionamiento concreto y el diseño de puertos consultando los modos de funcionamiento de RED.

Verificar:

• Las IDs de VLAN coinciden en el firewall, RED y switch.
• El puerto RED está configurado como Access, Hybrid o Tagged Trunk adecuadamente.
• El puerto del switch en la ubicación remota está correctamente etiquetado o no etiquetado.
• DHCP y DNS están planificados por VLAN.
• Existen reglas de firewall para las respectivas redes VLAN.
• El modo RED elegido admite el escenario VLAN deseado.

Para la solución de problemas, una red de prueba no etiquetada simple es útil. Si esta funciona, la causa generalmente está en la ID de VLAN, etiquetado, modo de puerto o configuración del switch.

Los puntos de acceso RED permanecen inactivos

Si los puntos de acceso RED o las funciones Wi-Fi en escenarios VLAN permanecen inactivos, la opción DHCP 234 puede ser relevante. Esto afecta principalmente a casos en los que la comunicación RED o de puntos de acceso se realiza a través de interfaces VLAN. Sophos menciona SD-RED 20 y SD-RED 60 para este escenario de punto de acceso.

Configure esta opción solo si corresponde al escenario y se conoce la IP de la interfaz del firewall que deben alcanzar los dispositivos. Elegir correctamente los modos de funcionamiento de Sophos RED explica la relación completa entre la zona Wi-Fi, la VLAN y la opción DHCP 234. La opción 234 no es la primera comprobación ante problemas generales de conexión RED.

Para este error específico de VLAN, Sophos también describe una recuperación retardada: Tras 30 reintentos, la RED puede obtener una IP de LAN del servidor DHCP y volver a aparecer como Active. Esto no demuestra que funcione la ruta VLAN deseada. Por tanto, no se limite a esperar a que aparezca Active, sino que compruebe la IP de la interfaz VLAN y la opción 234 guardada.

Solución en SFOS 23: Los siguientes pasos se aplican a puntos de acceso RED configurados en una VLAN que aparecen como Inactive después de reiniciarse y cuya VLAN no tiene configurada la opción DHCP 234:

1. Abra Network > DHCP y edite el servidor DHCP configurado para la VLAN del punto de acceso RED.
2. En DHCP options, buscar primero el código 234 y documentar el valor actual o la ausencia de la opción. No sobrescribir a ciegas una opción existente que funciona ni crear una segunda opción en conflicto. Si existe un valor, aclarar primero la asignación de VLAN e interfaz; los siguientes pasos de adición solo se aplican si falta la opción.
3. En DHCP options, establezca Options en Custom e introduzca 234 en Code.
4. En Value, introduzca la dirección IP configurada para la interfaz del punto de acceso RED conectada a esta VLAN. Este valor depende de la configuración de interfaces de su entorno; no es la IP asignada al dispositivo o a un cliente, ni una dirección pública cualquiera del firewall.
5. Guarde los cambios.

Después, compruebe la opción guardada en el servidor DHCP, incluidos el código y la IP de la interfaz. El punto de acceso RED debería recibir una dirección IP en su interfaz VLAN al cabo de poco tiempo. Verifique esta asignación y vuelva a comprobar el estado del punto de acceso RED. Si sigue como Inactive, compruebe primero que el servidor DHCP, la VLAN y la IP de la interfaz se correspondan correctamente.

Solución en SFOS 22: La guía de Sophos específica de la versión utiliza la Device Console para el mismo error de VLAN, en lugar de la entrada en WebAdmin descrita arriba. En la CLI, seleccionar 4. Device Console y, antes de cualquier cambio, consultar las vinculaciones del servidor DHCP de VLAN correcto sin modificarlas:

system dhcp dhcp-options binding show dhcpname <dhcp server name>

Sustituir <dhcp server name> por el nombre del servidor DHCP de la VLAN del punto de acceso RED. Documentar la vinculación existente para la opción 234 y su valor, o su ausencia. No sobrescribir a ciegas una vinculación que funciona ni añadir una vinculación en conflicto. Si existe un valor, aclarar primero la asignación de VLAN e interfaz. Antes de crear una vinculación, aclarar también el procedimiento de administración documentado para modificar o eliminar vinculaciones de opciones DHCP para la versión instalada. Si este procedimiento de reversión no está claro, no realizar cambios y recurrir a Sophos Support. Añadir específicamente la vinculación solo si falta la opción:

system dhcp dhcp-options binding add dhcpname <dhcp server name> optionname dhcp_magic_ip(234) value <interface ip address>

Sustituir <dhcp server name> como se indicó arriba y <interface ip address> por la IP configurada de la interfaz del punto de acceso RED conectada a la VLAN. No utilizar la IP del cliente. Después del cambio, volver a ejecutar el mismo comando de consulta system dhcp dhcp-options binding show dhcpname <dhcp server name> y comprobar la vinculación guardada y su valor. A continuación, comprobar la IP de la interfaz VLAN y el estado. No aplicar en paralelo sin control la vinculación mediante CLI de SFOS 22 y el procedimiento WebAdmin de SFOS 23; elegir la variante adecuada para la versión instalada y verificar la opción guardada.

Reversión para ambas variantes: Si la solución sigue sin surtir efecto o empeoran la asignación de direcciones VLAN o el estado, restaurar el estado inicial documentado. En SFOS 23, en el mismo servidor DHCP, en Network > DHCP > DHCP options, restablecer el valor anterior o eliminar únicamente la opción 234 recién añadida y guardar. En SFOS 22, utilizar el procedimiento de administración de vinculaciones de opciones DHCP previamente aclarado y documentado para la versión instalada: restaurar la vinculación registrada o eliminar únicamente la vinculación recién creada. No eliminar ninguna otra opción ni ningún servidor DHCP; no probar sintaxis de eliminación no confirmada. Después, volver a comprobar las opciones o vinculaciones guardadas, la IP de la interfaz VLAN y el estado del punto de acceso RED.

El aprovisionamiento offline se sobrescribe

Si un RED se aprovisionó primero en línea y luego se aprovisiona offline por USB, una configuración en línea antigua puede permanecer en el Sophos Provisioning Server. Si el RED no alcanza el firewall, puede volver a aprovisionarse en línea y sobrescribir la configuración USB.

Entonces, el RED debe aprovisionarse nuevamente offline. Además, la configuración en línea antigua debe eliminarse a través del soporte de Sophos.

Diagnóstico y comprobación operativa

Puntos de diagnóstico en el Sophos Firewall

Para problemas RED, estos puntos son útiles:

• Network > Interfaces para la interfaz RED y estado
• Administration > Device access para permisos de servicio RED
• Rules and policies > Firewall rules para tráfico desde la red RED
• Diagnostics > Packet capture para verificación de ruta
• Log viewer con eventos RED, de firewall y del sistema
• Backup & firmware > Pattern updates para el patrón de firmware RED
• Advanced Shell con tcpdump

Una conexión correcta también puede confirmarse en los registros específicos del dispositivo. En /log/red.log aparece un mensaje como New connection from ... with ID <RED ID>. En /log/red-<RED ID>.log aparecen después connected OK, pushing config y, tras una reconexión, is now re-connected. Estas líneas confirman la conexión y la transferencia de la configuración, pero no un flujo de tráfico productivo funcional. El registro completo específico del dispositivo puede contener datos de aprovisionamiento y configuración y debe depurarse antes de compartirlo.

Para archivos de registro y asignación de servicios, consulte Solución de problemas de Sophos Firewall: Servicios y registros.

Si, por el contrario, todo el firewall arranca en modo failsafe con Failed to start Red server service, no se trata de un fallo habitual de un túnel RED. El runbook de failsafe explica cómo distinguir los builds y guardar las pruebas antes de la recuperación.

Lista de verificación operativa

Antes del despliegue:

• Documentada la ID del RED y el código de desbloqueo.
• Verificada la dirección pública del firewall o FQDN.
• Verificados TCP 3400, UDP 3410 y NTP 123.
• Planificado el servicio RED y Device Access en el firewall.
• Definidas zona, DHCP, enrutamiento y reglas de firewall.
• Probado el modo VLAN si es necesario.

Después de la conexión:

• Los LEDs muestran un túnel exitoso.
• La interfaz RED está activa.
• El cliente recibe IP, gateway y DNS.
• Log Viewer muestra la regla de firewall esperada.
• Los sistemas de destino internos y la ruta a Internet funcionan como se planeó.
• El patrón de firmware está actualizado.

En operación:

• Verificar regularmente el patrón de firmware RED.
• Probar conexiones de ubicación después de actualizaciones de firewall.
• Probar los túneles RED entre firewalls por separado de los sitios SD-RED físicos.
• Comprobar, después de actualizar a SFOS 21.0 MR2 o 21.5 MR1, los efectos de la máscara /32 en los RED system hosts.
• Comparar el rendimiento RED con una referencia local, uno y cuatro flujos iPerf3 y ambos sentidos.
• Mantener 802.3az o EEE desactivado en los puertos de switch conectados directamente y volver a comprobarlo después de sustituir switches.
• Cambiar Tunnel compression y MTU solo con una prueba documentada antes y después.
• Incluir ubicaciones RED en monitoreo, respaldo y planificación de contingencias.

Preguntas frecuentes