Use a Sophos Firewall bypass rule safely

bypass-stateful-firewall-config excludes hosts or networks from normal firewall inspection. It isn’t a normal allow rule: the published SFOS 22 example uses separate source and destination entries, and the documented syntax can’t restrict them to a service or port. A host entry is therefore broader than the word “rule” might suggest.

The safe short version is to save the current state, add the narrowest possible dest_host and source_host entries for the test, validate the result with Packet capture, and immediately remove both entries with del. The selectors act independently: dest_host covers traffic to the destination host, while source_host covers traffic from the source host. Together, they don’t form a source-destination pair.

⚠️ A bypass reduces control and visibility for matching traffic. Use it only during a time-limited maintenance window with rollback prepared. Use a normal firewall rule or targeted policy exception for permanent access.

Which type of bypass this article covers

This article covers only bypass-stateful-firewall-config in the Device Console.

• Stateful firewall bypass: excludes a host or network from firewall inspection.
• DoS bypass rule: an exception under Protect > Intrusion prevention > DoS & spoof protection. It can additionally be scoped by IP version, source, destination, protocol, and ports, and isn’t the same feature.
• IPS Bypass session: an action within an IPS rule.
• FastPath / Firewall acceleration: accelerates known, trusted traffic. It isn’t a manual stateful firewall bypass.
• LAN bypass / fail-to-wire: a hardware feature on supported appliances that bridges a bypass port pair without scanning during a power or hardware failure.
• Normal exception: a targeted firewall, NAT, web, TLS, IPS, or Application Control policy change.

Check targeted options first

A bypass answers only a narrow diagnostic question: does the flow work when firewall inspection is skipped? It doesn’t identify the module or configuration responsible.

• Firewall rule doesn’t match: check order, zones, source, destination, and service.
• IPS blocks the flow: check the policy, signature, and possible exception.
• TLS inspection interferes: adjust the SSL/TLS inspection rule or TLS exclusion narrowly.
• Web filtering blocks the flow: check the web policy, category, URL group, or web exception.
• Application Control misclassifies it: check the policy and detected application.
• NAT or routing looks wrong: compare NAT Rule ID, Firewall Rule ID, return route, and Packet capture.

For a permanent connection, a normal Sophos Firewall rule with logging and the required security features remains the correct solution.

Prerequisites and change scope

Before running add, define:

• the specific test question and the source, destination, protocol, and port of the test flow;
• the narrowest possible hosts or networks rather than entire client, server, or VPN ranges;
• the ticket, owner, maintenance window, and abort condition;
• the output of show advanced-firewall before the change;
• an exact del command for every planned add command;
• evidence from Packet capture or the destination system’s log;
• a control test after rollback.

For NAT or asymmetric routing paths, capture the forward and return paths first. A bypass can conceal a routing, NAT, or policy issue; it doesn’t fix one.

Work in the Device Console

Connect over SSH as admin and open 4. Device Console from the console menu. Allow SSH only from a trusted administration network. See Connect to Sophos Firewall over SSH for preparation.

First display the state and save it in the ticket:

show advanced-firewall

The output contains other global settings. Don’t change them as part of this task; Check Advanced Firewall Settings safely explains them.

The Device Console provides contextual help. Use Tab or ? after a partial command instead of guessing parameters. The SFOS 22 help explicitly warns against running incomplete commands.

Add host entries for the test

This example uses reserved documentation addresses:

• Source host: 198.51.100.10
• Destination host: 192.0.2.20

Replace them with the two actual endpoints of your test flow. For the complete outbound bypass described by Sophos, add separate destination and source entries:

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.0.2.20
set advanced-firewall bypass-stateful-firewall-config add source_host 198.51.100.10

Check immediately:

show advanced-firewall

These lines follow the published SFOS 22 example. They aren’t a rule that only links 198.51.100.10 to 192.0.2.20: the first entry covers traffic from any source to 192.0.2.20, and the second covers traffic from 198.51.100.10 to any destination. The documented syntax also has no service or port parameter. During the maintenance window, generate only the intended traffic, prevent other access to the two hosts where possible, and don’t choose hosts exposed more broadly than necessary.

When a network entry is justified

SFOS 22 also supports dest_network and source_network. A network entry, however, expands the bypass to all matching hosts. Use one only when the same narrowly defined fault demonstrably affects multiple systems.

Sophos states no limit for the number of bypassed hosts or networks. That’s technical capacity, not operational guidance: numerous entries are hard to audit and indicate that the underlying cause should be fixed instead of extending the bypass list.

The public SFOS 22 page doesn’t show a complete executable network example. Check the exact network and netmask syntax on the installed SFOS release with Tab or ? rather than copying an older example. Reproduce with a host first; if that isn’t possible, coordinate the network bypass with Sophos Support.

Validate the effect

Don’t only check whether the application works. Confirm that the change remains within its intended scope:

1. show advanced-firewall shows the new source and destination entries with the planned selectors and values; pre-existing entries remain unchanged.
2. Under Diagnostics > Packet capture, filter for both hosts and the expected port.
3. Run a clearly timestamped test and inspect forward and return packets.
4. Check for other traffic to the destination host or from the source host during the window; it also falls under the corresponding bypass entry.
5. With asymmetric routing, verify that the return path actually crosses this firewall.
6. Proceed to rollback immediately, regardless of the result.

Packet capture shows interfaces, source and destination, ports, NAT ID, Rule ID, and processing status. If one direction is missing, first check routing, NAT, and the capture filter. Missing Log Viewer entries alone don’t support a reliable conclusion during a bypass.

Remove the bypass completely

Prepare deletion commands before testing. They must use exactly the same selectors and values as their corresponding add commands:

set advanced-firewall bypass-stateful-firewall-config del dest_host 192.0.2.20
set advanced-firewall bypass-stateful-firewall-config del source_host 198.51.100.10

Then verify:

show advanced-firewall

Success means both test entries are gone, older documented entries are unchanged, and a control test runs without the temporary bypass. If an entry remains, compare the selector (dest_host or source_host) and IP address with the output; don’t substitute a broader deletion attempt.

Fix the underlying cause

A successful bypass test only shows that firewall inspection was involved. Identify the actual cause next:

• Firewall rule: order, zones, source, destination, service, and user assignment;
• IPS, Web Protection, or Application Control: detected signature, category, application, and policy;
• TLS inspection: matching rule, certificate trust, and narrowly scoped exclusion;
• NAT and routing: NAT Rule ID, route precedence, SD-WAN decision, and return route.

The permanent solution must work without a stateful firewall bypass and restore visibility and reviewability. A temporary diagnostic change must not silently become production architecture.

Documentation and common mistakes

Record at least start and end time, administrator, reason, both hosts or networks, application and service, every add and del command, capture timestamp, result, and follow-up task in the ticket.

Common mistakes include:

• assuming the two host entries form a source-destination pair, or copying unconfirmed netmask parameters;
• adding or deleting only one of the two host entries planned for the test;
• using a whole network when two hosts are sufficient;
• relying on Log Viewer rather than Packet capture as the only evidence;
• confusing this bypass with a DoS bypass rule, FastPath, or LAN bypass;
• failing to implement a normal rule, policy, NAT, or routing solution after a successful test.

Frequently asked questions