Choose Sophos Firewall DPI Engine or Web Proxy correctly

For new general client internet rules, the DPI Engine is usually the more sensible starting point. It processes firewall, web, Application Control, IPS, malware, and TLS inspection decisions in a common path. The Web Proxy remains the right choice when an explicitly proxy-dependent feature is required, such as Policy Quota, Batch scanning, Web Cache, or a Direct Proxy design.

This is not a global either-or decision for the entire firewall. Different firewall rules and client groups can use different paths. For an individual test flow, however, it must be clear which rule matches and whether the DPI Engine, transparent Web Proxy, or an explicitly configured Direct Proxy processes the request.

⚠️ Do not switch a production rule spontaneously between DPI Engine and Web Proxy. The change affects TLS decryption, supported features, the log view, and sometimes browser and application behavior. Test a pilot client in a separate rule first, document the return path, and only then expand the scope.

Quick decision

1. Record the affected client group, Firewall Rule ID, web policy, TLS requirement, and required web features.
2. Choose DPI Engine when normal routed client traffic must be controlled without a proxy-specific feature.
3. Choose Web Proxy when Policy Quota, Batch scanning, Web Cache, or a deliberate proxy design is required.
4. For Direct Proxy, also check the listener, Device Access, PAC or browser configuration, and local firewall services.
5. Configure TLS decryption in the correct place: an SSL/TLS inspection rule for DPI, proxy HTTPS decryption for Web Proxy.
6. Put one pilot host in a separate logged rule and trigger exactly one allowed and one blocked request.
7. Check the Rule ID, web filter action, certificate issuer, scan result, and traffic path together.
8. If results differ, return to the previous rule path instead of changing both modes on the same test flow at once.

Understand DPI Engine, transparent Web Proxy, and Direct Proxy

The three terms do not describe the same configuration:

• DPI Engine: Normally routed traffic is inspected according to the firewall rule and SSL/TLS inspection rules. The client is not aware of a proxy.
• Transparent Web Proxy: The client is also unaware of a proxy. However, the firewall rule uses Use web proxy instead of DPI engine and sends conventional web traffic to the Web Proxy.
• Direct Web Proxy: The browser or application explicitly connects to the firewall’s proxy listener, normally on TCP port 3128. This path is created by the client configuration, not by the switch in the firewall rule.

A web policy takes effect in all cases only when it is selected in the firewall rule that actually matches. Scan HTTP and decrypted HTTPS also does not enable TLS decryption by itself. Set up Web Protection with web policies explains web policy planning, categories, and rule order.

With the DPI Engine, Sophos processes SSL/TLS inspection, IPS, Application Control, web policies, and antivirus in one inspection path. Depending on the platform and flow, this can benefit from firewall acceleration. Proxy connections, by contrast, are terminated and re-established by a proxy process. This still does not justify a blanket claim that one mode is faster or more secure in every environment. Only tests on the actual appliance with real rules, destination applications, and realistic throughput are meaningful.

Which features determine the decision

DPI Engine fits the general client path

The DPI Engine is a good starting point when the environment needs these properties:

• normal routed client traffic without PAC or browser proxy settings
• SSL/TLS inspection through rule-based Decryption Profiles
• HTTP or TLS detection outside the standard ports when the rule and detection match
• combined evaluation with IPS, Application Control, and malware scanning
• a consistent traffic path for new client internet rules wherever possible

In the DPI Engine, malware scanning always runs in Real-time mode. Configure and test Sophos Firewall malware scanning explains the scan engine, size limits, and error actions.

Web Proxy fits proxy features

The Web Proxy is required or appropriate when at least one of these requirements applies:

• a web policy uses Quota
• malware scanning must use Batch instead of only Real-time mode
• Web Content Cache is part of the design
• clients use a Direct Proxy with PAC, GPO, MDM, or application configuration
• a parent proxy or another proxy-based architecture is planned
• an existing, tested proxy authentication path must be retained

Policy Quota is not supported by the DPI Engine. Switching to DPI would therefore not provide an equivalent implementation of such a policy. Conversely, an existing proxy is not a reason to put every new rule into Proxy Mode. The required function and the actual traffic path determine the choice per client group.

With the transparent Web Proxy, the classic path processes HTTP on port 80 and HTTPS on port 443. The Direct Web Proxy listens on its configured listener, TCP 3128 by default. Set up the Direct Web Proxy with a PAC file brings together the listener, PAC file, narrow Local Service ACL, and proxy rule.

What both modes require

Regardless of the mode, web protection requires:

• a firewall rule that actually matches the test traffic
• a selected web policy and enabled logging
• clear source, destination, service, and user criteria
• a deliberate QUIC decision for browser traffic
• TLS visibility when HTTPS content or downloads must be inspected
• targeted rather than broad web and TLS exceptions
• a real positive and negative test

Web Exceptions can bypass security checks in both designs. They are therefore added only after root-cause analysis and documented with an owner and review date. Use Web Exceptions safely explains the exact separation between policy, malware, HTTPS, and certificate exceptions.

Prepare the example and pilot

The procedure uses these documentation values:

• Client network: 10.20.30.0/24
• Pilot client: CLIENT-WEB-01
• Fixed pilot IP: 10.20.30.50
• Existing rule: LAN_Clients_Web
• Pilot rule: LAN_Web_Mode_Pilot
• Web policy: Web_Standard
• Proxy FQDN for Direct Proxy: fw01.example.com
• Direct Proxy port: 3128

Replace 10.20.30.0/24 and 10.20.30.50 with the real client network and a fixed pilot IP visible to the firewall. No NAT may hide additional clients behind the pilot address. example.com is a reserved documentation domain; replace fw01.example.com with the internally resolvable firewall FQDN only for a Direct Proxy test.

Before the change, document the current Rule ID, web policy, Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, QUIC setting, TLS rules, CA, exceptions, and relevant logs. The pilot also needs a tested return path through the unchanged existing rule.

Place the pilot rule above the existing client rule and include only CLIENT-WEB-01 as its source. Initially copy the destination, services, web policy, and other security profiles exactly. This changes only the inspection path during the test, not routing, NAT, categories, or user logic at the same time.

Configure DPI Mode

Open the pilot rule under Rules and policies > Firewall rules:

1. Turn off Use web proxy instead of DPI engine.
2. Under Web filtering > Web policy, select Web_Standard.
3. Enable Scan HTTP and decrypted HTTPS according to the planned malware and content scanning design.
4. Enable Log firewall traffic.
5. Deliberately block QUIC if browsers must fall back to HTTPS over TCP for inspection.
6. Save the rule and check its position above the general client rule.

TLS decryption for DPI is not enabled in this firewall rule. Under Rules and policies > SSL/TLS inspection rules, the pilot needs a matching rule with Action: Decrypt, the intended Decryption profile, enabled logging, and the correct source scope. The CA used by this path must be trusted on the pilot client.

Introduce TLS inspection step by step covers a controlled rollout of the CA, Decryption Profile, exceptions, and SSL/TLS inspection rule. Without a matching Decrypt rule, the web policy can still make domain or category decisions, but the expected content and download inspection remains limited.

Configure Web Proxy Mode

For the transparent Web Proxy, adjust the same pilot rule:

1. Turn on Use web proxy instead of DPI engine.
2. Under Web filtering > Web policy, select Web_Standard.
3. Enable Scan HTTP and decrypted HTTPS according to the scan design.
4. Enable Log firewall traffic.
5. Under Web > General settings, check the proxy CA, certificate validation, and scan mode.
6. Enable Decrypt HTTPS during web proxy filtering only when the proxy CA is trusted on the pilot and the HTTPS test is prepared.
7. Check the rule position and pilot source again.

In this mode, HTTPS decryption and certificate behavior come from the proxy settings. A DPI SSL/TLS inspection rule is not the switch for proxy decryption. When changing modes, do not merely look for an existing Decryption Profile; verify the certificate issuer actually shown in the browser.

A Direct Proxy is a separate client path. The browser or application connects to fw01.example.com:3128; the listener, Device Access, firewall rule, and client configuration must all match. Use web proxy instead of DPI engine is not required for this explicit request. Direct Proxy traffic also has specific limitations: traffic shaping does not apply to this path, and IPS inspects between the proxy and WAN rather than between the client and proxy.

⚠️ A Direct Proxy reachable by a client can make local HTTP and HTTPS services of the firewall accessible through the proxy even when the zone matrix does not allow those services. WebAdmin, User Portal, and other management destinations must therefore be tested negatively. Stop the Direct Proxy rollout if an unacceptable exposure is visible.

Switch an existing rule safely

Do not migrate by editing the only production rule during the active test:

1. Export or document the existing rule and relevant web and TLS settings.
2. Create a pilot rule with identical criteria and only one pilot host.
3. Reproduce the current mode in the pilot rule first and confirm the baseline.
4. Change only the mode and its mandatory TLS configuration.
5. Test allowed, blocked, and decrypted traffic.
6. Test business-critical browser, update, collaboration, and login flows.
7. Expand the scope gradually after success.
8. If results differ, disable the pilot rule and test the unchanged return path again.

A rule migration is not the right time to change web categories, authentication, NAT, SD-WAN, exceptions, and the malware engine at the same time. Multiple simultaneous changes make unexpected results almost impossible to attribute.

Verify the effect correctly

Use at least the same four requests for each mode:

1. an intentionally allowed HTTPS site
2. a category or test URL intentionally blocked by Web_Standard
3. a controlled HTTPS download covered by the planned scan path
4. a business-critical application with a login or certificate expectation

In Log Viewer, check the time, source IP, user, Firewall Rule ID, web policy, category, action, and scan result together. The Rule ID must belong to the pilot rule. A visible webpage alone proves neither the correct rule nor the correct inspection path.

For the HTTPS test, also inspect the certificate issuer in the browser. In DPI Mode, it must match the CA of the matching SSL/TLS inspection rule. In Proxy Mode, it must match the proxy CA used under Web > General settings. If the browser shows the unchanged public server certificate, the connection may not have been decrypted or an exception may have matched.

For a blocked connection on port 80 or 443, the firewall log may show the connection as allowed while the Web Filter log shows the request as blocked. This is consistent with proxy behavior: the firewall allows the flow to the proxy, and the proxy then generates the block page. Correlate both logs by time rather than treating them as contradictory.

Test Sophos Firewall rules in a controlled way combines rule matching, Log Viewer, Policy Tester, and Packet Capture. Note that diagnostic tools can temporarily change the acceleration path during a capture. A performance difference during an active capture session is therefore not a clean comparison of the two modes.

Troubleshoot by symptom

The web policy does not apply

Check the Rule ID, rule position, source, user, service, and selected web policy. For Direct Proxy, also verify that the browser or application actually uses the listener. Do not add a broader Any rule before the actual match is understood.

HTTPS is not decrypted

Determine the active mode first. For DPI, check the matching SSL/TLS inspection rule, action, Decryption Profile, and CA. For Web Proxy, check Decrypt HTTPS during web proxy filtering, the proxy CA, and possible Web Exceptions. Scan HTTP and decrypted HTTPS does not replace either decryption step.

Certificate errors appear after the change

Check the issuer visible on the client, trust store, TLS exception, certificate pinning, and any application-specific store. Do not immediately create a broad Don't decrypt rule or Web Exception. Limit the exception as narrowly as possible to the affected domain or application.

Quota or Batch scanning is missing

These features require Web Proxy Mode. Check the active pilot rule, Use web proxy instead of DPI engine, policy assignment, and proxy scan mode. A successful DPI test cannot confirm this proxy feature.

The site is blocked but the firewall log shows allowed

Correlate Web Filter and Firewall by time. For proxy traffic, the firewall can allow the connection to the proxy before the proxy blocks the URL and returns a block page. The category, action, Rule ID, and web policy rule provide the actual decision.

Only certain ports or applications fail

Determine whether transparent proxy, Direct Proxy, or DPI is used. Transparent proxy focuses on the standard web ports; Direct Proxy requires a supported client and the listener; DPI can detect TLS on other TCP ports when the rule and decryption match. Do not use a universal port allow rule as a substitute for diagnosis.

Logs do not provide enough information

Enable firewall and web logging and repeat the test with an exact timestamp. Depending on the path, web proxy, TLS, and inspection logs are relevant. Sophos Firewall services and log files explains the files and a safe export.

Rollback and operations

For rollback, disable the pilot rule rather than deleting the production web policy. The pilot must then use the previously documented Rule ID and original traffic path again. Restore temporary proxy Device Access rules, PAC assignments, and pilot exceptions to their previous state.

In operation, every rule-specific mode decision has an owner and a traceable reason. Review proxy-only features, Decryption Profiles, CA changes, exceptions, and client groups regularly. A later switch starts with another pilot because newer browser, TLS, and application versions can change the result.

Operations checklist

• Client group, pilot IP, and return path are documented.
• The actual Firewall Rule ID and rule position are known.
• Web policy and logging are enabled in the pilot rule.
• Proxy-only features were identified before choosing the mode.
• DPI and proxy TLS decryption were not confused.
• The CA actually used is trusted on the pilot client.
• QUIC was handled deliberately and tested with browsers.
• Allowed, blocked, and scanned real traffic was tested.
• Certificate issuer and Web Filter action match the mode.
• Direct Proxy management destinations were tested negatively if this path is used.
• Firewall and web logs were evaluated together.
• No broad exception or Any rule was added as a quick fix.
• Rollback, owner, and review date are documented.

Frequently asked questions