Use Sophos Firewall Bypass Rule safely

A bypass rule on Sophos Firewall is not a normal allow object and is not a substitute for a clean firewall rule. The defined traffic bypasses the normal stateful firewall path. This also bypasses many functions that are deliberately relied on in day-to-day operations: firewall rules, Log Viewer, IPS, web filtering, Application Control, malware scanning, or other security features.

Bypass rules are therefore only useful for narrowly defined special cases, for example for short-term troubleshooting with guidance, for a very specific compatibility exception or for a clearly documented workaround. For normal releases, performance problems or false positives, you should first check specific rules, exceptions or policies.

⚠️ A bypass rule massively reduces the visibility and protective effect of the firewall. Bypass rules should always be narrowly defined, documented, tested and removed after completion.

Typical real-world occasions are special cases with asymmetric routing, unusual protocol behavior, or a short-term vendor analysis. Once the cause is clear, the solution should be reverted to normal firewall rules, NAT, routing, IPS, web or TLS exceptions.

Which type of bypass is meant

The term “bypass” appears several times in Sophos environments. This article is exclusively about bypass-stateful-firewall-config in the Device Console.

• Stateful firewall bypass: CLI configuration that routes defined host or network traffic past the normal stateful firewall path.
• DoS bypass rule: Exception under Spoof Protection and DoS Settings for DoS checks, not the same as Stateful Firewall Bypass.
• IPS Bypass session: IPS rule action that treats an IPS hit differently for the session.
• FastPath / Firewall acceleration: Normal acceleration of trusted flows on supported appliances or platforms. This is not a manual stateful firewall bypass and should not be understood as a workaround for rule problems.
• LAN bypass / fail-to-wire: Hardware function of specific appliances or modules, not an SFOS rule.
• Normal firewall exception: Firewall, NAT, web, TLS, IPS, or Application Control adjustment in WebAdmin.

This separation is important because the measures have different risks. A DoS exception or an IPS action is not automatically harmless, but it is more closely related to a function. A stateful firewall bypass, on the other hand, can bypass visibility and policy evaluation very broadly if the source or target is chosen too large.

Check better alternatives beforehand

Before setting a bypass rule, it should be clear why normal mechanisms are not sufficient.

• Firewall rule does not match: Check rule order, source/destination, services and logs.
• IPS blocks an application: Check IPS policy, signature, exception or false positive analysis.
• TLS inspection disrupts an app: Adjust SSL/TLS Inspection Rule or TLS Exclusion.
• Web filter blocks a URL: Check Web Policy, Category, URL Group or Web Exception.
• Application Control works incorrectly: Check Application-Control-Policy and detected application.
• NAT or routing works incorrectly: Check NAT rules, return route, SD-WAN and packet capture.

For rule and log analysis, Test Sophos Firewall rule with log viewer and packet capture, Firewall rule does not work: check causes and Understand and configure Sophos firewall rules correctly help.

Operating limits

A bypass rule should only be set if all points are met:

• Source and destination are specific networks or hosts, not Any.
• Direction and return direction are understood.
• There is a ticket, a reason and a responsible person.
• A maintenance window or test window is defined.
• The existing configuration was previously documented.
• A rollback command is available.
• After the test, a check is made to see whether the rule has been removed again.

A bypass rule is not suitable for permanent “quick activation” between networks. If a connection is to be allowed permanently, it belongs in a normal firewall rule with logging and appropriate security features.

Be especially careful with NAT paths. If SNAT, DNAT, VPN NAT, or another translation is required for the flow, a stateful firewall bypass can bypass the actual NAT decision or distort the test. In such cases, first check NAT Rule ID, Firewall Rule ID, Packet Capture, and routing instead of broadly bypassing the stateful path.

Connection to Device Console

The commands are executed in the Sophos Firewall Device Console. To do this, connect to the user admin via SSH and open the Device Console in the console menu.

SSH access should only be allowed from a trusted admin network. The preparation is in Connect Sophos Firewall via SSH.

Before making any changes, you should first display and document the current status.

show advanced-firewall

Select host or network correctly

Sophos allows bypass entries for individual hosts or networks. For troubleshooting, a single host is almost always better than an entire subnet because it means less traffic is invisible.

• Single source host to destination host: dest_host <Destination-IP> source_host <Source-IP>.
• Source network to destination host: dest_host <Destination-IP> source_network <Network-IP> source_netmask <Mask>.
• Source host to destination network: dest_network <Network-IP> dest_netmask <Mask> source_host <Source-IP>.
• Source network to destination network: dest_network <Network-IP> dest_netmask <Mask> source_network <Network-IP> source_netmask <Mask>.

Wide networks such as complete client, server or VPN zones are almost never a good starting point. It is better to have a tight test with a source host, a destination host and a clear service. Only if the test case really affects several hosts should one talk about a small network.

The direction is also important. Sophos describes that entries for both directions are often necessary for complete connections. But this should be done consciously: not automatically recreate Any logic, but rather understand the specific return path.

Sophos does not name a practical limit for the number of hosts or networks in this bypass list. That is exactly what makes operations risky: many small entries are technically possible, but they quickly become hard to understand. If several bypass entries seem necessary, this is usually a sign that the actual routing, NAT, policy, or application problem is not yet clearly understood.

Set change frame before bypass

A bypass rule should never be set spontaneously while troubleshooting is ongoing. Before executing the add command, it should be clear which individual test it is intended to answer and how the change will be reverted.

To ensure a clean maintenance or testing window, note these points:

• Test question: Does the defined traffic work without a stateful firewall path?
• Affected Flow: 192.168.33.0/24 to 192.168.46.0/24.
• Start state: Output of show advanced-firewall before change.
• Planned return route: appropriate del command for each set direction.
• Termination criterion: unexpected traffic, new disruption or incorrect target area.
• Follow-up inspection: show advanced-firewall, packet capture and functional test without bypass.

The withdrawal order is particularly important. It should be prepared before setting, not searched for after the test. This means that the change remains controllable even if pressure arises during the maintenance window.

Example: Create a bypass rule

Example:

• Source network: 192.168.33.0/24.
• Target network: 192.168.46.0/24.
• Source Netmask: 255.255.255.0.
• Target Netmask: 255.255.255.0.

The rule for the first direction:

set advanced-firewall bypass-stateful-firewall-config add dest_network 192.168.46.0 dest_netmask 255.255.255.0 source_network 192.168.33.0 source_netmask 255.255.255.0

A second rule is required for the reverse direction if the traffic from the destination network back to the source network should also use the bypass.

set advanced-firewall bypass-stateful-firewall-config add dest_network 192.168.33.0 dest_netmask 255.255.255.0 source_network 192.168.46.0 source_netmask 255.255.255.0

Then check again:

show advanced-firewall

If only a single client and a single server are being tested, it is better to use hosts instead of networks:

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.168.46.20 source_host 192.168.33.10

For the opposite direction accordingly:

set advanced-firewall bypass-stateful-firewall-config add dest_host 192.168.33.10 source_host 192.168.46.20

Check effect

After setting, you should not only test whether the application works. What is crucial is whether the bypass really only affects the planned traffic.

Checkpoints:

1. show advanced-firewall shows exactly the expected networks.
2. There are no wider nets than planned.
3. Direction and return are consciously set.
4. Test traffic only works between expected sources and destinations.
5. Uninvolved networks do not use the bypass.
6. Normal firewall logs for this traffic are no longer expected as a basis for decision-making.
7. Packet Capture only shows traffic during the scheduled test.
8. The withdrawal was carried out immediately after the test.

If the log viewer and rule counter suddenly no longer show events, this may be caused by the bypass itself. In this condition, Packet Capture is more helpful than Log Viewer.

With asymmetrical routing, you should also check whether the return path actually goes through the expected firewall. A bypass can mask symptoms if the root cause is an incorrect default gateway, an incomplete route, or NAT on the wrong side.

When performance or offloading is suspected, do not confuse bypass with FastPath. FastPath, Firewall acceleration, PKI acceleration, and IPsec acceleration are separate mechanisms. Depending on traffic and platform, normal traffic can be accelerated without setting a bypass rule. Conversely, a bypass rule does not turn a poor design into a clean performance architecture.

Delete bypass rule

To remove, use the same command with del instead of add.

Remove first direction:

set advanced-firewall bypass-stateful-firewall-config del dest_network 192.168.46.0 dest_netmask 255.255.255.0 source_network 192.168.33.0 source_netmask 255.255.255.0

Remove reverse direction:

set advanced-firewall bypass-stateful-firewall-config del dest_network 192.168.33.0 dest_netmask 255.255.255.0 source_network 192.168.46.0 source_netmask 255.255.255.0

Then check again:

show advanced-firewall

The output should no longer contain unexpected bypass entries.

Secure cleanly again after the test

A removed bypass rule does not automatically solve the original problem. The test only shows that the normal firewall path for the tested traffic was likely involved. You should then consciously transfer the cause into a supported, visible configuration.

Useful follow-up questions:

• Was a normal firewall rule too narrow or in the wrong place?: Check rule order, zones, source, destination, service and user assignment.
• Has IPS, Web Protection or Application Control blocked?: Document signature, category, policy or targeted exception.
• Was TLS inspection involved?: Cleanly check TLS rule, certificate, exception and affected application.
• Was it a routing or NAT issue?: Compare NAT Rule ID, return route, SD-WAN route and packet capture.
• Will the traffic be needed permanently in the future?: Create normal firewall rule with logging, owner and review date.

After withdrawal, at least one control test without bypass should be carried out. If the traffic only works with bypass again, the case is not yet closed. Then you need a clean rule, policy, NAT or inspection adjustment that remains visible in the log viewer and can be checked later.

For permanent changes, you should also document which security features are deliberately left active and which exception is really necessary. A temporary bypass rule must not silently become part of the operational architecture.

Documentation

Every bypass rule should be documented:

• Date and time
• Administrator
• reason
• Source network and destination network
• affected application
• planned duration
• Test evidence
• Time of removal
• Follow-up task in case a clean rule or exception needs to be created

Without documentation, bypass rules can easily go unnoticed. This is particularly dangerous because a normal look at firewall rules or log viewers is not enough to identify the protection gap.

Checklist

Before bypass:

• Normal firewall rule, NAT, routing, IPS, web, TLS inspection and application control checked.
• Specific test question defined.
• Source, destination, direction and return documented.
• Narrowest possible variant selected, preferring host instead of network.
• Current state saved with show advanced-firewall.
• del command prepared for each planned direction.
• Ticket, owner, time window and dismantling time determined.

During the test:

• Bypass only active for the planned period.
• Test traffic documented with source, destination, service and time.
• Packet capture or target system log used as evidence.
• No additional networks or applications unintentionally affected.

After the test:

• Removed all bypass entries with del.
• show advanced-firewall does not show unexpected bypass rules.
• Test repeated without bypass or subsequent problem documented.
• Permanent solution planned as a normal rule, policy, NAT, routing or inspection adjustment.
• Ticket and operational documentation updated.

Typical errors

• Nets used too wide: More traffic than planned bypasses the firewall.
• Forgot reverse direction: Application only works partially or asymmetrically.
• Rule not removed: Permanent protection gap arises.
• No ticket or comment: Later it is unclear why the bypass exists.
• Log viewer expected as evidence: The traffic does not appear like normal firewall decisions.
• Bypass used instead of targeted exception: Security features are switched off unnecessarily.
• Change without maintenance window: Mistakes have an immediate productive effect.

Frequently Asked Questions