Elegir el modo de funcionamiento correcto de Sophos RED

El modo de funcionamiento de una Sophos SD-RED no es una opción secundaria. Determina quién proporciona DHCP y la puerta de enlace en la sede remota, qué tráfico pasa por el túnel RED, si el acceso a internet se inspecciona de forma centralizada y qué sigue funcionando si falla el túnel. Un túnel Site-to-Site RED entre dos Sophos Firewall es otro diseño y no utiliza estos cuatro modos de funcionamiento.

Para nuevas sucursales administradas centralmente, Standard/Unified suele ser el punto de partida más claro. Standard/Split ahorra ancho de banda del túnel, pero deja el tráfico de internet local fuera del control central. Transparent/Split integra la RED en una red existente. Manual/Split es un diseño especial de cableado y enrutamiento para mantener la autonomía del acceso local a internet, no un modo rápido convencional.

El modo de funcionamiento debe decidirse antes de configurar DHCP, las VLAN, las reglas de firewall y el despliegue. Cambiarlo posteriormente modifica la ruta de datos y requiere una ventana de mantenimiento con pruebas funcionales controladas.

Esta guía se aplica a SFOS 22.0 y a los modelos SD-RED 20 y SD-RED 60 compatibles con esta versión. RED 15/15w y RED 50 ya no se conectan a partir de SFOS 20.0 MR1. Las interfaces Firewall RED heredadas entre UTM y SFOS deben sustituirse y eliminarse antes de actualizar a SFOS 22.0; de lo contrario, se bloquean la actualización, la restauración y la importación. Desde SFOS 21.0 MR2 y 21.5 MR1, los hosts de sistema RED reciben automáticamente una máscara /32. En Hosts and services > IP host, abra Usage para cada host de sistema RED y, cuando antes se pretendía abarcar toda la subred de la interfaz, sustitúyalo en las reglas y rutas dependientes por el host IP o de red correcto. Por tanto, estas comprobaciones de migración deben formar parte del plan de cambio antes de migrar el hardware o el firewall.

Las explicaciones sobre los modos de funcionamiento, los modos de los puertos LAN y las rutas de datos WLAN se aplican a SFOS 22.0 y 23.0. Las indicaciones de migración del párrafo anterior siguen vinculadas a las versiones que se mencionan expresamente en él. Antes de cambiar de modo en producción, debe comprobarse el comportamiento en condiciones controladas en el modelo y la versión utilizados.

Los cuatro modos RED de un vistazo

Este resumen ayuda a realizar la primera elección, pero no sustituye la revisión del comportamiento ante fallos, las VLAN y la seguridad. En particular, Split no significa automáticamente fail-open y Transparent no significa automáticamente que se transmitan las etiquetas VLAN.

Standard/Unified: Todo a través de la central

En Standard/Unified, Sophos Firewall proporciona DHCP y la puerta de enlace predeterminada a través de la interfaz RED. La SD-RED reenvía todo el tráfico por el túnel cifrado, incluido el tráfico de internet de la sucursal.

Esto proporciona el máximo control central. Las reglas de firewall, las políticas web, IPS, Application Control, los informes y la salida central a internet pueden aplicarse de forma coherente en la sede principal. Al mismo tiempo, aumentan los requisitos del túnel y de la conexión WAN central, porque también el tráfico de internet habitual de la sucursal recorre dos veces la ruta entre sedes.

Si falla el túnel RED, los clientes no solo pierden el acceso a las redes internas. Como su puerta de enlace se encuentra en Sophos Firewall al otro lado del túnel, normalmente también se interrumpe el acceso a internet. Standard/Unified es adecuado cuando la seguridad central es más importante que mantener internet local durante una interrupción del túnel.

Cuándo conviene Standard/Unified

• Todo el tráfico de la sede debe inspeccionarse y registrarse centralmente.
• DHCP, el reenvío DNS, las reglas y el acceso a internet deben concentrarse en Sophos Firewall.
• La capacidad WAN central es suficiente para el tráfico de internet adicional de la sucursal.
• Se acepta que un fallo del túnel deje la sede sin conexión de forma controlada, o existe un segundo enlace RED probado.
• Es necesario transportar VLAN a través de una SD-RED 60.

Standard/Split: Redes centrales a través del túnel

Con Standard/Split, Sophos Firewall sigue siendo el servidor DHCP y la puerta de enlace predeterminada para la red proporcionada por la RED. Solo las redes de destino introducidas en Split networks pasan por el túnel. Los demás destinos, normalmente internet, salen de la sede por la conexión WAN local de la RED.

Esto descarga el túnel y la conexión a internet central. A cambio, existe un límite de seguridad claro: Sophos enmascara el tráfico de internet local en la RED, pero el firewall central no puede inspeccionarlo con sus reglas de firewall, web o IPS. Desde el punto de vista de la central, esta ruta no es tráfico de internet reenviado de forma normal.

En Split networks se utilizan redes IP. Los objetos de host FQDN no son compatibles en este punto. Los frames con etiquetas VLAN tampoco corresponden a la ruta de datos de Standard/Split. Solo la red DHCP proporcionada directamente por la RED obtiene acceso local a internet mediante este modo.

Un ejemplo de Split network: La sucursal utiliza 10.20.30.0/24 y la red de servidores necesaria de la sede central utiliza 10.10.40.0/24. Solo se introduce la red de destino central como red dividida; no es ni el rango DHCP de la sucursal ni un host FQDN. Estas redes privadas son ejemplos y deben sustituirse por las redes propias, sin solapamientos. Después se prueban por separado un servidor de esta red, un destino local fuera de la lista y un destino de Internet. Los recursos internos no incluidos en la lista no pasan a ser accesibles automáticamente a través de la sede central: siguen la ruta local restante.

Standard/Split tampoco es un diseño fail-open general. Si falla el túnel, la documentación de Sophos indica que los clientes de la red proporcionada por el firewall pierden tanto los destinos centrales como el acceso a internet. Si el acceso local a internet debe funcionar con independencia del túnel, es necesario planificar y probar otro diseño.

Cuándo conviene Standard/Split

• La sucursal solo necesita unas pocas redes claramente definidas en la central.
• La salida local a internet es intencionada y puede quedar fuera de las políticas centrales de Sophos.
• Sophos Firewall puede administrar la red remota mediante DHCP.
• No se necesita etiquetado VLAN a través del túnel RED.
• La ruta ante fallos se ha probado y no se confunde con Manual/Split.

Transparent/Split: RED en la red existente

Transparent/Split es adecuado para sedes remotas donde ya existen router, DHCP, DNS y puerta de enlace predeterminada y deben mantenerse. La RED funciona de forma transparente en la red de capa 2 existente. Solo las redes o los dominios split configurados se dirigen por el túnel a la central.

Este modo evita cambiar la puerta de enlace de los clientes. Sin embargo, la resolución de problemas es más exigente: DHCP, DNS y la ruta normal a internet siguen perteneciendo a la red local, mientras que determinados destinos se redirigen por la RED. Por eso, la prueba debe mostrar por separado qué ruta permanece local y cuál entra realmente en el túnel.

Para los nombres internos, Transparent/Split requiere además un Split DNS server, es decir, un servidor DNS en la red central que los clientes remotos puedan consultar para el dominio interno correspondiente. Un dominio dividido no es lo mismo que un host FQDN en Split network. Por ejemplo, para corp.example, la resolución mediante el servidor DNS interno previsto debe funcionar y su red debe ser accesible a través del túnel. corp.example es un marcador de posición para el dominio interno propio. Si la IP del servidor es accesible pero el nombre no, comprobar primero la respuesta DNS real, el resolvedor utilizado y la ruta hacia ese resolvedor; no ampliar indiscriminadamente la regla de firewall.

Transparent/Split no transporta frames con etiquetas VLAN. En este modo tampoco está disponible un enlace de conmutación por error 3G/4G. Para un módulo inalámbrico, el servidor DHCP remoto debe transmitir al punto de acceso la opción DHCP 234 con la dirección IP de la interfaz RED en la sede del firewall; no se trata de la dirección del AP, de una dirección de la sucursal ni de la dirección pública del firewall.

Cuándo conviene Transparent/Split

• El router existente debe seguir proporcionando DHCP, DNS y la puerta de enlace predeterminada.
• Solo determinadas redes o dominios centrales deben ser accesibles a través de la RED.
• La RED puede integrarse correctamente en línea en la red existente.
• La sede no necesita transportar etiquetas VLAN por esta ruta RED.
• El tráfico local y el tráfico del túnel se pueden comprobar por separado con Packet Capture y pruebas contra destinos reales.

Manual/Split: Puerta de enlace local con rutas estáticas

En una SD-RED, Manual/Split describe principalmente un diseño de red creado manualmente de forma deliberada. Los lados WAN y LAN de la RED se integran en la infraestructura existente de la sede para que el router existente siga siendo la puerta de enlace predeterminada. Ese router recibe rutas estáticas hacia la RED para las redes centrales.

La ventaja es la autonomía local: el acceso normal a internet puede continuar incluso si falla el túnel RED o la propia RED. La contrapartida es una mayor planificación. Las rutas de retorno, las rutas estáticas, el comportamiento ARP y el cableado físico deben ser exactos. Un siguiente salto incorrecto puede hacer que el tráfico central evite el túnel o termine en una ruta sin salida durante un fallo.

Sophos describe para ello un despliegue físico manual y una configuración RED basada en el esquema de Standard/Unified, mientras que la puerta de enlace existente y las rutas estáticas determinan la división. Por tanto, la denominación no debe tratarse como un interruptor independiente y autoexplicativo.

El orden físico es importante: Primero se conecta el puerto WAN de la RED al mismo switch LAN al que están conectados los clientes de la ubicación. Solo después de que la RED haya recibido su configuración Standard/Unified se conecta también un puerto LAN de la RED a este switch. La RED no se coloca en línea delante de toda la LAN de la ubicación. Antes de la segunda conexión, deben aclararse la responsabilidad DHCP existente, la dirección de la RED como Next Hop y la asignación de puertos del switch; un servidor DHCP adicional y no coordinado no debe asumir la configuración de los clientes. Se trata de un diseño de enrutamiento planificado, no de una recomendación de conectar WAN y LAN entre sí en cualquier RED.

Ejemplo de plan de enrutamiento: La puerta de enlace existente de la ubicación 10.20.30.1 sigue siendo la puerta de enlace de los clientes; la dirección LAN de la RED prevista 10.20.30.2 sirve como Next Hop para la red central 10.10.40.0/24. Todos los valores son ejemplos ajustables; el Next Hop y el plan de direccionamiento deben corresponder a la interfaz RED realmente aprovisionada y no deben entrar en conflicto con dispositivos existentes. La sede central necesita la ruta de retorno a 10.20.30.0/24. Antes del despliegue se comprueban la resolución ARP hacia el Next Hop, un destino central y el acceso local a Internet. En caso de fallo del túnel o de la RED, la ruta de Internet a través de 10.20.30.1 debe mantenerse, mientras que el destino central deja de estar disponible según lo previsto. Si se observa un comportamiento DHCP, ARP o de enrutamiento inesperado, desconectar la conexión LAN de la RED añadida más recientemente y restaurar el estado inicial documentado del cableado y las rutas.

Manual/Split solo debe utilizarse en un diseño documentado con:

• una puerta de enlace local alternativa
• rutas estáticas para cada red de destino central
• una ruta de retorno comprobada desde la central
• un acceso de administración independiente
• pruebas con el túnel activo, el túnel desconectado y la RED apagada

Opciones de Layer 2 y ampliación

Usar varias RED como una red bridge compartida

Un Bridged RED setup no es un quinto modo de funcionamiento. En este diseño se agrupan al menos dos interfaces RED existentes en un bridge de Sophos Firewall. Las redes RED remotas se comportan entonces como una LAN compartida, mientras que las reglas de firewall pueden seguir limitando el tráfico entre las sedes RED.

El bridge se crea en Network > Interfaces > Add interface > Add bridge. Se especifican un nombre claro y la interfaz bridge, y se eligen las interfaces RED necesarias como Member interfaces con sus zonas. Antes deben coordinarse el plan de direccionamiento, la responsabilidad de DHCP y todos los miembros del bridge; varios servidores DHCP sin coordinar o direcciones IP duplicadas actuarían entonces en la misma red de Layer 2.

Recomendamos este diseño solo cuando varias sucursales necesiten realmente la misma broadcast domain. Para sedes normales, las redes RED enrutadas son más fáciles de aislar, supervisar y modificar de forma independiente. Después de guardar se comprueban DHCP, ARP, el tráfico entre sedes, la regla de firewall responsable y un tráfico bloqueado de forma intencionada. Un túnel RED en verde confirma los túneles individuales, pero no el bridge ni sus reglas.

Un segundo enlace y un segundo firewall no son modos de funcionamiento

La configuración RED también puede incluir un segundo endpoint de firewall y, según el modelo y el modo, un segundo enlace. Estas opciones complementan la ruta elegida, pero no la sustituyen.

Un segundo endpoint de firewall puede utilizarse para failover o balanceo de carga. Un segundo enlace puede proteger el establecimiento del túnel. Si ambos enlaces están configurados como Static, las direcciones IP de sus servidores DNS deben ser diferentes; no es necesario usar proveedores DNS distintos. La RED comprueba la entrada de ruta del primer enlace para resolver DNS. Si esa puerta de enlace no responde, considera inaccesible la IP del servidor DNS y no vuelve a intentar acceder a esa misma dirección IP por el segundo enlace.

Para el segundo extremo de firewall se establecen 2nd firewall IP/hostname y Use 2nd IP/hostname for; 2nd uplink connection y 2nd uplink mode controlan una segunda conexión WAN. Failover utiliza la segunda ruta cuando falla la primera; Load balancing distribuye el tráfico entre ambas. Por tanto, Load balancing no sustituye una ruta de fallo probada. 3G/UMTS failover requiere un adaptador USB compatible y los parámetros de red móvil del proveedor. El firmware RED 2.0.018 no admite el D-Link DWM-222; una conexión móvil de respaldo prevista debe ser compatible con el firmware y el hardware reales.

Respaldo móvil de la RED: correspondencia de los valores del proveedor

Si el modelo RED utilizado, el modo de funcionamiento, el firmware RED y el adaptador USB admiten este respaldo, se edita la interfaz RED correspondiente en Network > Interfaces y se comprueban sus ajustes de 3G/UMTS failover. En Transparent/Split, esta conmutación por error móvil no está disponible. La siguiente correspondencia explica los parámetros RED de la documentación de la API para SFOS 22.0 y 23.0; no es un ejemplo XML ejecutable ni una garantía de compatibilidad actual con conexiones móviles para SD-RED 20 o 60. Los nombres de modelos antiguos y las opciones móviles del ejemplo de la API no sustituyen una comprobación de compatibilidad de la combinación concreta.

• UMTS3GFailover: activación del respaldo móvil de la RED; la documentación indica Enable y Disable, con Disable como valor predeterminado. Activarlo solo después de comprobar la compatibilidad.
• Username y Password: nombre de usuario y contraseña para el acceso móvil según el proveedor, no las credenciales del administrador del firewall. Introducir únicamente las credenciales exigidas por el proveedor; no utilizar valores predeterminados inventados.
• Pin: PIN de la tarjeta SIM utilizada, si tiene un PIN configurado. No confundirlo con el código de desbloqueo de la RED y, si se desconoce el PIN, no arriesgarse a bloquear la SIM mediante intentos repetidos de adivinarlo.
• MobileNetwork: tipo de red móvil. Los valores documentados son GSM y CDMA, con GSM como valor predeterminado; la elección debe corresponder a la combinación de proveedor y adaptador realmente compatible. Estas opciones antiguas no demuestran la disponibilidad actual de la red.
• APN: Access Point Name del proveedor para esa SIM o tarifa concreta. No es la dirección pública del firewall ni se deriva del nombre del túnel RED.
• DialString: cadena de marcación del proveedor para la combinación compatible. No adoptar de forma indiscriminada el valor de ejemplo o predeterminado documentado: no existe aquí una cadena de marcación universal para todos los proveedores y módems.

Estos valores corresponden a la RED de la sede remota: en el ejemplo documentado de la API, los campos del proveedor se encuentran en UplinkSettings / FailOverSettings. En cambio, Cellular WAN en Sophos Firewall configura la conexión móvil del propio firewall; los campos del proveedor con el mismo nombre que aparecen allí no configuran un respaldo de la RED. Esta correspondencia es una ayuda para introducir los datos, no una recomendación de utilizar un payload de API o un serializador sin verificar.

Antes de realizar un cambio, guardar el estado del enlace RED que funciona y del ajuste de conmutación por error existente, y asegurar una ruta de administración independiente. Conservar la contraseña del proveedor, el PIN de la SIM y los archivos de aprovisionamiento únicamente de forma protegida y con acceso restringido; no copiarlos en capturas de pantalla, tickets ni ejemplos de configuración. Si no se ha confirmado la compatibilidad del hardware y el firmware o falta un valor del proveedor, no activar el respaldo basándose en suposiciones, sino aclararlo con el proveedor o con Sophos Support. Después de un cambio autorizado, se aplican las comprobaciones independientes del enlace y de la ruta que se indican más abajo; si falla la validación, restaurar los ajustes anteriores de la RED.

Las pruebas deben mantenerse separadas:

1. Primero, el modo RED seleccionado debe funcionar correctamente por el enlace principal.
2. Después se prueba un failover controlado del enlace.
3. A continuación se vuelven a comprobar el estado de RED, DHCP, los destinos centrales y la ruta de internet.
4. En entornos HA se añade una prueba independiente de failover del firewall; el túnel RED necesita tiempo para restablecerse tras el cambio de rol.

Un estado verde del túnel no demuestra por sí solo ni que la ruta de internet sea correcta ni que funcionen las políticas de seguridad.

VLAN y modos de puerto LAN en SD-RED 60

La SD-RED 60 puede transportar VLAN por el túnel, pero solo en Standard/Unified. Además, en cada puerto LAN se define cómo trata la RED los frames etiquetados y sin etiquetar.

• Tagged: Solo se reenvían con etiqueta las VLAN configuradas. Las VLAN no configuradas y los frames sin etiqueta se descartan. Se pueden introducir hasta 64 VLAN ID por puerto.
• Untagged, drop tagged: Los frames sin etiqueta se asignan a la VLAN configurada; los que ya están etiquetados se descartan. Esto corresponde a un puerto de acceso controlado.
• Disabled: El puerto LAN descarta el tráfico.
• Untagged: Los frames sin etiqueta reciben la VLAN ID configurada y los frames ya etiquetados se reenvían sin cambios. Solo se admite una configuración VLAN por puerto. Se trata de un puerto híbrido, no de un trunk configurable libremente; las VLAN permitidas deben seguir controlándose en el switch conectado y en el firewall.

Las asignaciones anteriores describen principalmente las tramas que llegan al puerto LAN de la RED. Para el sentido contrario, el modo LAN Untagged describe la salida de la VLAN-ID configurada sin etiqueta, para poder conectar un dispositivo final sin compatibilidad con VLAN. Para ello se prevé un ID en LAN VID(s); con Tagged se introducen varios ID separados por comas, por ejemplo 10,20. Los números son ejemplos para las VLAN propias y deben coincidir con el switch y el firewall.

Las descripciones de los modos LAN no son inequívocas en todos los sentidos: La tabla de tráfico describe el descarte de tramas entrantes etiquetadas en el puerto de acceso, mientras que el texto de Untagged, drop tagged describe de forma contradictoria la salida de las tramas VLAN correspondientes. Aquí no se deduce de ello ningún efecto garantizado de salida o aislamiento. Antes del uso en producción, se prueban en ambos sentidos las VLAN permitidas y no permitidas, así como las tramas sin etiqueta, en el modelo y la versión realmente utilizados. Antes, guardar el modo de puerto, LAN VID(s) y la configuración del switch, y prever una ruta de administración independiente. Si se produce un reenvío inesperado, retirar el puerto de prueba de la red de producción, restaurar los ajustes anteriores de puerto y VLAN y volver a comprobar; no improvisar permitiendo indiscriminadamente las VLAN.

Si una VLAN de invitados situada detrás de la RED debe acceder localmente a Internet, Standard/Split no sustituye este diseño de VLAN. Una arquitectura posible es un Sophos Firewall adicional en una XGS Appliance de clase de escritorio en la ubicación, que enrute este tráfico a través de la puerta de enlace local y lo proteja allí. Se trata de una ruta de enrutamiento y seguridad independiente y debe planificarse con reglas separadas, rutas de retorno y una prueba negativa de invitados a la red interna; el modo de funcionamiento de la RED por sí solo no proporciona esta separación.

Sophos Firewall necesita una interfaz VLAN correspondiente sobre la interfaz RED para cada VLAN utilizada. VLAN ID, red IP, DHCP, modo de puerto RED y configuración del switch deben coincidir exactamente. El procedimiento completo se describe en Configurar y probar una VLAN en Sophos Firewall.

Planificar por separado el comportamiento inalámbrico

Antes de configurar un módulo inalámbrico, debe existir una interfaz RED con una dirección IP y la resolución DNS debe funcionar en esa interfaz concreta. Un módulo inalámbrico opcional de la SD-RED 20 o 60 puede utilizar tres rutas de datos diferentes:

• Separate zone: El tráfico inalámbrico llega cifrado al firewall mediante VXLAN, con independencia del modo RED. Sophos Firewall debe permitir expresamente el tráfico de zona separada para la interfaz RED; esto no implica una autorización general hacia WAN.
• Bridge to AP LAN: La red inalámbrica se puentea con la LAN local del punto de acceso.
• Bridge to VLAN: La red inalámbrica se asigna a una VLAN; el comportamiento exacto depende del modo RED y de la configuración VLAN.

En Standard/Unified y Standard/Split, debe funcionar un servidor DHCP correctamente configurado en la interfaz RED. En el escenario inalámbrico documentado de Transparent/Split, la red remota proporciona DHCP y DNS, y la interfaz RED debe obtener su dirección IP del servidor DHCP remoto. Ese servidor debe proporcionar la opción 234 con la dirección IP de la interfaz RED en la sede del firewall. Sin esta opción, el valor de respaldo documentado es 1.2.3.4: es una pista de diagnóstico de que falta la opción, no una dirección que deba configurarse en producción. Por ello, la configuración inalámbrica, el modo de puerto LAN y el modo RED deben validarse como un diseño conjunto y no como tres menús independientes.

Bridge to VLAN no convierte un modo split en transporte VLAN general. En Standard/Split, los clientes inalámbricos pueden acceder a hosts locales con la misma etiqueta y, si existe sobre la interfaz RED, a la interfaz VLAN del extremo del túnel. No pueden acceder a las redes split configuradas porque la RED solo las enruta para paquetes sin etiqueta. En Transparent/Split, la misma VLAN se extiende localmente por los puertos LAN 1–4 y el puerto WAN; las redes split tampoco son accesibles por esta ruta inalámbrica.

Con Bridge to AP LAN, el puente local incluye los puertos LAN 1–4. Los clientes WLAN solo pueden acceder a la interfaz del extremo del túnel RED en el firewall si se permite el tráfico desde la red RED hacia esa interfaz. Con Bridge to VLAN en Standard/Unified, los clientes WLAN reciben la VLAN-ID configurada y pueden acceder a los dispositivos de la misma VLAN-ID en los puertos LAN que estén permitidos según corresponda, así como a la interfaz VLAN correspondiente en el extremo del túnel del firewall. Un inicio de sesión WLAN correcto todavía no confirma estos destinos; se comprueban individualmente con un cliente de prueba WLAN.

Configurar y probar de forma segura el modo

Requisitos previos y campos exactos

Primero se activa el servicio en System services > RED. Después se crea o edita el dispositivo en Network > Interfaces > Add interface > Add RED. Los campos clave son RED ID, Unlock code, Firewall IP/hostname, Device deployment, Uplink connection, RED operation mode, RED IP, Zone, Configure DHCP, RED DHCP range y, en los modos split, Split network.

RED ID figura en el dispositivo y en el embalaje; Tunnel ID debe estar libre en ambos dispositivos implicados. Firewall IP/hostname se refiere a la dirección pública accesible o al nombre público del extremo del túnel, no a cualquier dirección interna de administración. En el registro inicial, Unlock code se deja vacío. Para una RED ya utilizada o para cambiar a otro firewall, se debe guardar y utilizar el código existente. La dirección de contacto en System services > RED debe ser correcta: al eliminar una interfaz, el código se muestra y se envía a esa dirección. Si falta el código, recurrir a Sophos Support y no eliminar precipitadamente la interfaz que funciona.

Con el despliegue automático, la RED debe arrancar al menos una vez en una red con DHCP y acceso a internet para descargar su configuración. Un uplink estático requiere despliegue manual mediante memoria USB. La ruta debe permitir TCP 3400, UDP 3410 y NTP 123: la configuración y el canal de control usan TCP 3400 y el túnel de datos de Layer 2 usa UDP 3410. Sin una dirección WAN por DHCP durante el despliegue automático, el dispositivo se reinicia repetidamente.

Durante el aprovisionamiento automático, el servicio de aprovisionamiento guarda la dirección del firewall, los parámetros WAN y de red móvil, el modo de funcionamiento y el Unlock Code. La RED resuelve red.astaro.com y descarga su configuración del servicio de aprovisionamiento. Una RED que funciona no consulta continuamente este servicio; si su configuración no funciona, busca allí instrucciones actualizadas. Por tanto, la accesibilidad del servicio de aprovisionamiento y la del extremo real del túnel del firewall se comprueban por separado. Para el aprovisionamiento por USB, en Network > Interfaces, abrir el Menu de la interfaz RED correcta, seleccionar Download provisioning file y copiar el archivo actual al directorio raíz de la memoria USB. La comprobación detallada del arranque y de los tiempos figura en el procedimiento de configuración enlazado.

Recomendamos una zona dedicada de tipo LAN o DMZ en lugar de la zona LAN general. Si el cambio de RED IP mueve la interfaz RED a una subred que ya no contiene el RED DHCP range existente, SFOS desactiva el servidor DHCP de RED. Esta dependencia debe constar en el plan de cambio.

Después de cambiar RED IP, ajustar el servidor DHCP existente en Network > DHCP o crear un servidor nuevo para la nueva red. Comprobar no solo el rango dinámico, sino también Dynamic IP lease, Static IP MAC mapping, la puerta de enlace, DNS y otras opciones. Una prueba de cliente con la concesión renovada debe mostrar los valores realmente nuevos antes de volver a autorizar el uso de la sucursal.

Alinear enrutamiento, reglas de firewall y NAT con el modo

Las reglas se crean en Rules and policies > Firewall rules entre la zona RED y únicamente las zonas de destino necesarias. Any para redes y servicios solo resulta adecuado en una prueba funcional limitada en el tiempo; en producción se restringen orígenes, destinos y servicios a la necesidad real. En Standard/Unified, una regla RED-to-LAN no sustituye a una regla RED-to-WAN; la ruta central hacia internet también necesita una regla SNAT adecuada.

En Standard/Split, la propia RED enmascara el tráfico de internet local con su dirección pública. Esta ruta no aparece en el firewall central y no necesita allí una regla WAN SNAT. El tráfico del túnel hacia la central sí necesita rutas de ida y vuelta correctas y reglas coincidentes; las reglas NAT existentes no deben traducir involuntariamente sus redes de origen o destino. En Manual/Split, se prueban como una unidad las rutas estáticas del gateway de la sucursal y la ruta de retorno en la central.

No utilizar las opciones adicionales para corregir el modo

MAC filtering type distingue entre Allow list y Block list; el número máximo de direcciones MAC depende del modelo de dispositivo. Los filtros MAC no sustituyen las reglas de firewall ni corrigen un enrutamiento incorrecto. En PoE settings, se puede activar uno o ambos puertos PoE en SD-RED 60; PoE afecta a la alimentación eléctrica, no al modo del túnel.

Remote IP assignment, en Advanced settings, asigna una dirección mediante DHCP o Static al puente con el túnel RED en el lado WAN. Esta opción solo está prevista para los casos en que los dispositivos situados detrás de la RED no respondan a las solicitudes ARP. Antes de realizar un cambio, documentar los resultados de ARP y el valor anterior; después, repetir exactamente la misma prueba de destino y restaurar el valor anterior si no hay mejora.

Tunnel compression y MTU tampoco modifican la selección de redes divididas. La compresión puede ayudar con datos adecuados y conexiones lentas; MTU designa el tamaño máximo del paquete en bytes. No adoptar un valor general sin resultados que lo justifiquen. Las pruebas controladas antes y después, las rutas de retorno y la recomendación de desactivar 802.3az en los switches conectados directamente se describen en Configurar Sophos SD-RED y solucionar problemas.

Cambio de modo y reversión que conserva el estado

Antes del cambio se registran la configuración RED completa, RED IP, zona, rango y opciones DHCP, redes split, rutas estáticas, reglas de firewall y NAT, interfaces VLAN, modos de puerto LAN y una vía de administración independiente. También se guarda la última configuración funcional del router y de los puertos del switch implicados. Se modifica una capa cada vez: primero modo y red RED; después DHCP, enrutamiento y reglas; por último VLAN o red inalámbrica.

Si la validación falla, no se añaden más cambios en paralelo. Se restauran RED operation mode, RED IP, zona, DHCP y redes split a los valores registrados, se reponen las rutas y reglas anteriores y se renueva la concesión de un cliente de prueba. La reversión termina cuando gateway, DNS, destino central, ruta de internet y Rule ID vuelven a coincidir con el estado inicial. Manual/Split también exige restaurar el cableado original.

El procedimiento práctico con provisioning, LED, reglas, rendimiento y resolución de problemas se describe en Configurar y solucionar problemas de Sophos SD-RED. El modo requiere además validar la ruta real:

1. Un cliente recibe la dirección IP esperada, los servidores DNS y la puerta de enlace correcta.
2. Una red de destino definida en la central es accesible.
3. Log Viewer o Packet Capture muestra la Firewall Rule ID esperada y la ruta RED.
4. Una prueba de internet muestra la salida pública esperada, central o local.
5. Una aplicación permitida y otra bloqueada confirman dónde se aplica realmente la política de seguridad.
6. Las VLAN y las redes inalámbricas se prueban individualmente, no solo con un ping general.
7. Un fallo planificado del túnel o del enlace confirma el comportamiento documentado.

Si el túnel está verde pero la ruta sigue sin estar clara, resulta útil Utilizar correctamente Packet Capture en Sophos Firewall. En sedes productivas no se deben cambiar simultáneamente el modo, DHCP, las VLAN y las reglas de firewall. De lo contrario, será difícil asignar un fallo a una capa concreta.

Resolver problemas por ruta de datos

• La RED se reinicia repetidamente o no establece el túnel: comprobar primero DHCP en la WAN, DNS y acceso a internet en la sucursal; después TCP 3400, UDP 3410 y sincronización NTP 123. En un despliegue manual sin conexión, una hora incorrecta puede impedir el handshake TLS.
• El túnel está verde, pero no pasa tráfico: buscar la Firewall Rule ID prevista en Log Viewer y revisar después las rutas y reglas NAT para el par origen/destino exacto. En Advanced Shell, la captura de solo lectura documentada por Sophos tcpdump -ni any port 3410 muestra si el tráfico RED llega al firewall. No demuestra que una regla lo permita ni que los datos sigan la ruta correcta; después se ejecuta Packet Capture filtrando por cliente y destino.
• Solo fallan los destinos split: confirmar que la red de destino completa figura en Split network. Los hosts FQDN no son compatibles. En Transparent/Split se prueba aparte la ruta DNS local o split DNS.
• Solo falla el tráfico VLAN: comprobar primero el modo. SD-RED 60 solo transporta VLAN por el túnel en Standard/Unified. Después se comparan VLAN ID, interfaz VLAN sobre la interfaz RED, modo de puerto LAN, etiquetado del switch, DHCP y regla específica de la VLAN.
• Se ha producido un failover de HA: SFOS documenta un retraso de reconexión que varía según el número de interfaces y otros ajustes. Se espera a que el túnel vuelva a establecerse y se repite toda la prueba de ruta sin cambiar a la vez los parámetros RED.

Errores habituales de interpretación

Split no significa automáticamente internet durante una interrupción del túnel

Standard/Split utiliza salida local a internet, pero los clientes siguen dependiendo de la red RED proporcionada por el firewall. Sophos también documenta allí la pérdida del acceso a internet si falla el túnel. Manual/Split es el diseño independiente para una puerta de enlace local existente.

Transparent no significa passthrough arbitrario de capa 2

Transparent/Split integra la RED en una red existente, pero no transporta frames con etiquetas VLAN por esta ruta. DHCP, DNS y las opciones inalámbricas también deben planificarse de forma consciente.

Un túnel verde no demuestra que el modo sea correcto

El estado del túnel confirma la conexión con el firewall. Solo las pruebas de DHCP, enrutamiento, internet, reglas y fallos muestran si el modo seleccionado corresponde al diseño previsto.