Implementing Sophos Firewall TLS Inspection Correctly

With TLS Inspection, Sophos Firewall terminates the client’s encrypted connection and establishes a second connection to the destination server. It can inspect the plaintext between the two. The firewall re-signs an originally trusted server certificate for the client with its own CA (Certificate Authority). If the client does not trust this CA, it displays a certificate warning or terminates the connection.

This enables checks on decrypted content, such as malware and content scanning. Without decryption, protection features may be limited, depending on the module, to information such as the IP address, domain, SNI, certificate or protocol metadata. That does not justify a broad initial deployment: certificate pinning, privacy, application compatibility and the additional firewall load must be addressed before rollout.

The safe short version is: determine whether to use the DPI or Web Proxy path, distribute the re-signing CA to a small group, document the current state, create a narrowly scoped Decrypt rule, run one positive and one negative test, and only then expand the scope.

Decide before the pilot

License, CA and ownership

SSL/TLS Inspection Rules and URL Groups used in them are enforced with the Base License. Web Protection is not a general prerequisite for TLS Inspection. It is required when web categories are used as rule criteria or when the corresponding Web Protection features are needed. Malware, Zero-Day and other inspections each require the relevant subscription. What Sophos Firewall Bundles Are Available? and Understanding Sophos Firewall Base License explain the differences.

Clarify the following before creating the first rule:

• Document the SFOS version in use, the available license and the intended inspection path.
• Define a managed pilot group and a clear time window. The example below uses client 10.20.30.50 from test network 10.20.30.0/24; replace these values with your own objects.
• Obtain approval from the responsible privacy stakeholders for the scope, logging, retention and user notification.
• Back up the exact initial state of the firewall rule, TLS rules, Decryption Profile, CA and any global settings. Record the complete pre-pilot matching path, the rule that will match after disabling the pilot (including any lower broader Decrypt rule), and each pilot-only change to firewall rules, DPI/proxy mode, Web Policy and global settings. Define the exact authorized restoration steps before activation.
• Name the owner, abort criteria, exception process and rollback path.

The re-signing CA must be in the trust store of the affected operating systems or browsers. Alternatively, use a subordinate enterprise CA. A publicly trusted CA is not available for this purpose because the firewall re-signs certificates for third-party domains. With an external CA, both the root and subordinate CA must be imported; if the signing CA contains an EKU section, it must permit TLS Web Server Authentication. Install Sophos Firewall CA Certificate for HTTPS Scanning describes distribution, while Set up a subordinate CA for Sophos Firewall TLS inspection covers the enterprise CA method.

⚠️ Do not start with all users. Devices without a manageable trust store, BYOD and applications using certificate pinning should initially remain in a separate scope. An exception restores the connection, but excludes its content from decryption.

Keep DPI and Web Proxy separate

SFOS uses the DPI engine by default. On this path, the firewall processes the Firewall Rule first and then the SSL/TLS Inspection Rules. The Inspection Rule does not itself allow traffic: even Services: Any only means that TLS traffic already permitted by the Firewall Rule on any TCP port is eligible for this Inspection Rule.

For the DPI path, open Rules and policies > Firewall rules, edit the relevant LAN-to-WAN rule and check Security features > Web filtering:

1. Leave Use web proxy instead of DPI engine disabled.
2. Select a Web Policy only if the planned protection requires it; it is not a prerequisite for the Decryption Rule.
3. Scan HTTP and decrypted HTTPS enables malware scanning for HTTP and HTTPS that has already been decrypted. The option does not itself enable HTTPS decryption.

In Web Proxy Mode, the proxy handles HTTPS decryption. Decrypt HTTPS during web proxy filtering is the relevant setting on the proxy path. DPI rules under Rules and policies > SSL/TLS inspection rules do not apply to connections decrypted by the Web Proxy. With the transparent proxy, ports 80 and 443 pass through the proxy while SSL/TLS on other ports can still be handled by the DPI path; with the Explicit Proxy, the Web Proxy performs decryption.

The CAs are separate as well: DPI uses the CA from the SSL/TLS settings or the selected Decryption Profile. The Web Proxy uses the CA from Web > General settings. When changing mode, check not only the rules but also the CA actually presented. Choose DPI Engine or Web Proxy correctly explains the differences in more detail.

This outbound inspection path is not intended for web servers published to the internet. Web Server Protection / WAF or a reverse proxy is usually the more suitable architecture there. SSL/TLS Inspection Rules apply to outbound traffic, so only internal zones can be selected as Source zones. They detect TLS on any TCP port, but are not enforced over UDP.

Conflicting documentation on direction: The rule-creation guide mentions inbound and outbound connections, but later explicitly limits Source zones to internal zones and outbound traffic. The general wording is not evidence of WAN inbound inspection. This rollout stays on the internal client path described here; inbound server connections require build-specific clarification with Sophos Support before any change.

Routing, DNS and permitted internet access must already work before the decryption test. Under Rules and policies > NAT rules, check the SNAT rule that actually matches; in a typical IPv4 internet design, this might be Default SNAT IPv4 with Translated source (SNAT): MASQ. Do not replace a working rule with another broad NAT rule. IPv6 and routed networks need their own design decision, not automatic MASQ. The pilot firewall rule needs Action: Accept and the approved source, destination and service scope.

For the proxy, also check HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols and Block invalid certificates under Web > General settings > HTTPS decryption and scanning. For Direct Proxy, enable the configured listener under Web > General settings > Web proxy configuration and Administration > Device access > Other services > Web proxy only for the required clients or zones. Transparent proxy needs HTTP/HTTPS services; Direct Proxy additionally needs the configured listener port. The linked DPI/proxy article covers the complete workflow and protection of local firewall web services.

Outdated compatibility example: The retained SFOS 22/23 configuration guide asks for TLS 1.1 in its proxy example, while the decryption-profile documentation calls versions before TLS 1.2 insecure. TLS 1.1 is therefore not adopted as a rollout requirement. Keep secure protocol settings; if a legacy application needs an exception, clarify the version, affected path, risk and narrow scope with the firewall owner first. Lowering TLS globally is not a pilot fix.

Handle QUIC deliberately

QUIC, or HTTP/3, uses UDP. Block QUIC protocol in a Firewall Rule drops outbound UDP packets to ports 80 and 443 within that rule’s scope, normally prompting clients with a usable TCP fallback to retry over TCP; clients without one may lose connectivity. SFOS selects the option by default as soon as a Web Policy is selected in the rule or Scan HTTP and decrypted HTTPS is enabled. This is per rule, not global, so check the Firewall Rule that actually matches. This option does not cover UDP on other ports. Verify an actual TCP connection, application function and the intended inspection-path match; blocking UDP alone proves none of these.

This web filter cannot scan QUIC. That does not mean every other firewall control is bypassed, but the expected TCP TLS and web-filter path does not apply. Correctly Blocking QUIC and HTTP/3 on Sophos Firewall shows the rule test; Creating a Sophos Firewall Web Protection Policy covers the Web Policy.

Select scope by purpose and risk

The usual starting point is managed user traffic from LAN to WAN. A separate corporate wireless network can follow as Wi-Fi > WAN. For Remote Access, VPN > WAN is only relevant when users’ internet traffic actually traverses the firewall through a Full Tunnel. Include internal connections from LAN to a DMZ only when content inspection has a clear benefit there and the client trusts the re-signing CA while the firewall validates the original server certificate chain. Ordinary destination servers do not need this inspection CA installed. Assess mutual TLS (mTLS) separately for compatibility.

Technical compatibility and permission to decrypt are separate decisions. Banking, healthcare and government portals, password managers, identity providers, operating-system and vendor updates, and voice, video and collaboration services require a functional and privacy assessment before inclusion. Pinning or a pilot failure does not justify a blanket exception for an entire category: first identify the source, domain and application actually required.

Configure a complete pilot

For a pilot that can be tested directly, we use these example values:

• Pilot client: 10.20.30.50 from the documented test network 10.20.30.0/24
• Firewall Rule: LAN to WAN - TLS pilot
• SSL/TLS Inspection Rule: TLS decrypt pilot client
• Source zone: LAN, Destination zone: WAN
• Destination networks and Services: Any
• Action: Decrypt
• Decryption profile: initially Block insecure SSL or a pilot profile derived from it
• Logging: Log connections enabled for the pilot

10.20.30.0/24, the host IP and object names are examples. The production Source must be narrow enough to identify one client unambiguously. Any for Destination and Service makes it easier to observe TLS outside TCP 443 during the pilot; it does not broaden what the preceding Firewall Rule permits. If inspection is permitted only for a specific destination group, add a URL Group or another appropriate destination criterion.

Select a Decryption Profile

Under Profiles > Decryption profiles, three non-editable default profiles are available:

• Maximum compatibility maximizes compatibility and does not restrict ciphers.
• Block insecure SSL blocks weak ciphers and allows traffic that cannot be decrypted.
• Strict compliance applies strict requirements, including requirements based on PCI DSS.

Maximum compatibility can help isolate a problematic client temporarily, but its relaxed checks make it unsuitable as a production acceptance criterion. For the pilot, Block insecure SSL or a deliberately derived profile is the more transparent starting point. Tolerate old TLS versions or RSA keys below 2048 bits only for a named legacy server and in a narrowly scoped rule.

Legacy rejection under Decrypt: With Action: Decrypt, Sophos Firewall still rejects connections using SSL 2.0 and SSL 3.0, SSL compression or Unrecognized cipher suites, even if the profile selects Allow without decryption for them. An explicitly approved, narrowly scoped legacy allowance requires both Allow without decryption for the relevant profile fields and Action: Don’t decrypt; the profile allowance alone is insufficient.

A custom profile can override the global SSL/TLS settings. The re-signing CA options are Use CAs defined in SSL/TLS settings, Re-sign RSA with and Re-sign EC with. For traffic that cannot be decrypted, the options are Use SSL/TLS settings default, Allow without decryption, Drop and Reject. The global-default reference does not apply to Unrecognized cipher suites; this case must be assessed explicitly in the profile. Depending on the setting, certificate errors, minimum RSA size, TLS versions and blocked ciphers use Drop, Reject or Reject and notify as their Block action.

Inspection does not make a self-signed server certificate or one with an incomplete chain trustworthy. Instead of hastily excluding it, first check the hostname, original certificate and complete chain.

For a self-signed original, the firewall replaces the key and signs with that key, not as a trusted CA: the client still sees a self-signed certificate. If the full chain to a CA trusted by the firewall is missing, a system-generated certificate is used whose CN explains the problem. A warning therefore does not automatically indicate a CA-distribution failure.

Create a custom profile with Profiles > Decryption profiles > Add, a name and description, or clone a suitable profile; then save it and assign it to the Inspection Rule. RSA and EC original certificates can often use the same signing CA. If an application requires a specific key type, select the corresponding CA under Re-sign RSA with or Re-sign EC with. Download each CA actually used with the button beside the selection; if two different CAs are used, clients must trust both.

Before saving, deliberately review Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version and Cipher algorithms to block. TLS below 1.2 and RSA below 2048 bits are not secure defaults. Maximum supported allows the highest supported protocol version. Checking Revoked requires an imported CRL (Certificate Revocation List); selecting the checkbox alone does not prove that revocation checking works. A Web Exception for HTTPS decryption can allow matching connections with invalid certificates, so it is not merely a pinning fix.

Certificate errors include Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch and Invalid for other reasons. Name mismatch compares the server name in Client Hello with the names in the certificate. Review key exchange, authentication, bulk ciphers and hash algorithms separately when choosing blocked ciphers. SSL compression before encryption has known vulnerabilities; unknown ciphers cannot be decrypted.

Find global defaults under Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. TLS 1.3 decryption offers Decrypt as 1.3 and Downgrade to TLS 1.2 and decrypt. The second option affects all SSL/TLS Inspection Rules; do not lower TLS globally for a normal pilot.

When SSL/TLS connections exceed limit determines what happens when decryption capacity is exhausted: Allow without decryption preserves reachability but loses content inspection; Drop silently discards traffic, while Reject sends a reset. This is a deliberate availability-versus-protection decision for the pilot, not just a performance value. Reject and notify attempts to show an HTTPS block page with the error reason but does not guarantee one; it prevents data transfer to the server.

With TLS 1.3, certificate errors, the minimum RSA size, a global downgrade and Reject and notify behave as documented only with Action: Decrypt. With Don’t decrypt or Deny, Reject is used for this profile handling instead. A global downgrade to TLS 1.2 introduces a security risk and is not a general compatibility fix.

Create the rule and check its order

Under Rules and policies > SSL/TLS inspection rules > Add, set the fields as follows:

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, so the pilot rule precedes general custom Decrypt rules
3. Action: Decrypt
4. Log connections: enabled for pilot monitoring
5. Decryption profile: the selected pilot profile
6. Source zones: LAN
7. Source networks and devices: host object for 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: empty or limited to the approved destination scope

Log connections is optional and is not required for the rule to work. It is nevertheless useful for a time-limited pilot because the handshake and connection closure can be traced. Retention must follow the agreed privacy and operations policy.

The table is evaluated from top to bottom and processing stops at the first match. All configured criteria must match simultaneously. The fixed default rule Exclusions by website or category remains at the top and cannot be preceded by selecting Rule position: Top. Place custom Don't decrypt exceptions immediately below it, followed by specific pilot rules and, finally, broader Decrypt rules.

User and group criteria are reliable only if SFOS knows the user context for the connection. If this is not guaranteed, start with an unambiguous host or network object and add identity criteria only after a separate match test.

After Save, recheck the rule’s status and position in the table. More options offers editing, cloning, inserting beside a rule and deletion; the Rule handle changes the order. Source, Destination and Rule ID filters help with comparison; Reset filter restores the full table. Action: Deny prevents the connection from being established and is not the same as Don’t decrypt. Categories and websites is identified using SNI in the TLS handshake. Fresh installations enable SSL/TLS Inspection Rules by default, but the actual status remains part of the preflight.

Distinguishing TLS configuration via the XML API

In automated rollouts, the Inspection Rule, the global DPI settings and the HTTP/HTTPS scanning configuration are three different objects. Selecting a CA activates neither the pilot rule nor scanning in the Firewall Rule. Confirm the following SFOS 22/23 field mappings in the installed build before constructing a request. Before any write operation, the explicit operation and the complete payload must be confirmed in API help for the installed build. Source access restrictions, accounts, TLS verification, secrets and the distinction between HTTP success and XML status are explained in Safely restricting XML API access and checking responses.

Inspection Rule: identity, hierarchy and order

The object is called SSLTLSInspectionRule. Its direct Name identifies the rule; in the example, NewName is the edited name for a rename, not the name of the reference rule for a move. The documented requirements for the rule name are a maximum of 60 characters, UTF-8 and no commas; Description is limited to 255 characters. IsDefault is read-only and is not used to make a custom pilot rule the default rule.

The match fields remain under their respective parents, even where the parameter table lists the same child name more than once:

• SourceZones > Zone and SourceNetworks > Network: internal source zone and the approved pilot host object.
• DestinationZones > Zone and DestinationNetworks > Network: destination zone and approved destination objects.
• Identity > Members: source users or groups, only with a verified identity match.
• Services > Service: service objects for the approved scope.
• Websites > Activity > Name and Websites > Activity > Type: name and type of the website criterion; the example specifies Web Category and URL Group.
• MoveTo > Name and MoveTo > OrderBy: reference rule and relative position; OrderBy uses Before or After.

Zone, Network, Service and website activities can occur more than once. A flat Name or Network without the correct parent node does not describe the same purpose. Object names are taken from the existing configuration; scope and profile are not replaced by missing fields or unverified defaults.

Position uses Top or Bottom and is used only for initial placement during ADD. If no value is specified, the example gives Bottom; for UPDATE or APIImport, Position is not required and is not adopted here as a mechanism for moving rules. The optional MoveTo is applied after Position during ADD. Anyone setting both must therefore check the resulting relative position, not just the initial Top value. The fixed default exclusion remains at the very top; the order of approved exceptions, pilot rules and broader Decrypt rules described above still applies.

The direct fields Enable, LogConnections, DecryptAction and DecryptionProfile have separate roles: rule status, logging, decryption decision and profile assignment. For Enable, the table lists Yes, No, t, f; for LogConnections, Enable, Disable, t, f. DecryptAction uses exactly Decrypt, Do not decrypt or Deny. The UI label Don’t decrypt is therefore not an XML value to use without verification. The selected profile is assigned under DecryptionProfile using its actual name; a narrowly defined Source and the complete approved destination/service scope remain mandatory even with automation.

The object-specific XML status rows distinguish between operation and symbol:

Message.* remains an unresolved documentation identifier here, not guaranteed runtime text or a definitive cause of an error. Before every retry, the sanitised response must be checked against the actual saved state: original or new rule name, status, complete criteria, DecryptionProfile and position relative to the other rules. Even a 200 row replaces neither this check nor testing with new connections. If the state is unclear, stop and clarify it rather than creating a second or broader rule through another ADD or a different position.

Global DPI settings: CA selection is not an on/off switch

Under SSLTLSInspectionSettings, RSACA and ECCA directly specify the re-signing CA selection for RSA and EC server certificates respectively. They refer to CA objects, not file paths or activation values. The profile can override the CA selection for its rule. Before a change, the profile, the CA actually presented, client trust and the root/subordinate chain must therefore be checked together; where different CAs are used, clients must trust both.

Separate from these are the direct global fields SSLTLSEngine and SSLTLSInspection, each using Enabled or Disabled. The first controls the TLS engine, the second global SSL/TLS Inspection, not the status of an individual pilot rule. Disabling Inspection prevents rule application and connection/decryption details in Control Center and Log viewer. Disabling the engine additionally removes the application of the DPI web policy to HTTPS from the path; proxy HTTPS decryption remains unaffected. Neither is a normal pilot rollback.

TLS13Decryption is also directly under SSLTLSInspectionSettings and uses Decrypt as 1.3 or Downgrade to TLS 1.2 and decrypt. It selects the global handling of TLS 1.3, not the signing CA or the action of an individual rule. A downgrade affects all Inspection Rules and is not introduced as a compatibility fix for a single client. The limits already explained for TLS 1.3 and Action: Decrypt remain applicable.

The other direct fields, SSLv2SSLv3, SSLCompression and SSLConnectionsExceeded, each use Allow without decryption, Drop or Reject. They concern different cases and are not equated with DecryptAction. After an authorised change, the saved global values, profile overrides and the actual pilot path must be checked. Only the documented pilot-related changes are reverted to their exact previous state, without blanket disabling of controls.

HTTP/HTTPS scanning: observe its own parent node

The separate object AntiVirusHTTPsConfiguration directly contains ScanMode, FileSizeThreshold, AudioVideoFileScanning and PUADetection. By contrast, the child node HTTPSConfigurations contains HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate and NoHttpsNotification. HTTPSScanningCA therefore belongs to the HTTP/HTTPS configuration of the proxy path, not to RSACA or ECCA in the DPI settings. These fields replace neither the DPI rule match nor Decrypt HTTPS during web proxy filtering in the appropriate Firewall Rule. The scanning context is explained in Understanding malware scanning on Sophos Firewall.

ScanMode specifies RealTime and BatchMode. FileSizeThreshold is specified in KB; the table lists 1 to 1572864, a maximum of 7 digits and the default 1024. Files above the threshold are not scanned; the documented default is not a recommendation for every environment.

Unresolved value discrepancy: For AudioVideoFileScanning, the XML example shows Enable/Disable, whereas the parameter table lists on/off and the default Disable. No interchangeable aliases are inferred from this. For DenyUnknownProtocol and AllowInvalidCertificate, the example also shows Enable/Disable, while the table lists only on and on/off respectively; for PUADetection, it lists symbolic values. Before an automated change, API help or Support must confirm the values valid for the object and build. Without clarification, do not execute the affected write request; do not relax certificate controls to make an import fit.

After an approved change, the saved CA selection and controls under Web > General settings, the proxy/DPI path that actually matches and the visible certificate issuer must be compared with the previous state. Only then should functional, positive and exception-negative testing follow. A formally accepted scanning configuration is not proof of decryption or effective malware scanning.

Keep exceptions narrow

The default rule Exclusions by website or category uses Don’t decrypt with Maximum compatibility and remains in the first position. The Local TLS exclusion list is empty by default; the Managed TLS exclusion list contains known incompatible sites and is maintained through firmware updates.

Edit the local list at:

Web > URL groups > Local TLS exclusion list

URL Groups or SNI matches are more efficient for domain exceptions than many FQDN Hosts. According to Sophos, for example, 200 FQDN Hosts cause 200 lookups for each new SSL/TLS connection. The restriction on combined Source/Destination exceptions must be distinguished from normal rule matching. Create and safely use URL groups explains domain scope, wildcards and negative tests.

A custom SSL/TLS Inspection Rule with Action: Don’t decrypt should record the domain, affected Source, reason, ticket, owner and review date. Don’t decrypt is not an unconditional bypass: the restrictions of the selected Decryption Profile still apply. To permit SSL 2/3, Compression or unknown ciphers for an explicitly approved legacy case, use a profile with Allow without decryption together with Action: Don’t decrypt. This combination does not belong in a broad internet rule.

SSL/TLS Exclusions and Web Exceptions solve different problems. A TLS exception controls Decryption on any TCP port in DPI Mode. A Web Exception changes selected Web Policy checks; in Proxy Mode, it affects the relevant proxy path. Before making a change, determine whether Decryption or only a web check should be excluded. Create and test Web Exceptions safely shows the selection and regex workflow.

Unclear exception scope: The website-exclusion guide says Source and Destination exceptions cannot be combined, whereas the rule guide provides both matching fields. This does not establish that a combined source/destination-IP Web Exception is permitted. Keep the pilot source restriction with a confirmed hostname or URL Group. If both IP exception criteria are also mandatory, do not activate or broaden the exclusion until build-specific Support clarification is obtained. Do not remove a criterion merely to make the match work.

For an explicitly approved legacy case, create a profile such as Allow_non-decryptable_profile under Profiles > Decryption profiles > Add. Set only the fields actually required—SSL 2.0 and SSL 3.0, SSL compression or Unrecognized cipher suites—to Allow without decryption. Under Rules and policies > SSL/TLS inspection rules > Add, assign the profile to a narrow Don’t decrypt rule with the pilot source, an internal source scope, the appropriate destination and a known target. This reduces protection for a justified legacy case; it is not a general approval of these protocols.

If usable SNI is absent, a URL Group or domain regex cannot identify the target. After checking the actual flow, a narrow IP Host under Destination networks may be appropriate; an FQDN Host remains a DNS-based alternative with the costs described above. For regex, an anchored start ^ and a negative test matter; broad wildcards can also be slower. The Web Exceptions link above explains the complete safe syntax and how it differs from domain-list matching.

Support Android with a narrow scope

Some Android connections use certificate pinning. Connectivity Check, Play Store or updates can then fail under Decryption. The workflow documented by Sophos uses an isolated VLAN or wireless network and an FQDN Host Group containing:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• the local Google domain, for example *.google.ch in Switzerland

Create the group under Hosts and services > FQDN host group > Add. Under Hosts and services > FQDN host > Add, create one host per domain and assign it directly to this group. Create a new Sophos wireless network under Wireless > Wireless networks > Add, and its network object under Hosts and services > IP host > Add with IP version: IPv4, Type: Network, your network address and mask. For an existing isolated VLAN/wireless network, use its appropriate object rather than creating a new network speculatively. Confirm the actual ingress zone assigned to that interface or VLAN; Wi-Fi is the Sophos wireless example, not a requirement for every mobile network.

The general documentation recommends an exception for all Android devices; the concrete workflow limits it to Google destinations in an isolated mobile network. This rollout follows the narrower workflow with positive and negative tests, not a blanket bypass for all Android connections. Switching to Web Proxy is a separate architectural decision, not an automatically equivalent pinning fix.

Above the general Decrypt rule, add an SSL/TLS Inspection Rule with Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone set to the actual ingress zone of the mobile network (for example Wi-Fi, LAN or a configured custom zone), the mobile-device network as Source networks and devices, WAN as Destination zone, and the Google group as Destination networks. It sits below the fixed default exclusion but above the general Decrypt rule. Keep the mobile network isolated from sensitive internal resources.

Accept the change using one Android pilot device: verify Connectivity Check and browser access, download an approved test app from Google Play, and update an installed app through Google Play. Each operation must complete successfully. In the Log viewer, only the expected Google destinations may match the exception; another HTTPS destination from the same VLAN must still use the intended Decrypt rule. Confirm the actual source zone and source object, the Google exception match and the intended Decrypt-rule match for these real flows. Use a managed pilot whose specific test browser or app trusts the inspection CA; verify successful operation and certificate/log evidence for the decrypted destination. Keep clients or apps without manageable inspection trust outside the Decrypt scope. This negative test prevents acceptance of an exception that works but is too broad. Create web exceptions and TLS exclusions safely covers further methods and SNI limitations.

Prove the effect

A policy simulation, a real client and the logs answer different questions. Combine them for a reliable acceptance test.

Under Diagnostics > Tools > Pop-out tools > Policy tester, select Firewall, SSL/TLS, and web and set the Source IP, Destination or URL, protocol and, if needed, the port. Without a protocol, the tool tests HTTP using the protocol-specific default port. Policy tester simulates transparent web traffic; it does not model SD-WAN routes, and rules with MAC addresses under Source networks and devices do not match there. Web policy only tests only the Web Policy. The result is therefore a prediction, not proof of the actual data path.

Run four targeted tests on the client:

1. Before the change, record the destination domain, certificate issuer, response time and whether the business application works.
2. Open an approved positive destination and verify the chosen inspection path. For DPI, the browser must show the selected DPI re-signing CA as issuer, and the Log viewer must show the expected Decrypt Rule and Decryption Profile. For Web Proxy, verify the CA selected under Web > General settings > HTTPS scanning certificate authority (CA), the actual matching Firewall Rule with Use web proxy instead of DPI engine and Decrypt HTTPS during web proxy filtering, and corresponding proxy/web log evidence of the successful request. Do not require a DPI rule/profile match or DPI widget entry for a proxy-decrypted connection.
3. Open a deliberately excluded destination. It must match the expected Don't decrypt rule; the browser must not show a certificate re-signed by the firewall there.
4. A second, non-excluded destination from the same client scope must still be decrypted. This is the exception’s negative test.

If a Web Policy is part of the design, also block a test category or test URL specifically approved for this purpose. Run a malware test only with a documented, harmless vendor test object and a predefined expected result. Before and after the pilot, compare CPU and memory load, response time and user errors over the same time window.

Read Control Center and Log viewer correctly

The Control Center widget is named SSL/TLS connections. Its details are updated every five minutes. Sessions cover the last 24 hours and errors the last 7 days; Failed resets at midnight. The detailed data does not include Web Proxy connections. Decryption peak appears only near or above the peak, and Decryption limit only near the device-specific limit. There is therefore no universal threshold for all appliances.

Open the Log viewer at the top right and select the SSL/TLS inspection module. A TLS connection is logged after the handshake completes and when it closes. Action, Rule, Decryption Profile, Source, Destination, Domain and the error reason matter; colours alone are not a reliable acceptance criterion. Under Manage > Exclude, you can add domains or subdomains to the Local TLS exclusion list and categories to the default exclusion. Exclude is not available for Error IDs 19004 and 19005.

A Don't decrypt event proves only that the connection was not decrypted. Only the Rule, list match and negative test show whether the exception is justified and sufficiently narrow.

Troubleshoot and roll back safely

When an incident occurs, initially limit the case to one client, one domain, one point in time, one Firewall Rule and one SSL/TLS Inspection Rule.

• If the browser displays a certificate warning, compare the visible issuer with the CA used by the actual DPI or proxy path. Then check the client trust store, root/subordinate chain and hostname.
• If SSL/TLS events are missing, first check the Firewall Rule match and the mode. Then confirm that Rules and policies > SSL/TLS inspection rules and Advanced settings > SSL/TLS engine > Enabled are active.
• If traffic is allowed but not decrypted, search from top to bottom for the fixed default exclusion, Managed/Local List or a custom Don't decrypt rule. Then repeat the negative test.
• If the web filter does not apply, check the actual Firewall Rule for its Web Policy, Scan HTTP and decrypted HTTPS, Block QUIC protocol and DPI/proxy mode. The presence of a Web Policy does not prove Decryption.
• If only one application fails, use the error reason, TLS version, cipher, certificate chain and pinning to guide the next decision. Keep any temporary exception narrow and give it a review date.
• If load increases, reduce the pilot scope and compare the same time window before and after the change. Assess peak or limit notices for the specific appliance.

Disable the SSL/TLS engine only briefly for troubleshooting. While disabled, no SSL/TLS Inspection Rules apply and the DPI engine does not apply the firewall Web Policy to HTTPS; Web Proxy HTTPS Decryption remains unaffected. Disabling it is therefore not an equivalent, low-risk substitute for disabling the pilot rule specifically.

Test port-agnostic IPS only with a known initial state

By default, SFOS checks decrypted traffic against IPS signatures on every TCP port. For a reproducible false positive, document the Signature ID, Source, Destination, TCP port, Firewall Rule, Inspection Rule and SFOS build. Prefer a narrow signature exception with Action: Allow packet in the IPS Policy actually in use; Configure and test Sophos Firewall IPS describes this method.

One possible symptom of a problem with port-agnostic inspection is repeated matches for the same IPS signature on the same website. Repetition alone does not prove a false positive. Match the exact Signature ID and destination against the logs, check the affected legitimate workflow and assess the risk before approving a narrowly scoped, reversible signature exception.

The more extensive inspection for potential threats may increase load and slightly reduce throughput for decrypted HTTPS traffic compared with older Sophos Firewall versions. This is a possible version-related effect, not a guaranteed decrease or proof of a regression in the build currently in use. To put the results in context, compare throughput, CPU and memory load, and response time under comparable traffic loads within the same time window; a single comparison does not replace root-cause analysis.

A global comparison in the Device Console is permissible only if the exact current value, on or off, is already known from the change record or a reliably backed-up configuration. The official SFOS 22 documentation gives no read-only pre-check for this switch. If the initial state is unknown, do not perform the test.

Only with a documented initial state of on may you set the following for one prepared comparison:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

The second command here only restores the known initial state of on. If the initial state was off, do not enable it blindly; retain off, or restore it exactly after any authorized change. This global setting affects the entire firewall and may slightly reduce throughput or, with off, narrow the inspection scope. Document the result and time window without treating this alone as proof of a general cause.

Roll back in a fixed order

A rollback restores the documented initial state rather than introducing a new architecture:

1. Before disabling TLS decrypt pilot client, check the recorded fall-through rule and approved restoration plan: a lower broader Decrypt rule can take over. Disable the pilot rule and restore the documented pilot-only firewall-rule, DPI/proxy-mode, Web Policy and global-setting changes in the prepared order, without unrelated simultaneous changes.
2. Establish fresh connections from the pilot client and verify the recorded initial matching path, certificate issuer, logs and application function. Existing sessions are not assumed to be re-evaluated immediately. If a lower Decrypt rule takes over or restoration fails, stop cleanup: rollback is not complete. Identify the actual match and restore only the authorized rule order, criteria and settings needed to reproduce the initial state, then repeat these fresh-connection checks.
3. Only if the initial path was not decrypted and the approved recovery plan requires it, use a time-limited, narrowly scoped Don't decrypt rule for the pilot source and required destinations, placed ahead of the unintended lower Decrypt match but below applicable approved exclusions. Run both its positive and negative tests; do not improvise a broad bypass or replace a previously inspected path with an uninspected one.
4. Remove temporary exceptions, test objects and pilot-only CA trust/settings only after restoration has been verified and removal is approved. Retain CA trust still required by the active path until those checks succeed; do not remove shared CAs without checking dependencies.
5. Record the Rule ID, client, destination, visible CA, log event, time and restored settings in the change record.

The Web Policy may remain configured, but without Decryption it cannot scan the encrypted HTTPS payload. Revert to Web Proxy only if that was the verified initial state. Do not disable the entire SSL/TLS engine as the standard rollback because that stops all DPI TLS rules and the application of the DPI Web Policy to HTTPS.

Stop the rollout as soon as a business-critical application fails, certificate warnings appear outside the pilot group, the scope matches more broadly than expected, or load and errors exceed the predefined limits. Expand the Source group gradually only after the positive test, exception negative test, business applications, logs, user feedback and load profile all meet the agreed criteria throughout the agreed period.

During operation, review exclusions, TLS errors, new applications, load and user feedback on a defined schedule. Keep temporary exceptions only while the owner, reason and review date remain valid; otherwise, remove them after a fresh positive and negative test.

FAQ