Planificar correctamente zonas e interfaces en Sophos Firewall

Una zona agrupa interfaces con un nivel de confianza similar. Una interfaz es una conexión física o virtual, como Port1, una interfaz VLAN, LAG, RED o XFRM. Cada interfaz vinculada pertenece exactamente a una zona; los puertos físicos también pueden permanecer sin vincular.

Importante: Una zona no permite tráfico automáticamente. Incluso entre dos interfaces de la zona LAN se necesita una regla de firewall LAN-to-LAN adecuada. El acceso al propio firewall, por ejemplo a WebAdmin, SSH o DNS, se controla además mediante Device Access.

Configurar zonas e interfaces directamente

Crear una zona

En Network > Zones > Add se crea una zona personalizada en cuatro pasos:

1. Asignar un nombre claro, por ejemplo Server, Management, Guest o IoT.
2. Seleccionar LAN o DMZ como Type.
3. En Device Access, permitir solo los servicios locales del firewall que sean realmente necesarios desde esta zona.
4. Guardar la zona.

A continuación, la zona debe aparecer en Network > Zones y estar disponible como Source zone o Destination zone en una regla de firewall. El tráfico de producción solo utiliza la zona cuando se le ha asignado al menos una interfaz.

Las zonas personalizadas solo pueden crearse con el tipo LAN o DMZ. No es posible crear zonas WAN o VPN adicionales. SFOS asigna automáticamente las interfaces VPN a la zona VPN. El número máximo de zonas depende de la versión: SFOS 22.0 permite hasta 100 zonas y SFOS 23.0 hasta 248 zonas.

Configurar una interfaz física

El número de puertos físicos disponibles depende del modelo del appliance. Por tanto, al planificar, comprobar primero qué conexiones ofrece el dispositivo concreto; las interfaces virtuales no sustituyen los puertos físicos adicionales que puedan necesitarse.

Una interfaz existente se edita en Network > Interfaces mediante Edit interface:

1. Asignar un Name descriptivo de 58 caracteres como máximo, por ejemplo Core Switch Trunk o MPLS Provider.
2. Seleccionar la Network zone adecuada.
3. Configurar IPv4 y, si es necesario, IPv6.
4. En interfaces WAN, comprobar el gateway y, cuando corresponda, MTU y MSS.
5. Guardar la interfaz y comprobar después el estado del enlace, el estado del gateway y Log Viewer.

La zona WAN está prevista para conexiones con default gateway. Las interfaces internas suelen utilizar direccionamiento estático; las interfaces físicas ofrecen los métodos Static, DHCP y PPPoE para IPv4. Los procedimientos de configuración de campos que se describen a continuación distinguen estos métodos. Los campos de gateway indicados en ellos no justifican por sí solos asignar una interfaz interna a la zona WAN: la zona, el direccionamiento y el routing deben ajustarse al diseño de la red y al formulario que se muestre realmente.

Si la interfaz física ya tiene una VLAN, SFOS no permite cambiar la asignación IPv4 de Static a DHCP o PPPoE. En IPv6 también se bloquea el cambio de Static a DHCP o Delegated. Antes del cambio, registrar las dependencias de las VLAN en Object usage. A continuación, trasladar las interfaces VLAN afectadas a otra interfaz principal o eliminarlas durante una ventana de mantenimiento. Solo entonces se cambia el método de asignación; después se restaura la configuración de las VLAN y se comprueba la conectividad.

IPv4 en el puerto físico: Static o DHCP

⚠️ Antes de cambiar una dirección o un método de asignación, ejecutar Object usage > Refresh, documentar la dirección, la máscara, la zona y el gateway actuales, y preparar un backup, una ventana de mantenimiento y un acceso administrativo independiente. El cambio puede interrumpir las rutas actuales de gestión y de datos. Gestionar primero las dependencias de VLAN existentes como se ha descrito arriba. La vía de recuperación por consola que se explica más adelante no sustituye la configuración normal mediante WebAdmin.

Static: introducir valores IPv4 fijos

1. En Network > Interfaces, abrir el puerto físico correcto mediante Menu > Edit interface y comprobar Hardware. Esta conexión física no puede cambiarse aquí.
2. Seleccionar IPv4 configuration y elegir el método de asignación Static.
3. Introducir la dirección IPv4 prevista para esta interfaz. Si es necesario, adaptar la máscara de subred a la red planificada.
4. Introducir Gateway name y Gateway IP address según el formulario mostrado y los valores autorizados de la red o del proveedor. El nombre sirve para identificar el gateway de forma inequívoca; la IP del gateway es la dirección del equipo remoto previsto, no una dirección adicional del firewall.
5. Comparar de nuevo los valores y el ID del puerto, y guardar con Save. Después, comprobar la IP y la máscara guardadas, el enlace, el estado del gateway cuando corresponda, el routing, DNS, Device Access y las rutas reales de datos y de gestión.

Una conexión WAN estática puramente ilustrativa podría utilizar la dirección IPv4 192.0.2.2, la máscara 255.255.255.0, Gateway name ISP-Static y Gateway IP address 192.0.2.1. Estas direcciones pertenecen a una red reservada para documentación y no son valores de un proveedor para producción. Sustituir la dirección, la máscara y el gateway por los datos correspondientes de la propia conexión, facilitados por el proveedor; elegir un nombre que permita identificar la línea durante su operación.

DHCP: distinguir la obtención dinámica de los campos documentados

1. Abrir el puerto físico en Network > Interfaces > Menu > Edit interface, comprobar Hardware y la zona, y seleccionar IPv4 configuration.
2. Elegir DHCP. Este método obtiene la dirección de la interfaz de un servidor DHCP; no configura un servidor DHCP para los clientes.
3. El procedimiento documentado para los campos de DHCP también indica que se introduzca una dirección IPv4, que se cambie opcionalmente la máscara de subred y que se completen Gateway name y Gateway IP address. Sin embargo, la descripción no explica cómo interactúan estos datos con la dirección obtenida del servidor DHCP. No deducir de ello una dirección de sustitución manual, un mecanismo de fallback ni una sobrescritura del lease DHCP.
4. Antes de guardar, comprobar qué campos son realmente visibles o editables en el build instalado y contrastarlos con la configuración DHCP o del proveedor autorizada. No copiar valores estáticos de ejemplo en los campos DHCP. Si la función de un campo obligatorio no está clara, no guardar el cambio y aclararla con el proveedor o con soporte.
5. Una vez aclarada la configuración, guardar con Save y comprobar que se obtiene una dirección adecuada. Connecting significa que todavía se está obteniendo un lease; si el estado persiste, investigar primero el enlace, la accesibilidad del servidor DHCP y los requisitos del proveedor. A continuación, comprobar la IP, la máscara, el gateway, DNS, el routing y las rutas reales de gestión y de datos.

Si después de alguno de estos cambios no está disponible la ruta esperada, restaurar el método original documentado y sus valores mediante el acceso independiente, y volver a probar. PPPoE, en cambio, utiliza las credenciales del proveedor; su procedimiento completo se describe en Configurar y comprobar una WAN PPPoE.

IPv6 en el puerto físico: método y modo de recepción

En IPv6 configuration, las interfaces WAN ofrecen Static o DHCP; las interfaces internas ofrecen Static, DHCP o Delegated. Delegated utiliza un prefijo delegado por el proveedor para las interfaces internas. IPv6 Prefix Delegation en Sophos Firewall explica el procedimiento completo con DHCP en la WAN, Upstream Interface y distribución interna. Esta es una tarea independiente y no sustituye la configuración estática ni la selección del modo de recepción que se describe a continuación.

Static: dirección IPv6, prefijo y campos de gateway

1. Abrir el puerto físico en Network > Interfaces > Menu > Edit interface y seleccionar IPv6 configuration.
2. Elegir Static. Las direcciones IPv6 estáticas están previstas tanto para las interfaces WAN como para las internas.
3. Introducir la dirección IPv6 planificada y, si es necesario, adaptar el prefijo a la red asignada.
4. Completar los campos Gateway name y Gateway IP address indicados en el procedimiento Static según el formulario que se muestre realmente y el diseño de la red. Las instrucciones generales de Static también mencionan estos campos en el apartado dedicado a las interfaces WAN e internas; no deducir de ello que sea obligatorio un default gateway interno ni que estos campos estén siempre limitados a WAN. Aclarar cualquier campo obligatorio confuso o inesperado antes de realizar un cambio en producción.
5. Guardar con Save y comprobar la dirección IPv6 y el prefijo guardados, el gateway cuando corresponda, el routing IPv6, DNS y las conexiones permitidas. Mantener el acceso administrativo independiente; si la ruta es incorrecta, restaurar los valores IPv6 documentados previamente.

Las medidas de seguridad previas al procedimiento IPv4 también se aplican a IPv6: documentar el método y los valores anteriores, comprobar las dependencias de VLAN y no utilizar la ruta de gestión actual como única vía de recuperación.

DHCPv6: Auto, Manual y Stateless

Después de seleccionar DHCP en IPv6 configuration, Mode determina cómo recibe el propio firewall la dirección de su interfaz. No es el mismo ajuste que un servidor Router Advertisement para clientes internos:

• Auto: La dirección de la interfaz se asigna automáticamente según el método de configuración utilizado, que puede ser DHCP only o Stateless. No deducir de ello una regla fija de selección que no esté documentada aquí.
• Manual > DHCP only: El firewall asigna a la interfaz la dirección y los demás parámetros proporcionados por el servidor DHCPv6.
• Manual > Stateless: El firewall genera la dirección de la interfaz mediante Stateless Address Auto-Configuration (SLAAC), de acuerdo con los flags Managed u Other (M/O) anunciados en los mensajes Router Advertisement. Accept other configuration from DHCP permite obtener parámetros adicionales del servidor DHCPv6. Esto no convierte el modo de recepción en DHCP only.

La función opcional DHCP rapid commit utiliza un intercambio de dos mensajes (solicit y reply) en lugar de cuatro (solicit, advertise, request y reply). Actívala solo si Rapid Commit también está activado en el servidor DHCPv6 y es compatible con la configuración aprobada. No es una solución general para los problemas de velocidad.

El procedimiento DHCPv6 incluye Gateway name y Gateway IP address. Sin embargo, cuando Mode está configurado como Manual y Stateless, no se puede establecer Gateway IP address. Esta restricción corresponde al modo Stateless y no debe aplicarse a Manual > DHCP only. Antes de guardar, contrastar el modo de recepción y los campos de gateway con el diseño RA/DHCPv6 previsto y el formulario visible; no forzar una IP de gateway si el modo seleccionado no la permite.

Después de Save, comprobar la dirección IPv6 realmente asignada, el prefijo y los demás parámetros, así como el routing, DNS y una ruta de datos IPv6 permitida. Si la dirección es incorrecta o no se obtiene ninguna, comparar primero con el equipo remoto el modo seleccionado, los flags RA recibidos y la accesibilidad del servidor DHCPv6; no cambiar de modo sin comprobarlo previamente. Si se interrumpe la ruta de gestión, restaurar la configuración anterior mediante el acceso independiente.

Ajustar la configuración de puertos y enlaces

En Advanced settings, se ajustan Link mode, Auto-negotiation for media type, Forward Error Correction (FEC) según el modelo, MTU y MSS para que coincidan con el equipo remoto. En puertos de 25, 50 y 100 Gbit/s, primero se guarda Link mode, se vuelve a abrir la interfaz y después se carga la configuración recomendada. En XGS 2100, 2300, 3100 y 3300, todos los puertos SFP+ de los módulos FleXi Port deben estar configurados con la misma velocidad. Configurar interfaces breakout y ajustes de puertos describe el procedimiento completo con Show recommended settings, Load recommended configuration, los dos pasos de guardado y la diferencia en la visualización para otros puertos, incluidos los de 40 Gbit/s.

SFOS no admite marcado DSCP para el tráfico DHCP y ARP que genera el propio firewall, incluso cuando funciona como cliente, relay o servidor DHCP. Por tanto, ninguna política debe depender de la priorización basada en DSCP para estos paquetes. Esta restricción afecta a DSCP; no significa que se descarte cualquier otra forma posible de priorización.

En Advanced settings > Interface settings, Use default MAC address utiliza la MAC predeterminada de la interfaz. En una interfaz con puertos miembros, el primer puerto añadido como miembro proporciona esta MAC predeterminada. Override default MAC address permite utilizar otra dirección MAC; un Factory Reset restaura la MAC predeterminada. Esto no es una indicación de realizar un restablecimiento ni un requisito para un puerto físico PPPoE independiente. Antes de realizar un override justificado, comprobar las dependencias y la vía de recuperación descritas más adelante.

Las velocidades de los puertos del firewall y del equipo remoto deben ser compatibles. Por ejemplo, un puerto de 25 Gbit/s no puede conectarse a un puerto de 40 Gbit/s mediante cables breakout sin una conversión adecuada. Los puertos de 40 y 100 Gbit/s del firewall que admitan breakout pueden dividirse en dos o cuatro puertos mediante cables breakout adecuados. Esto no garantiza la compatibilidad con todos los appliances ni con todas las combinaciones de cables; antes de planificar, comprobar la compatibilidad de los puertos concretos, los transceivers y el equipo remoto.

Establecer una dirección IPv4 en el menú de recuperación interactivo

En 1. Network Configuration > Interface Configuration, la CLI muestra dirección IPv4 y máscara, dirección IPv6 y prefijo, zona, gateways y aliases configurados de los puertos físicos. Las interfaces VLAN y WLAN no aparecen en esta vista.

y inicia un cambio de IPv4. SFOS muestra para cada puerto la dirección, máscara y zona actuales; Enter sin valor nuevo conserva el campo. Esta ruta solo se aplica a Gateway mode y valores IPv4 estáticos. No permite configurar VLAN, DHCP, PPPoE, WLAN o WWAN, y el diálogo IPv6 es diferente.

Antes del cambio se guardan todos los valores, ID de puerto, zona, gateway, aliases y una ruta de administración independiente. Después se verifican enlace, nueva IP y máscara, gateway, Device Access, routing, DNS y acceso real. Si se pierde el acceso o la ruta de datos es incorrecta, se restauran los valores originales por consola o acceso independiente.

Corregir valores de enlace y MAC en Device Console

WebAdmin sigue siendo la ruta normal de configuración. Device Console se reserva para una corrección o recuperación documentada, porque un valor de enlace incorrecto puede interrumpir inmediatamente el único acceso de gestión. Antes se registran Port ID, equipo remoto, Link mode, autonegotiation, FEC, acceso administrativo independiente y reversión.

La sintaxis oficial de SFOS 22 admite 1000fd, 100fd, 100hd, 10fd, 10hd o auto para los valores de cobre enumerados:

Los siguientes ejemplos son alternativas, no una secuencia de comandos. Sustituir Port2 por el puerto físico verificado y elegir exactamente una opción que coincida con la configuración aprobada del puerto y del equipo remoto; no ejecutar ambas consecutivamente. Registrar primero en ambos extremos los valores originales de Link mode, autonegotiation y, cuando corresponda, FEC, junto con el estado del enlace, la velocidad y el dúplex efectivos. Asegurar el acceso independiente y aclarar cómo restaurar exactamente esos valores mediante WebAdmin o un procedimiento confirmado por soporte para el build instalado. Si se desconocen los valores originales o la vía de recuperación, detenerse antes del cambio CLI y consultar con soporte.

Alternativa 1: velocidad y dúplex automáticos, con autonegotiation adicional activada:

set network interface-link Port2 linkmode auto autoneg on

Alternativa 2: 1000 Mbps full-duplex, con autonegotiation adicional desactivada:

set network interface-link Port2 linkmode 1000fd autoneg off

autoneg controla parámetros de enlace adicionales a velocidad y dúplex. Los modos FEC dependen del modelo y Sophos no los enumera de forma universal en este comando CLI. Para puertos de 25, 50 o 100 Gbps se utiliza la configuración recomendada para el appliance y transceiver concretos, no un valor copiado de otro modelo.

Inmediatamente después del cambio elegido, comparar los valores guardados de Link mode, autonegotiation y, cuando corresponda, FEC en WebAdmin y en el equipo remoto con los valores de destino aprobados. Comprobar en ambos extremos el estado del enlace, la velocidad y el dúplex efectivos, así como el acceso de gestión normal y las rutas reales de datos necesarias. Si una ruta no está disponible, es inestable o se degrada, restaurar mediante el acceso independiente los valores originales exactos registrados del puerto y todos los ajustes del equipo remoto modificados para el cambio, incluido FEC si se modificó. Utilizar la vía de restauración aclarada previamente y repetir las mismas comprobaciones; la configuración de cada extremo debe volver a coincidir con su propio estado inicial. Ninguno de los ejemplos, tampoco auto con autoneg on, es una reversión universal.

Una dirección MAC solo se sobrescribe por una dependencia de diseño demostrada. Antes de cualquier cambio, documentar como estado inicial la MAC efectiva y el modo configurado (default u override, incluida cualquier dirección personalizada preexistente). Comprobar Port Security, bindings DHCP, allowlists del proveedor, HA, LAG y las asociaciones MAC/ARP del equipo remoto. Deben estar disponibles un acceso administrativo independiente y una ventana de mantenimiento.

Las descripciones CLI de SFOS 22.0 y 23.0 indican que default conserva la MAC existente. Esto no demuestra la interpretación de que restaura la MAC predeterminada después de un override. No utilizar default como comando inverso ni como vía universal de reversión sin confirmar su efecto en el build y el equipo utilizados. Antes del override, verificar cómo restaurar exactamente tanto la dirección como el modo en el build instalado. Si no se pueden verificar el estado inicial o la restauración, no realizar el cambio y aclararlo con Sophos Support.

El siguiente ejemplo cambia la MAC y puede interrumpir las conexiones de administración y datos. Sustituir Port2 por el puerto verificado y la dirección de ejemplo, administrada localmente, por la dirección de destino autorizada y única en la propia red. No es un valor de restauración:

set network macaddr Port2 override 02:00:5e:10:00:02

Para la restauración verificada:

• Si antes estaba configurado override con una MAC personalizada, volver a establecer la dirección exacta registrada mediante la rama override documentada, no la dirección de ejemplo. El procedimiento debe estar confirmado para el build instalado.
• Si antes estaba configurado default, utilizar Use default MAC address en Network > Interfaces > Edit interface > Advanced settings > Interface settings solo si se han confirmado ese control y la restauración del estado inicial registrado en el build instalado. De lo contrario, obtener un procedimiento específico del build confirmado por Sophos Support; no probar CLI default ni un restablecimiento de fábrica como sustitutos.

Después del cambio y de la restauración, comparar el modo configurado y la dirección efectiva con los valores previstos; al revertir, ambos deben coincidir con el estado inicial registrado. Comprobar también el acceso administrativo normal, el aprendizaje MAC/ARP del equipo remoto y el flujo de datos real afectado. Ante diferencias, detener el procedimiento mediante el acceso independiente y aclararlas con soporte, sin experimentar con más valores MAC.

Sophos documenta MTU 1500 y MSS 1460 como valores predeterminados; solo se modifican con el procedimiento controlado de Comprobar MTU y MSS en problemas VPN.

Para IPv6, DAD attempts determina cuántos mensajes Neighbor Solicitation consecutivos envía el firewall durante Duplicate Address Detection sobre una dirección provisional (tentative). En Allowed RA servers se introducen las direcciones MAC o IPv6 de los servidores Router Advertisement de los que esta interfaz puede aceptar una configuración stateless. IPv6 Prefix Delegation en Sophos Firewall explica el prefijo del proveedor y su distribución interna; Configurar IPv6 Router Advertisement describe los flags de cliente y los prefijos anunciados.

Para una tarea concreta, se pueden utilizar estas guías específicas:

• Configurar y probar una interfaz VLAN
• Configurar y probar una red Wi-Fi gestionada por SFOS
• Conectar APX existentes con Wireless Mesh
• Configurar una interfaz LAG
• Configurar y probar un túnel GRE
• Transportar IPv6 sobre IPv4 o IPv4 sobre IPv6 con un túnel IP
• Reenviar multicast entre interfaces con una ruta multicast estática
• Planificar y validar el enrutamiento multicast dinámico con PIM-SM
• Configurar y comprobar una WAN PPPoE
• Configurar el failover WAN con una segunda conexión a Internet
• Configurar Sophos SD-RED
• Proteger Device Access
• Configurar una VPN IPsec site-to-site

Planificar el modelo de zonas

Distinguir zona, interfaz y objeto de red

Estos tres elementos cumplen funciones diferentes:

• Zona: identifica el área de seguridad de la que procede el tráfico o a la que se dirige.
• Interfaz: conecta el firewall física o virtualmente con una red.
• Objeto de red: identifica la dirección IP o subred concreta de una regla.

Una regla solo es precisa cuando la zona y el objeto de red son correctos. Source zone: LAN junto con Source networks: Any suele ser innecesariamente amplio. A la inversa, un objeto de red correcto no ayuda si el paquete entra por una zona distinta de la indicada en la regla.

Las zonas predeterminadas tienen funciones fijas:

• LAN para redes internas
• WAN para conexiones de proveedor e internet
• DMZ para sistemas expuestos o especialmente aislados
• WiFi para entornos inalámbricos
• VPN para túneles de acceso remoto y site-to-site

La zona WiFi se aplica a las redes inalámbricas que utilizan una zona propia. Sin embargo, con Bridge to AP LAN y Bridge to VLAN no se crea una interfaz WiFi dedicada; la ruta del tráfico sigue la asignación de bridge seleccionada.

Una Wireless Network define ajustes comunes para los clientes WLAN: SSID, modo de seguridad y tratamiento del tráfico de los clientes. Con el Traffic Mode Separate zone, el firewall crea un túnel VXLAN asociado. Por tanto, la selección del Traffic Mode también determina cómo se conecta la WLAN al firewall; no es simplemente una denominación de la red.

Las zonas LAN personalizadas son adecuadas, por ejemplo, para Client, Server, Management, Guest, IoT, VoIP, Backup u OT. Una zona DMZ personalizada es apropiada para servidores publicados, reverse proxies u otros sistemas cuyo acceso a la red interna deba limitarse estrictamente.

No todas las VLAN necesitan una zona propia. Varias VLAN pueden compartir una zona si tienen el mismo nivel de confianza, las mismas reglas de firewall y el mismo Device Access. Si difieren los destinos permitidos, los accesos de administración o las funciones de seguridad, una zona independiente suele ser más clara.

Para usuarios VPN o túneles entre sedes no se crean tipos de zona VPN personalizados. La separación dentro de la zona VPN se realiza con objetos de red, usuarios y reglas de firewall precisos.

Definir las direcciones de acceso antes de crear las reglas

Antes de la configuración basta con una breve lista de direcciones permitidas. Por ejemplo:

• Client a WAN: servicios web, DNS, NTP y de aplicaciones necesarios
• Client a Server: solo puertos de aplicaciones definidos
• Guest a WAN: acceso a internet, pero sin acceso a redes internas
• IoT a Server: solo destinos necesarios, como DNS, NTP o una plataforma de administración
• Management a zonas internas: servicios administrativos, muy limitados y registrados
• DMZ a LAN: bloqueado de forma predeterminada; solo se permiten conexiones explícitamente necesarias
• VPN a Server: solo destinos y servicios autorizados

Para cada dirección permitida deben conocerse el destino, los servicios, la necesidad de NAT, el logging y la persona responsable. Estos datos forman las reglas reales. Configurar correctamente las reglas de Sophos Firewall explica su estructura, orden y funcionamiento del matching.

Comprobar antes de realizar un cambio

Antes de crear o mover una interfaz deben aclararse al menos los siguientes puntos:

• zona y nivel de confianza de la red
• dirección IP, subred y default gateway
• origen de DHCP y servidores DNS
• servicios locales del firewall necesarios
• reglas de firewall y NAT
• routing y SD-WAN
• cliente de prueba, acceso esperado y entrada de log esperada

Los cambios en producción también requieren un backup actual, una ruta de reversión y una comprobación en Object usage.

Crear y validar una VLAN

Una VLAN constituye un dominio de broadcast aislado: los broadcasts permanecen dentro de esa VLAN. La asignación de varias VLAN a la misma zona de seguridad no elimina esta separación de capa 2; la zona determina el contexto de las reglas de firewall y de Device Access.

Una VLAN se crea en Network > Interfaces > Add interface > Add VLAN. Los ajustes decisivos son:

• Interface: interfaz física, RED, bridge o LAG por la que llega la VLAN etiquetada
• Network zone: área de seguridad de la VLAN
• VLAN ID: debe coincidir con el switch y, si corresponde, con el access point
• IPv4/IPv6 configuration: normalmente una dirección de gateway estática para una VLAN interna

Por ejemplo, una VLAN de invitados podría utilizar Port3, VLAN ID 20, la zona Guest y la dirección de gateway 192.168.20.1/24. En el switch, la VLAN 20 debe estar tagged en el uplink hacia Port3; un puerto de cliente o el SSID de invitados asigna después los dispositivos a esta VLAN.

El firewall puede mostrar correctamente la interfaz aunque el switch envíe la VLAN por el puerto equivocado, sin etiquetar o con otra VLAN ID. Por tanto, una VLAN solo está terminada cuando se ha probado toda la ruta:

1. Comprobar en el firewall la VLAN ID, la interfaz principal, la zona, la dirección IP y la máscara.
2. Configurar el uplink hacia el firewall como trunk con la VLAN tagged.
3. Asignar el puerto de acceso o SSID a la VLAN correcta.
4. Comprobar DHCP, gateway y DNS con un cliente de prueba.
5. Probar un acceso interno permitido y otro bloqueado deliberadamente.
6. Comprobar el acceso a internet y confirmar en Log Viewer el firewall Rule ID esperado.

Normalmente no se necesita NAT para el tráfico interno. Si el cliente obtiene una dirección, pero no puede alcanzar el firewall como servidor DNS ni mediante ping, comprobar primero Device Access. El procedimiento completo con etiquetado en el switch y DHCP se describe en Configurar y probar una VLAN en Sophos Firewall.

Sophos no especifica un número máximo fijo de VLAN por puerto físico principal para XGS Appliances. Aun así, varios uplinks o un LAG pueden simplificar la operación y el diagnóstico con cargas altas, muchas VLAN o diseños HA.

Elegir el tipo de interfaz correcto

Las interfaces virtuales y los aliases se crean en Network > Interfaces mediante Add interface. Allí, seleccionar el tipo deseado y abrir su configuración. Las siguientes secciones ayudan a elegir el tipo; un alias complementa una interfaz existente, mientras que, por ejemplo, VLAN, bridge y LAG representan diferentes conexiones lógicas.

Alias

Un alias añade otra dirección IP a una interfaz existente. Resulta especialmente útil cuando un proveedor entrega varias direcciones IP públicas en la misma subred.

En Configurar y probar una IP alias en Sophos Firewall se explica cómo vincular la dirección adicional, utilizarla como objeto host en reglas y NAT, y comprobar ARP y el tráfico del sistema.

Varias interfaces WAN independientes en la misma subred pueden provocar problemas de ARP y gateways inaccesibles. En este caso, un alias en la interfaz WAN existente o un LAG correctamente planificado suele ser la solución más limpia. Un alias sigue el estado de su interfaz principal y no puede desactivarse de forma independiente.

Bridge

Un bridge conecta varias interfaces en la capa 2. Puede funcionar con una dirección IP para tráfico enrutado o de forma transparente sin dirección IP. Las VLAN suelen ser más claras para nuevas redes segmentadas; los bridges son más adecuados para migraciones o diseños deliberadamente transparentes.

El procedimiento completo con miembros, STP, filtros VLAN y EtherType, reglas y validación se describe en Configurar una interfaz bridge en Sophos Firewall.

Se aplican restricciones importantes:

• Un bridge no admite Dynamic DNS, cliente DHCP, PPPoE ni VPN IPsec.
• El tráfico entre miembros del bridge puede seguir necesitando reglas de firewall, por ejemplo una regla LAN-to-LAN.
• No se puede activar HA mientras STP esté activo en un bridge.
• Si se activa un filtro VLAN pero no se permite ninguna VLAN, el firewall descarta todos los frames etiquetados; el tráfico untagged no se ve afectado.
• El tráfico a través de un bridge sin dirección IP puede descartarse sin entrada de log si coincide con una regla de web proxy o NAT.

En un bridge transparente debe comprobarse si Web Proxy Filtering o Source Translation son realmente necesarios.

Sophos documenta NC-177630 para SFOS 22.0.0 GA-Respin Build 411. El error puede producirse cuando el tráfico enrutado a través de un bridge se traduce mediante SNAT o MASQ y la entrada y la salida utilizan el mismo miembro físico del bridge. En ese caso, el filtro hairpin descarta los paquetes de respuesta sin que aparezcan en drppkt. Esto también se aplica cuando solo está activo un miembro del bridge. El tráfico a través de miembros físicos diferentes o sin SNAT/MASQ no se ve afectado.

Sophos indica SFOS 22.0.1 MR1 Build 490 como versión corregida. En GA-Respin Build 411, solo se debe eliminar SNAT o MASQ para el flujo afectado si la traducción no es necesaria y existe una ruta de retorno hacia la dirección IP original del cliente. Como alternativa, el tráfico se enruta a través de una interfaz física dedicada en lugar del bridge. Si falta alguno de los desencadenantes descritos o el problema se produce en MR1 Build 490 o una versión posterior, se debe buscar otra causa. El caso independiente de SFOS 22 para tráfico VLAN hacia el firewall se describe en Comprobar las VLAN de un bridge después de SFOS 22.

Un bridge sobre RED puede extender una red de capa 2 entre sedes, pero debe seguir siendo una excepción justificada.

Los broadcasts, ARP y el tráfico unicast desconocido atraviesan entonces la conexión WAN. Un diseño enrutado con subredes propias para cada sede y reglas de firewall específicas es más estable, escalable y fácil de diagnosticar.

LAG

Un Link Aggregation Group combina de dos a cuatro interfaces físicas en un uplink lógico. Sobre él pueden configurarse VLAN.

Los modos de funcionamiento habituales son:

• Active-Backup: Un enlace está activo y otro toma el relevo si falla.
• LACP (802.3ad): Se pueden utilizar varios enlaces en paralelo; el firewall y el switch deben tener configuraciones idénticas.

Pueden ser miembros las interfaces físicas sin vincular con configuración estática. Las interfaces PPPoE, Cellular WAN y WLAN están excluidas. Con LACP, todos los puertos deben tener el mismo tipo y velocidad.

La xmit-hash-policy distribuye las conexiones entre los enlaces. Normalmente no hace más rápida una única conexión TCP porque esta permanece en un enlace. LAG aporta sobre todo redundancia y ancho de banda agregado adicional para varias conexiones paralelas.

LAG y el failover WAN cumplen funciones distintas: un LAG agrupa enlaces físicos en una conexión lógica. Las conexiones a Internet independientes, en cambio, se utilizan mediante sus gateways WAN en Network > WAN link manager. Varios gateways activos permiten distribuir la carga entre las conexiones disponibles; un gateway de respaldo puede tomar el relevo cuando se detecta un fallo. Esto no garantiza ni la continuidad de las sesiones existentes sin interrupciones ni más ancho de banda para una única conexión. Configurar el failover WAN con una segunda conexión a Internet explica el procedimiento y cómo comprobar que funciona.

WAN móvil y WWAN1

Al activar Cellular WAN, SFOS crea la interfaz WWAN1. Esta forma parte de la conexión móvil y no equivale a una VLAN o un alias creados libremente. Deben seguir teniéndose en cuenta las restricciones de HA descritas a continuación, así como su exclusión como miembro de un LAG.

En SFOS 23.0, Network > Interfaces ofrece, en el Menu de la interfaz WWAN, las acciones Connect y Disconnect para conectar o desconectar el módem de Cellular WAN. Reset reinicia el módem y solo está disponible para modelos 5G de Quectel y Sierra Wireless, no para otros modelos ni para dongles USB. No debe darse por hecho que estas acciones descritas para SFOS 23.0 estén disponibles mediante la misma ruta de clics en SFOS 22.0.

Antes de seleccionar Disconnect o Reset, asegurar un acceso administrativo independiente y una ventana de mantenimiento si la conexión móvil transporta tráfico de producción o proporciona el acceso de administración. Un reinicio del hardware mediante el apagado del firewall interrumpe todo el tráfico del firewall; también debe preverse un acceso administrativo independiente y una ventana de mantenimiento para esta operación. Para reiniciar el hardware de un modelo no compatible, apagar primero el firewall, desenchufar y volver a enchufar el módem y, a continuación, volver a iniciar el firewall; no realizar cambios físicos en el hardware WWAN mientras el firewall esté en funcionamiento. Después, comprobar el estado de la interfaz y las rutas reales de datos y de administración necesarias. Reiniciar el módem no garantiza la solución de un fallo de conexión cuya causa no se haya aclarado.

TAP / Discover Mode

Un puerto físico en Discover Mode recibe una copia del tráfico replicada por el switch. No está en línea y no puede bloquear el tráfico observado ni controlarlo mediante políticas de seguridad. Es útil para un inventario o una prueba de concepto, pero no sirve como ruta de protección en producción.

En la vista de interfaces, este puerto aparece como Discover, physical (TAP). Así puede distinguirse de una interfaz normal en la ruta de datos de producción.

Configurar Discover Mode con TAP y SPAN explica la configuración completa con puerto SPAN, comandos de Device Console, Packet Capture, Security Audit Report y límites de HA.

XFRM para IPsec route-based

Para IPsec route-based, se distingue entre conexiones Any-to-any y conexiones con Traffic Selectors específicos. Cuando ambas subredes están configuradas como Any, SFOS crea automáticamente una interfaz XFRM en la zona VPN:

• Any-to-any: Asignar una dirección IP a la interfaz XFRM creada automáticamente en Network > Interfaces. Las rutas estáticas, SD-WAN o dinámicas determinan después el tráfico del túnel.
• Traffic Selectors: SFOS añade automáticamente una ruta estática al establecerse el túnel. Si aparece una interfaz XFRM, no se le debe asignar una dirección IP ni rutas manuales.

La documentación oficial de SFOS 22 y SFOS 23 se contradice sobre la creación de XFRM para subredes específicas: «Configure an XFRM interface» indica que no se crea ninguna XFRM, mientras que «Route-based VPN» describe la creación de una por configuración. No se debe dar por hecho que la interfaz siempre existe o siempre está ausente. Despliegue la Listening interface en Network > Interfaces y compruebe si aparece en el build instalado. La sección Traffic Selectors de Configurar una VPN IPsec site-to-site explica las comprobaciones existentes de visibilidad y tráfico.

En ambos casos, el tráfico VPN necesita reglas de firewall adecuadas. En Administration > Device access, activar IPsec para la zona WAN permite solicitudes de conexión IPsec entrantes. El ping a una dirección local del firewall desde la zona VPN se permite por separado mediante Ping/Ping6 en Administration > Device access. El ping entre hosts a través del túnel VPN, en cambio, es tráfico de tránsito y necesita rutas y reglas de firewall adecuadas; el permiso de Device Access no autoriza este tráfico.

Una interfaz XFRM no se desactiva directamente en Network > Interfaces, sino mediante su conexión en Site-to-site VPN > IPsec. Si SSL/TLS Decryption se aplica al tráfico IPsec, Sophos exige que la MTU de XFRM sea al menos 113 bytes menor que la MTU de la Listening Interface. Con una MTU de 1400 en la Listening Interface, la MTU de XFRM no puede superar 1287. Este límite específico del producto se aplica a FastPath Offload y no es un valor general para todos los túneles. Comprobar MTU y MSS en problemas de VPN explica el procedimiento completo.

RED

Una interfaz RED conecta una sede remota mediante un túnel cifrado. El modo de funcionamiento determina cuánto tráfico pasa por el firewall central:

• Standard/Unified: El firewall central administra y filtra todo el tráfico de la sede. Si falla el túnel, también puede fallar el acceso a internet.
• Standard/Split: Solo las redes de destino especificadas utilizan el túnel; el tráfico de internet sale localmente y no se filtra de forma centralizada.
• Transparent/Split: El RED funciona de forma transparente en una red existente. Es flexible, pero más difícil de planificar y diagnosticar.
• Manual/Split: La configuración de red es más manual y puede permitir una mayor autonomía local.

El servicio RED debe estar activo en System services > RED. La conexión suele requerir TCP 3400, UDP 3410 y NTP mediante UDP 123. Deben funcionar DNS, la hora correcta del sistema y el acceso saliente a internet.

El comportamiento de las VLAN depende del modelo RED, el modo de funcionamiento, el modo de los puertos LAN y la configuración WLAN. Sophos recomienda Standard/Unified cuando se utilizan VLAN detrás del RED; en un SD-RED 60, el etiquetado VLAN solo es posible en este modo. Las redes WLAN con Bridge to VLAN siguen reglas propias. Elegir el modo de funcionamiento correcto de Sophos RED explica DHCP, la puerta de enlace, la ruta de internet y el comportamiento ante fallos de los cuatro modos. Configurar Sophos SD-RED explica el aprovisionamiento, el estado de los LED y el diagnóstico.

Comprobar el estado y Device Access

Estado de la interfaz

En Network > Interfaces, los valores de estado indican si debe investigarse primero el enlace o la política:

• Not configured: no hay ninguna zona asignada
• Connected: configurada y conectada
• Connecting: está obteniendo una dirección, por ejemplo mediante DHCP
• Disconnected: se ha liberado la dirección
• Disconnecting: se está liberando la dirección
• Unplugged: no hay conexión física; en WiFi, puede faltar un access point o una wireless network
• Not available: FleXi Port configurado sin un módulo FleXi Port instalado

Con Not configured o Unplugged, las reglas de firewall no son el primer punto que debe revisarse. Comprobar primero Zone Binding, cable, SFP, velocidad del puerto, puerto del switch y DHCP o PPPoE.

Servicios locales del firewall

En Administration > Device access se define para cada zona si se puede acceder a servicios locales como HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO o Wireless Protection.

Estos permisos se aplican al propio firewall. El tráfico de tránsito entre redes se controla mediante reglas de firewall. HTTPS y SSH solo deben permitirse desde una red de administración o mediante una Local service ACL exception rule específica. DNS es necesario cuando los clientes utilizan el firewall como servidor DNS.

⚠️ Si los clientes pueden utilizar el web proxy del firewall, SFOS trata las solicitudes HTTP y HTTPS como solicitudes internas del proxy. Por tanto, WebAdmin, Captive Portal, VPN Portal o User Portal pueden ser accesibles aunque el servicio correspondiente esté desactivado para la zona de clientes. En este diseño deben comprobarse por separado el acceso al proxy y los portales locales.

Gestionar dependencias y cambios de forma segura

Comprobar Object Usage antes de editar o eliminar

Zone Binding, DNS, gateways, SD-WAN, interface hosts, VLAN, Dynamic DNS, DHCP, reglas de firewall, NAT y VPN pueden depender de la misma interfaz. Object usage muestra estas referencias.

El contador mostrado solo se actualiza automáticamente una vez al día. Antes de realizar un cambio o eliminar una interfaz, seleccionar Refresh y documentar las dependencias importantes. No todas las referencias se pueden editar en la ventana emergente. Los gateways WAN y las configuraciones CLI deben modificarse en su página de configuración correspondiente o en la CLI.

Para las referencias editables en reglas o políticas, se accede desde el contador a la configuración concreta:

1. En la columna Usage, hacer clic en el número de usos del objeto afectado. La ventana emergente muestra qué configuraciones utilizan el objeto.
2. Expandir la categoría correspondiente mediante el icono de más para mostrar sus reglas o políticas.
3. Hacer clic en la regla o política afectada para editarla. Eliminar allí la referencia al objeto o sustituirla por el objeto de reemplazo previsto.

Después de comprobar las dependencias, la activación o desactivación se realiza en Network > Interfaces, desde el Menu de la interfaz afectada, con on u off, respectivamente. Antes de seleccionar off, asegurar un acceso administrativo independiente y una vía de recuperación; la acción puede interrumpir la ruta de datos que se esté utilizando. Alias y XFRM no pueden desactivarse de forma independiente aquí.

Al desactivar una interfaz se conserva su configuración. Los túneles IPsec en los que el firewall es el iniciador se desconectan inmediatamente. Los túneles responder y las conexiones de acceso remoto terminan como máximo por inactividad o Dead Peer Detection.

Una interfaz virtual se elimina en Network > Interfaces mediante Menu > Delete interface. Ejecutar esta acción únicamente después de seleccionar Refresh en Object usage, documentar la comprobación de dependencias y preparar un backup y una vía de recuperación; no elimina solo la entrada visible de la interfaz.

Al eliminar una interfaz virtual, SFOS elimina todas las reglas de firewall que la utilizan, incluso si la regla contiene otras interfaces. También elimina los Zone Bindings dependientes, los servidores o relays DHCP, las entradas ARP estáticas y de proxy ARP, los Protected Servers y las reglas de firewall basadas en ellos, los Interface Hosts y sus referencias en grupos, así como las rutas unicast y multicast. Las interfaces Alias siguen a su interfaz principal; las interfaces XFRM se administran mediante la conexión IPsec.

Incluso una simple modificación puede afectar a Zone Binding, DNS, las puertas de enlace, las rutas y perfiles SD-WAN, los Interface Hosts, las VLAN y Dynamic DNS. Tras una modificación o eliminación, las conexiones pueden dejar de responder temporalmente o fallar. Por tanto, después de cada cambio, comprobar las rutas reales de datos y de gestión, no solo la entrada de la interfaz guardada.

Eliminar deliberadamente la configuración de un puerto físico

Un puerto físico permanece en el dispositivo; solo se puede eliminar su configuración. off y Network zone None no son equivalentes: off conserva la configuración, mientras que None elimina la configuración IP. Esta acción sirve para liberar deliberadamente un puerto que ya no se necesita, no como primer paso de reparación en caso de Unplugged o de una puerta de enlace inaccesible.

⚠️ Antes de la eliminación, ejecutar Object usage > Refresh, documentar y migrar las dependencias y probar la copia de seguridad y el acceso administrativo independiente. Registrar las direcciones IP, las máscaras o prefijos, la zona, las puertas de enlace y los alias para poder revertir el cambio. No restablecer el puerto a través de la única vía de acceso de gestión.

1. En Network > Interfaces, abrir el puerto físico afectado.
2. Establecer Network zone en None. La configuración IP desaparece ya en el formulario; comprobar de nuevo el ID del puerto antes del siguiente paso.
3. Guardar con Save.
4. En la vista general deben aparecer Unbound, el estado Disabled y la dirección IP N/A. A continuación, comprobar mediante el acceso independiente que las demás rutas de datos y de gestión necesarias siguen funcionando.

Si se ha restablecido el puerto incorrecto, restaurar su zona y configuración IP anteriores mediante el acceso independiente o la consola. Restaurar las configuraciones dependientes eliminadas a partir del inventario previo o de la copia de seguridad; volver a asignar una zona no sustituye esta operación. Por último, volver a probar el enlace, la puerta de enlace, DHCP, DNS, el enrutamiento, las reglas y Device Access.

Cambios de HA y remotos

Las interfaces dedicadas del enlace HA deben pertenecer a una zona DMZ. Otras interfaces supervisadas o utilizadas para administración pueden pertenecer a otras zonas.

HA active-active requiere interfaces configuradas de forma estática. Cellular WAN se desactiva con HA. Active-passive puede utilizar interfaces WAN con direccionamiento dinámico, pero conexiones como PPPoE no conservan necesariamente su sesión durante un failover.

Antes de realizar un cambio en producción:

1. Documentar la configuración y las dependencias.
2. Preparar una ventana de mantenimiento, un momento de reversión, un backup y una ruta de reversión concreta.
3. Probar una vía de administración independiente, por ejemplo Sophos Fusion (antes Sophos Central), una segunda conexión WAN, una red de administración separada o una persona in situ.
4. Preparar un cliente de prueba o tráfico de prueba identificable; después añadir y probar la nueva zona o ruta.
5. Comprobar el enlace, la dirección IP, el gateway, DHCP, DNS, las reglas de firewall, NAT y Device Access.
6. Eliminar los objetos antiguos solo cuando la nueva ruta sea estable.

Para un trunk VLAN, la reversión debe incluir la VLAN ID anterior, la native VLAN y el perfil del puerto del switch. En cambios de WAN son importantes los ajustes del proveedor y las rutas SD-WAN; en XFRM, también el túnel, el routing y las reglas de firewall en ambas direcciones.

Diagnosticar errores de forma sistemática

El síntoma suele indicar dónde empezar:

• La interfaz está unbound o disabled: Comprobar primero si el puerto se ha dejado deliberadamente sin una zona asignada o si se ha desactivado la interfaz. Si el puerto estaba anteriormente en producción, comparar la zona y la configuración IP esperadas con la configuración documentada y restaurarlas mediante un acceso independiente. None no es una reparación, sino que elimina la configuración IP; el procedimiento deliberado se explica arriba en Eliminar deliberadamente la configuración de un puerto físico.
• La VLAN no funciona: Comparar VLAN ID, interfaz principal, trunk, ajustes tagged/untagged y native VLAN.
• No se puede acceder al firewall mediante ping, HTTPS o DNS: Comprobar Device Access y Local Service ACL, no una regla de firewall normal en primer lugar.
• El tráfico interno está bloqueado: Comprobar source zone, destination zone, objetos de red, routing, servicios y orden de las reglas.
• El gateway WAN permanece inactivo: Comprobar enlace, dirección IP, gateway, credenciales PPPoE y WAN Link Manager.
• Varios puertos WAN están en la misma subred: Evitar problemas ARP y considerar un alias o LAG.
• SFP o la velocidad del puerto no coinciden: Comprobar SFP y SFP+ de forma sistemática y comparar transceiver, cable, configuración breakout y velocidad en ambos lados.
• VPN o PPPoE son inestables: Comprobar MTU y MSS.

Para la investigación propiamente dicha, seguir este orden:

1. Network > Interfaces: enlace, dirección IP, zona y gateway
2. Network > Zones: tipo de zona y Device Access
3. Hosts and services: objetos de red y de servicio
4. Firewall rules: dirección, orden, servicios y logging
5. NAT rules: original y translation
6. Log viewer: Rule ID o motivo del drop
7. Diagnostics > Tools > Packet capture: entrada y reenvío del paquete

Si la regla parece correcta pero no hace match, consultar La regla de firewall no coincide. Usar Packet Capture en WebAdmin explica cómo seguir el flujo del paquete.

Lista de comprobación operativa

• zonas planificadas y documentadas según el nivel de confianza
• zona, interfaz y objeto de red no se confunden entre sí
• VLAN ID, interfaz principal, trunk y gateway comprobados
• Device Access restringido, especialmente para HTTPS, SSH, DNS, ping y portales
• reglas de firewall creadas con zonas, redes, servicios y logging concretos
• alias considerado para direcciones IP adicionales del proveedor en la misma subred
• DHCP, DNS, NTP, routing y, cuando corresponda, NAT probados
• Object Usage actualizado y comprobado antes de realizar cambios
• vía de administración independiente y ruta de reversión preparadas
• estado del enlace, Log Viewer y Packet Capture comprobados después del cambio

FAQ