Set up Sophos Firewall Direct Web Proxy with a PAC file

With the Direct Web Proxy, browsers and proxy-capable applications deliberately send their HTTP and HTTPS connections to Sophos Firewall. This differs from the transparent web proxy and the DPI Engine: The client knows the proxy target and normally connects to TCP port 3128.

The Direct Web Proxy is useful when web traffic must be controlled centrally through a PAC file, authenticated per user, or processed with features that require the web proxy. It is not a general internet path for every application. Only traffic that actually uses the proxy configuration follows this path.

⚠️ A client with access to the web proxy can use this path to reach local HTTP and HTTPS services on the firewall, even if WebAdmin, User Portal, or VPN Portal are not enabled for its zone under Device access. Therefore, first open the proxy only for one pilot client and explicitly test these management targets negatively.

This procedure covers a managed IPv4 pilot client. For IPv6-only clients, set up NAT64 with Direct Web Proxy explains the separate IPv6 rule to the proxy and IPv4 rule to the A-only destination.

Direct Web Proxy in ten steps

1. Define one managed pilot client, its fixed IP, and the required web destinations.
2. Document the proxy FQDN, DNS, listener port, and existing proxy dependencies.
3. Under Web > General settings, check the Web proxy listening port and allowed destination ports.
4. Under Administration > Device access, allow the Web proxy service only for the pilot and the intended firewall address.
5. Create a dedicated logged firewall rule with the pilot as source, WAN as destination, TCP service 3128, and the required Web Policy.
6. Prepare a PAC file with deliberate internal DIRECT destinations and no internet fallback that bypasses the proxy.
7. Deploy the PAC URL only to the pilot client and verify the proxy configuration that was actually loaded.
8. Test one allowed and one blocked HTTP/HTTPS request and verify the expected Firewall Rule ID.
9. Test local firewall portals, TLS decryption, applications without proxy support, and a proxy outage negatively.
10. Only then add more managed clients and document rollback, owner, and review date.

Direct Web Proxy, transparent proxy, or DPI?

The three terms describe different traffic paths:

• Direct Web Proxy: The client is explicitly configured for the firewall and its proxy port. The browser, operating system, or application sends the request to fw01.corp.example:3128.
• Transparent web proxy: The client is unaware of the proxy. When the service is enabled for its zone, the firewall intercepts HTTP on port 80 and HTTPS on port 443 transparently.
• DPI Engine: The firewall processes routed traffic without requiring a classic web proxy and can inspect HTTP or TLS on additional ports according to the firewall and SSL/TLS inspection rules.

The Use web proxy instead of DPI engine option in a firewall rule is not required for an explicitly configured client to use the Direct Web Proxy. The client path is created by the proxy configuration. The option determines whether the rule uses the web proxy instead of the DPI Engine to filter ordinary web traffic on the standard ports.

The complete mode decision, including proxy-only features, TLS configuration, and controlled rule migration, is covered in Choose DPI Engine or Web Proxy correctly.

Sophos still lists individual features that require Proxy Mode, including SafeSearch, YouTube Restrictions, Google Workspace domain restrictions, Pharming Protection, Web Cache, and a Parent Proxy. Web Protection on Sophos Firewall explains the policy and protection decision.

When Sophos Firewall must send web requests to another proxy instance, configure an upstream proxy in WAN or LAN/DMZ explains the separate rule, NAT, and validation path.

The Direct Web Proxy also changes how traffic is seen. The client connects to the firewall first, and the firewall then creates the connection to the destination. Sophos therefore documents two important limits:

• An IPS Policy applies between the proxy and WAN, not between the user and proxy.
• A Traffic Shaping Policy does not apply to Direct Proxy traffic.

If an application cannot work with an explicit proxy, do not expect a PAC file to capture its connections. That application still needs a normal routed DPI, firewall, or separate proxy path.

Example and replaceable values

This article uses a small pilot:

• Pilot client: CLIENT-PROXY-01
• fixed client IP: 10.20.30.50
• client zone: LAN
• firewall FQDN and proxy target: fw01.corp.example
• Direct Web Proxy port: 3128
• PAC URL: https://config.corp.example/proxy.pac
• internal DNS zone: .corp.example
• firewall rule: LAN_DirectProxy_Pilot
• Web Policy: Web_Standard_Pilot

Replace 10.20.30.50 with the fixed IP that the firewall actually sees as the pilot’s source. DHCP should provide a reservation for it. The address must not hide other devices behind NAT.

fw01.corp.example and config.corp.example are documentation names. Replace them with internally resolvable FQDNs covered by the appropriate certificates. The proxy FQDN points to the intended LAN or management address of the firewall. The PAC URL points to a controlled internal web server or an existing endpoint-management path, not to an arbitrary public location.

Port 3128 is the Direct Web Proxy default. If a different Web proxy listening port is used, Device Access, the firewall rule, PAC file, browser, SD-WAN Route, and tests must all contain the same port. The name of the rule or policy can be chosen freely, but it should make the purpose, source, and pilot status clear.

Prepare proxy access and the protection rule

Define the listener and allowed destination ports

Check the proxy basics under Web > General settings > Web proxy configuration:

1. Web proxy listening port: 3128 in this example.
2. Allowed destination ports: only ports to which clients genuinely need to connect through the proxy.
3. Minimum TLS version: the shared minimum version for the web proxy and Captive Portal; a change affects both functions.

The allowed destination ports are not the listener. The client connects to port 3128 on the firewall but can use HTTP CONNECT to request an external destination on port 443, for example. Add non-standard destination ports only after a specific application test. A broad port list needlessly turns the proxy into a generic tunnel.

Before changing the port, search existing PAC files, GPOs, browser policies, RDS hosts, SD-WAN Routes, and monitoring. The listener is a shared setting, not a value that should be changed for only one pilot.

Restrict Device Access to the pilot

The Web proxy service is enabled for LAN and Wi-Fi by default. An additional Accept exception does not narrow an already active broad zone permission. For genuine pilot access, the broad permission must therefore remain off or first be replaced in a controlled manner with narrower exceptions.

Under Administration > Device access > Local service ACL exception rule > Add:

1. Rule name: Allow_DirectProxy_Pilot
2. Rule position: above a matching Drop exception
3. IP version: IPv4
4. Source zone: LAN
5. Source Network / Host: CLIENT-PROXY-01 with 10.20.30.50
6. Destination host: the specific firewall address to which fw01.corp.example resolves
7. Services: Web proxy
8. Action: Accept

Before disabling a broad zone permission, check whether other clients or services already use the Direct or transparent proxy. The Device Access and Local Service ACL guide explains rule order, the zone matrix, and exception rules in detail.

Connect the Web Policy and firewall rule

Prepare the Web Policy under Web > Policies. It contains the required categories, URL Groups, user or group rules, and actions. At least one deliberately allowed and one deliberately blocked destination should be defined for the pilot.

Then create a dedicated IPv4 rule under Rules and policies > Firewall rules:

• Rule name: LAN_DirectProxy_Pilot
• Action: Accept
• Log firewall traffic: enabled
• Source zones: LAN
• Source networks and devices: CLIENT-PROXY-01
• Destination zones: WAN
• Destination networks: Any or a more narrowly planned destination group
• Services: dedicated TCP service for 3128
• Match known users: enable only if the selected authentication path has already passed a positive test
• Web filtering > Web policy: Web_Standard_Pilot
• Block QUIC protocol: enable if web traffic must not bypass proxy inspection in parallel over UDP 443; Control QUIC on Sophos Firewall explains the background
• Scan HTTP and decrypted HTTPS: only with the appropriate license and a deliberate scanning design

According to Sophos, Any is also possible as the service for a Direct Proxy rule, but it is broader than necessary. A dedicated TCP service for the actual listener makes the pilot easier to understand. After selecting a Web Policy and other protection features, check the entire rule again. The firewall rule fundamentals explain order, logging, user matching, and protection fields.

A Linked NAT is not automatically required for this pilot. However, the internet path created by the firewall needs an appropriate WAN gateway and the source translation valid for the environment. Routing and NAT are checked separately.

Create and deploy the PAC file

A deliberately narrow PAC example

A PAC file is JavaScript containing the FindProxyForURL function. This example sends only short internal names, the internal DNS zone, and the listed private networks directly. All other destinations must use the proxy:

function FindProxyForURL(url, host) {
  if (isPlainHostName(host) || dnsDomainIs(host, ".corp.example")) {
    return "DIRECT";
  }

  var isIPv4Literal = /^\d{1,3}(\.\d{1,3}){3}$/.test(host);
  if (isIPv4Literal && (
      isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "172.16.0.0", "255.240.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0"))) {
    return "DIRECT";
  }

  return "PROXY fw01.corp.example:3128";
}

Adapt .corp.example, the private networks, and the proxy FQDN to the environment. Not every RFC1918 network must be reachable internally. A list of the internal domains and networks that are actually required is cleaner.

The example deliberately does not call dnsResolve() for public hostnames. Such PAC functions trigger additional DNS lookups on the client and can delay processing; the proxy resolves external names here. Internal names are classified through the domain rules or, when the request contains a direct IPv4 address, through isInNet(). If an environment needs more complex DNS-dependent exceptions, plan them individually and test them with the browsers in use.

The example deliberately contains no DIRECT after the proxy instruction. A return value such as PROXY fw01.corp.example:3128; DIRECT allows internet traffic to continue directly if the proxy fails. This increases availability but then bypasses the Web Policy, proxy authentication, and proxy logging. We do not recommend this fail-open fallback for a mandatory security path.

Internal DIRECT exceptions are also bypasses. Add them only when the destination genuinely must be reached directly and another control path exists. Sensitive SaaS domains, identity providers, or broad wildcards do not belong in the bypass list as a precaution.

Deploy the PAC file in a controlled manner

1. Host the PAC file on an internal HTTPS endpoint with a trusted certificate.
2. Ensure that https://config.corp.example/proxy.pac can be retrieved without an already working proxy.
3. Assign the PAC URL only to the pilot through GPO, MDM, or a managed browser policy.
4. Document any existing manual proxy configuration and other PAC or WPAD settings first.
5. Fully restart the browser and affected applications.
6. Check which PAC URL was actually loaded in the browser or operating-system policy.
7. Block direct internet access outside the proxy path for the pilot in a controlled manner, or at least test it as a bypass.

WPAD autodiscovery is not required for this procedure. An explicit managed PAC URL is easier to identify and roll back. SFOS provides the listener in this design; deployment, hosting, and versioning of the PAC file remain tasks for client and web-server management.

Test the Direct Web Proxy

Verify the listener and PAC application

These read-only checks are useful on a Windows pilot client:

Resolve-DnsName fw01.corp.example
Test-NetConnection fw01.corp.example -Port 3128

DNS must return the intended firewall address, and the TCP test must reach the listener. A successful port test does not yet prove the Web Policy, authentication, TLS decryption, or internet connectivity.

Then check the proxy or PAC policy that is actually applied in the browser. An old local setting, a second management profile, or cached PAC content can override the expected configuration.

Validate allowed and blocked traffic

1. Open a new private browser window.
2. Open one deliberately allowed HTTP or HTTPS destination.
3. Open one destination deliberately blocked by Web_Standard_Pilot.
4. In Log viewer, check the time, source, user, Web Policy, action, and Firewall Rule ID.
5. For HTTPS, record whether the connection was decrypted or deliberately left undecrypted.
6. Under Diagnostics > Packet capture, narrow the capture to source 10.20.30.50, proxy port, and destination if required.
7. Test an application without proxy support and confirm that it is not incorrectly evaluated as proxy traffic.
8. Temporarily assign the pilot client a PAC test copy with a deliberately unused proxy port and verify that internet traffic fails as planned instead of bypassing the proxy. Then restore the production PAC version.

Success does not merely mean that a website loads. The request must use the expected Rule ID and Web Policy, the block test must genuinely block, and a proxy failure must match the selected fail-closed design.

Verify that management services are not exposed

From the pilot client, test the known HTTP and HTTPS addresses of the firewall, especially:

• WebAdmin
• User Portal
• VPN Portal
• Captive Portal
• other local HTTP/HTTPS services on the firewall address in use

The goal is not to force a successful login. The test determines whether the service becomes reachable through the proxy at all. If a local service that is not permitted by the security design is visible, stop the rollout. Device Access cannot subsequently block these HTTP/HTTPS requests generated internally by the proxy for individual destination portals.

Separate authentication, TLS, SD-WAN, and HA

User identity is a separate component

The Direct Web Proxy can be used with or without user identity. Depending on the environment, normal clients can use AD SSO, STAS, Captive Portal, or another supported method. The proxy configuration alone does not authenticate anyone.

For RDS or other multi-user hosts on which several people share the same source IP, Per-Connection AD SSO is the appropriate specialist procedure. It authenticates each HTTP/HTTPS proxy connection separately; non-proxy traffic does not receive this user identity.

HTTPS decryption requires a trusted CA

Scan HTTP and decrypted HTTPS does not enable decryption. In web-proxy mode, Decrypt HTTPS during web proxy filtering must also be used. The CA deployed to clients must match exactly the CA selected under Web > General settings > HTTPS decryption and scanning.

The safe rollout is described in Introduce TLS Inspection correctly. Deploy the Sophos Firewall CA certificate explains deployment and verification of the re-signing CA. Certificate pinning, separate trust stores, and applications with unusual TLS behavior require targeted tests instead of a broad exception.

Test SD-WAN and HA separately

An SD-WAN Route with HTTP and HTTPS services does not match Direct Proxy traffic on 3128. Use the actual proxy port or deliberately use Any. Source Network and Incoming Interface do not match reply packets in this special case. The proxy return path also needs at least one WAN gateway or a suitable static route. Set up and test SD-WAN Routes provides the complete explanation.

In HA, do not promise uninterrupted continuation of existing proxy or authentication sessions. After a controlled failover, create a new browser connection and verify the PAC file, Rule ID, policy, and decryption again. Each node stores the logs for traffic it processed, so the node handling the traffic at the time of the event is relevant during analysis.

Troubleshoot systematically

Proxy port is not reachable

Check the DNS response, firewall address, listener, client zone, and Web proxy under Device Access. For an ACL exception, source, destination host, service, action, and position must match. A successful ping does not prove the TCP listener; Test-NetConnection is the more specific preliminary check.

Browser accesses the internet directly

Check the effective PAC URL, the content of the loaded file, local browser exceptions, and additional GPO or MDM profiles. A DIRECT fallback after PROXY deliberately creates a bypass when the proxy cannot be reached. Applications with their own network stack may also ignore system proxy settings.

Proxy returns error 407 or a credentials prompt

This is an authentication problem, not a listener failure. Check the authentication method, user detection, group import, browser support, and FQDN/SPN where applicable. Do not broaden the rule to Any merely to remove the credentials prompt.

Website loads, but the Web Policy does not apply

Check the firewall rule, order, source, service 3128, selected Web Policy, and Rule ID together. A successful proxy request may have matched a different or broader rule. The controlled rule test combines Policy Test, Log Viewer, and Packet Capture.

HTTPS shows certificate errors

Check whether decryption is active, which CA the web proxy uses, and whether that exact CA is in the client’s trust store. If only individual applications fail, investigate certificate pinning, a separate trust store, the TLS version, and the narrowest possible exception.

Individual application or destination port does not work

First determine whether the application supports an explicit proxy. Then check Allowed destination ports, PAC bypasses, DNS, and TLS behavior. Add a non-standard destination port only for the specific application and validate it with a real request.

SD-WAN Route or WAN path is unexpected

Check service matching against the proxy port, Rule ID, WAN gateway, static route, and Route Precedence. Source Network and Incoming Interface are not reliable match criteria for proxy reply packets. Do not make a global Route Precedence change as the first response.

Logs are missing or show too little

Check Log firewall traffic in the rule and the local, Central, or Syslog destinations under System services > Log settings. awarrenhttp.log is relevant for the web proxy and access_server.log for authentication. Sophos Firewall services and log files explains classification and safe log collection.

Rollback and operations

Prepare the rollback before the pilot:

1. Document the previous proxy, PAC, GPO, or MDM setting.
2. Give the pilot rule and Local Service ACL exception unambiguous names.
3. Test the previous direct DPI or firewall path as a fallback.
4. Remove the PAC assignment from the pilot client or restore the previous version.
5. Fully restart the browser and applications.
6. Disable the pilot rule and test a real direct web flow over the fallback path.
7. Remove the pilot ACL exception and restore temporary broad Web proxy zone permissions to their previous state.
8. Check live and log data and document the time from which proxy traffic is no longer expected.

In operation, the PAC file has a version history, an owner, and a review date. Every new DIRECT exception is a policy exception and should be justified, tested, and reviewed later like a firewall or web exception. The listener, allowed destination ports, and broad zone permissions also belong in the regular review.

Checklist

• Direct Proxy is the appropriate model for the affected browsers and applications.
• The IPv4 pilot client and fixed source IP are documented.
• Proxy FQDN, PAC URL, and certificates resolve correctly.
• Listener and allowed destination ports are as narrow as possible.
• The broad web-proxy zone permission was checked and replaced where necessary.
• The Local Service ACL exception restricts the source and firewall destination address.
• The firewall rule uses the proxy port, logging, and the expected Web Policy.
• The PAC file contains only justified internal DIRECT exceptions.
• An internet fallback that bypasses the proxy is not active unnoticed.
• Real allowed and blocked traffic matches the expected Rule ID.
• Local HTTP/HTTPS services on the firewall were tested negatively.
• Authentication, TLS decryption, QUIC, and non-proxy applications were assessed separately.
• SD-WAN and HA behavior were tested when these functions are used.
• Rollback, owner, versioning, and review date are documented.

Frequently asked questions