Create and test Sophos Firewall Web Exceptions safely

A Web Exception is quick to create, but its impact can be much wider than expected. Depending on the selection, Sophos Firewall bypasses not only HTTPS decryption but also certificate validation, malware and content scanning, zero-day analysis, or complete web policy checks.

The safe order is therefore to identify the affected flow and the check that is actually causing the problem, then narrow the match, and only then enable the smallest necessary exception. A positive test alone isn’t enough. A similar destination that hasn’t been excluded must still undergo normal inspection in the negative test.

This guide applies to SFOS 22.0. WebAdmin labels deliberately remain in English so that they can be found directly in the interface.

Web Exception in seven steps

1. Document the affected client, destination host, URL path, protocol, and time.
2. Check whether DPI mode or web proxy mode is in use and which firewall rule and web policy actually apply.
3. Decide whether only TLS decryption or a specific web protection check is causing the problem.
4. Under Web > Exceptions > Add an exception, define narrow URL, category, source, or destination criteria.
5. Under Skip the selected checks or actions, select only the smallest necessary option.
6. Turn on the exception and retest the same flow with a new browser or application process.
7. Run a negative test against a similar destination that hasn’t been excluded, and document the match, impact, owner, and review date.

⚠️ HTTPS decryption isn’t a harmless compatibility option. Dependent checks are also lost for matching traffic, and the firewall allows invalid server certificates in this case. Malware and content scanning automatically bypasses zero-day analysis as well. A broad exception must therefore not be the first troubleshooting step.

Check product prerequisites before choosing an exception

For some managed products, port and domain allowances are prerequisites for the relevant function. Before choosing a firewall rule, TLS exclusion, or Web Exception, establish the product, function, version, and actual connection path with the product owner. Record required destinations, ports, protocols, directions, and explicitly required inspection exclusions in the change ticket rather than granting blanket access to all Sophos products.

• Wireless: The Wireless preflight separates the management network, DNS, time service, and regional destination requirements from later wireless configuration.
• ZTNA: First identify the local or cloud deployment in the ZTNA gateway guide; their connection directions and inspection requirements are not interchangeable.
• Switch registration: Switch onboarding covers DNS, registration destinations, and checks of the proxy/TLS path.
• Endpoint, XDR, and MDR: The network and proxy requirements distinguish platforms, licensed functions, and installation-specific destinations. A domain allowlist is not a blanket no-decrypt list.
• NDR and integration appliances: Appliance planning covers outbound port and domain requirements; the operations runbook helps check the NDR and log collector functions actually hosted on the appliance separately.

The internal guide is a starting point; the product owner must confirm the authoritative requirements for the specific deployment before the change. Network reachability and inspection bypass remain separate decisions. If a verified requirement set is missing or sources disagree, don’t widen the exception speculatively: preserve evidence and resolve the issue with the product and firewall owners. The pilot, positive/negative tests, review, and rollback in this guide still apply afterwards.

Choose a Web Exception or TLS exclusion

Both tools can prevent HTTPS traffic from being decrypted, but they don’t solve the same task.

An SSL/TLS inspection rule with Action: Don’t decrypt is suitable when only decryption must be excluded for clearly named destinations in DPI mode. A URL group in the Local TLS exclusion list is particularly efficient because the firewall compares Server Name Indication, or SNI, as text.

Create and safely use URL groups shows how to create such a domain list, assign it to a Don't decrypt rule, and test it against a negative destination.

A Web Exception is suitable when one of the following web protection checks must additionally or alternatively be bypassed:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

In DPI mode, a Web Exception only applies if at least one web policy, Malware and content scanning, or ATP is active for the flow. In web proxy mode, the Web Exception belongs directly to the proxy-based web protection path.

The traffic covered also differs: in DPI mode, Web Exceptions apply to SSL/TLS connections on any port; in web proxy mode, they apply to SSL/TLS on port 443. SSL/TLS exclusion rules only apply in DPI mode, but are also port-independent. In addition to URL groups, they can use zones, networks, IP addresses, services, users, and groups as criteria. Web Exceptions provide URL patterns, web categories, and source and destination IP addresses or ranges.

An active Web Exception can override the selected protection checks for matching web flows; this is not a promise that every system-level block can be lifted. Its scope therefore can’t be protected by placing a web policy rule later in the order. The exception’s own criteria are decisive; still check firewall, web, and SSL/TLS rule order separately because they determine which protection path processes the flow in the first place.

Documented boundary and unresolved conflict: Sophos describes exceptions generally as independent of policies and rules. However, the category guidance for SFOS 22.0 and 23.0 explicitly identifies highly objectionable criminal activity as always blocked: no policy or exception may allow these pages, and domain names are intentionally hidden in logs and reports. These differing statements do not establish a working bypass. The safe approach remains not to circumvent this block and, if necessary, clarify the conflict with Sophos Support. Use only harmless, approved destinations for tests, never prohibited content.

Roll out TLS Inspection correctly covers the planned setup of DPI or web proxy, decryption rules, and CA deployment. Set up Web Protection with web policies explains the actual filtering logic.

Plan a narrow and traceable match

An exception shouldn’t begin with an arbitrary vendor domain. First record the specific request in the browser, Log Viewer, or application logs. Then decide whether the hostname, path, category, source IP, or destination IP is the most stable criterion.

AND between types, OR within a type

Sophos Firewall links different criterion types with AND. If URL patterns and Source IP addresses are specified, for example, both types must match.

Multiple values within the same type are evaluated with OR. Two URL patterns therefore mean that either pattern may be sufficient. Two Source IP addresses mean that either source may be sufficient.

This logic matters during troubleshooting. An exception can look correct and still fail to apply because an additional criterion type doesn’t match the real flow.

Anchor the regular expression safely

Regular expressions are allowed under URL pattern matches. A bare pattern such as vendor.example is unsuitable. It can also match the text at an unexpected position in the URL and exclude too many requests.

For the reserved example domain updates.vendor.example, a deliberately anchored host pattern can look like this:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

The value is only an example. vendor.example is a reserved documentation domain and is replaced with the real destination host confirmed in the log or request. The optional prefix allows subdomains. If exactly one host must be excluded, no unnecessary subdomain wildcard is used.

Non-ASCII characters are specified as Punycode in the pattern. Every regex change requires an expected match and at least one deliberately similar non-match in the test.

Distinguish hostname and URL path

Exceptions for HTTPS decryption and HTTPS certificate validation can evaluate the hostname from the TLS context. A pattern that only targets a URL path, however, only works for HTTPS if the connection is already being decrypted.

This creates an important boundary: an exception can’t turn off decryption and then reliably use a part visible only in the encrypted HTTP path as its selection criterion. This case requires host-based scope or a different design.

Create the Web Exception

The example excludes a single pilot client from HTTPS decryption for a confirmed vendor host. It isn’t a universal exception rule.

1. Open Web > Exceptions.
2. Select Add an exception.
3. Enter a descriptive name, for example Vendor API no decrypt.
4. Turn on URL pattern matches.
5. Enter the tested, anchored pattern under Search/Add and select Add.
6. For the pilot, also turn on Source IP addresses and enter the specific client IP address.
7. Under Skip the selected checks or actions, select only HTTPS decryption.
8. Select Save.
9. In the list, turn on the switch for the new exception.
10. Recheck the name, Matching URLs, sources, and bypassed check.

The source IP address is set deliberately in the example. Without it, the exception would immediately apply to every client whose request matches the URL pattern. After a successful pilot, the scope can be expanded in a controlled manner to the sources that actually need it.

For a pure TLS exclusion across many destinations, a URL group in a Don't decrypt rule is usually more maintainable and efficient. Many FQDN host objects in the source or destination of an SSL/TLS inspection rule are inefficient because they can cause numerous DNS lookups for new TLS connections.

Understand the effect of the skip options

Before saving, it must be clear which protection is being lost.

HTTPS decryption

The firewall doesn’t decrypt matching HTTPS traffic. It therefore can’t perform checks that require decrypted content. Sophos also documents that traffic with an invalid server certificate is allowed for this match.

If only a certificate issue is causing the problem, this option is often too broad. First check whether HTTPS certificate validation is the more precise exception.

HTTPS certificate validation

The firewall bypasses server certificate validity checks. Configured decryption can continue. This exception is only suitable for a known destination with a consciously accepted certificate problem and requires a short review period.

An expired, incorrectly named, or untrusted certificate should be repaired on the destination system wherever possible. Deploying the correct inspection CA solves a different problem and is covered in Deploy the CA certificate for TLS Inspection.

Malware and content scanning

The firewall bypasses malware and content scanning for the match. This also automatically bypasses Zero-day protection. A single selection therefore removes two protection layers from the data path.

Before creating this exception, check the file type, scan limit, encryption, failure action, and the download that actually matches. Configure and test malware scanning provides the complete test flow.

Zero-day protection

Zero-day analysis is bypassed. No analysis reports are created for matching files, even if the classic malware scan reports a detection. This option is narrower than completely bypassing Malware and content scanning.

Policy checks

Web policy checks are bypassed for the matching request. Such an exception can render category, user, group, and other policy decisions ineffective. It should only be used for a clearly proven policy problem, not as a blanket solution for a blocked website.

This does not authorize using Policy checks to lift the documented absolute block for highly objectionable criminal activity described above.

Verify the effect with positive and negative tests

A successful page load only proves that something changed. It doesn’t yet prove that the exception is precise.

1. Record the time, pilot client, destination host, and expected result.
2. Close the existing browser or application session and create a new connection.
3. Repeat the affected request.
4. In Log Viewer, compare the source IP address, destination host, web policy, Firewall Rule ID, and action.
5. For a decryption exception, compare the server certificate visible to the client with its state before the change.
6. Open a similar destination that hasn’t been excluded.
7. Verify that this destination is still covered by the normal web policy, decryption rule, and scanning chain.
8. Briefly turn off the exception and reproduce the original error if this is safe within the maintenance window.
9. Turn the exception on again and reconfirm success.

If QUIC or HTTP/3 bypasses the expected TCP TLS path, the test can be misleading. Block QUIC and HTTP/3 correctly explains the boundary. Log Viewer, Policy Tester, and Packet Capture show which rule and policy actually match.

Open Policy tester under Diagnostics > Tools, in the Pop-out tools section. Its Firewall, SSL/TLS, and web test method helps identify the expected firewall rule, SSL/TLS inspection rule, and web policy. However, it only tests web traffic in transparent mode, so it doesn’t represent an explicit direct web proxy flow. Always confirm that the Web Exception actually applies with a newly generated request and real logs.

For log evidence, Log firewall traffic must be on in the firewall rule; also turn on Log connections in an SSL/TLS inspection rule. Under System services > Log settings, the relevant log types must be on for Local reporting. Then narrow Log Viewer to the test time and source IP address, and compare the Web filter and SSL/TLS inspection modules with the Firewall Rule ID, policy, and action. Use Sophos Firewall Log Viewer correctly explains the controls. If the entire view remains empty, follow Log Viewer isn’t updating rather than widening the exception on suspicion.

Narrow down errors systematically

Exception doesn’t apply

• The documented absolute category block is not a matching error. An intentionally hidden domain name is not a logging defect in this case. Web categories and web policies explain the boundary; don’t try a broader exception or tests against this content.
• The switch under Web > Exceptions isn’t on.
• An additional criterion type doesn’t match because of the AND logic.
• The regex isn’t anchored at the beginning or doesn’t represent the real hostname.
• The traffic isn’t decrypted for an HTTPS path exception, so the path isn’t visible.
• In DPI mode, neither a web policy, Malware and content scanning, nor ATP is active for the flow.
• A different firewall rule, web policy, or operating mode applies than expected.
• An existing browser or application session wasn’t recreated.

Exception applies too broadly

• The pattern contains an uncontrolled wildcard or only a bare root-domain string.
• Source IP addresses or another pilot scope are missing.
• Multiple URL patterns within the same type have a wider effect than expected because of OR.
• An entire web category was excluded instead of the specific host.
• Multiple skip options were selected even though only one check causes the problem.

Website works, but the protection impact is unclear

Don’t expand the exception further. First compare the browser certificate, web and SSL/TLS inspection logs, Firewall Rule ID, web policy, and a controlled download. Without this evidence, the exception is only a functional workaround, not yet an accepted security decision.

If the WebAdmin tools don’t isolate the cause, Map Sophos Firewall service logs correctly maps DPI, proxy, malware, and zero-day logs to the affected protection path. Debug isn’t enabled as the first step.

Review and rollback

Every production Web Exception has at least:

• technical justification and ticket
• application and firewall owner
• affected hosts, paths, sources, and user groups
• exact checks being bypassed
• date of the positive and negative tests
• review or expiry date
• documented previous state

For rollback, turn off the exception first rather than deleting it immediately. Then retest the original error, normal protection path, and unaffected destinations. Only remove the exception when no dependency remains.

Default and vendor exceptions shouldn’t be modified without control. A custom exception must make it clear why it exists and who will reassess it later.

Operational checklist

• DPI mode or web proxy mode identified.
• Actual matching firewall rule and web policy confirmed.
• Hostname and, where applicable, URL path captured from real traffic.
• Regex anchored at the beginning and tested against non-matches.
• AND between criterion types and OR within a type considered.
• Only the smallest necessary skip option selected.
• Automatic zero-day bypass for Malware and content scanning considered.
• Pilot source restricted.
• Positive and negative tests completed.
• Log Viewer, certificate, and protection impact checked together.
• Owner, ticket, review date, and rollback documented.

Frequently asked questions