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.
• 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.
• General settings: SafeSearch, YouTube Restrictions, Google Apps, 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.

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.

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.

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, file types, or content filters.
3. Add content filters if needed. For content filters, the firewall uses the same action for HTTPS as for HTTP.
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.

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.

Rules in a Web Policy are evaluated from top to bottom. An allow rule for All web traffic above a block rule makes the block rule practically ineffective. Therefore, after each change, check not only the content of the rule but also the order and the status switch.

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.
• Use web proxy instead of DPI engine is consciously enabled or deliberately disabled.
• 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 Web Proxy filters only the classic ports 80 and 443 in the firewall rule. The DPI Engine can inspect HTTP and SSL/TLS traffic on other ports as well, provided the rule and SSL/TLS Inspection rules match. In direct proxy designs, it must also be clear whether clients explicitly use the proxy or whether normal transparent client traffic passes through the rule. Otherwise, it is easy to test the wrong path.

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.

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.

These functions are helpful but not magical. With HTTPS, effectiveness partly depends on HTTPS Scanning or TLS Inspection. Moreover, they do not replace identity and cloud app governance in Microsoft 365 or Google Workspace. For productive environments, the effect should be tested with real test users and the affected browsers.

For Bing and Yahoo, SafeSearch can only be enforced on HTTPS connections when HTTPS scanning is active in the affected firewall rule. Google Apps login restrictions apply only to Google-hosted domains. Microsoft Entra ID Tenant Restrictions need clean tenant values and should be tested with real Microsoft cloud sign-ins, not only with an example URL.

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 Overrides are a different tool from quotas. They allow authorised users in the User Portal to create temporary access to normally blocked websites. This can be useful for schools or support scenarios, but it needs clear boundaries: non-overridable categories, authorised people, time windows, and a review of overrides.

Web Exceptions and TLS Exceptions

Web Exceptions are powerful and therefore dangerous when used as a quick repair. An exception under Web > Exceptions can skip protection checks for matching traffic, regardless of which Web Policy currently applies. Depending on the selection, HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection, or Policy checks are skipped.

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 the normal policy logic.

For exceptions, avoid root domains and overly broad URL regex patterns. A pattern such as example.com can also appear in paths or query parameters on other domains. Concrete hostnames, suitable URL Groups, and a clear scope by source, destination, category, or user group are better.

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

Under Web > Policies, the Policy tester is available. This allows you to check which policy decision is expected for users, URLs, and context.

The Policy Tester is a good pre-check but does not replace real packet flow. A firewall rule, NAT, TLS Inspection, QUIC, or routing can still prevent the expected policy from applying to real traffic.

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