Check Sophos Firewall HTTP proxy settings safely

The Sophos Firewall HTTP proxy settings control global properties of the Web Proxy and, in some cases, the Captive Portal. They include minimum TLS versions, timeouts, Via headers, proxy-loop protection, and URL categorization during the TLS handshake. A change can therefore affect several rules, user groups, and client networks at the same time.

The safe starting point is the read-only show http_proxy command in the Device Console. Only when a reproducible problem points to one specific parameter should set http_proxy change a single setting. Record the current value, a focused positive and negative test, and the rollback before making the change.

⚠️ The output of show http_proxy is a baseline, not a tuning list. Do not enable obsolete TLS versions, disabled URL categorization, or relaying of non-HTTP traffic as a precaution. A default documented by Sophos is not automatically a recommendation for a new security design.

Set up Direct Web Proxy with a PAC file covers the listener, Device Access, firewall rule, and PAC file. This article deals only with the global CLI parameters behind that setup.

Safe short procedure

1. Reproduce the symptom and record the client, destination, time, proxy path, and affected function.
2. Run show http_proxy in the Device Console and store the complete output securely.
3. Document the relevant parameter, its current effect, and the exact rollback command.
4. Change only this one value and create a new connection for the test.
5. Test Web Proxy and Captive Portal separately when the parameter affects both.
6. Restore the recorded value immediately if the expected effect is absent or a side effect appears.

After a secured SSH login, select 4. Device Console. Sophos Firewall CLI troubleshooting explains host-key verification, Device Access, and the difference between Device Console and Advanced Shell.

show http_proxy

Read the documented values correctly

Sophos documents the following default output for SFOS 22. The value shown on the actual firewall remains the authoritative baseline for a change and rollback.

The surprisingly enabled TLS 1.1 values are not a reason to allow TLS 1.1 in a new design. Sophos itself describes TLS 1.0 and TLS 1.1 as insecure and does not recommend them. The current state, the real legacy dependency, and a controlled test with the affected portal or proxy destination matter.

Via headers and proxy loops

With add_via_header on, the proxy adds an HTTP Via header. It makes intermediaries visible, conveys protocol information, and helps proxies detect loops. This is the documented default.

block_proxy_loop on drops requests when duplicate Via values indicate a loop. Sophos documents this protection as off by default. A loop can occur when an upstream proxy sends a request back to the same Sophos Firewall because of DNS, PAC, or routing.

Check the PAC file, Upstream Proxy, DNS resolution, and actual return path before changing the setting. A switch does not replace correcting that path.

set http_proxy block_proxy_loop on

For a time-limited trace, Sophos also requires debug logging for the awarrenhttp service. awarrenhttp.log may then show Duplicate Via header values, proxy loop. Debug is off by default and can affect performance, storage, and privacy. Enable it only for a reproducible test, turn it off afterwards, and do not use it as permanent monitoring. Sophos Firewall services and log files explains the log files and safe analysis workflow.

TLS for Web Proxy and Captive Portal

Treat minimum versions separately

The Device Console can control TLS 1.0 and TLS 1.1 separately for Web Proxy and Captive Portal. This permits a focused legacy test without automatically relaxing both functions. WebAdmin then shows only the proxy’s minimum version, and Sophos displays a warning if the values differ.

The four switches are:

set http_proxy captive_portal_tlsv1_0 off
set http_proxy captive_portal_tlsv1_1 off
set http_proxy proxy_tlsv1_0 off
set http_proxy proxy_tlsv1_1 off

These commands show the secure target for environments without a legacy dependency, not a blanket migration instruction. Inventory real portal logins, Direct Proxy clients, decrypted HTTPS destinations, and managed legacy applications before disabling a version. Test each function with a fresh client handshake. For a larger change, follow the staged TLS Inspection rollout.

If an old client demonstrably supports only TLS 1.0 or TLS 1.1, do not silently re-enable the version globally. Check an update, replacement, or a narrowly separated path first. An unavoidable temporary exception needs an owner, expiry date, documented risk, and a test that proves which of the two functions actually requires it.

X-Frame-Options protects the portal

captive_portal_x_frame_options on adds protection against embedding the Captive Portal in a foreign frame and therefore against clickjacking. Keep this documented default enabled. Disable it only for a proven, controlled embedding requirement after assessing the resulting risk separately.

Set up and test Captive Portal covers the complete design with Device Access, user rule, certificate, and sign-out.

The cipher string applies to both functions

tlsciphers_server sets the offered ciphers for Web Proxy and Captive Portal together. A supposed proxy fix can therefore change the portal and vice versa. Sophos documents this default:

HIGH:!RC4:!MD5:!aNULL

Do not copy a string from a blog or another platform. Supported ciphers depend on the SFOS version, TLS version, client, and server. Before a change, define the current output, expected cipher match, and tests for both functions. If a connection fails, separate TLS version, certificate chain, decryption policy, and client trust first.

Four timeouts with different effects

According to Sophos, all four values accept 1 to 2147483647 seconds or default. A technically valid extreme value is not necessarily operationally sensible.

client_timeout applies to established proxy clients. connect_timeout limits a connection attempt. response_timeout controls how long the proxy waits for a response from a new connection. tunnel_timeout applies while an HTTPS tunnel is being set up and has a documented default of 300 seconds, compared with 60 seconds for the other three.

set http_proxy client_timeout 60
set http_proxy connect_timeout 60
set http_proxy response_timeout 60
set http_proxy tunnel_timeout 300

These are documented defaults, not an automatic repair. First determine the phase in which a connection stops and whether the client, destination server, upstream proxy, WAN path, or application sets a shorter timeout. Increasing the value helps only when the Sophos proxy value actually terminates the connection. Observe open connections and resource use during the test.

For rollback, explicitly restore the value previously read with show http_proxy. Use default only when intentionally returning to the documented default, not when the earlier value is unknown.

Do not blindly disable categorization in the TLS handshake

disable_tls_url_categories on disables category lookup for SSL/TLS inspection rules. During the TLS handshake, the traffic is then uncategorized. Only SSL/TLS inspection rules with Categories and websites: Any can match at this stage. A web policy can also make a different decision during the handshake.

The setting does not change URL categorization for normal HTTP requests or later categorization of decrypted HTTPS content. A simple page load can therefore look successful while rule selection and protection have already changed.

Before using it, review the affected SSL/TLS inspection rules, category conditions, website matches, and desired handling of uncategorized traffic. Then verify that an allowed, blocked, and uncategorizable destination hit the expected rules. Web Protection on Sophos Firewall explains how categories and policy actions work together.

Do not force non-HTTP traffic through the proxy

relay_invalid_http_traffic on relays non-HTTP traffic sent over ports normally used for HTTP and HTTPS, ports 80 and 443. It may appear to repair one legacy protocol, but it widens the proxy path and makes security assessment harder.

Sophos advises a proxy bypass for the specific application instead. Scope the bypass as narrowly as possible by source, destination, and required service, then protect it with a normal firewall rule and, where applicable, an SSL/TLS inspection rule. The global relay switch normally remains off.

Core dump and debug are for diagnostics only

core_dump on creates a core dump if the proxy process crashes. It can help Sophos Support investigate a reproducible process failure, but it is neither a health check nor a performance option. A core dump can contain sensitive process data and consume storage.

Use the function only in a specific support or diagnostic window. Confirm free storage, reproduction steps, and the secure handover path first. After the test, restore the previous value and handle any generated files according to the support instructions.

Validate and roll back a change

Use the same source, destination, and a new connection before and after the change. For a global TLS or cipher change, test at least one Direct Proxy request and one Captive Portal login. For a timeout, validate the affected phase; for a proxy loop, the exact log message; and for categorization, the SSL/TLS inspection rule actually selected.

Record time, client, Web Policy, and Rule ID in Log Viewer. If rule selection remains unclear, Test a Sophos Firewall rule cleanly combines Policy Test, Log Viewer, and Packet Capture.

Rollback uses the value recorded beforehand:

set http_proxy <parameter> <previous-value>
show http_proxy

Create a new test flow afterwards. Seeing the old value again in show http_proxy confirms only the configuration. The real proxy or portal test confirms restored operation.

Operations checklist

• Complete show http_proxy output, SFOS build, time, and responsible person recorded.
• Affected function and exactly one parameter isolated.
• Impact on Web Proxy, Captive Portal, TLS Inspection, and Web Policy assessed.
• Previous value prepared as an executable rollback command.
• Positive, negative, and unrelated control tests defined.
• Debug and core dump used only for a limited period.
• A new connection tested after the change and after rollback.
• Temporary legacy exception assigned an owner and expiry date.

FAQ