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.

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.

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.

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

1. En la firewall, comprobar en Administration > Time si la firewall es adecuada como servidor NTP para el escenario RED. En el setup manual, el RED debe obtener una hora válida para que el TLS handshake con la firewall funcione.
2. En Network > Zones, crear una zona propia para sedes RED o usar una zona existente como VPN o WiFi. La zona LAN debería evitarse para RED, para que las reglas LAN no se apliquen involuntariamente a la sede remota.
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. Descargar el archivo de provisioning generado en la interfaz RED.
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.

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.

Los RED offline también necesitan una hora válida. O bien el RED puede alcanzar los servidores NTP de Sophos, o se planifica una Local service ACL exception rule específica para que el RED pueda comunicarse desde la zona WAN hacia la firewall. La source debe ser solo la IP conocida del RED, la destination es el puerto WAN de la firewall, el service en este escenario es HTTPS y la action Accept. Esta excepción no sustituye abrir RED de forma amplia por WAN.

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 LEDs parpadean juntos, el RED está instalando un firmware. En esta fase, no se debe apagar el dispositivo ni desconectarlo de Internet. Una actualización puede tardar varios minutos.

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

Backup & firmware > Pattern updates

Allí, el patrón de firmware RED debe estar actualizado. 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 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.

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. Durante una actualización se inventarían ambos tipos de RED y después se valida cada uno con su prueba funcional correspondiente.

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.

Hosts del sistema RED después de SFOS 21.5 MR1

Desde SFOS 21.5 MR1, los objetos de host del sistema RED reciben la máscara de subred /32 correcta. Si tales objetos se usaron anteriormente en reglas o configuraciones para más de una IP de host, el tráfico puede coincidir de manera diferente después de la actualización.

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 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?

Para el aprovisionamiento RED, el RED debe alcanzar el Sophos Provisioning Service. En muchos entornos, red.astaro.com en TCP 3400 es relevante.

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?

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, verificar suministro de energía, cables y DHCP. Luego, controlar el patrón de firmware RED, accesibilidad de puertos y configuración. Si se crea o restablece un nuevo RED, la ID del RED y el código de desbloqueo deben estar documentados previamente.

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.

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.

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.

Esta opción solo debe establecerse si el escenario concreto lo permite y está claro qué IP de interfaz de firewall deben alcanzar los dispositivos. En problemas generales de conexión RED, la opción DHCP 234 no es el primer paso.

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.

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

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.
• Verificar los efectos de /32 en hosts del sistema RED después de SFOS 21.5 MR1.
• 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