Setting Up Sophos Firewall Web Protection with Web Policies

Sophos Firewall Web Protection controls which websites, categories, and web content users are allowed to access. In practice, Web Protection is not just a single checkbox. A web policy must be professionally planned, activated in an appropriate firewall rule, and then tested with real traffic.

Many errors occur because a web policy exists but is not applied to any active firewall rule. Other issues are related to HTTPS, TLS Inspection, QUIC, user recognition, rule order, or overly broad exceptions. The sensible process is therefore: plan the policy, build the rule, activate, test, and monitor in operation.

Which Web Protection Article Fits?

Web Protection overlaps with firewall rules, TLS Inspection, QUIC, reporting, and exceptions. Depending on the task, a more specific article may be more suitable:

• Set up Web Protection and Web Policies in general: This article.
• Understand single or dual engine, scan failures, size limits, and a real malware test: Configure and test Sophos Firewall malware scanning.
• Evaluate web categories, URL groups, and instant alerts: Use Sophos Firewall Web Categories and Instant Alerts.
• Decrypt and inspect HTTPS traffic: Properly Implement Sophos Firewall TLS Inspection.
• Distribute CA certificate for managed clients: Distribute Sophos Firewall CA Certificate for TLS Inspection.
• Classify QUIC and HTTP/3 in web filtering issues: Properly Block Sophos Firewall QUIC and HTTP/3.
• Determine which firewall rule and policy actually apply: Test Sophos Firewall Rule with Log Viewer, Policy Tester, and Packet Capture.
• Evaluate web and security events over a longer period: Central Firewall Reporting or Send Syslog to SIEM.

This keeps the analysis clean: First, it must be clear whether the firewall rule matches. Then, check the web policy, category, user context, QUIC, TLS Inspection, and logging.

What Web Protection Controls

Web Protection consists of several components. Not every component needs to be used in every environment, but the relationships should be clear.

• Web Policy: Rules for allowed, warned, blocked, or quota-based web access.
• Web categories: Sophos categories and custom categories for websites.
• URL groups: Custom domain lists for targeted allow or block rules.
• File types: Control of specific download or file types.
• Content filters: Terms or patterns for content control.
• Exceptions: Targeted exceptions from web, TLS, or scan behaviour.
• Search engine enforcement: SafeSearch and YouTube Restrictions.
• Advanced settings: Google Apps login domain restrictions and Microsoft Entra ID Tenant Restrictions.
• Logging and Reporting: Traceability in Log Viewer, Reporting, Central, or SIEM.

Web Protection does not replace a clean firewall rule base. The firewall rule first decides which traffic is allowed from which zone to which destination zone. The web policy complements this rule with web control. The basics of rule order, source, destination, services, and security profiles are covered in Understanding and Building Sophos Firewall Rules.

Prerequisites

Before rollout, these points should be clarified:

• Web Protection is licensed or included in the bundle used.
• The affected client networks have their own firewall rules.
• Logging is active in the relevant rules.
• DNS and the firewall’s time are functioning correctly.
• User recognition is clarified if policies are to apply per user or group.
• TLS Inspection is planned if HTTPS content is to be inspected more closely.
• QUIC/HTTP/3 is consciously allowed or blocked.
• There is a pilot group and a fallback path for business-critical sites.

Particularly important is the separation by target groups. A web policy for normal clients, servers, guests, VPN users, and management systems should not be the same. Servers often need less browsing control but stricter target and update lists. Guests often need categories and bandwidth limitation but no access to internal resources.

If web policies are meant to react to users or groups, user recognition must work. AD SSO, Captive Portal, STAS, SATC, or other methods should not first be discovered during the web policy rollout. In Log Viewer, it must be visible whether a request was evaluated as a known user, as a group, or as Anybody or an unknown user.

User criteria in the matching firewall rule take precedence over Users in the Web Policy. First ensure that the user or group matches the firewall rule; the Web Policy can narrow that scope but cannot add a user excluded by the firewall rule.

Minimal Path to an Effective Web Policy

Create a Web Policy under Web > Policies and enable at least one narrow Allow/Block decision. Then edit a real rule under Rules and policies > Firewall rules with Action: Accept, the correct Source Zone and Source Network, Destination Zone and Destination Network, and required Services. Enable Log firewall traffic and assign the policy under Web filtering. Verify existing NAT against the established internet path; don’t invent new NAT behaviour just for the Web Policy.

Record the Rule ID and results for one deliberately allowed and one deliberately blocked URL as the pre-change baseline. Repeat both requests from a client with the real source and user context. Accept the change only when Log Viewer shows the expected Rule ID, new Web Policy, and genuine Allow and Block decisions.

Plan Web Policy

A good web policy does not start in the interface but with a few professional decisions.

Define Target Groups

First, determine who the policy applies to:

• Standard clients in the LAN
• Managed notebooks via VPN
• Guest WLAN
• Training rooms or school environments
• Servers with outgoing HTTP/HTTPS access
• Privileged admin workstations

If the same firewall rule contains several very different groups, web protection becomes difficult to understand. Separate rules and policies are better, for example, LAN_USERS_WEB, GUEST_WEB, or SERVER_UPDATES_WEB.

Define Categories and URL Groups

Sophos web categories are good for broad control: Malware, Phishing, Adult Content, Anonymizer, Streaming, Social Media, or Games. URL Groups are better when individual domains need to be specifically allowed or blocked.

The highly objectionable criminal activity category is always blocked. Neither policy rules nor exclusions can allow it, and SFOS hides the domain in logs and reports.

Typical usage:

• Block known risk categories: Web category.
• Allow specific SaaS domains: URL group.
• Handle a single miscategorized domain: URL group or custom category.
• Restrict streaming by time: Web Policy with Schedule or Quota.
• Warning page instead of hard block: Web Policy with Warn action.

URL Groups should not become an unsorted collection list. If many domains are entered, the list needs an owner, a purpose, and a review date. For very large or dynamic lists, Sophos Firewall Threat Feeds or other architectural components are often more appropriate.

Create and safely use URL groups explains how valid domain values, OR logic, web policy use, and TLS exclusions fit together.

For pure domain matches, URL Groups are usually better than custom Web Categories. Sophos itself points out that URL Groups are more performant and can produce fewer false positives. Custom categories are useful when a domain should additionally appear in a custom policy logic alongside its Sophos standard category.

Use keywords in custom categories very carefully. Keywords are checked against the full URL including path and query. An allow based on a keyword can therefore match unintentionally if the word appears in a query parameter on another domain. For allow decisions, concrete domains or URL Groups are usually cleaner; keyword rules are better suited to narrow block cases.

Set Allow Rules Carefully

Allow rules in web policies should be tight. An allow rule high up can render later block rules ineffective because Sophos evaluates web policy rules from top to bottom. This is particularly relevant if a URL Group, a file type rule, or a category exception is above other rules.

Practically proven:

A business allow rule placed above critical block rules applies only within its narrowly defined scope. If a risk category must remain blocked without exception, its block rule must sit above all matching Allow rules. Test the order with an allowed business destination and a blocked destination within the exception scope; allowing a domain must not inadvertently allow every file type or all content at that destination.

• Warn or quota rules for grey areas.
• Generally allowed web traffic only at the end.

Create Web Policy

The web policy is created under the following menu:

Web > Policies

Basic procedure:

1. Select Add policy.
2. Give a descriptive name, for example, LAN_USERS_STANDARD_WEB.
3. Add rules.
4. Check search engine enforcement, for example SafeSearch or YouTube restrictions.
5. Set policy quota status if quota actions are used.
6. Check advanced settings, especially logging, reporting, large downloads, Google Apps, and Microsoft Entra ID Tenant Restrictions.
7. Save the policy.

A rule within the Web Policy is created with Add rule. The firewall first creates a disabled default rule that blocks HTTP for Anybody. Then adjust the fields deliberately:

1. Open Users and deliberately set Anybody, specific users, or groups.
2. Open Activities and select All web traffic, user activities, categories, URL Groups, or file types.
3. For content rules, select the separate Content filters tab, choose the filter, and enable and with content. Keep the HTTPS action as Use action.
4. Set Action for HTTP: Allow, Warn, Block, or Quota.
5. Check HTTPS action: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS, or Quota HTTPS.
6. Set Constraints if the rule should only apply to a schedule.
7. Check the rule position within the policy.
8. Turn on the rule status.
9. Save the policy.

In Users > Add new item, deselect Anybody if the rule is intended only for specific users or groups. In Activities > Add new item, deselect All web traffic before selecting individual Activities. Confirm each selection with Apply selected items. Otherwise, the rule remains unnecessarily broad despite the additional individual objects. The HTTP actions are named Allow HTTP, Warn HTTP, Block HTTP and Quota HTTP; Use action applies the same decision to HTTPS. For Content filters, this link is fixed and cannot be replaced with a different HTTPS action.

Import Content Filter Lists Cleanly

Content filters are maintained under Web > Content filters and then selected under Activities in the web policy rule. For larger term lists, Sophos supports a simple .txt file. The file can contain no more than 2,000 lines, and each entry can be no longer than 80 characters, including spaces and punctuation.

The import file contains exactly one term per line, and every line is evaluated as an exact match. Headings, comments, metadata, or additional columns do not belong in the file. Save non-ASCII content as UTF-8.

Safe procedure:

1. Clean up the terms in a text editor and place exactly one entry on each line.
2. Save the file as .txt with UTF-8 encoding.
3. Import the list under Web > Content filters and assign a descriptive name.
4. While editing Activities, use the separate Content filters tab, select the filter, enable and with content, and leave HTTPS at Use action.
5. Use a pilot client to test one allowed term and one deliberately matching term, then check the action in Log Viewer.

If an import is rejected or individual terms do not apply, first check the line count, character length, encoding, and invisible extra characters. A broad allow rule above the content filter rule must not bypass the list.

To import the list, select Add content filter, enter the name, use Choose file to select a file such as blocked.txt, and click Apply. Then explicitly check Block HTTP and Use action for HTTPS in the web policy rule, confirm the filter with Apply selected items, enable Status, and save the policy. Importing alone does not activate a block. A dedicated, assigned policy is better suited to the pilot than an uncontrolled change to the shared Default Policy.

Create Custom Web File Types

Sophos Firewall identifies File types by file extension or MIME header. Built-in types can’t be edited. Create a custom type under Web > File types > Add from a suitable template, then add the required extensions without a leading period or add MIME headers. The same object can subsequently be used in web and email protection policies.

In the Add dialog, enter a name. Template is optional and supplies the common extensions and MIME headers for a category; you can add values for the custom type. Then click Save. Do not put a period before an extension: pdf is correct and .pdf is not. Built-in types serve as presets and can’t be edited; create a custom type when changes are required.

SFOS provides the built-in categories All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files, and Web files. The detail view under Web > File types is the operational source for the extensions and MIME headers currently configured. For example, Compressed files includes entries such as 7z, gz, rar, tar.gz, and zip, while Document files includes entries such as docx, xlsx, pptx, odt, rtf, and pdf. Before allowing a category, open the specific built-in type on your SFOS version and compare it with the real use case rather than relying on its name alone.

The new file type has no effect on its own. Select it under Activities > File types in the relevant web policy rule. Then check the action, rule status, and order, and make sure the web policy remains assigned to the firewall rule that actually handles the traffic.

Validate it with one representative download and a deliberately similar file that shouldn’t match. Check the web policy and action in Log Viewer. A match based on an extension or MIME header is a policy classification, not proof of malware or a completed Zero-Day analysis. For HTTPS, the required visibility also depends on the TLS inspection path. If the type doesn’t match, first compare the rule status and order, the File Type actually selected, the server’s Content-Type response, the visible file extension, and the TLS inspection status. An incorrect or generic MIME type supplied by the server can make the test behave differently from what the filename suggests.

Built-in file type reference

The following reference maps the documented extensions and MIME headers to the built-in categories. It describes a classification, not whether a file is allowed or safe. Before making changes, cross-check the values in your own installation. All executable files also covers Mac/Linux executables through additional MIME headers; Executable files is Windows-focused. Dynamic files generate dynamic web content, while Encoded files include encrypted or binary-encoded content, among other types. Categories can overlap: for example, mdf appears under databases and disk images, tar under documents, and tar.gz under compressed files. In particular, application/octet-stream under Backup files is a generic MIME value, not reliable proof of a backup file.

All executable files

• Extensions: exe, cmd, bat, com.
• MIME headers: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Extensions: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• MIME headers: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

Backup files

• Extensions: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• MIME headers: application/octet-stream.

Compressed files

• Extensions: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• MIME headers: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Extensions: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• MIME headers: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Extensions: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• MIME headers: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensions: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• MIME headers: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

Disk image files

• Extensions: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• MIME headers: application/x-cdlink.

Document files

• Extensions: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, wpd, wps, pdf.
• MIME headers: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

• Extensions: jsp, asp, php, cgi, shtml.
• MIME headers: text/x-script.perl, text/asp.

Encoded files

• Extensions: bin, enc, hex, hqx, mim, mime, uue.
• MIME headers: application/mac-binary, application/macbinary, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Extensions: exe, cmd, bat, com.
• MIME headers: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Extensions: bmp, gif, jpeg, jpg, pcx, png.
• MIME headers: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

• Extensions: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• MIME headers: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Extensions: 8bi, arx, plugin, vst, xll.
• MIME headers: application/x-visio.

System files

• Extensions: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• MIME headers: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Extensions: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• MIME headers: application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, Video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

• Extensions: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• MIME headers: application/atom+xml.

Combine User Activities Cleanly

Under Web > User activities > Add, a User activity combines Web Categories, File types, and URL Groups into a reusable activity. These elements are evaluated with OR; one match is sufficient. The name therefore doesn’t refer to a signed-in user, but to a collection of web criteria.

Select the User Activity under Activities in the web policy rule. This is useful when the same combination is used in several policies. For validation, test at least one match for each included object type and one similar non-match.

In the dialogue, enter a descriptive name such as RISK_WEB_CONTENT, use Add new item to select the required categories, file types or URL Groups, and click Save. Show: All lets you limit the object types displayed if needed. For example, an activity can combine the Spyware/Malware category with a custom list of blocked test domains: a match against either criterion triggers the policy rule’s Block action. Use harmless destinations under your own control for testing; do not open a real malware site.

Check Rule Order and Migrated Policies

Web policy rules are evaluated from top to bottom. For example, if an allow rule for the .mdb file type is above a category block rule, .mdb downloads from that category remain allowed. In DPI mode, the initial connection to the category may be allowed until the file type is known; if the file doesn’t then match, the firewall drops the connection without displaying a block page. If the category must always be blocked, place its rule above the file type allow rule.

Migrated legacy policies are also subject to a hard limit of 128 rules per policy. If the source contains more rules, SFOS uses only the first 128. Therefore, deliberately consolidate adjacent rules for User Activities, Categories, URL Groups, File types, and Dynamic Categories into combined Activities before or after migration. Rule count, order, and real allow and block tests are part of migration validation.

Create recurring time windows as a separate schedule. Set up Sophos Firewall schedules for rules and policies explains the process and how it differs from a time-controlled firewall rule.

A web policy alone does not take effect. The policy must then be used in a firewall rule. This is one of the most common configuration errors.

Only merge adjacent rules with the same user assignment, HTTP/HTTPS action and time conditions. Differences in Content filters, Constraints or order must not be lost. Before merging, back up or document the old policy and record representative matches and non-matches for each Activity. After merging, check these decisions again; a lower rule count alone does not prove equivalent protection.

Configure Advanced settings selectively

Enable logging and reporting includes the policy in logs and reports; Log firewall traffic must also remain enabled in the matching firewall rule. Prevent downloading of large files blocks downloads above the specified size. Choose the threshold based on the business downloads actually required and test it with harmless files below and above that value; this download block is not the same as a malware scan size limit.

Add X-Forwarded-For header to outgoing HTTP requests forwards the IP address of the original HTTP request to the destination. This option is not required for web filtering. Enable it only where there is a justified need, because it gives the destination server additional client information; assess the disclosure of internal addresses and data protection requirements beforehand. For the pilot, document the existing values and revert these specific changes if unwanted effects occur.

Activate Web Policy in Firewall Rule

The firewall rule is located under:

Rules and policies > Firewall rules

For normal client internet traffic, a rule from LAN or a client zone to WAN is usually responsible. In the Web filtering section, the appropriate web policy is selected.

Checkpoints in the firewall rule:

• Source zone and source networks match the client network.
• Destination zone is usually WAN.
• Services include HTTP/HTTPS or the desired web services.
• Log firewall traffic is active.
• In the Web filtering section, the correct web policy is set.
• Scan HTTP and decrypted HTTPS is activated where web malware or content scanning should apply.
• Use Zero-day protection is only useful when files are scanned over HTTP or decrypted HTTPS.
• Block QUIC protocol is consciously set.
• On the transparent firewall-rule path, Use web proxy instead of DPI engine is enabled for SafeSearch, YouTube Restrictions, and Google Apps login domain restrictions. An explicit Direct Proxy can provide these functions without this firewall-rule switch; choose the mode deliberately for other use cases.
• TLS Inspection is planned separately and not confused with web policy.

Sophos Firewall sets Block QUIC protocol by default when a Web Policy is selected in the rule or Scan HTTP and decrypted HTTPS is enabled. That is often useful because QUIC cannot be scanned like classic HTTPS traffic. Even so, the option should not simply be accepted without testing: browsers, Google services, collaboration tools, and individual SaaS applications can change behaviour when QUIC is blocked.

If Application Control is also used in the same firewall rule, there is an important overlap: some Micro Apps, for example uploads or downloads within Dropbox or Gmail, are detected through URL details. In DPI environments, this detection requires an appropriate SSL/TLS Inspection rule with decryption. Application Control can then evaluate such Micro Apps even if the Web Policy itself is not the main decision point.

If a more general rule above the desired web rule matches, the traffic does not reach the web policy. In such cases, Test Sophos Firewall Rule with Log Viewer and Packet Capture can help.

Classify HTTPS, TLS Inspection, and QUIC

A large portion of web traffic is HTTPS. Without TLS Inspection, the firewall sees less content. Categories, SNI, certificates, destination IP, domain information, and metadata help but do not replace full content inspection.

DPI or Web Proxy?

With Web Protection, you must decide early whether the affected firewall rule uses the DPI Engine or the Web Proxy. This decision influences which functions apply and which logs are relevant later.

• DPI Mode: Modern standard for many client internet rules. TLS Inspection runs via SSL/TLS inspection rules, Quota is not supported.
• Web Proxy Mode: Environments with explicit proxy behaviour or policy quota. Check proxy behaviour, browser/client compatibility, and proxy logs consciously.

In many installations, DPI Mode is the better starting point. However, if time quotas are needed via Quota, a pure DPI rule is not sufficient. Then Web Proxy Mode must be consciously planned and tested. This decision should be made before rollout, as a later switch can create different error patterns, logs, and user experiences.

The Transparent Web Proxy processes only ports 80 and 443 in the firewall rule; on other ports the DPI Engine continues inspection when the rule and SSL/TLS inspection rules match. Direct Proxy is a separate, explicit client path and does not necessarily require the firewall-rule switch Use web proxy instead of DPI engine. Record whether every test uses transparent traffic or the client’s explicit proxy configuration.

The complete feature decision, pilot migration, and mode-specific acceptance tests are covered in Compare DPI Engine and Web Proxy cleanly.

Set up Direct Web Proxy with a PAC file explains how the listener, PAC file, Device Access, and working proxy rule fit together.

IPv6-only clients accessing IPv4-only web destinations use a separate two-rule path. NAT64 with Direct Web Proxy separates the web policy in the IPv6 rule from Application Control and IPS in IPv4 egress.

When Sophos Firewall must forward its web requests to a parent proxy, configure an upstream proxy in WAN or LAN/DMZ walks through the correct rule and NAT path for each topology.

When several RDS users share one server IP, Per-Connection AD SSO for multi-user hosts can distinguish the individual HTTP and HTTPS proxy connections. It doesn’t apply to non-proxy traffic and must therefore be deliberately distinguished from SATC.

TLS Inspection

If downloads, malware scanning, certain web categories, or content controls are to be reliably inspected, TLS Inspection must be planned. This requires a trusted CA certificate on the clients, appropriate TLS rules, exceptions, and a clean pilot.

The rollout is covered in Gradually Roll Out TLS Inspection on Sophos Firewall. For distributing and validating the CA certificate, see Install Sophos Firewall CA Certificate for HTTPS Scanning.

QUIC and HTTP/3

Modern browsers often use QUIC or HTTP/3 over UDP 443. This can disrupt web filtering, TLS Inspection, and scanning expectations if you actually want to inspect classic HTTPS traffic over TCP.

In many corporate environments, it makes sense to block QUIC in client internet rules so that browsers fall back to HTTPS over TCP. Details are covered in Properly Block Sophos Firewall QUIC and HTTP/3.

SafeSearch, YouTube, and Tenant Restrictions

Sophos Firewall can set additional search and cloud controls in web policies. SafeSearch and YouTube are under Search engine enforcement; Google Apps login domain restrictions and Entra Tenant Restrictions are under Advanced settings.

Typical options:

• Enforce SafeSearch for Google, Yahoo, and Bing.
• Enforce YouTube restrictions for restricted YouTube content.
• Restrict login domains for Google Apps for allowed Google domains.
• Apply Microsoft Entra ID tenant restrictions for Microsoft cloud tenant control.

The SFOS 22/23 XML API reference describes EnforceSafeSearch as applicable only when the Adult Content, Nudity, and Porn categories are denied in the Web Policy. Check these decisions in the policy actually assigned to the traffic; enabling the switch and meeting the proxy and HTTPS scanning prerequisites alone do not establish this documented condition. Check the API requirement against the installed build’s UI and runtime behaviour before rollout. If the installed build’s help differs, clarify the difference before relying on SafeSearch.

On the transparent firewall-rule path, SafeSearch, YouTube Restrictions, and Google Apps login domain restrictions require Use web proxy instead of DPI engine. An explicit Direct Proxy can provide these functions without this firewall-rule switch. SafeSearch for Bing and Yahoo over HTTPS additionally requires HTTPS scanning, and Google Apps restrictions apply only to Google-hosted domains. Treat Entra Tenant Restrictions separately and test valid tenant values with real Microsoft cloud sign-ins, not only with an example URL. These controls don’t replace identity and cloud app governance.

Under Apply Microsoft Entra ID tenant restrictions, Restrict-Access-To-Tenants contains the allowed tenants as a comma-separated list of domain names or domain IDs, with a maximum of 256 characters in total. Restrict-Access-Context contains the domain ID of the tenant that defines the restriction, with a maximum of 50 characters. Take these values from your own tenant administration, not from someone else’s example configuration. Back up the existing values first; then test sign-ins to an allowed and a disallowed tenant during the pilot. If errors occur, restore only the changed values to their previous state.

Quota and Warning Pages

Web policies can not only block or allow. With warn or quota actions, users can be consciously informed or allowed time-limited access.

Meaningful examples:

• Users may consciously confirm a warning for certain grey areas.
• Streaming or shopping is only allowed for a limited time.
• School or lab environments allow certain categories only during defined times.

Important: Policy Quota is not supported in DPI Mode. If time quotas are needed, Web Proxy Mode must be used. This should be decided early because DPI and Web Proxy have different properties and limits.

The allowed time quota is set at Web Policy level and applies to all rules in that policy that use a quota action. If two categories need different time quotas, separate Web Policies are cleaner than a single policy with mixed quota expectations. Quotas are reset locally at midnight and cannot be set to zero.

Policy Quota doesn’t apply to Content filters or Dynamic Categories. Quota changes also don’t take effect when the policy is invalid, no time remains, or a quota session is already active. Check policy and session state before changing the value again.

This policy quota applies to web categories and is not the user-based surfing quota. Creating, assigning, and reviewing consumption for surfing quota and network traffic quota follows a separate workflow.

When a destination with a Quota action is requested, the quota page appears first. The user selects a duration up to the available quota and Proceed, or declines access with Return to previous page. The page appears again at the end of the selected period; once the quota is exhausted, no remaining time is offered. A Policy Override can provide temporary access instead; the quota does not apply in that case. Override permission must therefore not be enabled as an unrestricted alternative for all users.

A matching SSL/TLS inspection rule with Action > Deny continues to block access; increasing the quota or resetting it does not resolve this conflict. First check whether the TLS block is intentional for the business requirement. Plan a Web Exception to skip HTTPS decryption only for an explicitly approved, narrowly scoped case. This also removes dependent checks and can allow invalid server certificates; do not use it as a standard fix. Separately test allowed pilot access, continued blocking outside the exception scope, and rollback by disabling the pilot exception. The Web Exception’s real boundary must be its supported criteria, for example the pilot source IP plus the confirmed hostname pattern—not the quota user’s group.

Check Policy Quota During Operation

Under Web > Policy quota status, SFOS shows the time remaining for individual users in the affected Web Policies within a 24-hour period. A selected user can be reset there with Reset. This is a deliberate state change, not a diagnostic button: document the user, policy, remaining time, reason, and timestamp first.

This reset affects the time-based Policy Quota of a web category. It isn’t the same as Reset user accounting for surfing or network traffic quotas. A reset corrects neither incorrect rule order nor missing user identification.

Customise Warning and Block Pages

Under Web > User notifications, custom images and block, override, quota, and warning messages can be configured. The placeholders {category}, {user}, and {url} insert the web category, username, and blocked URL. The preview checks presentation and text, but not whether the correct Web Policy and firewall rule match the production request.

The message should briefly explain why access was blocked or warned and where a legitimate business case can be reported. Usernames and URLs may contain sensitive information, so the page must not include internal secrets, passwords, or unnecessary contact details.

For images, enable Use custom images and select the required images. For text, enable Use custom block message, Use custom override message, Use custom quota message or Use custom warn message as appropriate and enter the text. Open the corresponding Preview link, then use a real pilot request to test the relevant message type. Do not use real customer data in test images.

Restrict Policy Overrides Safely

A user who has already been authorized by the administrator creates a session in the User Portal as follows:

1. Open My policy overrides > Add and enter a descriptive session name.
2. Keep the supplied access code or generate a new one with Generate access code. A custom, manually created code is permitted only when explicit permission has been granted.
3. Select the required permitted websites and web categories; destinations the administrator has excluded from overrides cannot be allowed.
4. Under Restricted to time periods, select an existing schedule from the list. This selects a schedule; it does not allow an arbitrary time range to be entered as free text.
5. Save with Apply. Then enter the access code in the code field on the block page when making a matching blocked request.

The user enables or disables this override session with Status. This is separate from administrative management through View overrides: the administrator can independently enable, disable, or delete the session created by the user. This user workflow is unavailable without authorization; the restriction to the AD Main Group and individual users remains in effect.

Policy Overrides are a different tool from quotas. With Enable policy override, authorised users can create temporary access to normally blocked websites in the User Portal. Authorized users and groups limits who can do this, while Blocked websites and categories defines destinations that can never be overridden. Turn on Allow manual access code entry only when user-created codes fit the approval process.

Under Web > General settings > Policy overrides, first document the previous state and authorised users. The authorised user specifies websites or categories, a limited time range and an access code for the override in the User Portal. When a matching blocked destination is requested, the block page contains an additional field for that code. If Allow manual access code entry is enabled, the specified users can create their own codes; if it is disabled, they must use generated codes. This choice must not be confused with entering an already valid code on the block page.

View overrides displays existing overrides and allows them to be enabled, disabled or deleted. For acceptance, use an authorised test user to request a matching destination within the time range with a valid code; without a code, outside the time range and for a destination that can never be overridden, normal blocking must still apply. Correlate user, Rule ID, web policy, action and time in Log Viewer. For HTTPS, the block page must actually be displayable; a connection drop alone provides no input field.

For rollback, disable the pilot override through View overrides and use a new request to check the original block. Only then delete an override that is no longer needed and restore only the global values changed during the pilot to their documented previous state. Do not indiscriminately remove existing overrides belonging to other users.

For AD users, My policy overrides only applies to the main group and individual users, not to other group memberships. A matching SSL/TLS inspection rule with Action > Deny still takes precedence. If an approved override must work in that situation, plan a narrowly scoped Web Exception that skips HTTPS decryption and test it separately with a negative case; don’t broadly weaken the TLS rule. Override authorisation does not restrict the Web Exception; define and negatively test its own source-IP plus hostname/category scope as described below.

Web Exceptions and TLS Exceptions

Web Exceptions are powerful and therefore dangerous as a quick repair. Skipping HTTPS decryption also removes dependent checks and allows invalid server certificates. Skipping Malware and content scanning automatically skips Zero-day protection as well.

For DPI environments, one important limitation applies: Web Exceptions only take effect when a Web Policy is set, Malware and content scanning is active, or ATP is active. SSL/TLS Exclusion Rules, by contrast, are the right place when the only goal is to avoid decrypting specific TLS connections. The operational difference matters:

• SSL/TLS Exclusion Rule: excludes TLS connections from decryption in a targeted way, typically because of certificate pinning or incompatibility.
• Web Exception: can skip Web Policy checks, malware scanning, Zero-Day analysis, or certificate validation.
• URL Group in Web Policy: controls allow, warn, block, or quota decisions within normal policy logic; a URL Group isn’t a Web Exception criterion.

For Web Exceptions, avoid root domains and overly broad URL regex patterns: a bare pattern such as example.com can also match text in another domain’s path or query. Specific hostname patterns can match in the TLS context; URL-only paths are visible only with HTTP or already-decrypted HTTPS. The supported Web Exception criteria are URL regex patterns, web categories, source IP addresses, and destination IP addresses—not users, user groups, or URL Groups.

For a business allowance limited to a user group, use the matching firewall rule and Users in the Web Policy; for an identity-scoped decryption exclusion in DPI mode, use the appropriate SSL/TLS inspection rule with Don’t decrypt and explicit user/group criteria. Those identity criteria do not become criteria of a separately applied Web Exception and do not by themselves confine its bypass.

For a Web Exception pilot, combine the specific client Source IP addresses with a confirmed hostname pattern or a justified web category. Test both an unapproved source and a destination outside that actual match scope; an IP address is not a user identity. Do not infer from generic AND logic that source-IP and destination-IP exceptions may be combined for TLS exclusion: the retained TLS-exclusion guidance says they cannot be combined, and its exact scope is unclear. If both IP restrictions are required, stop without enabling or widening the exception and obtain build-specific clarification. The procedure and matching limits are covered in Create and test Web Exceptions safely.

Exceptions combine their different criteria with AND. Within one criterion type, for example multiple URL patterns, OR applies. This is useful but error-prone: an exception with URL pattern and source IP only applies when both match. An exception with many URL patterns, however, can have a much broader effect than expected.

Be especially careful with Policy checks. If a Web Exception skips Policy checks, it can indirectly weaken other rule decisions. In combination with Synchronized Security Heartbeat, such an exception can mean that web requests are not blocked as expected even though Heartbeat checks are set in the firewall rule.

Targeted Web Protection automation through the XML API

The XML API is useful when the same verified web objects must be maintained on multiple firewalls. It replaces neither assigning the Web Policy to the firewall rule that actually applies nor traffic verification. Before writing, back up the current object inventory, its references, and the old policy. Access, request construction, API version, XML status, and Audit Trail are explained in Securely configure XML API access and evaluate responses. The following object relationships are not a complete executable request template. For the explicitly noted source conflicts, first check API help for the installed build and do not write without unambiguous clarification.

Objects first, policy and assignment afterward

A manageable automation use case is a custom URL Group for business destinations, a custom File Type for downloads, and a User Activity that combines these criteria. First read or create these objects using their actual names, then have the policy rules reference these objects, and finally assign the Web Policy to the existing firewall rule that actually applies in a controlled manner. A new object alone does not yet allow or block any traffic.

• URL Group: WebFilterURLGroup contains Name and repeated URL entries under URLlist. The spelling URLlist is not the same as URLList for an external Web Category. IsDefault identifies a built-in URL Group; according to the reference, the field is read-only, and changes to it are ignored during an update. It does not turn a custom object into an editable default object. The URL Group workflow remains authoritative for suitable domain values and UI maintenance.
• File Type: FileType combines FileExtensionList with repeated FileExtension values and MIMEHeaderList with repeated MIMEHeader values. The comment in the XML example describes Template as importing the template’s extensions and MIME headers and adding separately specified entries. Therefore, after writing, check the effective complete list, not just the added values. The example shows Blank, but the parameter table does not explain Template; do not derive a universally valid template list from this. Extensions remain without a leading dot, for example pdf.
• User Activity: UserActivity uses Name for the existing name and NewName for an intended rename. Under CategoryList are Category objects with Type and ID. In the example, the type labels web category, file type, and url group are separate from the ID, which is an object name. Do not use a type word as an object ID or invent a numeric ID. The example calls the description tag Desc, whereas the table calls it Description; confirm the valid tag for the specific build. The OR combination of the activity criteria remains separate from the subsequent HTTP/HTTPS action.

For a File Type error, these XML responses are particularly relevant: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type or Edit File Type 503 / Message.FileTypeSameDetailRecordExists, and 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. These are unchanged reference symbols, not resolved message texts and not HTTP codes. For 202, read the old and new names and the policy references; for 503, compare the existing detail values, and for 505, check extensions/MIME headers. Do not simply create a second object with a different name.

Custom categories: separate content, classification, and bandwidth

WebFilterCategory distinguishes two input paths through ConfigureCategory: Local uses DomainList/Domain and KeywordList/Keyword; External uses URLList/URL for the external category list. An external list URL is not automatically a business domain value to be allowed. The origin, updates, and content of the external list must be traceable. Do not mix both paths in a request without verification.

Classification classifies the category but does not decide Allow or Block. The description sometimes uses different labels from the enum table; the latter lists Productive, Unproductive, Acceptable, and Objectionable. ConfigureCategory is not entirely consistent either: the example shows Local/External, while the table additionally lists 0. Do not submit translated classification names or use 0 as an unverified substitute. QoSPolicy references a bandwidth policy, not a Web Policy action; selection and effect are checked in the Traffic Shaping workflow. Only an appropriate Web Policy rule turns the category into an access decision.

The category table requires careful follow-up verification of the details:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded and Update Category 201 / Message.WFCCategoryDetailCannotUpdated: Do not treat all XML 2xx responses as fully saved domain/keyword/list values. Read back the object header and each required set of details separately. Add Category 202, like 200, references Message.WFCAddSuccess; the shared symbol name does not explain the difference between the codes.
• Add Category 522 / Message.WFCMaxFiveURL and 523 / Message.WFCMaxFiveKeyword, but Update Category 503 / Message.WFCMaxFiveURL and 504 / Message.WFCMaxFiveKeyword: Evaluate the operation and code together. The symbol names alone do not establish a universal current limit of five entries; clarify the actual permitted scope using the build help.
• Delete WebFilter Category 201 / Message.WFCRelationExists and 203 / Message.WFCSomeCategoryCannotDeleted: Check references and remaining categories before deleting or retrying. Do not assume blanket deletion success for a selection of multiple categories.

All Message.* symbols are intentionally left unresolved here. Before a retry, preserve the actual saved state and the response; in particular, do not blindly repeat a partially applied category change.

Content Condition Lists: Key is not Name

A ContentConditionList object contains the visible Name, the separate identity Key, and ContentList with repeated ContentString values. The reference requires Name and Key; for Delete Content Condition List, Key is explicitly the selector. Therefore, retain both values when reading and documenting, and never use the displayed name as a deletion key without verification.

The API table describes ContentString as raw regex values and says that duplicates are not ignored. By contrast, the UI import described above is a text list with one Exact Match per line. A UI import and an API regex list are therefore not established as identical input formats. Before switching, clarify the semantics using the build help and test harmless matches and non-matches; do not submit an existing text list as a regex payload without verification.

The reference’s contradictory operation/message mappings are particularly notable:

These rows demonstrate a documentation conflict, not that an update deletes or a delete updates. Check the operation, Key, response, and actual existing contents. Without unambiguous clarification for the build, do not derive a destructive operation from this or initiate an automatic retry based on a symbol name.

WebFilterPolicy: preserve order and selectors

WebFilterPolicy holds the rules under RuleList/Rule. Each rule references an ID object name and a type selector under CategoryList/Category. The policy example uses WebCategory, URLGroup, UserActivity, DynamicCategory, and FileType; these tokens differ from the type labels in the User Activity example, and the tag type is lowercase here. Use the spelling, object type, and existing name from the object read back or from the build help, rather than serializing UI labels or invented IDs.

HTTPAction and HTTPSAction are separate decisions; FollowHTTPAction describes their coupling. The API example lists Deny, Allow, Warn, Log, and Quota. These example values do not confirm that all of them are selectable on every build, and Deny must not simply be replaced with the UI word Block. PolicyRuleEnabled controls rule activation, Schedule the referenced schedule, and UserList/User the user scope. CCLRuleEnabled and CCLList/CCL link the content filters to the rule; the example references a CCL name there, whereas deleting the CCL requires its Key. The HTTPS behavior of a Content Filter must still correspond to the UI coupling explained above. During an update, preserve order, user scope, schedule, content filters, and Default Action, and compare the entire saved policy. A missing field must not be assumed to guarantee either retention or deletion.

For the following inputs, the reference provides no conflict-free, executable template:

• DefaultAction: The table specifies a maximum of one character but also allows Allow and Deny. Do not truncate to one character or invent a numeric substitute encoding. EnableReporting shows Enable/Disable in the example, whereas the table allows only Enable; disabling is therefore not confirmed without checking the build.
• DownloadFileSizeRestriction: The XML comment specifies 1 to 1536 MB, while the parameter table specifies 0 to 1536. The meaning of 0 is therefore unclear; treat it neither as unlimited nor as a valid active limit. Set the DownloadFileSizeRestrictionEnabled switch and the limit together based on the build help, and test with harmless files on both sides of the confirmed limit. QuotaLimit is specified as 1 to 1440 in the API table; confirm that the installed build accepts the intended value. DPI still does not support Policy Quota.
• Tenant Controls: Office365Enabled, Office365TenantsList, and Office365DirectoryId belong to the Microsoft tenant restriction. For the list, the API table specifies 4096 characters, whereas the UI help for Restrict-Access-To-Tenants specifies 256; do not equate these limits or derive a longer production value from the API specification. The example value for Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, contains non-hexadecimal characters and is not a valid GUID example value. Do not silently repair it; instead, use the actual Directory ID from your own tenant administration and test both permitted and non-permitted tenant logins. Confirm the UI field mapping, lengths, and semantics in the installed build.

Add Policy 522 / Message.WebPoliciesLimit concerns the policy limit; do not derive a limit for rules or categories from it. Update Policy 503 / Message.WFPQuotaLimitInvalid requires checking the quota input. The reference additionally lists Update Policy from API as a separate operation name; its response rows do not contain this 503 entry. This does not establish that this path accepts every quota. Check the status, saved policy, and actual effect before writing again.

Do not mix global protection options and notifications

WebFilterSettings is the global web filter settings area, not an individual WebFilterPolicy. It contains, among other things, PharmingProtection, Scanning, BlockUnscannableContent, and PUAWhitelist with repeated PUA names. A PUA entry is a deliberately approved exception, not a necessary step for a new Web Policy. Scanner selection and effect remain covered by the linked Malware Scanning workflow; adjusting a message is not a reason to change global protection options or the PUA list at the same time.

WebFilterProtectionSettings is another, separate scanner/protection contract with fields such as ScanMode and FileSizeThreshold. Similarly named protection fields do not make it synonymous with WebFilterSettings or WebFilterNotificationSettings; do not interchange payloads between these objects. For purely informational text, do not include scanner, size, or certificate options. For this protection object as well, the valid contract must come from the build help, not from example values copied without verification.

Here too, the example contradicts the table: BlockUnscannableContent shows Enable/Disable, whereas the table allows Allow and Block (Best Protection). Do not normalize these enums or guess them from the field name. Before any change, preserve the previous behavior and clarify the exact build contract.

WebFilterNotificationSettings, by contrast, addresses user notifications. OverrideDefaultDeniedMessage belongs to DefaultDeniedMessage, and OverrideDefaultWarnedMessage to DefaultWarnedMessage; custom texts are deliberately selected only with the appropriate override. Additional override/quota fields appear in the table but are partly missing from the example: OverrideDefaultOverrideMessage/DefaultOverrideMessage and OverrideDefaultQuotaMessage/DefaultQuotaMessage. The override/quota switches list 0/1 as permitted values but also specify Enable as the default. This is another source conflict, not a reason to encode all flags identically. For a text-only change, change only the intended text/override fields according to the confirmed build contract and check the corresponding page in the pilot.

DeniedMessageImage selects Default or Custom. The example binds TopImageFile and BottomImageFile to a filename from the multipart request; the table describes jpg/jpeg. For User Notifications, however, the table calls the upper parameter Top Image, whereas the example uses TopImageFile. This information is insufficient to reliably construct part names, Content-Disposition, an upload endpoint, or file mapping. First clarify file transfer using the build help or an official collection confirmed for that purpose. Do not perform an automated image change without a confirmed upload contract. The similar message/image fields in WebFilterSettings do not make the two objects interchangeable.

DefaultWebFilterNotificationSettings is separate again: it provides named default message texts, for example WebsiteBlocked. A useful narrow use case is an approved notice with the correct support contact. For this, back up exactly the affected original text, change only the confirmed message key, check the corresponding preview and actual pilot page, and restore exactly this text if necessary. Message text is neither access authorization nor evidence of a malware/zero-day finding.

Read back and validate every automation change

After every write operation, read back the exact object addressed through the API or in WebAdmin: compare names/keys, effective lists, references, policy order, activation, and the actual firewall assignment. Then run the same permitted and blocked pilot requests as before the change, and correlate Rule ID, user, Web Policy, and action in Log Viewer. An HTTP success, an XML 2xx code, or an unresolved Message.* symbol alone is not sufficient. In the event of a partial change or an unclear response, first preserve the current state and Audit Trail, then make targeted corrections; no blind Add/Delete retries. Roll back only your own documented changes, not other existing policies, overrides, or global protection values.

Test Web Protection

After saving, you should not only check if the policy exists. What matters is whether it applies to real traffic.

1. Use Policy Tester

The exact path is Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web tests the combined transparent path; Web policy only isolates the Web Policy decision. Web tests are transparent only, SD-WAN routes aren’t considered, and Source Networks containing MAC addresses aren’t supported. If protocol is omitted it uses HTTP; if port is omitted it uses that protocol’s default port.

Run the applicable modes before and after the change, recording the baseline result and expected Rule ID. Policy Tester remains a pre-check: always perform real Allow/Block tests from a pilot client because NAT, TLS Inspection, QUIC, routing, or an explicit Direct Proxy path can differ.

2. Real Test with Pilot Client

With a pilot client, check:

• Allowed business site
• Blocked category
• Warning category
• URL Group Allow
• URL Group Block
• HTTPS site with and without TLS Inspection
• Download of a harmless test file type
• Behaviour with QUIC active or blocked

3. Check Log Viewer

In the Log Viewer, it should be visible:

• Which firewall rule was hit
• Which user was recognized, if relevant
• Which web category or URL group was involved
• Whether HTTPS, TLS Inspection, or malware scan was involved
• Whether the action allowed, warned, or blocked
• Whether a Web Exception or TLS Exclusion applied
• Whether a download was handled differently because of size, malware scan error, or Zero-Day analysis

For Syslog or SIEM, URL and action are not enough. Reliable analysis also needs Firewall Rule ID, user, category, Web Policy, HTTP method, status, scan result, exception hint, and SSL/TLS relation. If these fields are missing in the SIEM or normalized incorrectly, Web Protection quickly looks less clear in reporting than it actually is on the firewall.

For deeper troubleshooting, log files are also relevant. The assignment is covered in Sophos Firewall Troubleshooting: Services and Logs.

Instant Alerts and Reporting

If certain categories are not only to be blocked but actively reported, instant alerts can be useful. This is particularly useful in schools, strictly regulated environments, or areas with a clear internet usage policy.

The three evaluation paths answer different questions:

• Quick email for a few sensitive web categories: Instant Alerts.
• Recurring reports, trends, and user or category evaluations: Central Firewall Reporting.
• Longer retention, correlation with other systems, or SOC processes: Syslog or SIEM.

Before instant alerts, it should be clear who receives the notification, which categories really trigger a reaction, how false positives are handled, and when the category selection is reviewed. A broad alert list without an owner quickly creates email noise but no better security.

For technical activation and triage, see Use Sophos Firewall Web Categories and Instant Alerts. For longer-term evaluations, Central Firewall Reporting or Send Sophos Firewall Syslog to SIEM should be considered.

Manage Changes and Exceptions in Operation

Web Protection changes continuously in operation. New SaaS services are added, individual domains are miscategorized, departments need short-term access, and browser behaviour changes. Without a clear process, broad exceptions quickly arise that no one can explain later.

For each change, you should at least record:

• Who needs access? Prevents global exceptions for a few users.
• Which domain, category, or file type is affected? Separates URL Group, Web Category, and File Type cleanly.
• Is it a temporary or permanent exception? Forces review instead of permanent shadow approvals.
• Which firewall rule and web policy are affected? Prevents changes to the wrong rule.
• How is it tested? Makes success verifiable in the Log Viewer.

A small change process has proven effective:

1. Record request with user, URL, time, business reason, and screenshot or error message.
2. Check in the Log Viewer which firewall rule, web policy, category, and action were applied.
3. Decide whether the category is fundamentally wrong, whether only a single domain should be allowed, or whether the request is denied.
4. If a business allowance is necessary, keep it narrow in the matching firewall rule and Web Policy: a specific URL Group instead of an entire category, and explicit Users instead of the entire LAN. If a Web Exception is needed instead, use its own supported URL/category/IP criteria; a user group or URL Group is not a Web Exception criterion.
5. Test the change in a test rule or pilot group.
6. After saving, conduct a real test and document Log Viewer, category, Rule ID, and user context.
7. Set a review date, especially for temporary business exceptions.

Temporary exceptions should be clearly named, for example, TMP_ALLOW_vendor-portal_until_2026-07-31. Permanent business exceptions also need an owner. If no one is responsible for an exception, it should not remain permanently in the policy.

If many individual domains arise for the same service, often the web policy is not the problem, but the architecture of the service. Then you should check whether a separate firewall rule, a separate web policy, a well-maintained URL Group, or another control point is more appropriate. For dynamic IOC or block lists, web policy exceptions are usually the wrong place; Sophos Firewall Threat Feeds are more suitable.

Rollback and temporary emergency access

A web policy change can immediately affect productive work. Therefore, before major changes, you should determine how to restore the old state.

Practical rollback options:

• Duplicate or document the affected web policy before the change
• Test the change first in a pilot rule or small user group
• Do not immediately delete the old firewall rule or old web policy
• Define time window, test users, and fallback criteria
• After saving, check Log Viewer, Rule ID, and category decision

For acute blockages, do not reflexively insert a broad Allow rule at the top. Prefer a narrow, time-limited business allowance in the matching firewall rule and Web Policy, with a specific URL Group, explicit Users, and a review date. This is not a user-group-scoped Web Exception. Any necessary inspection bypass requires its own approved, supported match criteria and separate positive and negative tests. Reassess the temporary allowance afterwards.

Common Errors

Web Policy Does Not Apply

Usually, the policy is not activated in the correct firewall rule, the rule is not hit, a rule higher up allows the traffic, or the user context does not fit. First, check Log Viewer and Rule ID.

HTTPS Not Blocked as Expected

Without TLS Inspection, the firewall sees fewer details. Depending on the target, a domain or category decision may work, while content inspection, file types, or certain search functions remain limited.

If the connection is not decrypted, the firewall can still use SNI or domain information for policy decisions. Block pages, warning pages, file types, content filters, malware scanning, and Zero-Day analysis need more visibility. Therefore, check not only the Web Policy action in Log Viewer, but also the SSL/TLS Inspection status.

QUIC Bypasses Expectation

When browsers use UDP 443, traffic can be processed differently than classic HTTPS over TCP. In client rules, it should be consciously decided whether QUIC is blocked.

Allow Rule Too High

A broad allow rule at the beginning of the web policy can override later block rules. Rule order within the web policy is just as important as rule order in the firewall rule list.

Too Many Exceptions

Exceptions quickly solve a single problem but can reduce protection effectiveness. Each exception needs a purpose, owner, and review date. If many exceptions arise, often the policy structure is wrong, or a business application needs its own rule.

Web Exceptions that skip Policy checks or Malware and content scanning are especially risky. If only HTTPS decryption causes problems, an SSL/TLS Exclusion is usually narrower and easier to understand.

Reporting Shows Nothing

Then logging, reporting, firewall rule, policy selection, or log forwarding should be checked. A policy without logging is difficult to evaluate in operation.

Operational Checklist

• Checked Web Protection license status.
• Evaluated client, server, guest, and VPN traffic separately.
• Created web policy with a descriptive name.
• Planned critical categories and URL Groups consciously.
• Checked rule order within the web policy.
• Activated web policy in the appropriate firewall rule.
• Log firewall traffic, Web Policy logging, and Reporting active.
• Web Policy rules are enabled and in the correct order.
• Checked TLS Inspection and CA certificate for pilot group.
• Defined QUIC strategy.
• Web Exceptions and TLS Exclusions documented separately.
• Conducted policy tester and real tests.
• Controlled Log Viewer and reporting.
• Defined change process for web policy exceptions.
• Provided temporary exceptions with expiration date.
• Documented exceptions with owner and review date.

FAQ