Check Sophos Firewall outbound services and ports

Sophos Firewall establishes its own connections to Sophos and some external platform services. It uses them to download firmware and patterns, synchronize licenses, connect RED devices, send reports to Sophos Fusion (formerly Sophos Central), or open support access. If another router, proxy, or egress filter sits in front of the firewall, individual functions can fail even though normal client traffic continues to work.

The key distinction is that this is system traffic generated by the firewall itself. An additional broad LAN-to-WAN rule on Sophos Firewall doesn’t fix an upstream filter. A targeted outbound rule is required on the upstream system that is actually blocking the connection.

⚠️ Controlled Avanet working baseline: The following overview is the internal snapshot dated September 4, 2026 for SFOS 22. It is the starting point for planning and acceptance; destination names may change later. Fixed IP addresses from a single DNS lookup aren’t a permanent substitute for FQDNs and wildcards. The accountable firewall owner follows the reconciliation process below before changing the snapshot.

Quick check when a Sophos service isn’t working

1. Record the affected function, error time, and current SFOS build.
2. Check whether the firewall resolves the destination from the snapshot through DNS and whether system time and NTP synchronization are correct.
3. On the upstream router or egress filter, look for a block involving the firewall’s WAN address, the destination FQDN, and the required port.
4. Allow only the missing function group, not *.sophos.com, Any, and all ports across the board.
5. Trigger exactly one new test and compare Packet Capture, the upstream log, and the matching SFOS service log by timestamp.

Successful DNS resolution only proves that a destination name can be resolved. A successful TCP handshake doesn’t yet prove that licensing, an update, an upload, or RED provisioning works end to end. Test the actual function again after changing the network rule.

Destinations and ports required by SFOS 22

The table is the approved snapshot for initial planning. Select only function groups that are active on the specific firewall or scheduled for rollout. For regional Sophos Fusion services, allow only the region actually in use. An organization in the Frankfurt region, for example, doesn’t automatically need S3 destinations in Oregon, Mumbai, Sydney, and Tokyo.

utm.cloud.sophos.com/api/utm is a URL containing a path, not an FQDN. If the upstream product accepts only an FQDN as a destination, enter only the host utm.cloud.sophos.com; /api/utm doesn’t belong in an FQDN object. The snapshot contains specific upe.p.hmr.sophos.com hosts for Heartbeat and Sophos Fusion, not an allow rule for the entire wildcard domain. These names can change as the platform is operated and are updated only through the controlled reconciliation process. Likewise, pool.ntp.org applies only when the default NTP destination is used; if you configured another NTP server, allow that destination instead.

Select regional destinations for reporting and backups

First confirm the region actually used by the respective service in your Sophos Fusion environment. The organization’s physical location alone does not determine it. If the mapping is unclear, identify the report-upload or backup destination with Packet Capture and the upstream log, and clarify it before allowing access. This list is a catalogue, not a combined allowlist: select only the required destinations for the region and function in use. CFR sends reports and logs; backup stores and restores the firewall configuration.

• United States (Oregon) — us-west-2
  • CFR: tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Backup: us-west-2-firewall-backup.s3.us-west-2.amazonaws.com
• Europe (Frankfurt) — eu-central-1
  • CFR: tf-presigned-url-eu-central-1-prod-firewall-bucket.s3.eu-central-1.amazonaws.com
  • Backup: eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europe (Ireland) — eu-west-1
  • CFR: tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Backup: eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• US East (Ohio) — us-east-2
  • CFR: tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Backup: us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Asia Pacific (Mumbai) — ap-south-1
  • CFR: tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Backup: ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Asia Pacific (Tokyo) — ap-northeast-1
  • CFR: tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Backup: ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Canada (Central) — ca-central-1
  • CFR: tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Backup: ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Asia Pacific (Sydney) — ap-southeast-2
  • CFR: tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Backup: ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• United Arab Emirates (Dubai) — me-central-1
  • CFR: tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Backup: *.s3.me-central-1.amazonaws.com — the documented exception, not a basis for inventing a single backup host.

For the first eight regions, TCP 443 is the port for these service groups. Source limitation for Dubai: Both frozen service tables contain nine regional rows, but the shared port and purpose cells span only eight rows (rowspan=8); the Dubai cells are empty. The overview above assigns TCP 443 at service-group level, not as an explicitly populated UAE port value. The Dubai destinations are documented, but their regional port remains ambiguous in these tables. Clarify it through controlled reconciliation before allowing UAE access; no missing cell value is supplied here and no tested product behavior is claimed.

Build the egress allowlist safely

Create the rule on the device that actually filters outbound system traffic. This can be an upstream firewall, provider router, or cloud network firewall. Use only Sophos Firewall’s WAN address as the source, exactly as the filtering device sees it before or after any translation. Use the required FQDNs as destinations and only the documented TCP or UDP ports as services.

Handle wildcards and dynamic IP addresses correctly

Many Sophos services use CDNs, cloud platforms, or regionally distributed hosts. The IP addresses behind an FQDN can change. A one-time nslookup followed by fixed IP entries and an unchanged allowlist for years is therefore unreliable.

If the upstream filter supports FQDN- or URL-based rules, maintain the names from the approved snapshot there. If the device can only filter IP addresses, establish a documented process for regular resolution and updates. Broadly allowing all AWS or Sophos networks isn’t an equivalent substitute and unnecessarily increases the permitted attack surface.

Be especially careful with *.sophos.com: in the snapshot, this broad wildcard belongs only to Central Firewall Management. Don’t extend it to other functions or additional ports. RED, updates, sandbox, licensing, and support access have narrower destination patterns.

Don’t create an inbound WAN rule

These connections start on the firewall and go outward. Don’t create an inbound DNAT or WAN-to-Local rule for them. Likewise, don’t broadly exempt TLS inspection, IPS, or web filtering on suspicion. First check DNS, the route, the upstream block, and the specific service.

Support access is particularly easy to misunderstand: the firewall connects outbound over TCP 22 to *.apu.sophos.com. The safe workflow for enabling and time-limiting it is in Configure Sophos Firewall Support Access.

Isolate errors systematically

Check DNS, route, and port separately

Under Diagnostics > Tools > Name lookup, first resolve a destination from the snapshot without changing the configuration. Lookup using all configured servers shows whether the configured resolvers return different answers or take unusually long. Alternatively, use the familiar Device Console query:

dnslookup host xg-up2date-firmwares.sophosupd.com

Then use Diagnostics > Packet capture to see whether the firewall starts a connection to the resolved address, which WAN interface it uses, and whether responses return. Limit the Display filter to the specific destination IP and port. The Generated status identifies packets created by the firewall itself. In parallel, search the upstream system for the same time window, source, and destination. Turn off the capture after the test; its buffer is limited and it isn’t a substitute for permanent logging.

Interpret the result layer by layer:

• No DNS response: Check the DNS server, route to the resolver, and system time.
• SYN leaves the firewall but no response returns: Check the upstream rule, provider path, NAT, and return path.
• TCP or UDP works but the function still fails: Check the matching service log and product status; network connectivity alone isn’t complete functional proof.
• Only one HA node shows the error: Check logs and capture on the node that processed the connection at the time of the error.

Use the matching SFOS service log

For updates, u2d.log and up2date_av.log are good starting points; use licensing.log for licensing, red.log for RED, sandboxd.log for sandbox, and for Sophos Fusion, among others, centralmanagement.log, sophos-central.log, and the fwcm-*.log files. For NTP, use ntpclient.log. The full mapping and safe export process are in Find and interpret Sophos Firewall service logs.

In HA, service logs are stored on the node that processed the connection. A successful test on the current primary doesn’t prove retrospectively that the other node had the same connection at the time of the error. Record the time, node, destination name, resolved IP, and port together.

Validate and operate the change

After adding an egress rule, don’t only repeat the port test. The actual function must show visible success: a pattern shows a new status, the license synchronizes, RED connects, Sophos Fusion receives the task, a report appears, or Support Access shows an active session.

Keep logging enabled on the upstream rule and review it after a few days. Remove unused regions and temporarily broad test rules.

The firewall owner reviews the snapshot at least quarterly and before firmware upgrades, when enabling a new Sophos function, after changing regions, after a relevant vendor notice, and during unresolved connectivity incidents. At that concrete reconciliation step, open the changing Default services page and record the review date, SFOS build, reviewer, and diff against the internal snapshot.

Map every added, changed, or removed entry to an actively used function, region, and port. Apply additions one function group at a time in a maintenance window, then validate them with DNS, Packet Capture, the upstream log, and the functional test. Don’t delete a destination merely because the diff removes it: first check rule-log usage, then disable the old object and monitor it for a defined observation period. If validation fails, revert the change and keep the previous snapshot approved. Only a successful test produces a new dated snapshot.

Roll back unexpected side effects

Export or otherwise save the existing upstream rule base before making the change. If unexpected connections or other side effects appear afterward, disable only the newly created rule or restore its last documented destination and port scope. Then retest both the originally affected function and an independent normal internet connection. This isolates whether the allowlist caused the side effect without changing unrelated rules at the same time.

Success criterion: DNS resolution, outbound connection establishment, the matching upstream allowlist, and the functional test all succeed together. If one layer is missing, the problem hasn’t been cleanly resolved.

Frequently asked questions