Configurar y probar una interfaz bridge en Sophos Firewall

Una interfaz bridge conecta dos o más interfaces en la capa 2. De este modo, es posible insertar Sophos Firewall en un enlace de red existente sin cambiar la subred ni la puerta de enlace predeterminada de los clientes. El bridge puede funcionar de forma transparente, sin dirección IP, o enrutar mediante una dirección IP propia.

En el ejemplo de este artículo, el firewall se instala entre un router existente y el switch principal. Port4 está orientado hacia el router y pertenece a la zona WAN; Port3, hacia el switch interno y pertenece a la zona LAN. El bridge no tiene dirección IP. WebAdmin sigue accesible a través de un puerto de administración independiente.

⚠️ Al guardar la configuración, el bridge pasa a controlar sus interfaces miembro. Una zona incorrecta, la ausencia de una ruta de administración o un enlace redundante de capa 2 pueden interrumpir el acceso o provocar un bucle. Antes de continuar, cree una copia de seguridad, documente el cableado y pruebe un acceso de administración independiente. No conecte una segunda ruta física hasta haber definido el uso de STP y, si corresponde, el diseño de HA.

¿Qué tipo de bridge se ajusta al objetivo?

Bridge transparente sin dirección IP

Un bridge transparente reenvía tramas Ethernet entre sus miembros, pero no actúa como puerta de enlace. Las direcciones IP, la subred y la puerta de enlace predeterminada de los dispositivos finales no cambian. Este diseño resulta adecuado para una migración controlada o para añadir una capa de seguridad entre un router existente y la red interna. Según la regla y la licencia, SFOS puede aplicar DPI, IPS, análisis de malware e inspección del correo electrónico en ese punto, aunque el router existente continúe siendo la puerta de enlace.

Que sea transparente no significa que el tráfico pase sin filtrado. Las zonas de los miembros determinan qué regla de firewall puede aplicarse. Para el trayecto de ejemplo, desde Port3 en la zona LAN hasta Port4 en la zona WAN, se necesita una regla LAN-to-WAN adecuada. Si ambos miembros pertenecen a LAN, se necesita en su lugar una regla LAN-to-LAN.

En Planificar zonas e interfaces en Sophos Firewall se explica cómo elegir los niveles de confianza, crear zonas propias y asignarles interfaces. Todas las decisiones específicas del bridge se detallan en este artículo; el artículo de fundamentos sirve de apoyo cuando el modelo de zonas es nuevo o no es uniforme.

Si el bridge no tiene una dirección IP, la administración debe realizarse a través de otra interfaz. En el ejemplo, Port2 utiliza una red de administración independiente. Así, WebAdmin permanece accesible aunque la configuración del bridge o sus reglas aún no sean correctas, o exista un problema de cableado.

Bridge enrutado con dirección IP

Al activar Enable routing on this bridge pair, el bridge obtiene una dirección IP y puede actuar como puerta de enlace o como extremo local del firewall. Esto cambia por completo su función: además del reenvío de capa 2, aparecen tráfico enrutado, servicios locales y, posiblemente, dependencias de puerta de enlace.

El filtrado de VLAN del bridge sigue aplicándose únicamente a las tramas que atraviesan el bridge. No filtra el tráfico que este enruta. Por tanto, si el bridge se utiliza como puerta de enlace, también deben revisarse el enrutamiento, Device Access, las reglas de firewall y NAT.

La ayuda de SFOS 22 contiene información ambigua sobre DHCP. Para asignar la dirección IP de un bridge enrutado, enumera Static y DHCP, pero en el mismo documento indica que los clientes DHCP no son una función compatible con bridges. Por ello, en un diseño de producción predecible debe utilizarse una dirección estática. DHCP solo debe usarse en un bridge tras comprobar la versión concreta de SFOS y obtener la confirmación de Sophos.

Bridge Mode en el asistente de configuración

La opción Bridge Mode del asistente de configuración inicial y una interfaz bridge creada posteriormente en Network > Interfaces se basan en el mismo principio de capa 2, pero corresponden a procedimientos distintos.

En un appliance nuevo, el puerto A utiliza de forma predeterminada 172.16.16.16/24 y el puerto B obtiene su dirección por DHCP. Para realizar la configuración inicial, puede asignarse, por ejemplo, 172.16.16.2/24 a un ordenador y conectarlo al puerto A. WebAdmin estará disponible en https://172.16.16.16:4444. En el asistente se selecciona Internet gateway (Bridge Mode). Tras completar el registro y configurar la protección y las notificaciones, SFOS aplica la configuración y se reinicia.

Este modo está pensado para el despliegue inicial completo. No debe volver a ejecutarse el asistente en un firewall existente para crear un único par de interfaces bridge. Si el asistente se ejecuta después de configurar HA, desactiva HA.

Bridge Mode es compatible con HA. Sin embargo, mientras HA esté activo, no es posible activar la función STP de SFOS en ninguna interfaz bridge. Esto no debe confundirse con el reenvío de paquetes STP, RSTP y de enrutamiento multicast. Un bridge transparente puede dejar pasar estas tramas sin participar por sí mismo en la prevención de bucles mediante la opción de SFOS Turn on Spanning Tree Protocol (STP).

Planificar el ejemplo antes de configurar

Topología y valores de ejemplo

El router existente continúa siendo la puerta de enlace predeterminada de la red 10.20.0.0/24. El firewall se inserta de forma transparente en su enlace LAN:

Internet
   |
Router existente: 10.20.0.1
   |
Port4, zona WAN
[ Bridge_Inline / brinline / sin dirección IP ]
Port3, zona LAN
   |
Switch principal y clientes: 10.20.0.0/24

Ruta de administración independiente:
Port2, zona LAN, 10.99.0.1/24

Después de instalar el firewall, un cliente con 10.20.0.50/24 sigue utilizando 10.20.0.1 como puerta de enlace. El bridge no recibe ninguna dirección de 10.20.0.0/24 ni una ruta predeterminada. Los números de puerto, las zonas, la red de administración y las reglas deben adaptarse al entorno. La red del ejemplo no debe trasladarse sin más a un entorno de producción.

Antes de modificar la instalación, conviene registrar dos situaciones: qué conexiones funcionan antes de insertar el firewall y por qué ruta puede administrarse este si falla el trayecto de datos de producción. Como mínimo, deben comprobarse DNS, la puerta de enlace, una aplicación habitual, el rendimiento esperado y el acceso a WebAdmin.

Comprobar miembros, zonas y dependencias

Un bridge puede tener hasta 64 miembros. Pueden utilizarse como miembros:

• interfaces físicas;
• interfaces RED;
• LAG;
• interfaces VLAN sobre una interfaz física, RED o LAG.

Tener más miembros no mejora el diseño. Cada conexión adicional amplía el dominio de capa 2, la tabla MAC y el número de posibles bucles. Para un trayecto inline suelen bastar dos miembros.

Antes de añadir una interfaz, revise si tiene direcciones IP, VLAN, DHCP, puertas de enlace, NAT, reglas de firewall, enrutamiento, Device Access u Object Usage asociados. El hecho de convertir un puerto en miembro de un bridge no elimina automáticamente su función anterior de todos los objetos que dependen de él.

Según Sophos, las interfaces bridge no son compatibles con Dynamic DNS, PPPoE ni IPsec VPN. Como se ha indicado, la información sobre DHCP también es contradictoria. Por tanto, un bridge no sustituye de forma universal a una interfaz WAN o VPN. En redes nuevas con una segmentación clara, las VLAN y el enrutamiento suelen ser más fáciles de administrar.

LAN Bypass es una función de hardware independiente, no el comportamiento habitual de cualquier bridge. En Configurar LAN Bypass y probarlo de forma controlada se explican los modelos y pares de puertos compatibles, así como su comportamiento en caso de fallo.

Crear el bridge en WebAdmin

Nombre, Hardware name y miembros

1. Abra Network > Interfaces > Add interface > Add bridge.
2. En Name, introduzca, por ejemplo, Bridge_Inline. El nombre visible puede tener hasta 58 caracteres y puede modificarse posteriormente.
3. En Hardware name, introduzca, por ejemplo, brinline. El valor puede tener como máximo 10 caracteres y solo puede contener letras, números y _. No puede modificarse después de guardar.
4. Para el ejemplo transparente, deje desactivada la opción Enable routing on this bridge pair.
5. Añada Port3 con la zona LAN y Port4 con la zona WAN como Member interfaces.
6. Revise la configuración de VLAN, ARP, STP, MAC, MTU, MSS y EtherType.
7. No seleccione Save hasta haber comprobado que el acceso de administración independiente funciona y que ambos cables están identificados sin ambigüedad.

SFOS no permite utilizar nombres de hardware reservados. La lista completa de la ayuda de SFOS 22 es la siguiente:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

En un bridge enrutado también se configura IPv4 o IPv6. Si contiene miembros WAN, aparecen además campos de puerta de enlace. Estos valores deben ajustarse al diseño de enrutamiento real. En el bridge transparente del ejemplo se dejan vacíos.

Filtros de VLAN y EtherType

Filter VLANs limita el tráfico etiquetado a los identificadores introducidos en Permitted VLAN ID or ID range. Se admiten valores individuales y rangos como 20-35. Si el filtro está activo pero la lista está vacía, SFOS descarta todo el tráfico VLAN etiquetado. El tráfico sin etiqueta sigue pasando. Esta combinación puede resultar engañosa durante el diagnóstico.

El filtro de VLAN solo se aplica a las tramas que reenvía el bridge. No sustituye a las reglas de firewall ni controla el tráfico enrutado. Las etiquetas VLAN históricas configuradas mediante CLI requieren una revisión específica en SFOS 22. El procedimiento Comprobar las VLAN de un bridge después de actualizar a SFOS 22 aborda este caso particular e incluye la información de versiones correspondiente.

La opción Filter Ethernet frames permite restringir los EtherTypes. Sin el filtro, el bridge admite todas las tramas Ethernet. Si se activa el filtro sin añadir ningún tipo permitido, solo se admiten ARP, IPv4, IPv6, 8021Q y EXTE. Los demás protocolos se introducen mediante un identificador hexadecimal de cuatro dígitos; por ejemplo, 809B para AppleTalk, 8138 para Novell, y 8863 y 8864 para PPPoE.

No añada un EtherType de forma preventiva. Primero debe verificarse en Packet Capture qué protocolo falta realmente. De lo contrario, se genera una lista de excepciones difícil de interpretar y que más adelante nadie podrá atribuir con seguridad a una necesidad concreta.

ARP, STP y MAC aging

Permit ARP broadcast está activado de forma predeterminada. El bridge necesita ARP para aprender las correspondencias entre direcciones IP y MAC y construir su tabla de reenvío. Desactivarlo no constituye una medida general de protección contra broadcasts. Solo resulta apropiado si se ha demostrado que existe una tormenta ARP y requiere asociaciones estáticas en Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) protege frente a bucles cuando existe más de un trayecto de capa 2 entre las mismas zonas. STP puede bloquear una ruta redundante y habilitarla si falla la ruta activa. Esta opción no está disponible en las interfaces bridge mientras HA está activo. Por tanto, un clúster HA con cableado redundante exige un diseño conjunto de los switches, las rutas de los puertos y la prevención de bucles.

El valor predeterminado de STP max age es de 20 segundos. SFOS utiliza BPDU para intercambiar información sobre la topología entre bridges. Este valor no debe ajustarse de forma aislada en el firewall, sino de acuerdo con todo el dominio STP.

De forma predeterminada, MAC aging elimina las direcciones MAC inactivas después de 300 segundos. Un valor inferior permite reaccionar con más rapidez a los cambios de dispositivo en una red de invitados o de pruebas muy dinámica. En una red estable de centro de datos, un valor superior evita procesos innecesarios de reaprendizaje. Solo debe cambiarse si lo justifican la inestabilidad de las asociaciones MAC, los cambios frecuentes de ubicación o un requisito operativo concreto.

MTU y MSS

Si la MTU del bridge difiere de la de sus miembros, el bridge adopta el menor de los valores. Un bridge con una MTU de 9000 funciona en la práctica con 1500 si uno de sus miembros solo admite 1500. El valor heredado aparece en la tabla de interfaces.

Override MSS afecta a TCP. Este valor limita la carga útil de cada segmento TCP para evitar que las cabeceras adicionales o la encapsulación de un túnel superen la MTU efectiva. Puede resolver un problema demostrado de MTU o fragmentación, pero no corrige una VLAN incorrecta, una regla ausente ni una ruta de retorno defectuosa. El MSS clamping no reduce el tamaño del tráfico UDP. El procedimiento de diagnóstico detallado se describe en Comprobar MTU y MSS cuando hay problemas de VPN.

Reglas de firewall, NAT y Web Proxy

El bridge no elude el firewall con estado. En el ejemplo, el tráfico de los clientes necesita una regla de LAN a WAN. Como Source Network se utiliza 10.20.0.0/24 o un objeto más específico; Destination y Service deben limitarse estrictamente a lo necesario. El registro permanece activo durante las pruebas de aceptación.

Si aún necesita definir el orden de las reglas, la coincidencia de zonas o las funciones de protección, consulte el procedimiento completo en Configurar reglas de firewall en Sophos Firewall. En el caso del bridge, lo determinante sigue siendo por qué zonas de los miembros entra y sale cada trama concreta.

Los paquetes de respuesta de una conexión permitida e iniciada desde el interior regresan mediante el estado existente. No se necesita para ello una regla WAN-to-LAN amplia. En cambio, las nuevas conexiones entrantes sí requieren una regla específica y deliberadamente restrictiva.

En un bridge sin dirección IP puede darse un tipo de error poco habitual. Si el tráfico coincide con una regla de firewall que utiliza Web Proxy Filtering o con una regla NAT, SFOS puede descartar los paquetes sin generar ninguna entrada en Log Viewer. En este caso, que el registro esté vacío no demuestra que no haya intervenido ninguna regla.

Si la regla NAT es necesaria, active Override source translation for specific outbound interfaces únicamente en esa regla. Defina Outbound interface como el bridge y Translated source (SNAT) como Original. Así se conserva la dirección de origen para esa salida. Modificar NAT de forma global no sería una prueba válida, ya que afectaría a otros trayectos de datos y ocultaría la causa real del problema.

Web Proxy Filtering solo debe utilizarse en un bridge transparente sin IP cuando el diseño y la versión de SFOS empleada lo contemplen expresamente. Para la inspección inline habitual, las reglas basadas en DPI constituyen un punto de partida más claro.

Validar el trayecto de datos y aislar errores

Comprobaciones después de guardar

Tras guardar, se comprueban por separado la configuración, el tráfico de los usuarios y el comportamiento en caso de error:

1. En Network > Interfaces, compare con el plan el nombre del bridge, el Hardware name, los miembros, las zonas, el modo IP, la MTU heredada y el estado del enlace.
2. Desde el cliente de prueba, establezca una conexión con un servicio necesario y confirme en Log Viewer la Firewall Rule ID esperada.
3. Compare la entrada y la salida en Packet Capture. Las direcciones MAC de origen y destino, la etiqueta VLAN, el EtherType y la interfaz deben corresponderse con la topología.
4. Pruebe un servicio permitido en ambos sentidos. A continuación, intente utilizar deliberadamente un servicio no permitido y compruebe que se produzca el descarte previsto.
5. Pruebe DNS, la puerta de enlace predeterminada y una aplicación de negocio habitual. Un solo ping no es suficiente.
6. Vuelva a comprobar el acceso de administración a través del puerto independiente.
7. Si se utiliza STP, conecte una ruta redundante únicamente durante una ventana de mantenimiento y mida el tiempo de conmutación y la pérdida de paquetes.
8. Si se utiliza HA, vuelva a probar el bridge, sus miembros, el aprendizaje de direcciones MAC y las aplicaciones después de un cambio de rol controlado.

No hay tráfico ni entradas en el registro

Si en Log Viewer no aparece ningún evento Allow ni Drop, compruebe primero los casos particulares de los bridges:

• ¿Carece el bridge de dirección IP?
• ¿Coincide el flujo con una regla NAT?
• ¿Utiliza Web Proxy Filtering la regla de firewall?
• ¿Está configurada como Original la anulación de SNAT para este bridge?
• ¿Muestra Packet Capture la trama en el miembro de entrada, pero no en el de salida?

Solo entonces conviene investigar un problema habitual de orden de reglas o de ruta de retorno. Así se evita responder a un descarte no registrado del bridge mediante reglas Allow cada vez más amplias.

Se descarta una VLAN o un EtherType

En System services > Log settings > Firewall, active el componente Bridge ACLs. A continuación, en Log Viewer puede filtrar por Log component > Bridge ACLs y también por los subtipos ARP broadcasts, EtherType filtering o VLAN filtering.

Si existen problemas con una VLAN, compruebe conjuntamente si el tráfico está etiquetado o no, la lista de VLAN permitidas y el perfil del puerto del switch. Si el problema afecta a un EtherType, Packet Capture muestra qué identificador de cuatro dígitos aparece realmente. El filtro y el dispositivo del otro extremo deben corresponder al mismo trayecto de datos.

El tráfico solo funciona en un sentido

Un flujo unidireccional suele indicar una zona incorrecta, una regla ausente, enrutamiento asimétrico o una entrada MAC que no se ha aprendido. En Packet Capture, compare los trayectos de ida y vuelta en ambos miembros. Después, compruebe la Rule ID, Source NAT, la puerta de enlace y la tabla MAC.

Bucle o asociaciones MAC inestables

Un volumen elevado de broadcasts, asociaciones MAC que cambian constantemente y enlaces inestables apuntan a un bucle o a un cableado redundante incorrecto. Desconecte la segunda ruta antes de modificar más filtros. Después, analice como un único conjunto STP en los switches, STP en SFOS, el cableado de HA y los miembros reales del bridge.

Un diseño HA no puede dar por supuesto que el firewall active al mismo tiempo su propia opción STP. Si los switches se encargan de evitar los bucles, la prueba de failover debe demostrar que no se genera ningún bucle ni queda bloqueada de forma permanente una ruta de producción.

Para identificar con más detalle la interfaz, la Rule ID, el estado y el motivo, también puede seguir el procedimiento de Packet Capture en Sophos Firewall. No obstante, las pruebas de aceptación específicas del bridge se describen íntegramente en esta página.

Controles avanzados en Device Console

La configuración habitual debe realizarse en WebAdmin. system bridge ofrece tres controles adicionales. Estos comandos no sustituyen una regla de firewall ausente ni un diseño de capa 2 sin definir. Antes de realizar cambios, registre el nombre del bridge, el Hardware name, los miembros, los identificadores de puerto, la tabla MAC, la ruta de administración y el estado actual en la CLI.

Gestionar tráfico desconocido no enrutable

bypass-firewall-policy afecta al tráfico no enrutable del bridge al que no se aplica ninguna Security Policy. SFOS distingue entre dynamic y static. Para consultar el estado actual, utilice:

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

Las acciones posibles son allow y drop. allow reenvía expresamente el tráfico afectado sin aplicar una Firewall Policy. La ayuda de SFOS 22 no indica ningún valor predeterminado ni explica con precisión la diferencia entre dynamic y static. Por tanto, esta opción solo debe modificarse para resolver un caso concreto con el acompañamiento de Sophos Support. Después, compruebe el estado en la CLI y Packet Capture, y pruebe un flujo permitido y otro bloqueado.

Esta opción no equivale ni a LAN Bypass ni a una stateful Firewall Bypass Rule. No habilita una ruta fail-to-wire ni excluye de la Stateful Inspection una conexión conocida.

Crear entradas MAC estáticas de forma selectiva

La Bridge Forwarding Table suele aprender las direcciones MAC de forma dinámica. static-entry asocia permanentemente una dirección MAC a un 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 forman parte de la descripción de la sintaxis y no deben copiarse. Antes de ejecutar add, compruebe los identificadores reales mediante show y la asignación correspondiente en WebAdmin. Una entrada incorrecta u obsoleta puede dirigir las tramas al puerto equivocado. Para revertir el cambio, elimine con delete exactamente la entrada documentada. Después, vuelva a comprobar el aprendizaje de direcciones MAC, los trayectos de ida y vuelta y el acceso de administración.

No utilizar el límite de miembros como objetivo de escalabilidad

Para consultar el límite interno actual, utilice:

system bridge max_bridge_members show

Device Console admite valores de 2 a 256 para max_bridge_members y también ofrece reset:

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

Los dos límites oficiales no son coherentes entre sí y la documentación no aclara el motivo. La ayuda de WebAdmin establece un máximo de 64 miembros, mientras que la ayuda de Device Console documenta valores de 2 a 256. Tampoco explica cómo se relacionan ambos datos. Por tanto, el rango de la CLI no basta para considerar válido un diseño de producto con más de 64 miembros.

Antes de modificar el valor, registre el estado actual mediante show. Si antes se utilizaba el valor predeterminado, revierta el cambio con reset. Si se había definido un límite propio, restablezca exactamente ese valor mediante set limit <valor anterior>. A continuación, vuelva a ejecutar show para confirmar el estado esperado.

Retirar el bridge de forma segura

Antes de eliminarlo, documente Object Usage, las reglas, NAT, las VLAN, DHCP, las rutas, los hosts, las zonas de los miembros y el acceso de administración. Primero, cree una ruta alternativa y pruébela con tráfico real. Solo entonces deben eliminarse las dependencias de producción, borrarse el bridge y volver a asignarse sus miembros de forma controlada.

Tras retirar el bridge, vuelva a comprobar la puerta de enlace, DNS, la administración, las aplicaciones de producción, la Firewall Rule ID y la ruta de retorno. El cambio no se considera finalizado hasta que estas pruebas coincidan con el estado inicial documentado.

Preguntas frecuentes