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 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.
⚠️ The destination names are a changing vendor list. The following overview reflects the public SFOS 22 documentation as of August 21, 2026. Before creating a production allowlist, check the current Sophos Default services page again. Fixed IP addresses from a single DNS lookup aren’t a permanent substitute for the documented FQDNs and wildcards.
Quick check when a Sophos service isn’t working
- Record the affected function, error time, and current SFOS build.
- Check whether the firewall resolves the documented destination name through DNS and whether system time and NTP synchronization are correct.
- On the upstream router or egress filter, look for a block involving the firewall’s WAN address, the destination FQDN, and the required port.
- Allow only the missing function group, not
*.sophos.com,Any, and all ports across the board. - 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 summarizes the most important groups. For regional Sophos Central services, allow only the region actually in use. An organization in the Frankfurt region, for example, doesn’t automatically need every S3 destination in Oregon, Mumbai, Sydney, and Tokyo.
| Function | Documented destinations | Ports | Typical symptom |
|---|---|---|---|
| Web categorization and IP reputation | 4.sophosxl.net | TCP 443 | Categories or reputation aren’t evaluated with current data. |
| Firmware, pattern, and client updates | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware or patterns remain stuck during checking or download. |
| Additional antivirus scanner for small appliances | oem.avdl.ctmail.com | TCP 80 | Additional antivirus updates fail. |
| Licensing | *.soa.sophos.com | TCP 443 | Activation or license synchronization fails. |
| RED provisioning | *.astaro.com | TCP 3400, UDP 3410 | The RED device doesn’t register or establish a tunnel. |
| Security Heartbeat and Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, the regional *.upe.p.hmr.sophos.com hosts documented by Sophos, and *.sophos.com for Central Firewall Management | TCP 80, 443; Central Firewall Management additionally uses TCP 22 | Registration, Heartbeat, Synchronized Application Control, or Central management remains offline. |
| Central Firewall Reporting | regional tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com host | TCP 443 | Logs and reports don’t appear in Central. |
| Central Firewall Backup | regional <region>-firewall-backup.s3.<region>.amazonaws.com host; for UAE, Sophos documents *.s3.me-central-1.amazonaws.com | TCP 443 | Central backup or restore can’t reach storage. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Files aren’t sent to the sandbox or results are missing. |
| Support Access | *.apu.sophos.com | TCP 22 | The outbound support tunnel can’t be established. |
| NTP | pool.ntp.org | UDP 123 | Time drifts; certificates, MFA, Kerberos, or logs appear inconsistent. |
| SAR, telemetry, and DDNS check | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; DDNS check uses TCP 80 | Security Audit Report, telemetry, or public-IP detection doesn’t work. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | The ZTNA data path or connection to Sophos Central fails. |
Sophos also lists individual concrete Heartbeat and Central hosts. These values can shift with region, platform operation, or vendor changes. The table is therefore not translated into a static IP list.
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. On that system, use only the public or translated address of Sophos Firewall as the source. 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 documented by Sophos 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: Sophos explicitly names this broad wildcard for Central Firewall Management. Don’t automatically 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
In the Device Console, first perform a read-only check of a documented destination name:
dnslookup host xg-up2date-firmwares.sophosupd.com
Then use a narrow 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 capture to the specific destination IP and port. In parallel, search the upstream system for the same time window, source, and destination.
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 Central, 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, Central 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, old destination names, and temporarily broad test rules. Before firmware upgrades or when enabling new Sophos functions, compare the current Default services list again so the missing dependency isn’t first discovered during the maintenance window.
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.