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:

1. Specific allowed business exceptions at the top.
2. Critical block categories thereafter.
3. Warn or quota rules for grey areas.
4. 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.

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.

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.

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.

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.

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.

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.

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.

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.

Restrict Policy Overrides Safely

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.

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 exceptions, avoid root domains and overly broad URL regex patterns. Specific hostname patterns can match in the TLS context; URL-only paths are visible only with HTTP or already-decrypted HTTPS. Prefer concrete hostnames and a clear scope by source, destination, category, or user group.

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.

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 an exception is necessary, work as narrowly as possible: single URL Group instead of entire category, single user group instead of entire LAN.
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 Emergency Release

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. Better is a narrow, time-limited exception with a clear URL Group, user group, and review date. If the pressure is high, a temporary exception can stabilize operations, but it must be reassessed afterward.

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