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 firewall admite hasta 100 zonas en total.

Configurar una interfaz física

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

1. Asignar un Name descriptivo, 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.

Solo las interfaces de la zona WAN disponen de configuración de gateway. Las interfaces internas suelen utilizar direccionamiento estático; las conexiones WAN pueden configurarse de forma estática, mediante DHCP o PPPoE.

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

• Configurar y probar una interfaz VLAN
• Configurar una interfaz LAG
• 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

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 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 dispositivos XGS. 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

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.

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.

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.

La Sophos Known Issues List describe además un defecto específico de las versiones SFOS 22.0 GA Build 411 y MR1 Build 490: Si el tráfico a través de un bridge se traduce mediante SNAT o MASQ y el origen y el destino se encuentran detrás del mismo miembro físico del bridge, el filtro hairpin puede descartar los paquetes de respuesta sin que aparezcan en drppkt. Esto también se aplica cuando solo se utiliza activamente un miembro del bridge. El tráfico entre miembros físicos diferentes o sin SNAT/MASQ no se ve afectado. Las versiones más recientes, como 22.0 MR2 Build 546, no figuran como afectadas en la Known Issues List actual.

Si solo fallan determinadas conexiones a través del bridge, comprobar conjuntamente la topología y NAT, probar temporalmente sin Source Translation o utilizar un diseño enrutado. 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.

XFRM para IPsec route-based

En una conexión IPsec route-based, SFOS crea automáticamente una interfaz XFRM en la zona VPN. Esto se aplica tanto a conexiones Any-to-any como a conexiones con Traffic Selectors:

• 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 crea la interfaz XFRM y, al establecerse el túnel, añade automáticamente una ruta estática. No se puede asignar una dirección IP ni añadir una ruta a esta interfaz XFRM.

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 través del túnel se activa por separado para VPN.

Una interfaz XFRM no se desactiva directamente en Network > Interfaces, sino mediante su conexión en Site-to-site VPN > IPsec. MTU y MSS son relevantes para diagnosticar problemas de fragmentación; Comprobar MTU y MSS en problemas de VPN explica el procedimiento.

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. Configurar Sophos SD-RED explica la selección del modo, 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.

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.

Al eliminar una interfaz virtual, SFOS puede borrar reglas de firewall, configuraciones DHCP, entradas ARP, rutas, interface hosts y otras referencias dependientes. Las interfaces Alias siguen a su interfaz principal; las interfaces XFRM se administran mediante la conexión IPsec.

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 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 Zone Binding y el estado. Un puerto físico no se elimina; su configuración puede quitarse asignando la zona None.
• 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: 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