Configurar y probar una interfaz bridge en Sophos Firewall

Una interfaz bridge conecta varias interfaces físicas o virtuales en la capa 2. De este modo, una Sophos Firewall puede insertarse de forma transparente en un trayecto existente o actuar como gateway bridge enrutado de forma consciente. La decisión central se toma antes de crearla: ¿la bridge solo debe reenviar frames o debe tener una dirección IP y enrutar por sí misma?

⚠️ Una configuración bridge incorrecta puede provocar un bucle de capa 2, una broadcast storm o la pérdida del acceso de gestión. Antes del cableado hacen falta un backup, una ventana de mantenimiento, acceso administrativo independiente y una vía de recuperación clara. Las rutas redundantes de capa 2 solo se activan cuando STP y el diseño HA estén resueltos.

Transparente o enrutada

Una bridge transparente sin dirección IP reenvía frames entre sus members. Puede conectar redes sin actuar como gateway. Es adecuada para migraciones controladas o un trayecto inline donde la arquitectura IP existente deba permanecer sin cambios.

Una bridge enrutada con dirección IP se activa mediante Enable routing on this bridge pair. Su IP puede actuar entonces como gateway o endpoint local del firewall. El filtrado VLAN de la bridge solo se aplica al tráfico bridged, no al tráfico enrutado.

En los modelos XGS compatibles, un par de puertos bridge fijo por hardware también puede funcionar como ruta Fail-to-Wire. Configurar y probar LAN Bypass de forma controlada explica el límite de modelos, el par FTW, el tráfico sin inspección durante el fallo y el retorno al funcionamiento protegido. Dos members cualesquiera no adquieren esta función de hardware.

Una bridge no es un sustituto universal de una interfaz WAN o VPN propia. Sophos no admite Dynamic DNS, DHCP client, PPPoE ni IPsec VPN en interfaces bridge. Para nuevas redes segmentadas, VLAN y routing suelen ser más fáciles de operar. Zonas e interfaces en Sophos Firewall explica la elección entre alias, bridge, LAG, VLAN, XFRM y RED.

Planificar el ejemplo y los members

El ejemplo conecta Port3 y Port4 de forma transparente. Ambos puertos están en el mismo trayecto de capa 2 planificado y la bridge no recibe dirección IP. Son valores de ejemplo que deben sustituirse por el cableado, las zonas y la estrategia de gestión reales.

SFOS permite hasta 64 members. Pueden ser interfaces físicas, RED, LAG e interfaces VLAN sobre una interfaz física, RED o LAG. Cada member se comprueba previamente en cuanto a direcciones IP existentes, VLAN, DHCP, NAT, reglas, routing y acceso administrativo.

Las zonas de los members siguen siendo relevantes para las reglas de firewall. Una bridge no permite el tráfico automáticamente. Si ambos members están, por ejemplo, en LAN, el flujo deseado puede seguir necesitando una regla LAN-to-LAN adecuada.

Controles avanzados de bridge en Device Console

La configuración habitual de la bridge permanece en WebAdmin. Device Console ofrece además tres controles globales o de bajo nivel. Antes de utilizarlos se guardan el nombre de la bridge, el nombre de hardware, los members, los IDs de puerto, la tabla MAC, la ruta de administración y el estado actual de la CLI. Estos comandos no sustituyen reglas de firewall ausentes ni un diseño de Layer 2 sin aclarar.

Tratar tráfico desconocido no enrutable

bypass-firewall-policy se aplica al tráfico de bridge no enrutable al que no se aplica ninguna Security Policy. SFOS distingue entre dynamic y static. Primero se lee el estado actual de ambas categorías:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

Las acciones disponibles son allow y drop. allow es relevante para la seguridad porque este tráfico puede reenviarse expresamente sin una firewall policy. La ayuda de SFOS 22 no indica un valor predeterminado ni explica la distinción exacta entre dynamic y static. Por eso no se cambia ninguna categoría por sospecha. Si Sophos Support indica una modificación, se sustituye show por allow o drop en la misma sintaxis y después se verifican el estado, un Packet Capture y un flujo de prueba positivo y otro negativo.

Este conmutador no es LAN Bypass ni una stateful firewall bypass rule. No activa una ruta fail-to-wire ni excluye una conexión conocida de la Stateful Inspection.

Establecer entradas MAC estáticas solo de forma deliberada

La bridge forwarding table aprende normalmente las direcciones MAC de forma dinámica y decide por qué puerto reenviar los frames. static-entry puede vincular una dirección MAC a una bridge, una interfaz y un puerto. La plantilla oficial del comando es:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Los corchetes y las llaves describen la sintaxis y no se copian en el comando. Antes de add, se comprueban los IDs reales mediante show, la finalización con Tab y su correspondencia en WebAdmin. Una entrada estática incorrecta u obsoleta puede dirigir frames al puerto equivocado o dejar el destino inaccesible. Para el rollback se elimina exactamente la entrada documentada con delete. Después deben volver a funcionar el aprendizaje MAC, las rutas de ida y vuelta y el acceso de administración.

No utilizar el límite de members como objetivo de escalado

El límite interno actual se muestra con:

system bridge max_bridge_members show

Device Console acepta valores de max_bridge_members entre 2 y 256 y también ofrece reset:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

Esto no debe equipararse al límite publicado de WebAdmin. Sophos sigue indicando un máximo de 64 members para una bridge. Por tanto, el rango mayor de la CLI no es un objetivo de diseño admitido para una bridge con 256 interfaces. Solo se modifica para una excepción demostrada y tras coordinarla con Sophos Support. Como la ayuda no indica el valor predeterminado resultante después de reset, se documenta previamente si el estado inicial era un valor propio o el predeterminado. El rollback restaura exactamente ese estado.

Añadir la bridge en WebAdmin

1. Abrir Network > Interfaces > Add interface > Add bridge.
2. Introducir un Name descriptivo de hasta 58 caracteres, por ejemplo Bridge_Inline.
3. Definir un Hardware name inmutable de hasta 10 letras, números y _, por ejemplo brinline. Nombres del sistema como all, ipsec0, xfrm, Port, eth, WLAN o Halink están reservados.
4. Activar Enable routing on this bridge pair solo si la bridge debe recibir conscientemente una dirección IP y enrutar.
5. Añadir las Member interfaces preparadas y sus zonas.
6. Para una bridge enrutada, configurar IPv4 o IPv6 y el gateway previsto para members WAN.
7. Revisar los ajustes VLAN, ARP, STP, MTU, MSS y EtherType.
8. Seleccionar Save y comprobar después el enlace, las reglas y un flujo real.

El nombre visible se puede cambiar más adelante. El Hardware name permanece inmutable y debe coincidir con la convención de nombres antes de guardar.

Entender los filtros VLAN y EtherType

Con Filter VLANs, solo se reenvían las VLAN introducidas en Permitted VLAN ID or ID range. Se permiten rangos como 20-35. Si el filtro está activo y la lista queda vacía, SFOS descarta todo el tráfico VLAN tagged; el tráfico untagged no se ve afectado.

Este filtro solo actúa sobre frames bridged. No es una regla de firewall para tráfico enrutado. El caso específico de versiones con configuraciones antiguas system vlan-tag se explica en Comprobar Bridge-VLAN después de SFOS 22.

Filter Ethernet frames permite limitar EtherTypes. Sin valores permitidos, se descartan todos los frames salvo ARP, IPv4, IPv6, 8021Q y EXTE, que siempre están permitidos. Otros tipos se añaden como ID hexadecimal de cuatro cifras, por ejemplo 809B, 8138, 8863 o 8864. Estas excepciones solo se agregan por una necesidad concreta de protocolo.

ARP, STP, MTU y MAC aging

Permit ARP broadcast está activo de forma predeterminada. Sin broadcasts ARP, la bridge no puede crear una tabla MAC normal mediante ARP. Desactivarlo no es una protección general contra broadcast, sino una medida limitada ante una storm confirmada y exige entradas estáticas adecuadas en Neighbors (ARP–NDP).

Spanning Tree Protocol (STP) protege frente a bucles de capa 2 y puede activar una ruta redundante. Sin embargo, STP no puede activarse en interfaces bridge mientras HA esté activo. Un diseño no debe confiar a la vez en una prevención de bucles desconocida y en HA. STP max age es 20 segundos de forma predeterminada y solo se cambia de acuerdo con todo el dominio STP.

MAC aging elimina direcciones MAC inactivas después de 300 segundos de forma predeterminada. Valores más cortos pueden encajar en redes dinámicas y valores más largos en redes estables. Los cambios se justifican con el comportamiento del switch y de las aplicaciones, no como consejo general de rendimiento.

Si difieren las MTU de la bridge y sus members, la bridge hereda el valor menor. Un member con MTU 1500 limita también una bridge configurada con 9000. Override MSS solo se usa ante un problema TCP o MTU demostrado. Comprobar MTU y MSS en Sophos Firewall ofrece un procedimiento controlado.

Reglas, NAT y web proxy

El tráfico entre members necesita una regla de firewall adecuada entre las zonas implicadas. Source, destination y service se limitan al máximo, y el logging queda activo durante la comprobación. Reglas de firewall en Sophos Firewall explica el comportamiento general.

Una bridge sin dirección IP tiene una condición de parada importante: si el tráfico coincide con una regla que usa web proxy filtering o con una regla NAT, SFOS puede descartar los paquetes sin registrar un log. Este comportamiento no debe interpretarse como un drop ordinario en Log Viewer.

Si una regla NAT es inevitable, se usa Override source translation for specific outbound interfaces para esta bridge concreta, se establece Outbound interface en la bridge y Translated source (SNAT) en Original. Una modificación NAT amplia no es una prueba segura. Web proxy filtering solo se usa en una bridge transparente si el diseño lo admite expresamente.

Probar la bridge de forma controlada

Después de guardar se comprueban por separado el control plane y el tráfico de usuario:

1. En Network > Interfaces, comparar bridge, members, zonas, modo IP y estado del enlace con el plan.
2. Confirmar la Firewall Rule ID esperada con un único flujo controlado.
3. Comparar entrada y salida en Packet Capture; direcciones MAC, tag VLAN y EtherType deben coincidir con el diseño.
4. Probar un servicio permitido en ambas direcciones y hacer una prueba negativa de uno expresamente prohibido.
5. Con STP, activar rutas redundantes individualmente y solo en una ventana de mantenimiento, midiendo topología y failover.
6. Con HA, volver a comprobar bridge, members, aprendizaje MAC y aplicaciones tras un cambio de rol controlado.

Para drops de Bridge ACL, activar Bridge ACLs en System services > Log settings > Firewall. En Log Viewer se puede filtrar por Log component > Bridge ACLs y los subtipos ARP broadcasts, EtherType filtering o VLAN filtering.

Si el datapath sigue sin estar claro, Packet Capture en Sophos Firewall explica cómo leer conjuntamente interfaces de entrada y salida, Rule ID, estado y motivo.

Volver atrás de forma segura

Antes de borrar se documentan Object Usage, reglas, NAT, VLAN, DHCP, rutas, hosts y acceso de gestión de la bridge y todos los members. Primero se crea una ruta alternativa y se prueba con tráfico real. Solo entonces se eliminan las dependencias productivas, se borra la bridge y se vinculan los members a sus nuevas funciones de forma controlada.

Un ping correcto no basta como prueba de rollback. Después se vuelven a comprobar gateway, DNS, gestión, aplicaciones productivas, Firewall Rule ID y ruta de retorno.

Preguntas frecuentes