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:

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 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.

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:

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.

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. Consciously choose users, groups, or Anybody.
5. Select activities, categories, URL groups, file types, or content filters.
6. Set action for HTTP and HTTPS: Allow, Warn, Block, or Quota.
7. Set schedule if the rule should only apply at certain times.
8. Activate the rule.
9. Check rule position within the policy.
10. Activate logging and reporting.
11. 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.

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.
• Malware scan is appropriately activated.
• Block QUIC protocol is consciously set.
• TLS Inspection is planned separately and not confused with web policy.

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.

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.

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.

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.

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

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:

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:

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.

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.

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 and web logging active.
• Checked TLS Inspection and CA certificate for pilot group.
• Defined QUIC strategy.
• 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