Choose Sophos Firewall DPI Engine or Web Proxy correctly

For new general client internet rules on SFOS 22, 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, SafeSearch or YouTube restrictions, restricting Google Workspace sign-ins to specified domains, pharming protection, Web Cache, a parent proxy, 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.

When a classic proxy or mail service must process a known protocol on a different port, Inspect non-standard ports explains the global service-param assignment, validation, and rollback.

⚠️ 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 one of the proxy-only features listed below or a deliberate proxy design is required.
4. For Direct Proxy, also check the listener, Device Access, Allowed destination ports, and PAC or browser configuration.
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, TCP port 3128 by default. 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
• SafeSearch or YouTube restrictions must be enforced
• Google Workspace sign-ins must be restricted to accounts in specified domains
• pharming protection must be enabled
• 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 proxy processes only HTTP on port 80 and HTTPS on port 443; HTTP and TLS traffic on other ports remains with the DPI Engine even when the proxy switch is enabled. 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

Routing and outbound NAT must also work before the pilot. For a typical internet connection, this can be a matching SNAT rule with Translated source (SNAT): MASQ under Rules and policies > NAT rules. Do not change an existing correctly matching NAT rule for the mode comparison.

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. Under Web > Exceptions > Add an exception, different criterion types use AND, while multiple values within one type use OR. Skipping HTTPS decryption also skips every check that depends on decrypted content and allows invalid certificates for the match. A URL-path-only exception works for HTTPS only when the traffic is already decrypted. 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. The following options are under Security features > Web filtering:

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. Leave Block QUIC protocol selected under Filtering common web ports. SFOS selects it by default when a web policy or Scan HTTP and decrypted HTTPS is enabled; QUIC over UDP 80/443 can’t be scanned and bypasses web filtering.
6. Use Services: Any for a broad DPI pilot, or include every service actually required. DPI detects HTTP and TLS on all ports; an overly narrow service scope can invalidate the comparison.
7. 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. Under Security features > Web filtering, select the Web_Standard web policy.
2. Under Malware and content scanning, enable Scan HTTP and decrypted HTTPS according to the scan design.
3. Under Filtering common web ports, enable Use web proxy instead of DPI engine.
4. Directly below it, enable Decrypt HTTPS during web proxy filtering only when the proxy CA is trusted on the pilot and the HTTPS test is prepared. This switch also decrypts Direct Proxy traffic.
5. Leave Block QUIC protocol enabled and enable Log firewall traffic.
6. For transparent proxy, include at least the HTTP and HTTPS services. For Direct Proxy, also include the port configured under Web > General settings > Web proxy configuration > Web proxy listening port; the default is TCP 3128.
7. Under Web > General settings > Malware and content scanning, check Web proxy scanning mode. Under HTTPS decryption and scanning, check HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols, and Block invalid certificates.
8. Check the rule position and pilot source again.

In this mode, decryption is enabled in the firewall rule; the CA and certificate behavior come from Web > General 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.

⚠️ For Direct Proxy, allow only the required client zone under Administration > Device access > Other services > Web proxy; for a single pilot, a narrowly scoped Local Service ACL exception is better than broad zone access. A reachable proxy can expose the firewall’s local HTTP and HTTPS services even when the zone matrix denies them to the client, because the firewall sees these requests as coming from the proxy itself. Test WebAdmin, User Portal, VPN Portal, and other local web destinations negatively, and stop the rollout if an unacceptable exposure appears. Keep Allowed destination ports under Web > General settings > Web proxy configuration as narrow as possible, and restore temporary ACL, listener, and destination-port changes to their documented previous state after the pilot.

Check invalid SSL protocols and server certificates

Under Web > General settings > HTTPS decryption and scanning, Block unrecognized SSL protocols prevents traffic using invalid SSL protocols from avoiding HTTPS inspection. This is a protection decision, not a switch that makes every incompatible application decryptable.

Block invalid certificates allows the web proxy to connect only to websites with valid server certificates. The option applies only to the proxy; certificate validation in the DPI path is configured through Decryption profiles. Client trust in the Signing CA solves a different problem and does not repair an invalid original certificate. For an explicitly approved special case, Web > Exceptions can selectively bypass certificate validation based on websites, web categories or source and destination IP addresses. Skip only the necessary check rather than also disabling all HTTPS decryption.

Save the global proxy values before a change and confirm the affected data path. Use a valid destination and a controlled test destination with an invalid certificate to compare the client result, Rule ID and web/TLS logs; also test an exception against an unapproved destination as a negative case. If the cause remains unclear, do not widen the scope. For rollback, restore only the changed values or pilot exception to their previous state and check new connections.

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 in the firewall rule and the proxy CA and certificate options under Web > General settings > HTTPS decryption and scanning; then check 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 zone access and Allowed destination ports are narrowly scoped 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