Skip to content
Avanet

Configure and test an upstream proxy on Sophos Firewall

An upstream proxy, also known as a parent proxy, is the next proxy instance behind Sophos Firewall. Internal clients first send their web requests to the firewall’s web proxy. The firewall inspects the traffic and then forwards it to the upstream proxy. Only that proxy establishes the connection to the internet.

Sophos Firewall supports exactly one upstream proxy. The DPI engine cannot use this path. The affected web rules must therefore use proxy mode with Use web proxy instead of DPI engine.

⚠️ The parent proxy is a global dependency for web requests in proxy mode. Before enabling it, document a current backup, an independent admin connection, the existing proxy rules, the original NAT path, and a tested return path. Sophos Firewall doesn’t provide a second parent-proxy entry as a built-in failover target.

This workflow covers forwarded HTTP and HTTPS requests from internal networks. It doesn’t claim that firewall system traffic, firmware updates, or licensing connections use the same parent-proxy path.

Upstream proxy in ten steps

  1. Define a managed pilot client, one allowed web request, and one blocked web request.
  2. Decide whether the parent proxy is in WAN, LAN, or DMZ.
  3. Document the proxy IP, port, optional service account, routing, and return path.
  4. Create the proxy as an IP host and verify that the firewall can reach it.
  5. Go to Routing > Upstream proxy, select Parent proxy, and enter the address, port, and optional credentials.
  6. Set the client web rule to Use web proxy instead of DPI engine and turn on logging.
  7. For a proxy in WAN, create a narrow client-to-proxy rule and verify the effective SNAT rule.
  8. For a proxy in LAN or DMZ, also translate the client path with MASQ and create a dedicated proxy-to-WAN rule without a web policy or malware scanning.
  9. Validate allowed, blocked, and direct proxy access using the Firewall Rule ID, NAT Rule ID, web logs, and proxy logs.
  10. Test proxy failure, HA failover, and rollback in a maintenance window before adding more networks.

Understand two connections and two topologies

The data path consists of two separate connections:

  1. The client sends an HTTP or HTTPS request to or through the Sophos Firewall web proxy.
  2. Sophos Firewall turns it into a connection to the parent proxy, which forwards the request to the internet.

A browser therefore doesn’t need to point directly to the parent proxy. With an explicit direct web proxy and PAC file, Sophos Firewall remains the client’s proxy target. The parent proxy is the next hop behind the firewall.

Parent proxy in WAN

When the parent proxy is in WAN, the data path needs a firewall rule from the internal client networks to the specific proxy host and proxy port in addition to the web proxy rule. The existing Default SNAT IPv4 rule normally masquerades private source addresses. A separate SNAT rule is only required when this path needs a different source translation.

Parent proxy in LAN or DMZ

When the parent proxy is in LAN or DMZ, its internet path remains behind Sophos Firewall. Three additional components are required:

  • a client-to-proxy firewall rule,
  • a narrow MASQ SNAT rule for this path only,
  • a proxy-to-WAN rule without a web policy or another malware or content scan.

Place the proxy-to-WAN rule above overlapping rules in web proxy mode. Otherwise, traffic created by the parent proxy may enter the proxy path again or be inspected differently than intended.

Example and replaceable values

This article uses two alternatives:

  • Pilot client: CLIENT-WEB-01
  • Fixed client IP: 10.20.30.50
  • Client network: 10.20.30.0/24
  • Client zone: LAN
  • Web rule: LAN_Web_ParentProxy_Pilot
  • Parent proxy port: 3128
  • WAN proxy: PARENT-WAN_192.0.2.80
  • WAN proxy IP: 192.0.2.80
  • DMZ proxy: PARENT-DMZ_10.20.40.20
  • DMZ proxy IP: 10.20.40.20
  • DMZ zone: DMZ
  • Optional proxy account: svc_sfos_parent_proxy

192.0.2.80 is a documentation address and must be replaced with the upstream proxy’s real public or provider-side IP address. 10.20.40.20 represents an internal proxy in its own DMZ. From the Sophos Firewall’s perspective, the selected address must be reachable through the intended path.

Sophos accepts an IPv4 address, IPv6 address, or domain name. Prefer the IP address for a controllable data path: Sophos recommends it to prevent clients from bypassing the firewall’s web proxy by accessing the upstream proxy directly. A domain name isn’t a documented second proxy or failover mechanism.

Port 3128 is commonly used for proxies but isn’t an immutable product value. If the parent proxy uses another listener, the host and service objects, firewall rules, packet capture, monitoring, and tests must all use the same port.

Only use the optional account when the parent proxy requires authentication. Use a dedicated, minimally privileged service account, document password rotation and ownership, and don’t store personal admin accounts.

Enter the parent proxy globally

Before the change, the firewall must be able to reach the proxy through the intended routing and firewall path. An open TCP port alone doesn’t prove working proxy authentication or HTTP forwarding.

  1. Go to Hosts and services > IP host and create the specific proxy host.
  2. Go to Routing > Upstream proxy and select Parent proxy.
  3. Enter the parent proxy’s IP address or domain name. Use the confirmed IP for this workflow.
  4. Enter the actual proxy port, 3128 in this example.
  5. Enter a username and password only when the proxy requires authentication.
  6. Select Apply.

This setting doesn’t act like a single firewall rule limited to the pilot. Narrow rules and their order constrain the pilot. Before saving, record every existing rule that already uses Use web proxy instead of DPI engine.

Set the web rule to proxy mode

The web rule from the internal network to WAN binds the web policy and scanning to the first part of the data path. Firewall rules on Sophos Firewall explains the general rule mechanics.

Create a dedicated rule for the pilot or narrowly adapt an existing pilot rule:

  • Source zones: LAN
  • Source networks and devices: CLIENT-WEB-01 or the confirmed pilot network
  • Destination zones: WAN
  • Destination networks: only the intended web destinations or deliberately Any
  • Services: the required HTTP and HTTPS services
  • Web policy: the prepared pilot policy
  • Scan HTTP and decrypted HTTPS: only when the planned protection requires it
  • Use web proxy instead of DPI engine: turned on
  • Log firewall traffic: turned on

Web Protection on Sophos Firewall explains how to validate categories, exceptions, and real allowed and blocked destinations.

The parent proxy doesn’t work with the DPI engine. A green rule status doesn’t prove the actual path. After saving, the test request must show the expected Firewall Rule ID and web policy.

HTTPS decryption is a separate decision. If both Sophos Firewall and the parent proxy decrypt TLS, it must be clear which instance issues which certificate and where an error originates. The controlled TLS inspection rollout remains the detailed workflow.

Connect a parent proxy in WAN

For a proxy in WAN, create an additional rule that explicitly permits the proxy hop:

  • Name: LAN_to_PARENT-WAN_3128
  • Source zones: LAN
  • Source networks and devices: 10.20.30.0/24 or the narrower pilot
  • Destination zones: WAN
  • Destination networks: PARENT-WAN_192.0.2.80
  • Services: a dedicated TCP service for 3128
  • Log firewall traffic: turned on

The rule must not become a broad general LAN-to-WAN allow rule. Keep the proxy host and proxy port specific. After testing, use the Firewall Rule ID to confirm that this exact rule matches.

In a standard configuration, Default SNAT IPv4 often masquerades private client addresses. Still verify the effective NAT Rule ID in Log Viewer and packet capture. A new SNAT rule only makes sense when the provider proxy requires a specific source address or the existing NAT path doesn’t match. NAT on Sophos Firewall explains the fundamentals.

Connect a parent proxy in LAN or DMZ

For a proxy in LAN or DMZ, keep its own internet traffic separate from the client-to-proxy path.

Create the client-to-proxy rule

The first rule permits only the confirmed client path:

  • Name: LAN_to_PARENT-DMZ_3128
  • Source zones: LAN
  • Source networks and devices: 10.20.30.0/24 or the narrower pilot
  • Destination zones: DMZ
  • Destination networks: PARENT-DMZ_10.20.40.20
  • Services: a dedicated TCP service for 3128
  • Log firewall traffic: turned on

If the proxy is in LAN, use its actual zone. The production Avanet workflow doesn’t require Any as either source or destination.

Create SNAT only for this path

Go to Rules and policies > NAT rules and create a narrow source NAT rule:

  • Original source: 10.20.30.0/24 or the narrower pilot
  • Translated source (SNAT): MASQ
  • Original destination: PARENT-DMZ_10.20.40.20
  • Translated destination (DNAT): Original
  • Original service: TCP 3128
  • Inbound interface: the confirmed client interface or deliberately Any
  • Outbound interface: the interface toward the proxy or deliberately Any

Only set the interface fields when the real path is stable. An incorrect interface prevents the rule from matching. Validate the rule with the expected NAT Rule ID, not only by its position.

Create the proxy-to-WAN rule without another web inspection

The parent proxy needs a dedicated rule for its internet connections:

  • Name: PARENT-DMZ_to_WAN
  • Source zones: DMZ
  • Source networks and devices: PARENT-DMZ_10.20.40.20
  • Destination zones: WAN
  • Destination networks: the required destinations or deliberately Any
  • Web policy: None
  • Malware and content scanning: turned off
  • Log firewall traffic: turned on

Place this rule above other rules that could match the same source and destination combination in web proxy mode. An IPS policy can be selected deliberately when operations require it for the proxy-to-WAN path. Don’t apply the web policy and malware scanning a second time here.

For the parent proxy’s WAN hop, the SNAT rule that actually matches applies again. Default SNAT IPv4 may be sufficient; the NAT Rule ID decides.

Validate the data path in a controlled test

A successful test doesn’t merely show that some website opens. It ties the client, rule, NAT, web policy, and parent proxy into one timeline.

  1. Record the time with time zone, pilot IP, target URL, and expected action.
  2. Open an allowed HTTP or HTTPS page.
  3. Open a category or test URL that the pilot web policy should block.
  4. In Log Viewer, verify the expected Firewall Rule ID, NAT Rule ID, web policy, action, source, and destination.
  5. In the parent proxy’s logging or monitoring, confirm that both requests arrive from the expected Sophos or NAT source.
  6. In built-in Packet Capture, use host 192.0.2.80 and port 3128, or the real proxy IP, to verify the outbound and return path.
  7. From the pilot client, test direct access to the proxy IP and port. When the parent proxy is entered as an IP address, the Sophos policy must also apply to this path; an untested bypass is a stop condition.
  8. Make the parent proxy unavailable in a controlled way or block the test port during a maintenance window. Document the observed failure and alerting behavior without assuming an automatic second proxy.

The test only passes when the allowed and blocked requests behave correctly, the parent proxy sees both, and direct access doesn’t bypass the security policy. Test a firewall rule systematically explains validation using Rule IDs and packet capture in detail.

Test HA separately

In active-active mode, Sophos can distribute parent-proxy TCP traffic between the nodes. However, each node only stores logs for traffic it processed. During troubleshooting, therefore examine both nodes or the node that processed the traffic at the time of the event.

Repeat a controlled failover with a new browser connection. Then verify the Firewall Rule ID, NAT Rule ID, parent-proxy log, and the allowed and blocked actions again. Don’t assume that an existing proxy connection continues without interruption.

Isolate errors systematically

Websites open directly but not through the parent proxy

  • Verify that the client web rule uses Use web proxy instead of DPI engine.
  • Check the actual Firewall Rule ID and rule order.
  • Check the route, proxy IP, port, NAT Rule ID, and return path.
  • When authentication is used, compare the username, password, lock status, and parent-proxy log.
  • An open TCP port proves neither a successful proxy request nor valid authentication.

The parent proxy returns 407 or an authentication error

Check the credentials and account status on the parent proxy. Don’t store a personal admin account as a quick workaround. After changing the password, update the global entry in a controlled way, test a new connection, and revoke access to the old secret.

A proxy in LAN or DMZ can’t reach the internet

  • Check the client-to-proxy rule and its Rule ID.
  • Check the narrow MASQ rule and NAT Rule ID.
  • Check the proxy-to-WAN rule, its position, and the actual proxy source.
  • Make sure Web policy is set to None and malware and content scanning isn’t enabled again.
  • Check the route and SNAT for the parent proxy’s WAN hop separately.

The web policy applies twice or the data path loops

The proxy-to-WAN rule must appear before overlapping rules in web proxy mode. Compare the source, destination, service, and Rule ID for each hop. Search awarrenhttp.log, fwlog.log, firewall_rule.log, and nat_rule.log for the same time, client IP, proxy IP, and destination. Sophos Firewall service logs explains the file mapping.

Don’t restart proxy services or leave debug output enabled. First save Log Viewer data, packet captures, and the available log files. awarrenhttp_access.log contains detailed individual requests only when debug is enabled, so it isn’t standard evidence for every incident.

HTTPS shows unexpected certificates or certificate errors

Determine whether Sophos Firewall, the parent proxy, or both decrypt TLS. Compare the issuer certificate in the browser, the matching web policy, the SSL/TLS inspection rule, and the upstream-proxy log. Don’t change CA deployment, decryption, and parent-proxy rules at the same time on suspicion alone.

Only individual applications bypass the proxy

Not every application uses browser or operating-system proxy settings. The parent proxy isn’t a general tunnel for arbitrary TCP or UDP traffic. Capture the affected application’s actual data path and matching firewall rule rather than inferring all application behavior from a successful browser test.

Operations and rollback

The single parent proxy is a documented dependency. Monitoring should check more than the TCP port: use a real HTTP or HTTPS request, authentication, latency, and the expected upstream response. Record the owner, maintenance window, secret expiry, and recovery path in the operating documentation.

To roll back:

  1. Save the time, configuration, Rule IDs, and NAT Rule IDs from before the change.
  2. Go to Routing > Upstream proxy and restore the documented previous state.
  3. Return the client web rule to its previous DPI or proxy mode.
  4. Disable temporary client-to-proxy, proxy-to-WAN, and SNAT rules only after confirming the replacement path.
  5. Open a new browser or application connection and repeat the allowed and blocked requests.
  6. In HA, repeat the test for the current processing node and after a planned failover.
  7. Remove unused proxy access and secrets only after successful validation.

Checklist

  • A current backup, independent admin connection, and previous state are documented.
  • The proxy location WAN, LAN, or DMZ, its IP, port, routing, and return path are confirmed.
  • The parent proxy is entered as an IP address or the FQDN decision is justified.
  • The client web rule uses Use web proxy instead of DPI engine.
  • The client-to-proxy rule, Firewall Rule ID, and proxy port match.
  • For LAN/DMZ, narrow MASQ SNAT and proxy-to-WAN rules exist.
  • The proxy-to-WAN rule has web policy None and no second malware scan.
  • Allowed, blocked, and direct proxy access were tested.
  • Parent-proxy failure, alerting, HA failover, and rollback were tested.
  • Owner, secret rotation, monitoring, and review date are documented.

Frequently asked questions

No. With the transparent web proxy, the client doesn’t know about a proxy. With the direct web proxy, the browser points to Sophos Firewall. In both cases, the parent proxy is the next proxy hop behind the firewall.

No. Sophos documents the upstream proxy only for web proxy mode. The affected web rule must use Use web proxy instead of DPI engine.

No. Sophos documents one upstream-proxy entry. High availability must therefore be provided on the upstream side through a tested stable address or an HA service there. A domain name alone isn’t a documented parent-proxy failover mechanism.