Configure and test a Sophos Firewall bridge interface
A bridge interface connects several physical or virtual interfaces at layer 2. This allows a Sophos Firewall to be inserted transparently into an existing path or used as a deliberately routed bridge gateway. Make the key decision before creating it: should the bridge only forward frames, or should it have an IP address and route traffic itself?
⚠️ An incorrect bridge configuration can cause a layer 2 loop, a broadcast storm, or loss of management access. Before cabling, prepare a backup, a maintenance window, independent administrator access, and a clear recovery path. Don’t enable redundant layer 2 paths until STP and the HA design are understood.
Transparent or routed
A transparent bridge without an IP address forwards frames between its members. It can connect networks without acting as their gateway. This suits controlled migrations or an inline path where the existing IP architecture should remain unchanged.
A routed bridge with an IP address is enabled with Enable routing on this bridge pair. The bridge IP can then act as a gateway or local firewall endpoint. VLAN filtering on the bridge applies only to bridged traffic, not routed traffic.
On supported XGS models, a fixed hardware bridge port pair can additionally serve as a Fail-to-Wire path. Set up and test LAN Bypass in a controlled way explains the model boundary, FTW port pair, unscanned outage traffic, and return to protected operation. Two arbitrary bridge members do not gain this hardware function.
A bridge isn’t a universal replacement for a dedicated WAN or VPN interface. Sophos doesn’t support Dynamic DNS, DHCP client, PPPoE, or IPsec VPN on bridge interfaces. VLANs and routing are often easier to operate for new segmented networks. Zones and interfaces on Sophos Firewall explains how to choose between aliases, bridges, LAGs, VLANs, XFRM, and RED.
Plan the example and members
The example connects Port3 and Port4 transparently. Both ports are in the same planned layer 2 path, and the bridge receives no IP address. These are example values and must be replaced with the actual cabling, zones, and management strategy.
SFOS allows up to 64 members. Members can be physical interfaces, RED, LAG, and VLAN interfaces on a physical interface, RED, or LAG. Check every member beforehand for existing IP addresses, VLANs, DHCP, NAT, rules, routing, and administrative access.
Member zones remain relevant to firewall rules. A bridge doesn’t permit traffic automatically. For example, if both members are in LAN, the required data flow may still need a matching LAN-to-LAN rule.
Advanced Bridge Controls in the Device Console
Routine bridge configuration remains in WebAdmin. The Device Console provides three additional system-wide or low-level controls. Before using them, preserve the bridge name, hardware name, members, port IDs, MAC table, management path, and current CLI state. These commands aren’t a shortcut for missing firewall rules or an unresolved Layer 2 design.
Handle Unknown Non-routable Traffic
bypass-firewall-policy applies to non-routable bridge traffic for which no security policy is applied. SFOS distinguishes between dynamic and static. Read the current status of both categories first:
system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static
The available actions are allow and drop. allow is security-sensitive because this traffic can be forwarded explicitly without a firewall policy. The SFOS 22 help states neither a default nor the exact distinction between dynamic and static. Don’t change either category on suspicion. If Sophos Support directs a change, replace show with allow or drop in the same syntax, then verify the status, a packet capture, and both a positive and negative test flow.
This switch is neither LAN Bypass nor a stateful firewall bypass rule. It doesn’t activate a fail-to-wire path or remove a known connection from stateful inspection.
Set Static MAC Entries Only Deliberately
The bridge forwarding table normally learns MAC addresses dynamically and uses them to decide through which port to forward frames. static-entry can bind a MAC address to a bridge, interface, and port. The official command template is:
system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]
The brackets describe syntax and aren’t copied into the command. Before add, verify the actual IDs with show, Tab completion, and their WebAdmin mapping. An incorrect or stale static entry can direct frames to the wrong port or make the destination unreachable. For rollback, remove the exact documented entry with delete. Afterwards, MAC learning, forward and return paths, and management access must work again.
Don’t Use the Member Limit as a Scaling Target
Show the current internal limit with:
system bridge max_bridge_members show
The Device Console accepts max_bridge_members values from 2 to 256 and also provides reset:
system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset
Don’t equate this with the published WebAdmin boundary. Sophos continues to state a maximum of 64 members for a bridge interface. The larger CLI range therefore isn’t a supported design target for a bridge with 256 interfaces. Change it only for an evidenced exception and after coordinating with Sophos Support. Because the help doesn’t state the resulting default after reset, record whether the starting state was a custom value or the default. Rollback restores exactly that state.
Add the bridge in WebAdmin
- Open Network > Interfaces > Add interface > Add bridge.
- Enter a descriptive Name of no more than 58 characters, such as
Bridge_Inline. - Set an immutable Hardware name of no more than 10 letters, numbers, and
_, such asbrinline. System names includingall,ipsec0,xfrm,Port,eth,WLAN, andHalinkare reserved. - Turn on Enable routing on this bridge pair only when the bridge should deliberately receive an IP address and route traffic.
- Add the prepared Member interfaces and their zones.
- For a routed bridge, configure IPv4 or IPv6 and the planned gateway for WAN members.
- Review the VLAN, ARP, STP, MTU, MSS, and EtherType settings.
- Select Save, then verify the link, rules, and a real data flow.
The descriptive display name can be changed later. The Hardware name is immutable and should match the naming convention before saving.
Understand VLAN and EtherType filters
With Filter VLANs, only the VLANs entered under Permitted VLAN ID or ID range are forwarded. Ranges such as 20-35 are allowed. If the filter is enabled and the list is empty, SFOS drops all tagged VLAN traffic; untagged traffic isn’t affected.
This filter only applies to bridged frames. It isn’t a firewall rule for routed traffic. The version-specific issue involving legacy system vlan-tag configurations is covered separately in Check bridge VLANs after SFOS 22.
Filter Ethernet frames can restrict EtherTypes on the bridge. Without permitted values, all frames except the always permitted ARP, IPv4, IPv6, 8021Q, and EXTE types are dropped. Add other types as four-digit hexadecimal IDs, such as 809B, 8138, 8863, or 8864. Only add these permits for a specific protocol requirement.
ARP, STP, MTU, and MAC aging
Permit ARP broadcast is enabled by default. Without ARP broadcasts, the bridge can’t build a normal MAC table through ARP. Turning this off isn’t a general broadcast-protection measure. It is a narrow response to a confirmed storm and requires suitable static entries under Neighbors (ARP–NDP).
Spanning Tree Protocol (STP) prevents layer 2 loops and can activate a redundant path. However, STP can’t be turned on for bridge interfaces while HA is enabled. A design must not depend on an unknown loop-prevention mechanism and HA at the same time. STP max age defaults to 20 seconds and should only be changed to match the entire STP domain.
MAC aging removes inactive MAC addresses after 300 seconds by default. Shorter values can suit dynamic networks, and longer values can suit stable networks. Base changes on the switch and application behavior, not on a generic performance tip.
If the bridge and member MTUs differ, the bridge inherits the lower value. A member with MTU 1500 therefore also limits a bridge configured for 9000. Use Override MSS only for a confirmed TCP or MTU issue. Check MTU and MSS on Sophos Firewall provides a controlled diagnostic path.
Rules, NAT, and web proxy
Traffic between bridge members needs a matching firewall rule between the participating zones. Keep source, destination, and service as narrow as possible, and leave logging on during validation. Firewall rules on Sophos Firewall explains the general rule behavior.
A bridge without an IP address has an important stop condition: if traffic matches a firewall rule with web proxy filtering or a NAT rule, SFOS can drop the packets without a log entry. Don’t interpret that behavior as an ordinary drop in Log Viewer.
If a NAT rule is unavoidable in the path, use Override source translation for specific outbound interfaces for this exact bridge, set Outbound interface to the bridge, and set Translated source (SNAT) to Original. A broad NAT change isn’t a safe test. Use web proxy filtering on a transparent bridge only when the design explicitly supports it.
Test the bridge in a controlled way
After saving, test the control plane and user traffic separately:
- Under Network > Interfaces, compare the bridge, members, zones, IP mode, and link status with the plan.
- Confirm the expected Firewall Rule ID with one controlled test flow.
- Compare ingress and egress in Packet Capture; MAC addresses, VLAN tag, and EtherType must match the design.
- Test one permitted service in both directions and negatively test one deliberately prohibited service.
- With STP, enable redundant paths individually only in a maintenance window and measure topology and failover.
- With HA, recheck the bridge, members, MAC learning, and applications after a controlled role change.
For bridge ACL drops, enable Bridge ACLs under System services > Log settings > Firewall. In Log Viewer, filter for Log component > Bridge ACLs and the subtypes ARP broadcasts, EtherType filtering, or VLAN filtering.
If the data path remains unclear, Packet Capture on Sophos Firewall explains how to read ingress and egress interfaces, Rule ID, status, and reason together.
Roll back safely
Before deletion, document Object Usage, rules, NAT, VLANs, DHCP, routes, hosts, and management access for the bridge and all members. First create a replacement path and test it with real traffic. Only then remove production dependencies, delete the bridge, and bind the members to their new roles in a controlled way.
One successful ping isn’t sufficient proof of rollback. Recheck the gateway, DNS, management, production applications, Firewall Rule ID, and return path after the change.