Configure and test a Sophos Firewall bridge interface

A bridge interface connects two or more interfaces at Layer 2. This allows a Sophos Firewall to be inserted into an existing network path without changing the clients’ subnet or default gateway. The bridge can operate transparently without an IP address or route traffic using its own IP address.

The example in this article places the firewall between an existing router and the core switch. Port4 connects to the router and belongs to the WAN zone; Port3 connects to the internal switch and belongs to the LAN zone. The bridge itself has no IP address. WebAdmin remains accessible through a separate management port.

⚠️ When you save the configuration, the bridge takes control of its member interfaces. An incorrect zone, a missing management path, or a redundant Layer 2 path can interrupt access or create a loop. First create a backup, document the cabling, and test an independent administrative connection. Do not connect a second physical path until you have resolved the STP configuration and any HA design considerations.

Which bridge mode meets your requirements?

Transparent bridge without an IP address

A transparent bridge forwards Ethernet frames between its members but does not act as a gateway. The IP addresses, subnet, and default gateway of the end devices remain unchanged. This approach is suitable for a controlled migration or for adding a security layer between an existing router and the internal network. Depending on the rule configuration and license, SFOS can apply DPI, IPS, malware scanning, and email scanning at this point even though the existing router remains the gateway.

Transparent does not mean unfiltered. The member zones determine which firewall rule can apply. The example path from Port3 in the LAN zone to Port4 in the WAN zone requires a matching LAN-to-WAN rule. If both members are in LAN, a LAN-to-LAN rule is required instead.

Plan zones and interfaces on Sophos Firewall explains how to select trust zones, create custom zones, and assign interfaces. This article covers all bridge-specific decisions; the introductory article is helpful when designing a new zone model or standardizing an inconsistent one.

Without a bridge IP address, administration should use another interface. In this example, Port2 uses a separate management network. WebAdmin therefore remains accessible even if the bridge, its rules, or the cabling are not yet correct.

Routed bridge with an IP address

With Enable routing on this bridge pair, the bridge receives an IP address and can act as a gateway or local firewall endpoint. This fundamentally changes its role: in addition to Layer 2 forwarding, the design must account for routed traffic, local services, and potentially gateway dependencies.

VLAN filtering on the bridge still applies only to bridged frames. It does not filter traffic routed by the bridge. If you use the bridge as a gateway, you must therefore also check routing, Device Access, firewall rules, and NAT.

The SFOS 22 help is ambiguous about DHCP. It lists Static and DHCP as IP assignment options for a routed bridge, but identifies DHCP clients as an unsupported bridge feature in the same document. Use a static address for a predictable production design. Use DHCP on a bridge only after checking the specific SFOS version and obtaining confirmation from Sophos.

Bridge mode in the setup assistant

Bridge Mode in the initial setup assistant and a bridge interface subsequently created under Network > Interfaces use the same Layer 2 principle, but they are separate workflows.

On a new appliance, Port A uses 172.16.16.16/24 by default, while Port B obtains its address through DHCP. For initial setup, configure a computer with an address such as 172.16.16.2/24 and connect it to Port A. WebAdmin is then available at https://172.16.16.16:4444. In the assistant, select Internet gateway (Bridge Mode). After registration and the protection and notification settings, SFOS applies the configuration and restarts.

This mode is intended for a complete initial deployment. Do not run an existing firewall through the assistant again merely to add a single bridge pair. Running the assistant after HA has already been configured disables HA.

Bridge Mode supports HA. However, the SFOS STP function cannot be enabled on any bridge interface while HA is active. This is distinct from forwarding STP, RSTP, and multicast routing packets. A transparent bridge can pass these frames without participating in loop prevention through the SFOS option Turn on Spanning Tree Protocol (STP).

Plan the example before configuration

Topology and example values

The existing router remains the default gateway for the 10.20.0.0/24 network. The firewall is inserted transparently into its LAN path:

Internet
   |
Existing router: 10.20.0.1
   |
Port4, WAN zone
[ Bridge_Inline / brinline / no IP address ]
Port3, LAN zone
   |
Core switch and clients: 10.20.0.0/24

Separate management path:
Port2, LAN zone, 10.99.0.1/24

After the firewall is installed, a client with 10.20.0.50/24 continues to use 10.20.0.1 as its gateway. The bridge receives neither an address from 10.20.0.0/24 nor a default route. Adapt the port numbers, zones, management network, and rules to your environment. Do not copy the example network unchanged into production.

Before making the change, record two baselines: which connections work before installation, and which path can be used to administer the firewall if the production data path fails? At a minimum, check DNS, the gateway, a typical application, expected throughput, and access to WebAdmin.

Check members, zones, and dependencies

A bridge can contain up to 64 members. Supported member types are:

• physical interfaces;
• RED interfaces;
• LAGs;
• VLAN interfaces on a physical interface, RED, or LAG.

Adding members does not improve bridge quality. Every additional connection expands the Layer 2 domain and MAC table and increases the potential for loops. Two members are normally sufficient for an inline path.

Before adding an interface, check it for existing IP addresses, VLANs, DHCP, gateways, NAT, firewall rules, routing, Device Access, and Object Usage. A port’s previous function does not automatically disappear from every dependent object simply because the port becomes part of a bridge.

According to Sophos, bridge interfaces do not support Dynamic DNS, PPPoE, or IPsec VPN. As noted above, the DHCP information is also contradictory. A bridge is therefore not a universal replacement for a WAN or VPN interface. For new, clearly segmented networks, VLANs and routing are often easier to operate.

LAN Bypass is a separate hardware function, not an inherent feature of an arbitrary bridge. Set up LAN Bypass and test it in a controlled manner explains which models and port pairs support this function and what happens during a failure.

Create the bridge in WebAdmin

Name, hardware name, and members

1. Open Network > Interfaces > Add interface > Add bridge.
2. Under Name, enter a value such as Bridge_Inline. The display name can contain up to 58 characters and can be changed later.
3. Under Hardware name, enter a value such as brinline. The value can contain no more than 10 characters and must consist only of letters, numbers, and _. It cannot be changed after you save the bridge.
4. Leave Enable routing on this bridge pair disabled for this transparent example.
5. Add Port3 in the LAN zone and Port4 in the WAN zone as Member interfaces.
6. Check the VLAN, ARP, STP, MAC, MTU, MSS, and EtherType settings.
7. Select Save only after confirming that the separate management connection works and that both cables are clearly labeled.

SFOS prohibits reserved hardware names. The complete list in the SFOS 22 help is:

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

For a routed bridge, also enter an IPv4 or IPv6 address. Gateway fields appear if the bridge contains WAN members. These values must match the actual routing design. Leave them empty for the transparent bridge in this example.

VLAN and EtherType filters

Filter VLANs restricts tagged traffic to the IDs entered under Permitted VLAN ID or ID range. You can enter individual values and ranges such as 20-35. If the filter is active but the list is empty, SFOS drops all tagged VLAN traffic. Untagged traffic continues to pass. This combination can be misleading during troubleshooting.

The VLAN filter applies only to frames forwarded by the bridge. It neither replaces firewall rules nor controls routed traffic. Legacy CLI VLAN tags require separate verification under SFOS 22. Check bridge VLANs after upgrading to SFOS 22 covers this special case and the relevant version information.

Filter Ethernet frames restricts EtherTypes. Without this filter, the bridge permits all Ethernet frames. If the filter is active but contains no permitted types, only ARP, IPv4, IPv6, 8021Q, and EXTE are permitted. Enter other protocols as four-digit hexadecimal IDs, such as 809B for AppleTalk, 8138 for Novell, and 8863 and 8864 for PPPoE.

Do not permit an EtherType preemptively. First use Packet Capture to identify the protocol that is actually missing. Otherwise, you create an exception list that is difficult to understand and cannot later be mapped reliably to its original requirements.

ARP, STP, and MAC aging

Permit ARP broadcast is enabled by default. The bridge needs ARP to learn IP-to-MAC mappings and build its forwarding table. Disabling this setting is not a general-purpose form of broadcast protection. It is appropriate only for a confirmed ARP storm and requires static bindings under Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) protects against loops when more than one Layer 2 path exists between the same network segments. STP can block a redundant path and switch to it if the active path fails. The option is unavailable on bridge interfaces while HA is active. An HA cluster with redundant cabling therefore requires a design that addresses switches, port paths, and loop prevention together.

STP max age is 20 seconds by default. SFOS uses BPDUs to exchange topology information between bridges. Do not optimize this value on the firewall in isolation; it must be appropriate for the entire STP domain.

By default, MAC aging removes inactive MAC addresses after 300 seconds. A lower value can respond more quickly to device changes in a highly dynamic guest or test network. In a stable data center network, a higher value prevents unnecessary relearning. Change this value only when justified by MAC flapping, frequent device moves, or a specific operational requirement.

MTU and MSS

If the MTU of the bridge differs from that of its members, the bridge uses the lower value. A bridge configured with an MTU of 9000 effectively remains at 1500 if one member supports only 1500. The inherited value appears in the interface table.

Override MSS applies to TCP. The value limits the payload in each TCP segment so that additional headers or tunnel encapsulation do not exceed the effective MTU. This can resolve a confirmed MTU or fragmentation problem, but it cannot fix an incorrect VLAN, a missing rule, or a broken return path. MSS clamping does not reduce the size of UDP traffic. For a detailed diagnostic procedure, see Check MTU and MSS for VPN problems.

Firewall rules, NAT, and Web Proxy

The bridge does not bypass the stateful firewall. In this example, client traffic requires a rule from LAN to WAN. Use 10.20.0.0/24 or a more specific object as the Source Network, and restrict the destination and service to what is actually required. Keep logging enabled during validation.

If you still need to define rule order, zone matching, or protection features, see Configure firewall rules on Sophos Firewall for the complete introductory procedure. For the bridge, the determining factor remains the member zones through which the specific frame enters and exits.

Response packets for an allowed connection initiated from the internal network return as part of the existing state. They do not require a broad WAN-to-LAN rule. New inbound connections, however, require their own deliberately restricted rule.

A bridge without an IP address has an unusual failure mode. If traffic matches a firewall rule that uses Web Proxy Filtering or matches a NAT rule, SFOS may drop the packets without creating an entry in Log Viewer. In this case, an empty log does not prove that no rule is involved.

If the NAT rule is required, enable Override source translation for specific outbound interfaces in that rule. Set Outbound interface to the bridge and Translated source (SNAT) to Original. This preserves the source address on that outbound path. A global NAT change would be a poor test because it affects other data paths and obscures the actual cause.

Use Web Proxy Filtering on a transparent bridge without an IP address only if the design and the SFOS version explicitly support it. For standard inline inspection, DPI-based rules provide a more transparent starting point.

Validate the data path and isolate faults

Validation after saving

After saving, test the configuration, user traffic, and failure scenario separately:

1. Under Network > Interfaces, compare the bridge name, hardware name, members, zones, IP mode, inherited MTU, and link status with the plan.
2. Access a required service from the test client and confirm the expected Firewall Rule ID in Log Viewer.
3. Compare ingress and egress in Packet Capture. The source and destination MAC addresses, VLAN tag, EtherType, and interface must match the topology.
4. Test an allowed service in both directions. Then attempt a deliberately disallowed service and confirm the expected drop.
5. Test DNS, the default gateway, and a typical business application. A single ping is not sufficient.
6. Recheck management access through the independent port.
7. If you use STP, connect a redundant path only during a maintenance window and measure the convergence time and packet loss.
8. With HA, retest the bridge, members, MAC learning, and applications after a controlled role change.

No traffic and no log entry

If neither an Allow nor a Drop entry appears in Log Viewer, check the bridge-specific cases first:

• Does the bridge have no IP address?
• Does the flow match a NAT rule?
• Does the firewall rule use Web Proxy Filtering?
• Is the SNAT override set to Original for this bridge?
• Does Packet Capture show the frame on the ingress member but not on the egress member?

Only then investigate a conventional rule-order or return-path problem. This approach prevents you from responding to an unlogged bridge drop by creating increasingly broad Allow rules.

VLAN or EtherType is dropped

Under System services > Log settings > Firewall, enable the Bridge ACLs component. In Log Viewer, you can then filter by Log component > Bridge ACLs and further by the subtypes ARP broadcasts, EtherType filtering, or VLAN filtering.

For VLAN problems, check the tagged or untagged state, permitted VLAN list, and switch port profile together. For EtherType problems, Packet Capture shows the four-digit ID that is actually present. The filter and the peer configuration must describe the same data path.

Traffic works in only one direction

One-way traffic usually indicates an incorrect zone, a missing rule, asymmetric routing, or an unlearned MAC entry. Use Packet Capture to compare the outbound and return paths on both members. Then check the Rule ID, Source NAT, gateway, and MAC table.

Loop or flapping MAC addresses

A high volume of broadcasts, changing MAC mappings, and unstable links indicate a loop or incorrectly cabled redundancy. Disconnect the second path before changing any other filters. Then assess switch STP, SFOS STP, HA cabling, and the actual bridge members as a single design.

An HA design must not assume that the firewall can also enable its own STP option. If the switches provide loop prevention, the failover test must demonstrate that it creates neither a loop nor a permanently blocked production path.

For detailed mapping of the interface, Rule ID, status, and reason, you can also follow Packet Capture on Sophos Firewall. The bridge validation procedure above is nevertheless fully documented on this page.

Advanced controls in the Device Console

Use WebAdmin for the standard configuration. system bridge provides three additional controls. These commands cannot compensate for a missing firewall rule or an unresolved Layer 2 design. Before making changes, record the bridge name, hardware name, members, port IDs, MAC table, management path, and current CLI status.

Handle unknown non-routable traffic

bypass-firewall-policy applies to non-routable bridge traffic to which no security policy is applied. SFOS distinguishes between dynamic and static. Display their current states with:

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 explicitly forwards the affected traffic without a firewall policy. The SFOS 22 help specifies neither a default value nor the exact distinction between dynamic and static. Make a change only for a specific case being handled with Sophos Support. Afterward, verify the CLI status and Packet Capture, then test one permitted and one blocked flow.

This switch is neither LAN Bypass nor a stateful firewall bypass rule. It does not activate a fail-to-wire path or exempt a known connection from stateful inspection.

Set static MAC entries deliberately

The Bridge Forwarding Table normally learns MAC addresses dynamically. static-entry binds a MAC address to a specific 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 are part of the syntax notation and must not be copied into the command. Before using add, verify the actual IDs with show and compare them with the WebAdmin mapping. An incorrect or outdated entry can direct frames to the wrong port. To roll back the change, use delete to remove the exact entry you documented. Then retest MAC learning, the forward and return paths, and management access.

Do not use the member limit as a scaling target

Display 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

The two official limits do not align without further explanation. The WebAdmin help specifies a maximum of 64 members, while the Device Console help documents values from 2 to 256. It does not explain how these figures relate to each other. Therefore, do not treat a value above 64 as a supported production design solely because it falls within the CLI range.

Before making a change, record the current state with show. If the default was previously active, use reset to restore it. If a custom limit was configured, restore that exact value with set limit <previous value>. Then run show again to confirm the expected state.

Remove the bridge safely

Before deleting the bridge, document Object Usage, rules, NAT, VLANs, DHCP, routes, hosts, member zones, and management access. First create a replacement path and test it with real traffic. Only then remove production dependencies, delete the bridge, and reassign the members in a controlled manner.

After removing the bridge, recheck the gateway, DNS, management access, production applications, Firewall Rule ID, and return path. The change is complete only when these test results match the documented baseline.

Frequently asked questions