Configurar zonas e interfaces en Sophos Firewall

Las zonas e interfaces son una de las bases más importantes de una Sophos Firewall. Si se planifican bien, las reglas de firewall, NAT, VPN, Web Protection y el troubleshooting posterior serán mucho más fáciles. Si se configuran demasiado rápido, es habitual acabar con reglas poco claras o servicios de administración accesibles desde lugares incorrectos.

Una zona es un grupo lógico de seguridad. Una interface es una conexión física o virtual, por ejemplo Port1, una VLAN, una Bridge, un LAG, un Alias, una RED interface o una XFRM interface para route-based VPN. Cada interface pertenece exactamente a una zona. Las reglas de firewall trabajan mucho con estas zonas, por lo que la estructura no debe planificarse solo desde el punto de vista técnico, sino también desde el punto de vista de seguridad.

Por qué las zonas son importantes

En Sophos Firewall, las zonas son mucho más que una agrupación visual. Definen áreas de seguridad y se utilizan en varios puntos:

• Las reglas de firewall usan Source zone y Destination zone.
• Device Access controla por zona qué servicios locales de la firewall son accesibles.
• NAT, SD-WAN, VPN, Web Protection y los logs son más fáciles de entender con zonas claras.
• El troubleshooting es más transparente porque se ve enseguida de qué área de seguridad viene un paquete y hacia dónde debe ir.

Una buena zonificación no evita automáticamente todos los errores, pero obliga a definir límites claros. Una red de clientes, una red de servidores, una red WiFi de invitados y una DMZ no deberían tratarse simplemente como LAN si tienen riesgos y reglas diferentes. De lo contrario aparecen reglas Allow demasiado amplias, excepciones confusas y accesos de administración innecesariamente abiertos.

Una buena zona siempre responde a esta pregunta: qué redes tienen el mismo nivel de confianza y pueden tratarse de forma similar? Si dos redes necesitan permisos diferentes, requisitos de logging distintos o accesos de administración separados, conviene crear una zona propia o al menos un concepto de reglas muy consciente.

Entender las zonas estándar

Sophos Firewall incluye varias zonas estándar:

Las zonas estándar se encuentran en Network > Zones. Las zonas propias pueden crearse como tipo LAN o DMZ. No se pueden crear libremente más zonas WAN o VPN, porque estos tipos de zona tienen funciones especiales en la firewall.

Importante: una zona no permite tráfico automáticamente. También entre dos interfaces de la misma zona se necesitan reglas de firewall adecuadas según la dirección y el escenario. Sophos indica expresamente en la documentación que el tráfico entre dos interfaces de zona LAN no se permite automáticamente, sino que requiere una regla LAN-to-LAN apropiada.

Planificar las zonas antes de crearlas

Antes de crear zonas, conviene anotar qué redes tienen requisitos de seguridad diferentes. Ejemplos típicos:

• LAN de puestos de trabajo
• Red de servidores
• Red de administración
• DMZ
• WiFi de invitados
• VoIP
• Cámaras o IoT
• Red de producción
• Clientes VPN
• MPLS o conexiones entre sedes

Una zona propia tiene sentido cuando una red necesita reglas propias, Device Access propio o un nivel de confianza diferente. Varias VLAN también pueden estar en la misma zona si se van a tratar igual. Tener muchas zonas no hace que una configuración sea automáticamente más segura. Solo ayudan si detrás hay reglas claras.

Para muchas pequeñas y medianas empresas, esta estructura básica es un buen punto de partida:

No cada VLAN necesita automáticamente una zona propia. Si varias VLAN de clientes reciben exactamente las mismas reglas de firewall, la misma Web Policy y el mismo Device Access, pueden quedarse en una zona común de clientes. Pero si una VLAN puede llegar a servidores, otra solo a Internet y una tercera no debe acceder a servicios locales de la firewall, la separación debe modelarse conscientemente.

Un buen patrón es:

Crear una nueva zona

Se abre Network > Zones y se hace clic en Add.

1. Asignar un nombre corto y claro, por ejemplo Server, Guest, Management o MPLS.
2. Elegir el tipo LAN o DMZ.
3. En Device Access, definir de forma consciente qué servicios locales de la firewall pueden alcanzarse desde esta zona.
4. Guardar.

LAN o DMZ como tipo de zona?

En las zonas propias de Sophos Firewall normalmente se puede elegir entre LAN y DMZ. Ambos tipos agrupan interfaces para usarlas luego de forma limpia en reglas, Device Access y policies. La diferencia está sobre todo en la idea de seguridad detrás de la zona.

LAN se usa para redes internas, básicamente de confianza. Esto incluye redes de clientes, redes internas de servidores, management, VoIP, impresoras o VLAN internas. Incluso en una zona LAN, el tráfico entre interfaces no se permite automáticamente. Si dos zonas LAN o dos interfaces dentro de una zona LAN deben comunicarse, se necesitan reglas de firewall adecuadas.

DMZ se usa para redes con mayor riesgo o aislamiento claro. Ejemplos típicos son servidores web públicos, reverse proxies, mail gateways, jump hosts o sistemas que deben ser accesibles desde varias áreas de seguridad. Una DMZ debe planificarse de forma que solo tenga las conexiones necesarias hacia dentro. Si un servidor de la DMZ se ve comprometido, no debe existir acceso amplio automático a la LAN interna.

Como regla sencilla:

Las interfaces HA también pertenecen a una zona DMZ. Para redes normales de administración o clientes, LAN suele ser el tipo más adecuado.

Para una red interna de administración puede tener sentido activar HTTPS. En redes normales de clientes o invitados se debe evitar el acceso de administración. Ping/ping6 suele ser útil para troubleshooting, pero debe activarse conscientemente. DNS solo se necesita si los clientes de esa zona usan la firewall como servidor DNS.

⚠️ Device Access no es lo mismo que una regla de firewall. Los accesos a servicios locales de la firewall, por ejemplo WebAdmin, SSH, User Portal, DNS o Ping, se controlan mediante Administration > Device access y excepciones ACL locales.

Configurar una interface

Las interfaces se encuentran en Network > Interfaces. Un puerto físico puede funcionar, por ejemplo, como LAN, WAN o DMZ. Además se pueden crear interfaces virtuales como VLAN, Bridge, LAG, RED o XFRM.

Para una interface física, estos puntos son especialmente importantes:

Solo las interfaces en la zona WAN reciben configuración de gateway. Las interfaces internas normalmente se direccionan de forma estática. En conexiones de proveedor, DHCP o PPPoE pueden ser útiles.

Los nombres descriptivos son importantes. PortD dice poco dentro de seis meses. Server VLAN, MPLS Provider, Guest WiFi o Core Switch Trunk ayudan mucho más en operación.

Crear una VLAN interface

Una VLAN interface se crea en Network > Interfaces > Add interface > Add VLAN. Lo más importante es Parent Interface, Zone, VLAN ID y configuración IP.

La Parent Interface es el puerto físico o LAG por el que llega la VLAN etiquetada. Si el switch envía la VLAN por otro puerto, sin tag o con VLAN ID incorrecta, la firewall mostrará una VLAN interface, pero los clientes no la alcanzarán de forma fiable.

Para VLAN internas se usa normalmente una dirección IP estática en la firewall, por ejemplo como Default Gateway de esa VLAN. La zona decide después qué reglas de firewall, Web Policies y ajustes de Device Access se aplican. Por eso, al crear una VLAN no conviene introducir solo la IP, sino pensar también si la VLAN pertenece mejor a Client, Server, Management, Guest, DMZ u otra zona.

Leer correctamente el estado de interfaces

En Network > Interfaces, Sophos Firewall muestra mensajes de estado. Estos estados son muy útiles en troubleshooting porque permiten ver rápidamente si una interface está mal configurada o si realmente no hay enlace.

Si una interface muestra inesperadamente Not configured o Unplugged, no se deben revisar primero las reglas de firewall. Primero se revisan Zone Binding, enlace, SFP/transceiver, cable, puerto del switch y, con DHCP/PPPoE, la asignación de dirección.

Clasificar VLAN, Bridge, LAG, Alias y RED

Sophos Firewall admite diferentes tipos de interface. Para principiantes es especialmente importante saber cuándo tiene sentido cada tipo.

Para instalaciones nuevas, VLAN sobre un uplink claramente definido hacia el switch suele ser más limpio que una gran Bridge sobre muchos puertos. Una Bridge puede ser práctica en migraciones o setups muy simples, porque varios puertos se tratan como un segmento Layer 2 común. Pero precisamente eso es también la desventaja: los límites de seguridad, dominios de broadcast y fuentes de error son menos visibles.

Por eso recomendamos Bridges solo de forma específica, no como diseño estándar. En la práctica, las Bridges tienen varias desventajas:

• Varios puertos comparten el mismo segmento Layer 2, por lo que broadcasts y problemas pueden afectar más dispositivos.
• Las reglas de firewall son menos claras porque la separación ya no se ve limpiamente mediante interfaces, VLANs y zonas propias.
• El troubleshooting es más difícil porque hay que considerar flujo de paquetes, MAC learning, STP y configuración del switch juntos.
• La segmentación posterior se complica si de una Bridge simple deben salir más tarde redes separadas de clientes, servidores, invitados o management.
• HA, VLAN, DHCP o Device Access se vuelven rápidamente confusos si demasiadas funciones pasan por una Bridge.

Las Bridges en Sophos Firewall pueden crearse con interfaces físicas, RED interfaces, VLANs o LAGs. Pueden funcionar con o sin dirección IP propia. Aquí surgen muchos malentendidos:

• Sin dirección IP, la Bridge trabaja de forma transparente, pero no puede usarse como una interface routed normal.
• Si se necesita routing en una Bridge, se debe asignar una dirección IP a la Bridge.
• Para tráfico entre Bridge members se siguen necesitando reglas de firewall adecuadas entre las zonas implicadas, por ejemplo LAN a LAN.
• STP puede ser útil si hay caminos redundantes y se deben evitar bridge loops.
• VLAN filters y EtherType filters pueden ayudar a limitar el tráfico Layer 2 que pasa por una Bridge.
• Sophos indica que el tráfico a través de Bridge interfaces sin dirección IP puede descartarse si coincide con una regla de firewall con Web Proxy Filtering o con una regla NAT. Estos drops no se registran. En NAT hay que vigilar especialmente Source Translation u Override Source Translation.

Este último punto es importante: si de repente no se ven logs en una Bridge aunque el tráfico no funcione, el problema no siempre está en el Log Viewer. Puede estar en el modo de Bridge, NAT o Web Proxy Filtering.

Si ya existen VLANs en el switch, la firewall debería tomarlas conscientemente como VLAN interfaces propias. Esto genera zonas más claras, reglas de firewall más limpias y suele ser mejor de mantener a largo plazo.

RED Bridge: extender una red entre sedes

Técnicamente es posible incluir RED interfaces en una Bridge y extender así una red Layer 2 entre varias sedes. Esto puede ayudar en casos especiales, por ejemplo si una aplicación debe permanecer obligatoriamente en la misma subred o durante una migración sin cambios IP inmediatos.

Recomendaríamos este diseño con mucha cautela. Una Bridge sobre RED prolonga el dominio Layer 2 a través del túnel. Broadcasts, ARP, unknown unicast y otros efectos Layer 2 pasan entonces por una conexión WAN o Internet. Esto puede reducir el rendimiento y hacer los errores mucho más difíciles de entender. Si el túnel RED es inestable, el impacto afecta directamente a la red extendida.

En la mayoría de casos es mejor un diseño routed: cada sede tiene sus propias subredes, la firewall enruta entre ellas y las reglas definen exactamente qué está permitido. Es más limpio, escalable y mucho más cómodo para troubleshooting.

LAG: planificar correctamente redundancia y ancho de banda

Una Link Aggregation Group (LAG) agrupa varios puertos físicos en una interface lógica. Es útil cuando se necesita redundancia hacia el core switch o más ancho de banda entre firewall y switch. Pero LAG no sustituye una zonificación limpia. Al final, la LAG sigue siendo una interface sobre la que se pueden operar VLANs o asignar una zona.

Sophos Firewall admite sobre todo dos modos habituales:

Importante: LACP solo funciona correctamente si el otro extremo está configurado de forma coherente. En el switch, los puertos deben estar en la misma LAG group, usar la misma velocidad y dúplex, y coincidir con la configuración de la firewall. Si se crea una LAG solo en la firewall pero no se configura bien el switch, suelen aparecer pérdidas de paquetes o problemas asimétricos difíciles de diagnosticar.

Para LAGs hay algunas limitaciones prácticas:

• Una LAG en Sophos Firewall consta de dos a cuatro interfaces físicas.
• Solo sirven interfaces físicas unbound con configuración estática.
• PPPoE, Cellular-WAN y WLAN interfaces no pueden ser miembros de una LAG.
• Con LACP (802.3ad), los member ports deben tener el mismo tipo y velocidad.
• La xmit-hash-policy determina cómo se distribuyen las sesiones entre enlaces. Una única sesión TCP normalmente no será más rápida porque suele permanecer en un enlace.

En entornos pequeños, un único trunk port limpio suele ser suficiente. LAG merece la pena sobre todo si el core switch debe conectarse de forma redundante, muchas VLANs pasan por el mismo uplink o la firewall necesita realmente más throughput hacia el switch.

XFRM: entender route-based IPsec como interface

Una XFRM interface pertenece al tema route-based IPsec VPN. No se planifica como una VLAN normal o un puerto físico, sino que aparece en el contexto de una conexión IPsec. Sophos Firewall crea automáticamente una XFRM interface cuando en una conexión IPsec tanto las subredes locales como las remotas están configuradas como Any.

Esto es una diferencia importante frente a túneles IPsec clásicos policy-based. En route-based VPN no decide solo la IPsec Policy, sino también routing, reglas de firewall y la XFRM interface. Esto hace que conexiones complejas entre sedes sean más flexibles, pero exige una planificación limpia:

• La XFRM interface está en la zona VPN.
• En Administration > Device access, IPsec debe estar permitido para la zona WAN para que la conexión pueda establecerse.
• Si las subredes locales o remotas no son Any, no se crea XFRM interface.
• MTU y MSS son especialmente importantes en route-based VPN porque IPsec añade overhead.
• Una XFRM interface no se desactiva directamente en Network > Interfaces, sino mediante la conexión IPsec correspondiente en Site-to-site VPN > IPsec.

Para administradores, XFRM es especialmente relevante cuando se quieren controlar limpiamente SD-WAN routing, dynamic routing o varias redes a través de un túnel de sede. Si solo se necesita una conexión Site-to-Site muy simple con dos redes fijas, un túnel policy-based clásico suele ser más fácil de entender.

RED: sedes remotas como concepto de interface propio

Las RED interfaces no son un switch port normal. RED significa Remote Ethernet Device y se usa para conectar una sede remota con Sophos Firewall mediante un túnel cifrado. Esto puede hacerse con hardware SD-RED dedicado o con conexiones Firewall-to-Firewall RED.

Antes de planificar, debe quedar claro qué modo de operación se necesita:

Para muchas empresas, Standard/Unified es la variante más limpia si la sede debe quedar completamente protegida por la firewall central. La desventaja es clara: si el túnel RED falla, según el diseño la sede también pierde el acceso a Internet gestionado centralmente. Standard/Split reduce esta dependencia, pero significa que el tráfico local de Internet ya no se filtra ni se registra completamente en la Sophos Firewall central.

En RED conviene revisar pronto estos puntos:

• El servicio RED debe estar activado en System services > RED.
• Para la conexión se necesitan normalmente TCP 3400, UDP 3410 y NTP 123.
• Los dispositivos SD-RED necesitan hora correcta, porque si no pueden fallar el TLS handshake y el establecimiento del túnel.
• En la primera puesta en marcha, DHCP en el uplink suele ser más sencillo porque el dispositivo debe alcanzar la provisión.
• Las VLANs no son igual de adecuadas en todos los modos RED. Standard/Split y Transparent/Split no están pensados para VLAN-tagged frames. Si se necesitan VLANs detrás de una SD-RED, el modo debe elegirse con especial cuidado.
• Si un dispositivo RED está detrás de un router del proveedor, deben funcionar las conexiones salientes y DNS/NTP.

RED es muy práctico para sedes pequeñas, pero no debe tratarse como un cable LAN normal. La decisión clave es si la sede debe estar protegida centralmente, trabajar de forma local autónoma o conectarse solo parcialmente por el túnel. Esto afecta a DHCP, DNS, VLANs, routing, reglas de firewall, logging y troubleshooting.

Restringir Device Access correctamente

En Administration > Device access se ve qué servicios locales de la firewall son accesibles desde qué zonas. Entre ellos están:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Para entornos productivos se aplica: cuanto menos servicios locales sean accesibles desde una zona, mejor. Especialmente HTTPS y SSH deberían permitirse solo desde redes de management de confianza o mediante una Local service ACL exception rule.

Si se necesita SSH, ayuda esta guía: establecer una conexión SSH con Sophos Firewall.

Tener en cuenta las dependencias

Los cambios en interfaces rara vez son aislados. Sophos indica que los cambios de interface pueden afectar configuraciones dependientes, por ejemplo:

• Zone Binding
• DNS
• Gateways
• SD-WAN routes
• Hosts basados en interface
• VLAN interfaces
• Dynamic DNS
• Reglas de firewall
• Reglas NAT

Antes de cambios grandes conviene revisar en Object usage dónde se usa ya una interface, zona u objeto host. Sophos Firewall muestra el uso de objetos y enlaza directamente a muchas configuraciones dependientes.

Al desactivar o eliminar hay que tener especial cuidado:

• Si se desactiva una interface, la configuración se conserva y el estado sigue visible.
• Los túneles Site-to-site IPsec en los que la firewall es iniciadora se desconectan inmediatamente.
• Los túneles Site-to-site IPsec como responder y las conexiones Remote Access se desconectan como muy tarde por inactividad o Dead Peer Detection.
• Alias y XFRM interfaces no se desactivan directamente como interfaces normales. Alias interfaces siguen a la interface física; XFRM interfaces se desactivan mediante Site-to-site VPN > IPsec.
• Si se elimina una interface virtual, pueden eliminarse también reglas de firewall, configuraciones DHCP, entradas ARP, rutas, interface-hosts y otras referencias dependientes.

Por eso, antes de eliminar se debe revisar siempre si la interface se usa en reglas de firewall, reglas NAT, DHCP, routing, SD-WAN, Dynamic DNS u objetos host. Una eliminación descuidada puede quitar más que solo la interface.

Errores típicos

Interface unbound o disabled: comprobar si hay una zona asignada. Una interface física no se puede borrar, pero su configuración puede retirarse poniendo la zona en None.

La VLAN no funciona: comprobar VLAN ID, puerto del switch, configuración Tagged/Untagged, Native VLAN y si la VLAN se creó sobre la Parent Interface correcta.

Los clientes no llegan a la firewall por Ping o HTTPS: no revisar primero reglas normales de firewall. Revisar Administration > Device access y excepciones ACL locales.

El tráfico entre dos redes internas no funciona: comprobar Source zone, Destination zone, objetos de red, routing y posición de la regla de firewall.

El WAN gateway no se activa: comprobar configuración IP, Gateway-IP, link status, credenciales PPPoE, DNS y, si corresponde, WAN link manager.

Varias WAN interfaces en la misma subred: si varias WAN interfaces usan IPs de la misma subred, pueden aparecer problemas ARP y los gateways quizá no sean alcanzables. Si un proveedor entrega varias IP públicas en la misma subred, Alias o LAG interfaces suelen ser más limpios que varias interfaces WAN separadas en la misma red.

SFP, port speed o breakout no encajan: la velocidad del puerto en switch, router, transceiver y firewall debe coincidir. Un puerto de 25 Gbit/s no puede conectarse directamente a uno de 40 Gbit/s sin la tecnología adecuada. En modelos con puertos 40G o 100G, los cables breakout pueden ser relevantes si un puerto debe dividirse en varios más pequeños.

Problemas MTU en VPN o PPPoE: revisar MTU y MSS. En tráfico VPN, un valor MTU demasiado alto puede causar pérdidas de paquetes que parecen problemas de conexión aleatorios.

Troubleshooting

Para la búsqueda de errores, este orden es práctico:

1. Network > Interfaces: revisar link status, IP address, zone y gateway.
2. Network > Zones: revisar Device Access y tipo de zona.
3. Hosts and services: revisar si host y service objects son correctos.
4. Rules and policies > Firewall rules: revisar Source zone, Destination zone, Services y orden.
5. Rules and policies > NAT rules: si hay NAT, comparar limpiamente Original y Translated.
6. Log viewer: revisar qué regla o qué drop se aplica.
7. Diagnostics > Tools > Packet capture: revisar si los paquetes llegan y hacia dónde se reenvían.

Si las zonas e interfaces están bien creadas, el siguiente paso es mucho más sencillo: entender y configurar correctamente reglas de Sophos Firewall. Si el tráfico no funciona aunque la zona parezca correcta, ayuda la lista Firewall rule not matching: revisar orden, matching y logs. Para análisis más profundo también se puede usar Packet Capture en WebAdmin y, en traducciones o port forwardings, el artículo entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Más información

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface