Create and safely use URL groups on Sophos Firewall

A URL group collects specific domains so that they can be used together in a web policy or an SSL/TLS inspection rule. This sounds simple, but it has an important consequence: Every change to the group affects all rules and policies that reference this object.

The safe workflow therefore does not start with the largest possible vendor list. First, identify the domains that are actually used from a request, log, or vendor documentation. Then create a small group with a clear purpose, owner, and test plan.

URL group in seven steps

1. Document the affected client, the actual destination hosts, and the intended decision: allow, block, or don’t decrypt.
2. Confirm that a URL group is the right tool. It processes domains, but not URL paths, query strings, or regular expressions.
3. Under Web > URL groups > Add, set a meaningful name and use Add to accept each valid domain name.
4. Select the group either as an activity in a web policy or under Categories and websites in an SSL/TLS inspection rule.
5. Check rule order, status, source scope, and logging. A group alone doesn’t allow or block anything.
6. Use a new connection to test an expected match and a deliberately similar non-match.
7. Document the domain list, consumers, owner, reason, test date, and rollback.

⚠️ Multiple domains in a URL group are evaluated with OR. A single match is sufficient. For TLS exclusions, a domain entry also includes its subdomains. An overly broad root domain or a highly positioned allow rule can therefore capture significantly more traffic than intended.

What a URL group controls and what it doesn’t

A URL group is a reusable domain object. It describes which domains belong together. The consuming rule then decides what happens to the match.

Typical uses include:

• a small business allowlist in a web policy
• an explicit blocklist for known domains
• a domain list in a Don't decrypt rule
• the local TLS exclusion list for confirmed decryption issues

A URL group isn’t the right tool for every web use case:

• Web category: Broad content classification or a custom category with URL paths or keywords
• Web Exception: Regex-based matching and targeted bypass of web, scanning, or certificate checks
• FQDN Host: DNS-based network object for firewall, NAT, or routing rules
• Threat Feed: Dynamically maintained IOC or domain lists

Set up web protection with web policies explains the complete policy logic. The choice between a custom category and a domain list is covered in Use web categories and Instant Alerts. For dynamic security lists, use Sophos Firewall threat feeds.

Domain instead of a complete URL

Under Search/Add, SFOS expects a valid domain name. Protocol, path, and query don’t belong in this field.

Valid example values:

updates.vendor.example
cdn.vendor.example

Unsuitable values:

https://updates.vendor.example/download/file.bin
*.vendor.example
^updates\.vendor\.example/

The .example ending is reserved for documentation. In the actual configuration, replace the examples with the domains confirmed in the log, request, or vendor documentation.

If a specific URL path, query parameter, or regular expression is required, a custom web category or a safely scoped web exception is suitable, depending on the objective. Don’t expand the domain list with a seemingly convenient wildcard pattern.

Plan the domain scope

The example uses the group Vendor update domains with two separate hosts:

• updates.vendor.example for the update download
• cdn.vendor.example for the related content endpoint

The root domain vendor.example is deliberately not used as a shortcut. Sophos explicitly documents that subdomains are included when URL groups are matched in TLS exclusions. An entry of vendor.example would therefore also include login.vendor.example, telemetry.vendor.example, and other subdomains in this path.

Even a narrower entry can include subdomains. In a TLS match, updates.vendor.example can therefore also capture api.updates.vendor.example. If only one specific host is expected, always test a deliberately similar host as a negative target in addition to the positive target.

Multiple entries in the same group aren’t a mandatory list. Because of the OR logic, one matching domain is enough. If a service only works when two hosts are reachable together, test each host separately. The URL group doesn’t prove a functional dependency between them.

Create a URL group

1. Open Web > URL groups.
2. Select Add.
3. Set a name such as Vendor update domains.
4. Enter updates.vendor.example under Search/Add.
5. Select Add and confirm that the value appears in the list.
6. Add cdn.vendor.example in the same way.
7. Select Save.
8. Open the saved group again and check the name and both domains.

Selecting Add is a separate step. A domain name that remains only in the input field isn’t yet part of the group.

The current SFOS 22 help doesn’t specify a fixed maximum number of domains per URL group. This isn’t a promise of an unlimited list. If hundreds of entries, frequent vendor changes, or continuously changing IOCs are expected, a manually maintained URL group is usually the wrong operating model.

Use a URL group in a web policy

A URL group only gains an allow, warn, block, or quota effect through a web policy rule.

1. Open Web > Policies.
2. Edit the affected policy or create a new policy.
3. Select Add rule.
4. Under Users, set the intended user or group scope.
5. Under Activities, clear the general selection All web traffic and select the URL group Vendor update domains.
6. Set the intended action for HTTP and HTTPS, such as Allow or Block.
7. Check the rule position, turn on its status, and save the policy.
8. Under Rules and policies > Firewall rules, verify that this web policy is selected under Web filtering in the firewall rule that actually matches.
9. Turn on Log firewall traffic for acceptance testing.

Web policy rules are evaluated from top to bottom. A general allow rule above the new URL group rule can hide the match. Conversely, a specific allow rule placed too high can make later block rules ineffective. The position is therefore part of the security decision and not merely a display choice.

A URL group in a web policy doesn’t replace a firewall rule. The firewall rule first allows the data flow between zones, and then the assigned web policy evaluates web access. Test rules with Log Viewer, Policy Tester, and Packet Capture shows which rule and policy actually apply.

Use a URL group as a TLS exclusion

For confirmed certificate-pinning or other decryption issues, the same object type can be used in an SSL/TLS inspection rule with Action: Don’t decrypt. SFOS efficiently compares the domain as text using Server Name Indication, or SNI.

There are two clean options.

Add to the Local TLS exclusion list

The Local TLS exclusion list is a built-in URL group and is empty by default. It belongs to the permanent default exclusion rule at the top of the SSL/TLS rule table.

The manual path is:

Web > URL groups > Local TLS exclusion list

This option is suitable for a locally confirmed domain exclusion that should apply independently of a narrower custom source or user rule. Domains can also be added to this list through the troubleshooting features in Control Center or Log Viewer. Every new domain is therefore documented and tested as a production security exception.

The Managed TLS exclusion list serves a different purpose. Sophos maintains known incompatible domains in this list and can update it with firmware updates. Custom operational domains aren’t a substitute for a deliberate local rule in this vendor-managed object.

Create a custom Don’t decrypt rule

If the exclusion needs to be limited to specific sources, users, services, or destination zones, a custom rule is easier to audit:

1. Open Rules and policies > SSL/TLS inspection rules.
2. Select Add.
3. Set a name such as Vendor updates no decrypt.
4. Select Action: Don’t decrypt.
5. Turn on Log connections.
6. Limit Source zones, Source networks, Users, Destination zones, and Services to the required scope.
7. Under Categories and websites, select the URL group Vendor update domains.
8. Position the rule directly below the default exclusions and above general Decrypt rules.
9. Save and test with a new connection.

SSL/TLS inspection rules operate independently of firewall rules. A correctly matching firewall rule therefore doesn’t prove that the intended TLS rule applies. Conversely, Don’t decrypt only excludes decryption from this path. It isn’t a general permit for arbitrary network traffic.

URL groups are more efficient for this SNI match than many FQDN host objects in the source or destination of a TLS rule. FQDN host objects resolve through DNS and serve a different purpose. Create and safely use FQDN hosts explains the differences.

If the TLS connection doesn’t contain usable SNI, the domain can’t be identified this way. Don’t broaden the group with a root domain. First check the destination IP, certificate, packet capture, and actual application flow.

Verify the match with positive and negative tests

A successful page load only proves that the service is reachable. It doesn’t prove the correct web policy rule or the intended TLS exclusion.

Web policy test

1. Record the pilot client, user, time, and expected action.
2. Close the browser or application session completely and restart it.
3. Open updates.vendor.example or the actual positive domain.
4. In Log Viewer, check Source, User, Domain, Firewall Rule ID, Web Policy, and Action.
5. Test login.vendor.example or a real host that was deliberately not added.
6. Confirm that the negative host is still evaluated by the normal subsequent policy rule.
7. If two group entries are required, test each host individually.

If the browser uses QUIC or HTTP/3, the expected TCP web path may look different. First distinguish the test from QUIC and HTTP/3.

TLS exclusion test

1. Establish a new TLS connection to the positive host.
2. In the SSL/TLS log, check the matching rule and non-decryption status.
3. Compare the certificate visible to the client with the state under the normal decryption rule.
4. Open a similar negative host that isn’t in the group.
5. Confirm that this host is still handled by the expected Decrypt rule.
6. Document the source scope, SNI, and rule position.

For a deliberate rollback test, restore the consuming web or TLS rule to its documented previous state during a maintenance window. The positive host must then show the previous behavior again. Only this countercheck turns a working workaround into a reproducible acceptance test.

Troubleshoot systematically

URL group doesn’t apply in the web policy

• The domain was entered but wasn’t accepted with Add.
• The URL group isn’t selected under Activities in the active policy rule.
• All web traffic or another earlier rule matches first.
• The policy rule is turned off.
• The web policy isn’t selected in the firewall rule that actually matches.
• The actual request uses an undocumented redirect, login, API, or CDN host.
• An existing browser or QUIC connection wasn’t re-established.

TLS exclusion doesn’t apply

• The URL group isn’t selected under Categories and websites in the expected rule.
• The Don't decrypt rule is below a Decrypt rule that already matches.
• Source, User, Zone, Service, or another rule criterion doesn’t match.
• The connection doesn’t send usable SNI.
• The actual TLS host differs from the URL visible in the browser.
• The existing TLS session remained in use after the change.

URL group applies too broadly

• A root domain was added instead of the hosts that are actually required.
• An entry includes additional subdomains in the TLS match.
• The group is used by multiple policies or TLS rules.
• An allow rule is positioned too high or applies to too many users.
• The Local TLS exclusion list has a broader effect than a custom source-scoped rule.

Don’t add another domain at this point. First check all uses of the group, the actual rule order, and the negative test.

Operate changes and rollback safely

Before every change to a production URL group, record:

• the previous domain list
• referencing web policies and SSL/TLS inspection rules
• owner and business reason
• affected users, sources, and services
• positive and negative test cases
• review or expiry date

Don’t silently expand a shared group for a single incident. If a web allowlist and a TLS exclusion have different owners or lifecycles, separate URL groups are cleaner even if some domains are identical.

For rollback, first restore the consuming rule or policy state, or remove only the newly added domain. Delete the entire group only after no other policy or rule depends on it. Then recheck new connections for the positive and negative hosts and review the logs again.

Operational checklist

• Confirmed that a URL group is the right tool.
• Added only valid domains, without protocols, paths, wildcards, or regex.
• Deliberately limited the root-domain and subdomain effect.
• Accounted for OR logic between multiple domains.
• Documented group name, owner, purpose, and review date.
• Clearly identified the consuming web policy or SSL/TLS inspection rule.
• Checked rule status, position, source scope, and logging.
• Selected the web policy in the correct firewall rule.
• For a TLS exclusion, confirmed SNI and the Don't decrypt rule.
• Completed positive and negative tests with new connections.
• Recorded references and previous state for rollback.

Frequently asked questions