Set up LAN Bypass and Fail-to-Wire on Sophos Firewall

LAN Bypass, also called Fail-to-Wire (FTW), connects a designated physical port pair directly during a power failure or hardware malfunction. The data path can remain available while the firewall is down. Sophos Firewall automatically resumes normal operation when power returns.

This availability has a clear security boundary: all traffic passes without scanning while bypassed. Firewall rules, IPS, Web Protection, Application Control, malware inspection, and logging cannot be enforced. LAN Bypass is a deliberate choice between connectivity and protection, not a performance or troubleshooting switch.

⚠️ Test LAN Bypass only in a planned maintenance window. During a real or simulated outage, the firewall has no visibility into this traffic. Critical networks need a documented risk decision, external monitoring, and a tested return to protected operation.

Requirements and boundaries

Sophos documents LAN Bypass for Sophos XGS 2xxx models and later, for example XGS 2100. The appliance must operate as a bridge in the intended path. Smaller XGS models, virtual firewalls, and cloud instances do not have this hardware feature.

Bypass ports form fixed hardware FTW pairs. Adding any two interfaces to a bridge is not sufficient. Confirm the actual pair on the appliance label, hardware guide, or model documentation. Depending on the appliance, one or both pairs can be enabled.

lanbypass is off by default. Before enabling it, confirm the FTW pair, LAN and WAN bridge path, independent management access, backup and owner, normal firewall rule, and a maintenance test that temporarily accepts unscanned traffic.

LAN Bypass is not a stateful firewall bypass rule, which is a software exception while the firewall runs. It also does not replace an HA cluster: HA transfers protected processing to another node, while FTW forwards traffic without protection.

Plan the port pair and bridge

The official Sophos KBA uses Port1 and Port2, zones LAN and WAN, and a routed bridge with a static IP and gateway as an example. These values are not a universal wiring plan. The hardware FTW pair and existing network design are authoritative.

Document both links before rewiring: switch or provider port, speed, duplex, VLANs, addressing, gateway, MAC dependencies, and zones. A bypass pair can transport only what both connected sides can exchange at Layers 1 and 2 without an active firewall.

A bridge can be transparent without an IP or deliberately routed with one. FTW alone creates neither gateway, firewall rule, nor NAT. Set up and test a bridge interface explains the IP mode, members, STP, VLAN filtering, rules, and management risk.

Configure the bridge and protected operation

Under Network > Interfaces > Add interface > Add bridge:

1. Set a clear name and immutable hardware name.
2. Add the confirmed FTW pair as bridge members and assign the intended zones.
3. Enable Enable routing on this bridge pair only if the bridge must have an IP and route.
4. For a routed bridge, enter the real IP, netmask, and gateway.
5. Save, confirm the displayed Add Bridge step, and cable the pair correctly.
6. Create a narrow, logged firewall rule for normal traffic between the zones.
7. Test allowed and deliberately denied traffic and verify Rule ID, NAT, IPS, and return path.

The rule is essential while the firewall is running. It cannot inspect packets during a powerless hardware bypass. A normal-operation test therefore does not prove FTW, and a successful FTW test does not prove the protection rule.

Enable LAN Bypass in Device Console

After secured SSH login, open 4. Device Console and read the current state:

show lanbypass

Enable or disable the hardware feature:

set lanbypass on
set lanbypass off

Run show lanbypass after each change. on confirms configuration, not correct wiring or a working hardware pair.

The official KBA also lists xgs-ftw -h in Advanced Shell. It exposes model-specific status, bypass, arming, and watchdog options. These directly affect the hardware path and are not a general administrator recipe. For issues beyond show lanbypass and the documented set switch, record model, SFOS build, and status for Sophos Support.

Test Fail-to-Wire in a controlled way

A realistic test is intentionally disruptive. Proceed only when systems can tolerate a brief link interruption and temporarily unprotected traffic. Prepare out-of-band access, contacts, and abort criteria.

1. In normal operation, create an allowed flow in both directions and record Rule ID, security policy, and logs.
2. Confirm show lanbypass, speed, duplex, and link on both ports.
3. Start an external end-to-end monitor between both sides; a monitor on the firewall is unsuitable while power is off.
4. Interrupt power during maintenance. A brief link change or new client connections may occur; seamless sessions are not promised.
5. Confirm whether the planned traffic continues through the physical pair. Firewall scanning and logs are absent as expected.
6. Restore power and wait for SFOS, bridge members, and interfaces to become ready.
7. Create a new flow and verify the expected Firewall Rule ID, IPS or Web Policy, and logs.
8. Test deliberately denied traffic. This proves that the path is again protected rather than still bypassed.

Start with a small, recognizable pilot flow instead of full production load. This makes physical bypass, bridge policy, and external routing easier to distinguish.

Isolate common failures

No traffic passes during power failure

Check model support, the actual FTW pair, show lanbypass, cabling, and link parameters. Any two bridge members do not create a hardware bypass. Speed, duplex, and VLAN trunks must work on both sides without an active firewall.

The bridge fails during normal operation

Check members, zones, IP mode, gateway, firewall rule, NAT, and VLAN filters. LAN Bypass does not repair a bridge configuration. Packet Capture and Rule ID show whether normal traffic reaches the expected rule.

Protection does not return after power restoration

Test a deliberately blocked service and an IPS or Web Policy, not only connectivity. If logs remain absent, check interfaces, bridge, rule match, and service state. Rule IDs and security events distinguish protected operation from FTW.

The bypass switches unexpectedly

Record model, SFOS build, show lanbypass, and event time. Do not change arming or watchdog values through xgs-ftw speculatively. Give topology, wiring, and status to Sophos Support.

Rollback and operations

When FTW is no longer required, first test the normal path, run set lanbypass off, and confirm with show lanbypass. This does not remove the bridge; migrate it separately if needed.

Operational documentation should record model, FTW pair, cable destinations, status, last test, risk owner, and next test date. Verify the assignment again after firmware changes, hardware replacement, or rewiring.

FAQ