Understand and safely configure Sophos Firewall rules

A Sophos Firewall rule determines which traffic between zones, networks, users and services is allowed or blocked. The goal is not to enable as many options as possible, but to use suitable match criteria, the correct order, appropriate security features and a reproducible test.

The menu path is:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Before selecting Add firewall rule, explicitly select IPv4 or IPv6 on the rules page. The following examples do not provide a combined allowance for both protocol families.

This article explains the rule form from top to bottom and uses the example LAN_to_WAN_Clients throughout. It covers specialist topics such as NAT, TLS Inspection and IPS only as far as they are relevant to the firewall rule; detailed guides are linked at the appropriate point.

Plan before creating the rule

Identify the correct control point

Normal firewall rules control forwarded traffic that passes through the firewall. Other tasks are configured elsewhere:

• Local firewall services: WebAdmin, User Portal, VPN Portal, SSH, DNS and SNMP are controlled through Administration > Device access, Local Service ACL and the respective service configuration. See Device Access and Local Service ACL.
• System-generated traffic: Connections initiated by the firewall itself do not require a normal firewall rule. The relevant controls are the service configuration, routing, WAN Link Manager and, where applicable, SD-WAN for system traffic.
• Address and port translation: NAT translates traffic but does not allow it. The firewall rule and NAT rule must work together.
• Routing and return path: A matching firewall rule does not prove that routing, SD-WAN, VPN or the return path is correct.
• Web logic: Web categories, URL groups and actions are defined in the Web Policy. The firewall rule applies that policy.
• HTTPS decryption: An SSL/TLS inspection rule decrypts the traffic. Scan HTTP and decrypted HTTPS only scans HTTPS that has already been decrypted.
• User identity: AD SSO, STAS, Captive Portal, Entra ID SSO or RADIUS must first map the user reliably to the traffic. Devices without a login can be configured as Clientless Users when they have a fixed, unambiguous IP; this assignment isn’t authentication.

Management access through the firewall to servers, switches or hypervisors belongs in normal firewall rules. Access to the firewall itself belongs under Device Access.

Rule order, IPv4 and IPv6

Sophos Firewall evaluates rules from top to bottom. Once all configured positive match criteria of a rule are met and no configured Exclusion causes it to be skipped, subsequent rules are not evaluated. A general LAN_to_WAN_Any rule placed above LAN_to_WAN_Restricted therefore makes the specific rule ineffective for traffic handled by the general rule.

A rule can match on positive criteria including Source zone, Source network, schedule, Destination zone, Destination network, Service and user. All configured positive match criteria must match the connection. If all configured criteria of an Exclusion match, SFOS skips this rule and evaluates subsequent rules.

Automatically generated MTA, IPsec or Hotspot rules can appear at the top of the list. The Server Access Assistant also creates a firewall rule together with DNAT, reflexive SNAT and loopback. The order should therefore be checked again after using wizards, performing migrations or changing VPN settings. For a Sophos Firewall hotspot, this check is an explicit part of the setup process; the guide to DNAT for published servers explains the Server Access Assistant.

⚠️ Before creating the logged Drop rule: Do not assume it preserves existing HTTP/HTTPS blocking: the documentation conflicts on Drop, authentication, Web Exceptions, and block pages. For any web traffic, written Sophos clarification for the exact SFOS version, build, and processing path or explicitly authorized, isolated verification is required before production rollout. Follow the verification, rollback, and escalation guidance under Action and logging below.

If SFOS finds no matching rule, the implicit drop-all rule with Firewall Rule ID #0 applies at the bottom. It shows no Usage Count and does not generate a normal firewall traffic log entry. To make these drops visible in Log Viewer, Central Reporting or syslog, create a narrowly scoped Drop rule with Log firewall traffic enabled at the end of the rule base. Select the Source and Destination zones actually required individually instead of zone Any; otherwise, the rule can also match internal traffic to local services. See Analyzing dropped packets on Sophos Firewall for details.

For an approved logging rule, select Add firewall rule > New firewall rule in the correct IPv4/IPv6 ruleset, then specify a unique name, Rule position Bottom, Action Drop, and Log firewall traffic. Select Source zones and Destination zones individually; set Source networks and devices, Destination networks, and Services to the approved scope, then select Save. Record the existing order and logging configuration beforehand. New permitted and deliberately non-permitted test connections must match the expected Rule IDs without affecting local services. If results differ, disable the new rule and restore the previous state. The clarification of web traffic under Action and logging remains a prerequisite, not a test completed by these steps.

IPv4 and IPv6 rules are managed separately. A working IPv4 rule does not automatically protect the same service over IPv6. In dual-stack environments, both rule sets must be deliberately planned and tested.

Separate the rule base clearly

Before creating a rule, define its Source, Destination, Services, Owner and test case. Traffic with different risks should not be combined in one blanket rule:

• Client internet access: Client networks to the WAN zone, with a suitable Web Policy, Application Control, IPS and logging.
• Server internet access: Only the required update, backup or cloud destinations, generally without user matching.
• Guest Wi-Fi: Guest zone to the internet, without internal destinations and, if required, with a bandwidth limit.
• Management: Defined admin networks to servers and infrastructure, separate from normal client traffic.
• Remote Access VPN: VPN zone to the specific internal destinations and services required.
• Site-to-site: Local and remote networks with suitable routing, NAT and return path.
• Published systems: WAN to a DMZ or server zone with a tightly restricted source, DNAT or WAF, IPS, logging and a current patch level.
• Temporary access: A separate rule with a ticket, Owner, expiry date and planned removal.

For help with the network structure, see Configure Sophos Firewall zones and interfaces.

⚠️ Any can be useful for a short test, but is rarely a good final configuration. Afterwards, restrict the rule to the sources, destinations and Services actually required, or remove it again.

Practical example: LAN_to_WAN_Clients

In this example, clients from a defined LAN are allowed to access the internet. Servers, guests, VoIP and management use separate rules.

• Rule name: LAN_to_WAN_Clients
• Description: Internet access for the client network. Web filtering, App Control and IPS enabled. Owner IT, review 2026-12-01.
• Rule position: Bottom, then place it below specific block and exception rules
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: enabled
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS and only the basic services that clients actually access directly on the internet
• Web policy: Default Workplace Policy
• Block QUIC protocol: enabled
• IPS: suitable client policy
• App control: suitable client application policy
• Shape traffic: only for a specific bandwidth objective
• DSCP marking: only if downstream devices process the marking

Add DNS and NTP to this LAN-to-WAN rule only if clients communicate directly with external resolvers or time servers. If they use the firewall as their DNS or time service, this is local traffic.

Acceptance testing must use a defined client, a specific destination, the expected Firewall Rule ID, the expected NAT Rule ID and the Log Viewer. This confirms not only that the application works, but also that the intended rules process the connection.

Configure the firewall rule

Header

Rule status, Rule name and Description

Rule status is enabled by default for a new rule. Rules prepared in advance can remain disabled until the maintenance window. Permanently disabled test or migration rules should be reviewed regularly.

The name should identify the Source, Destination and purpose, for example:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

The Description records the purpose, Owner, ticket, restrictions and, where applicable, the expiry date. Names such as Rule1, Allow or Internet provide little help during later operations. See How to document Sophos Firewall rules clearly for the Avanet approach.

Rule position and Rule group

When creating a rule, Rule position in SFOS 22 offers Top or Bottom. After saving, the rule can be moved in the rule table or positioned precisely with Move To. Use Top only when a specific rule must deliberately take precedence over existing rules.

Rule group improves readability but does not change the matching logic. None is the default. With Automatic, SFOS assigns the rule to an existing group based on the first matching rule type and the Source and Destination zones. The firewall still evaluates each individual rule from top to bottom. A group cannot remain empty. The SFOS 22 help describes detaching an individual rule with Detach before moving it out of a group; alternatively, move the entire group. Deleting the last rule in a group also deletes the group.

In the SFOS-22 table, show or hide filters with Enable filter / Disable filter, select a field and value under Add filter, and reset them with Reset filter. When filters are applied, individual rules can be selected, but rule groups cannot. Rules or groups can be toggled with Enable / Disable; a mixed selection of enabled and disabled rules prevents this action. More options provides editing, cloning, adding, deleting, Detach, Reset data transfer count, and group actions. For a rule that is not yet grouped, select Add to group > New group, specify the group name, and set the rule type and source/destination zones; alternatively, select an existing group. Groups can be edited or deleted. The # column shows the position; use the Rule handle to drag a rule or group, or enter the target position in Move To and confirm with Enter. Before any move, record the previous state, then check new test flows against the expected Rule ID. A clone is not an automatically safe allowance: check its criteria, status, and position before enabling it.

The SFOS 23 help describes a different workflow: for a filtered search, click the search box, select a suggested criterion, and complete the search using the additional suggestions. Press Enter to filter the rule table. To search by rule name, type it directly in the search box and press Enter; remove individual filters with x. Use Show/Hide columns to select the visible columns, change their order by clicking and dragging, and freeze up to three columns so they are always shown first. Enable or disable rules through Status, or in bulk with Turn on / Turn off; a mixed selection of enabled and disabled rules prevents that bulk action. Disabled rules appear faded with a strikethrough name. Dragging a rule at least one position outside its group removes its membership; dragging it between two rules in another group adds it to that group. The View menu offers Clone rule above/below, Add rule above/below, Move To, and Edit group. Hover over Features for details: distinguish user/network type and rule action from policy actions and heartbeat thresholds. In the SFOS 23 table, User means Match known users is selected and Network means it is not; policy icons distinguish None, Accept, Drop, and Reject, while heartbeat icons distinguish Green, Yellow, and No restriction. This presentation does not prove a traffic-engine change.

The icons are configuration indicators, not test results: In SFOS 23, check under Features; in SFOS 22, check under Feature and service to see whether Web/FTP/Mail scanning and Traffic Logging are enabled or disabled, whether Proxy-Filtering is selected, and whether policies are assigned. An enabled proxy applies to 80/443; other HTTP/TLS ports remain on DPI. Web policy, App control, IPS and Shape traffic can each show None; the IPS and shaping icons indicate an assigned policy, while the web and app icons also indicate its action. For Heartbeat, distinguish the minimum status of Green or Yellow from No restriction and check the separate state of Block clients with no heartbeat. No restriction alone does not prove that this additional toggle is disabled. Enabled Exclusions must also be taken into account when checking for a match.

For new installations, the SFOS-22/23 help pages list a LAN-to-WAN rule and the MTA rule with Linked NAT that is automatically created when MTA mode is enabled; MTA is enabled by default in those versions. This does not replace checking your own installation. The implicit rule #0 cannot be edited, deleted, or moved and is excluded from filters. A Factory Reset is a separate case: both help pages describe the removal of all firewall rules, followed by only the rule Auto added firewall policy for MTA. This must not be taken to mean that a LAN-to-WAN allowance is automatically restored. A reset is not a method for cleaning up individual rules; a backup, independent admin access, and a recovery plan belong in the separate procedure Reset Sophos Firewall.

The startup overview Access rules and policies for SFOS 22/23 also describes rule groups created by default with a firewall rule to drop traffic towards WAN, DMZ and internal zones (LAN, Wi-Fi, VPN and DMZ). This refers to visible, grouped firewall rules, not the implicit rule #0. However, this overview and the detailed installation and reset defaults mentioned above do not establish a uniform initial set of rules for every installation. Therefore, on your specific SFOS version, build and installation, check under Rules and policies > Firewall rules which rules and groups are actually present and enabled, which source/destination zones and other match criteria they use, and where they are positioned. The presence of a group alone does not prove isolation: an earlier matching allowance may already permit the traffic. Check the intended zone separation using new, explicitly authorized test connections and the expected Rule IDs; for web traffic, the documentation conflict concerning Drop described above still applies. Do not infer guaranteed group names, creation conditions or a general blocking effect from the startup overview.

Action and logging

Action determines how matching traffic is handled:

• Accept: Allows the connection.
• Drop: Is documented as discarding non-web traffic without notification. HTTP/HTTPS behavior is not universally assured because of the documentation conflict described below.
• Reject: drops the connection and sends a TCP reset for TCP; for UDP and ICMP, the help explicitly specifies an ICMP port unreachable message to the source.
• Protect with web server protection: Creates a WAF rule. This option is available only for IPv4 and requires Webserver Protection. The configuration is covered in Sophos Firewall WAF.

Selecting Protect with web server protection displays Preconfigured template. None means configuring the WAF details yourself. The documented templates are Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2, and Microsoft Sharepoint 2010 and 2013. These historical names do not indicate current support or security for the respective server version. Before use, the template must match the service actually in operation; subsequent WAF configuration and acceptance validation remain required.

⚠️ Unresolved documentation conflict for web traffic: The SFOS 22/23 rule-form help describes Drop accepting and examining HTTP/HTTPS, authenticating unknown users when Use web authentication for unknown users is enabled, permitting requests allowed by a matching Web Exception, and displaying an HTML block page for other requests. The dropped-traffic logging guide instead describes silent discarding generally and ties the web block page to that authentication option. Resolve these contradictory descriptions for the installed SFOS build before relying on a specific web-blocking response. They do not establish silent discarding of all web connections, a block page dependent solely on the authentication option, or blanket blocking of all services.

If guaranteed blocking or a specific response is required, obtain written Sophos clarification for the exact SFOS version, build, and processing path, or verify in an explicitly authorized, isolated test environment. Test non-web traffic, HTTP, and HTTPS separately; for web traffic also cover known/unknown users, authentication on/off, and a matching Web Exception present/absent. Use only defined test clients, destinations, and services, enable Log firewall traffic, and generate fresh connections. Record the build, rule position, Firewall Rule ID, user, Action, web/TLS settings, and log, Packet Capture, and browser results. A timeout, block page, or Policy Tester alone does not prove the intended blocking. If access is unexpected or the result is unclear, do not roll out to production; revert test changes and escalate the evidence to Sophos Support. Reject provides the protocol response described above; it is not recommended here as an unverified substitute for web control.

Log firewall traffic should be enabled for important rules. Logs are stored locally on the firewall by default; check local log settings and Syslog destinations under System services > Log settings. Sending logs to the cloud service additionally requires enabling Sophos Central services on the Sophos Central page. The SFOS 22 help calls the destination Sophos Fusion (formerly Sophos Central), while the SFOS 23 help calls it Sophos Central; the name does not replace this separate prerequisite. Without a Destroy event, a session may end without a final session log, for example after an abrupt line failure.

For longer retention, use Central Firewall Reporting or a Syslog/SIEM server. Logging supports not only troubleshooting but also reviews: Which sources match the rule, which destinations are used, and is the access still appropriate?

The same checkbox is the data source for NetFlow v5 on Sophos Firewall: without Log firewall traffic, NetFlow does not export this rule’s connections.

Source, Destination and Services

The Source section defines where the traffic originates:

• Source zones: For example LAN, VPN, DMZ, Guest or WAN.
• Source networks and devices: Individual hosts, networks, IP ranges, groups, FQDN hosts or country objects.
• During scheduled time: All the time, business hours or a maintenance window.

The zone alone is usually too broad. The client example therefore combines LAN with net_LAN_Clients. For scheduled rules, the firewall time, time zone and schedule must all match.

Set up Sophos Firewall schedules for rules and policies shows how to create, assign, and test recurring and one-time time windows at their switching boundaries.

Under Destination and services, configure:

• Destination zones: For example WAN, DMZ, LAN or VPN.
• Destination networks: Any, a host, network, group, country object or FQDN host.
• Services: Protocol and port definitions such as HTTP, HTTPS, DNS, NTP or a custom service.

For guidance on creating IP hosts, networks, ranges, lists, services, and groups and checking them before changes, see Use Sophos Firewall hosts and services correctly.

Any can be acceptable for a general client internet rule. Server, management and VPN rules should use much more restrictive destinations and Services. For dynamic cloud destinations, FQDN hosts and wildcard FQDNs may help.

MAC-based rule: clarify the limitations before attempting to block traffic

A MAC host can provide additional device mapping for directly visible clients, for example when their DHCP address changes. However, a MAC address is not a strong identity: it can be changed or spoofed. The source guide describes MAC filtering as more secure and shows Block_MAC for IPv4 from LAN to WAN with Drop, logging, position Top, group None, schedule All the time, and destination and Services Any. This combination is not a promise of a complete internet block here: the HTTP/HTTPS/Web Exception conflict documented above remains unresolved.

The guide limits MAC-based internet filtering to devices directly connected to the firewall. If a router, another firewall, or a Layer-3 switch is in between, the original client MAC is not automatically visible. The guide mentions MAC binding for local users in this context; without clarifying identity mapping and the actual packet path, this is not a guarantee of routed MAC filtering or a substitute for authentication. Before attempting a test, the MAC visible at the firewall ingress must actually belong to the test client.

For an explicitly approved, isolated pilot, only a new non-web IPv4 TCP flow to a controlled WAN test server is blocked:

1. Compare the MAC on the test client with the MAC at the firewall ingress. Under Hosts and services > MAC host > Add, enter the name MAC_Host, Type MAC address, and the MAC actually verified, then select Save. 37:97:0E:AB:56:46 is the guide’s unchanged example value and must not be copied blindly.
2. Under Rules and policies > Firewall rules, select IPv4 and Add firewall rule > New firewall rule. For Block_MAC, set Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time, and Destination zones WAN. Limit the destination to the controlled test server and Services to the approved non-web TCP test service instead of adopting the original Any values. Record the order and configuration state beforehand, then select Save.
3. Generate a fresh test flow, for example an approved TCP iPerf3 flow, and check Block_MAC with its Rule ID in the Log Viewer as well as the dropped packet flow. Another control client that is not blocked must still be able to reach the test destination. A timeout alone is not sufficient.
4. After the pilot, disable or remove the test rule, restore the previous order, and verify a new permitted test flow from the original client using the expected Rule ID. Remove the test MAC host only if no other configuration requires it.

If there is no match, check MAC visibility, IPv4 selection, Source, Schedule, and order; do not expand the rule to all devices. If unexpected access occurs or the control client fails, revert the test and investigate the evidence with the exact version and build. HTTP, HTTPS, Web Exceptions, other zones/destinations/services, and IPv6 are not covered by this pilot. A complete MAC-based internet block must not be promised until these cases have been separately clarified and tested.

Users, Exclusions and Linked NAT

Match known users

With Match known users, users or groups become match criteria. Depending on the configuration, further fields then become available:

• Use web authentication for unknown users: Redirects unknown web users to AD SSO or Captive Portal. Authentication and access from the affected zone must already be configured. Set up and test Sophos Firewall Captive Portal shows how authentication, Device Access, the DNS prerequisite, and the user rule work together.
• Users or groups: Restricts the rule to selected identities.
• Exclude this user activity from data accounting: Excludes this user traffic from individual data usage accounting.

Unknown here means logged in to the endpoint but not yet authenticated to the firewall. Configure AD SSO with Kerberos/NTLM or Captive Portal under Authentication > Web authentication, and access from the required zones under Administration > Device access. By default, matching traffic counts toward the individual’s data usage. Exclude this user activity from data accounting excludes it from that accounting, for example when no data limit should apply to these users; it is neither an additional allowance nor authentication.

A user rule works only with reliable user mapping. A broad fallback rule below it must not allow the same traffic without user matching. During acceptance testing, the user, group and Rule ID shown in the Log Viewer must be consistent with the test case.

Add exclusion

Add exclusion excludes traffic from this rule. SFOS skips the rule only when all configured exclusion criteria match, and then evaluates the next rule.

Available criteria are Source zones, Source networks and devices, Destination zones, Destination networks and Services.

A useful exclusion might be an update server that is excluded from a general client rule and handled by a separate rule above it with different security features. If exclusions become numerous or difficult to understand, a separate specific rule is usually clearer.

The documented country example allows HTTPS from African countries to 172.16.16.0 and uses an Exclusion with only Source zone WAN and a selected country object as Source network. This rule is skipped only when both criteria match; the traffic may be allowed by a later rule or reach #0. The address is an unchanged example, not a complete network definition with a prefix. For your own test, select a target object that actually exists, document the rule order, and check an excluded and a non-excluded test flow using the Rule IDs. An Exclusion is not a global block.

Create linked NAT rule

Unlinking a Linked NAT Rule in the NAT table makes it editable and evaluated independently of the original firewall rule using its own criteria. Document its scope and NAT order before unlinking, then verify a fresh test flow; this is not simply a rename.

A Linked NAT Rule is a Source NAT rule that applies only to traffic handled by the linked firewall rule. The NAT rule primarily defines the translated Source and interface-specific Source translation.

Many installations already have a Default SNAT rule with MASQ. However, this depends on the setup and migration status and must be checked in the specific NAT rule table. Before adding a Linked NAT Rule, check whether an existing rule already handles the traffic correctly. If an independent NAT rule higher in the list matches, it takes precedence over the Linked NAT Rule.

For DNAT, SFOS first determines the translated destination and then uses its zone for firewall rule matching. A port forward to a server in the DMZ therefore typically requires Destination zone DMZ in the firewall rule, even though the client connects to the public WAN address.

If the NAT Rule ID is unexpected, also check the order under Rules and policies > NAT rules. Create a new connection after NAT changes because existing sessions are not evaluated again. NAT does not allow traffic by itself: The firewall rule decides whether to Accept or Drop, while NAT translates addresses or ports. See Understanding NAT on Sophos Firewall for details.

For outbound client traffic, you can create the firewall allowance and Source NAT together:

1. Under Rules and policies > Firewall rules, select the protocol family and open Add firewall rule > New firewall rule. Specify the name and position; in the example, use Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN, and Destination networks Any. Network_LAN must contain your own verified client network. The guide shows Services Any; in production, select only approved services instead.
2. Select Create linked NAT rule, specify the NAT name and position, and set Translated source (SNAT) to MASQ. First save the Linked NAT Rule with Save, then save the firewall rule with Save.
3. Check the firewall rule in the firewall table and the linked SNAT rule in the NAT table using the Firewall Rule ID and name. The firewall rule is evaluated first, followed by Source NAT. With Linked NAT, only the translated source and outbound-interface-specific source translation can be changed; the other criteria, including users/groups, come from the firewall rule.

The source notation 10.145.16.10/24 is the guide’s unchanged example value, not a value to copy unchecked as a network address. MASQ uses the IP address of the outbound interface actually selected. Check the appropriate route, interface, and higher-positioned NAT rules beforehand. A new test flow must show the expected Firewall Rule ID, NAT Rule ID, and translated source. If the translation is incorrect, check the order and egress; if the test fails, revert the new firewall and Linked NAT configuration and restore the previous state, including the order, without changing other required NAT rules.

Select security features

Not every option is available with the Base License. Before rollout, check under Administration > Licensing:

• Normal firewall rules: Base License
• IPS and Security Heartbeat: Network Protection
• Web Security, Application Control and web malware protection: Web Protection
• Sandboxing and file analysis: Zero-Day Protection
• Email protection: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection and Xstream Protection include Web Protection. The Avanet Epic Protection bundle also includes Web Protection. See Compare Sophos Firewall license bundles for the complete overview.

Web Filtering

Web policy applies a Web Policy containing categories, URL groups, users and actions. Without a Web Policy, this field provides no category-based web control. Create and test the policy under Web Protection.

Apply web category-based traffic shaping uses the bandwidth settings from the web categories. This option is useful only if limits or guarantees are actually configured there.

Block QUIC protocol blocks outbound UDP on ports 80 and 443 for this rule. QUIC cannot be scanned like normal HTTP/HTTPS traffic and bypasses Web Filtering. SFOS enables the option by default when a Web Policy or malware scanning is selected. See Block QUIC and HTTP/3 for details.

Scan HTTP and decrypted HTTPS scans HTTP and already decrypted HTTPS for malware, but does not enable decryption. In DPI mode, this requires an appropriate SSL/TLS inspection rule under Rules and policies > SSL/TLS inspection rules; in web proxy mode, use Decrypt HTTPS during web proxy filtering. Before rollout, verify the processing path actually in use and ensure that clients trust the decryption CA.

Use Zero-day protection requires Scan HTTP and decrypted HTTPS and sends downloaded HTTP/HTTPS files for additional analysis for unknown or not yet disclosed threats. The feature requires Zero-Day Protection and may cause a delay depending on the file type and policy; it does not enable HTTPS decryption itself.

Scan FTP for malware is needed only if the rule allows FTP. Test the scan separately for legacy systems.

Use web proxy instead of DPI engine limits proxy filtering to the standard ports 80 and 443. The web proxy is required for features including SafeSearch, YouTube restrictions, Google Workspace domain restrictions, Pharming Protection, Web Cache and Parent Proxy. In DPI mode, SSL/TLS inspection rules apply to HTTP and TLS on all ports.

Configure an upstream proxy on Sophos Firewall explains the additional rule and NAT chain for a parent proxy. A proxy in WAN requires a different path from one in LAN or DMZ.

An explicitly configured Direct Web Proxy client, by contrast, uses the listener even without this option. Set up Direct Web Proxy with a PAC file explains the complete design with port, Device Access, PAC file, rule, and tests.

Decrypt HTTPS during web proxy filtering belongs to web proxy mode. In DPI mode, decryption is controlled by SSL/TLS inspection rules. Web Exceptions can bypass decryption, malware scanning, Zero-Day Protection and Policy Checks, and should therefore be narrowly scoped and reviewed regularly.

Even when Use web proxy instead of DPI engine is enabled, the DPI engine continues to filter HTTP and SSL/TLS on other ports; the switch applies to the proxy for 80/443, not to all traffic. The help describes web proxy filtering on a bridge without an IP address as a case where traffic is dropped, and it must not be enabled without verification. Decrypt HTTPS during web proxy filtering also decrypts in Direct Proxy mode explicitly configured on the client. In DPI mode, Web Policies, including Web Exceptions, apply only when a Web Policy is set, malware/content scanning is enabled, or ATP is enabled. These conditions must be distinguished from the URL-based micro-app detection explained under Application Control, IPS and Traffic Shaping.

Process only specific destinations through the Web Proxy

If SafeSearch, YouTube restrictions, or Google Workspace sign-ins are to be limited to specific domains while other traffic uses DPI decryption, create a separate, higher-positioned rule. First check the Web Protection license, appropriate global web settings, client trust in the decryption CA, and the intended Web Policy. FQDN groups define the destinations; they do not themselves configure the permitted account domains or filtering actions.

1. Under Rules and policies > Firewall rules, select IPv4 or IPv6, open Add firewall rule > New firewall rule, and set the name and position. Select Action Accept, the source zone actually required, and the approved client network. The source guide uses Any here; this broad source is not a required production setting.
2. Set Destination zones WAN, Destination networks with the predefined groups SafeSearch enforcement, YouTube restrictions enforcement, and Google app enforcement, and Services HTTP, HTTPS. Select only the groups required for the intended use case.
3. Enable Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine, and Decrypt HTTPS during web proxy filtering. The actual Web Policy must match the intended restriction. Enable Log firewall traffic for the pilot and save with Save.
4. Position the rule above the DPI rules. Use new connections to check the intended SafeSearch/YouTube/account restriction, Rule ID, and web/TLS logs; also test another destination that should still match the intended DPI rule and SSL/TLS inspection rule.

If the restriction is not applied, check the rule position, FQDN mapping, Web Policy, and QUIC; for certificate errors, check CA trust and the decryption configuration. If behavior is unexpected, disable the new proxy rule or restore the previous values and position, then recheck the original DPI path. Do not indiscriminately disable TLS protection or certificate validation.

Synchronized Security Heartbeat

Heartbeat rules require:

• a firewall registered with the same Sophos Fusion account and Security Heartbeat enabled;
• a managed Sophos Endpoint with a trial or full license;
• Network Protection on the firewall.

To detect missing heartbeats, select the affected zones under System > Sophos Fusion > Optional configurations > Missing heartbeat zones.

Minimum source HB permitted and Minimum destination HB permitted define a minimum health status. Destination Heartbeat is suitable only for internal destinations, not for the WAN zone.

For both thresholds, Green allows only Green; Yellow allows Green or Yellow; No restriction also allows Red and devices without a heartbeat. Check the separate no-heartbeat blocking options as well. The missing-heartbeat guide distinguishes a lost heartbeat from one never sent; Synchronized User ID covers sign-out after heartbeat loss or sleep/wake and validation of a fresh sign-in.

The options Block clients with no heartbeat and Block request to destination with no heartbeat address devices without a heartbeat. A device that has never sent a heartbeat remains allowed by default and is blocked only when both options are enabled. This must be tested deliberately with devices that do not run Sophos Endpoint.

A Web Exception that skips Policy checks can allow web requests despite Block clients with no heartbeat. See Analyze missing Security Heartbeat alerts for the practical verification process.

Application Control, IPS and Traffic Shaping

Identify and control applications (App control) applies an Application Filter Policy. Application Control requires Web Protection. For URL-based micro apps in encrypted traffic, such as file uploads and downloads within Dropbox or Gmail, a suitable decrypting SSL/TLS inspection rule is required. Filters, logs and false positives are explained in Configure Application Control.

Malware and content scanning uses the settings under Web > General settings. Selecting web proxy filtering first requires a web policy or Scan HTTP and decrypted HTTPS. An Application Filter Policy for URL-based micro apps still applies in the decrypting DPI path with Web policy None and both malware scanning and ATP turned off. This does not remove the separate activation conditions for Web Exceptions in DPI mode. The detailed guides cover proxy filtering on a bridge without an IP address and HTTPS decryption with Direct Web Proxy.

Apply application-based traffic shaping policy uses the bandwidth policy assigned to an application or category under Applications > Traffic shaping default. Application Objects, by contrast, are used for SD-WAN routes. A Rules policy selected through Shape traffic shapes all traffic handled by the firewall rule. The current help for the rule form does not describe the priority between an Application policy and a Rules policy. For a predictable design, use only one method per use case and test any required combination on the deployed SFOS build. When Match known users is enabled, however, the user’s Traffic Shaping Policy applies; if the user has no policy, the policy of their group applies.

Detect and prevent exploits (IPS) applies an IPS Policy. IPS requires Network Protection or a valid trial license and must be enabled globally under Intrusion prevention > IPS policies. Client, server, web server and VoIP traffic require different, tested policies. See Configure and test IPS for a safe rollout.

Shape traffic assigns a Traffic Shaping Policy to the entire rule, for example for VoIP, meetings, backups or guests. Guarantees and limits must match the available WAN bandwidth. See Configure Application Traffic Shaping for more information.

DSCP marking marks only outgoing IPv4 and IPv6 packets that match this rule. It overwrites a DSCP marking already present on incoming traffic. Reply packets and system-generated traffic are not marked by the firewall rule. Marking alone does not prioritize or classify anything; all participating switches, routers and WAN devices must process the selected DSCP values consistently.

A narrowly scoped QoS test uses a defined client, an approved test destination, and ICMP with AF31 = 26. After confirming the rule match, inspect the marking with Packet Capture at WAN egress and check the reply separately. CS0 = 0 is the reply in the documented example, not a guarantee about arbitrary peer markings. Do not create a broad Any permission for this test; remove the test rule afterwards. Test a Sophos Firewall rule explains the capture workflow.

The DSCP selection must match the QoS design of the entire path: EF describes Expedited Forwarding for low delay and low loss in real-time services; AF describes Assured Forwarding with dropping under congestion; CS provides compatibility with IP Precedence. These are class concepts, not a quality of service guaranteed by marking alone. The documented values are:

The original ICMP example uses 8.8.8.8, Source zone LAN, Destination zone WAN, source and destination Any, and AF31. For your own check, replace these with approved, specific client and destination objects; neither this public address nor a broad allowance is required. Record the previous DSCP value before the test, restore it after the test, and verify with new packets. If the expected prioritization does not occur, investigate the rule match, actual egress marking, and QoS handling by downstream devices separately.

NDR Active threat intelligence

Scan with NDR Active threat intelligence checks the traffic against curated NDR signatures. The action is fixed at Log threats: The feature detects and logs events but does not block the traffic.

Requirements are:

• Xstream Protection Bundle;
• global activation of NDR Active threat intelligence;
• enabled IPS logging;
• selection of the option in each relevant firewall rule.

XGS Appliances, virtual, software and common cloud deployments are supported, but XGS 87, 87w, 88 and 88w are not. XDR or MDR and forwarding to Sophos Fusion are optional for further analysis.

Scan email content

Under Scan email content, one can select IMAP, IMAPS, POP3, POP3S, SMTP and SMTPS. The protection requires Email Protection. If the standard ports are missing under Services, add them through Add ports.

Email traffic should not be hidden in a general client internet rule. A separate email rule makes the Source, Destination, protocols, logging and security features clearer.

For an existing SMTP server published through DNAT, Configure Mail Protection in legacy mode connects the inbound and outbound rules with NAT, scan policy, TLS, and the legacy proxy logs.

For mail retrieval, the checkbox alone isn’t sufficient: CA trust, global scan limits, an optional POP-IMAP policy, and the actual rule match must fit together. Scan and test POP3 and IMAP on Sophos Firewall provides the complete pilot and validation process.

Prepare firewall rules through the XML API

The XML objects FirewallRule and FirewallRuleGroup support traceable rule changes and group maintenance. They replace neither access planning nor acceptance testing with new test connections. Secure access, HTTP POST to APIController, explicit XML operations, TLS validation, secret storage, and evaluating XML status rather than HTTP success are explained in Secure XML API access. First, a harmless read query must succeed from the intended automation host using an account with narrowly scoped permissions.

Preserve the rule type, parent structure, and order

In the SFOS 22/23 reference, Name, Position, and PolicyType are required for Add/Edit. Name is a UTF-8 string of no more than 60 characters, with no commas. Under FirewallRule, setting PolicyType to Network selects the NetworkPolicy block, while setting it to User selects the UserPolicy block. Do not mix these branches or send both without verification. HTTPBased and HTTPBasedPolicy belong to WAF configuration, while authentication binding belongs to WAF authentication. WAF path actions are not a numeric translation of network actions.

IPFamily allows IPv4 or IPv6; the table lists IPv4 as the default. Status allows Enable or Disable, but lists ON as the default. For rules prepared in advance, deliberately set the status to Disable and check the stored protocol family rather than treating documented defaults as safe payload values. According to the parameter table, Position allows Bottom, Top, After, or Before; the example writes these values in lowercase. Therefore, confirm the capitalization and complete operation in API help for the installed build. After/Name and Before/Name identify the existing anchor rule; the reference restricts these tags to Set requests. Section distinguishes Central_TOP, Local, and Central_Bottom: clarify ownership and the management path before attempting a local write; do not bypass a central restriction by using a different section.

Keep source and destination separate in the selected policy block: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network, and Services/Service contain repeatable references. Schedule refers to an existing schedule. The tables limit network and service references to 60 characters; they do not document a combined maximum count across all criteria. The same parent elements can appear under Exclusions, where they mean exceptions to this rule, not additional allowances. Before writing, read the zones, hosts, services, and schedules that actually exist and check the intended match, including subsequent rules.

For UserPolicy, MatchIdentity, ShowCaptivePortal, and Identity/Member add user matching. Multiple user/group references of no more than 256 characters are documented for Member. Identity mapping and web authentication must work separately. DataAccounting is described only when identity matching is enabled and excludes user traffic from data accounting; it does not authenticate users. The example and table conflict here: the example shows Include/Exclude, while the table shows Enable/Disable. Similarly, WebCategoryBaseQoSPolicy and ApplicationBaseQoSPolicy show Apply/Revoke in the example, while the table describes a string. Do not automatically translate such values or treat them as interchangeable. If the specific value for the object and build remains unresolved, stop the write request and clarify it with Sophos.

Action in the Network/User branch allows Accept, Drop, or Reject; the table lists Drop as the default. An explicit action is still necessary, and the conflict concerning HTTP/HTTPS handling by Drop explained above also applies to API changes. LogTraffic allows Enable/Disable, with a documented default of Disable; deliberately choose logging for acceptance testing. SkipLocalDestined concerns traffic to the appliance IP and is not a substitute for Device Access. Policy references such as WebFilter, ApplicationControl, IntrusionPrevention, and TrafficShapingPolicy must match the protection planned beforehand. Scanning, Proxy, Decryption, Zero-Day, and Heartbeat remain distinct controls with the prerequisites explained above. In particular, default entries such as OFF, NULL, or NoRestriction sometimes conflict with the listed input values; neither these entries nor empty example elements establish how omission, clearing, or updating behaves in the specific build.

When transferring existing protection settings, check the value domain for each field: ProxyMode lists Enable/Disable and also true/false; NDRActiveThreatIntelligence lists only true/false. The thresholds MinimumSourceHBPermitted and MinimumDestinationHBPermitted allow GREEN, YELLOW, and No Restriction, while the default column uses NoRestriction. These inputs differ from those of the separate Heartbeat toggles; they are not automatic translations of the GUI labels. The user-related selectors WebFilterInternetScheme and ApplicationControlInternetScheme list Enable/Disable, but a default of 0; do not confuse them with policy names. The XML comments tie WebCategoryBaseQoSPolicy to a selected WebFilter and ApplicationBaseQoSPolicy to a selected Application Filter. For Traffic Shaping, the table lists TrafficShappingPolicy/TrafficShapingPolicy, but the XML example uses TrafficShapingPolicy: do not infer that the tags are interchangeable or that both are accepted. DSCPMarking is documented as a string; serialization of the GUI value must match the build. Compare every affected protection setting before and after the change; do not normalize unknown inputs or silently lose any protection setting.

Group membership is not a security decision

FirewallRuleGroup groups existing rules through SecurityPolicyList/SecurityPolicy. SourceZones/Zone and DestinationZones/Zone are separate parent elements for group assignment, not new match criteria for the individual rules. The group’s Policytype, with a lowercase t, differs from a rule’s PolicyType. The documented group selectors are User/network rule, Network rule, User rule, WAF rule, and Any; do not derive these values from the rule type or normalize their capitalization or spelling.

The group name is required, must use UTF-8, must not contain commas, and is limited to 150 characters; Description is optional and limited to 255 characters. For SecurityPolicy, the reference specifies no more than 60 characters per rule name, no commas, and up to 200 values. This membership limit is not a capacity guarantee. For an Internet Access group, first read the existing rule names, select only the approved members, and assign source and destination separately. The vendor example containing colons and a comma-separated selection of all types is not an executable payload.

Before updating a group, record its membership, rule positions, and statuses. Afterwards, cross-check the same rules again in WebAdmin and through an authorized read query. The “Add/Remove” description for SecurityPolicy does not establish safe incremental list changes or replacement semantics. Do not write if the handling of omitted or empty lists remains unclear. According to the GUI help, a group cannot exist empty; removing the last rule may also remove the group. Grouping improves clarity but provides neither isolation nor precedence: the match criteria and actual order of each rule remain decisive.

Distinguish responses by operation and read back the state

The following mappings are consistent across the SFOS 22/23 references. The Message.* identifiers remain unresolved documentation symbols, not guaranteed runtime messages, translations, or unambiguous causes. The same code can mean something different depending on the operation. In particular, these are XML status codes, not HTTP status codes.

The following differences are relevant when creating and editing Network/User rules:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: check the old and new names, references, and stored rule type; do not simply assume complete success.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: compare the existing and intended rules against the state read back; do not overwrite automatically.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. Do not infer a common error cause or a numeric user limit from these mappings.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: check the destination zones and Destination Heartbeat configuration together.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: cross-check the existing name and rule type; do not attempt a speculative workaround by renaming or changing the type.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: clarify management responsibility and the authorized change path.

The WAF-specific responses listed alongside these belong in the WAF guide; do not apply their port, redirect, or protected-server conflicts to Network/User rules.

Record the operation for groups as well: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. The Edit reference does indeed use the same Add symbols. Before trying again, read the stored group name, membership, and both zone lists; do not infer that Edit performs a create operation from the symbol names.

For deletion, the mappings are Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. The Delete table marks Name as optional and inconsistently describes it as an anchor for Before/After. Do not infer that an unnamed, blanket deletion is supported. Before Remove, check the exact target, dependencies, group membership, Linked NAT, management responsibility, and confirmed payload in API help. For unclear legacy rules, controlled disabling with an observation window remains the safer first step.

After every response, and also after a timeout or connection loss, read the actual stored state before retrying: name, type, status, protocol family, position, criteria, Exclusions, protection references, and group membership must match the approved intended state. For Remove, also check that exactly the target rule is absent and that required rules and NAT remain unchanged. An unknown outcome may already include a change. Do not retry blindly, perform automatic upserts, or expand the scope to Any; if the state differs, stop, retain the sanitized response and Audit Trail, and use the confirmed rollback path. Only then proceed with the new permitted and deliberately non-permitted test flows described below.

Test and operate the rule

Acceptance testing after saving

After configuring the rule, save it with Save. It is complete only when the defined test case produces the expected results:

Make only one change per test so that cause and effect remain attributable.

1. Check the rule position and Rule group.
2. Check Log firewall traffic and the destinations under System services > Log settings.
3. Generate exactly one test connection from a defined client to a defined destination and Service.
4. Check the Firewall Rule ID, Rule name, user and Action in the Log Viewer.
5. Check the NAT Rule ID and translated addresses.
6. Verify DNS and routing separately.
7. Validate the Web Policy, Application Control, IPS and TLS Inspection against the expected action.
8. Check for unexpected drops, SSL/TLS errors or performance problems.
9. Remove the test rule or restrict it to the production objects.

The Policy Tester simulates rule selection but does not generate real packet flow and confirms neither routing nor the return path. See Test a Sophos Firewall rule for the complete workflow using Policy Test, Log Viewer and Packet Capture.

New rule, existing rule or disabling

An existing rule can be expanded if the Source, Destination, purpose, Owner and required protection remain the same. A separate rule is better when logging, expiry date, Security Features, responsibilities or review cycles differ.

Temporary support access, servers, guests, VoIP, IoT and management should not disappear inside a general client rule. For unclear legacy rules, controlled disabling is usually safer than immediate deletion:

1. Clarify the purpose, Owner and dependencies.
2. Define logging and the test window.
3. Inform the affected teams.
4. Disable the rule and run defined tests.
5. Remove it only after a traceable observation period.

A rarely used emergency rule can be important. Conversely, a frequently used broad rule is not automatically secure.

Revert a rule change

Before making a change, record the current position and all affected fields, or export a traceable configuration state. An existing rule should not be repurposed: a new rule that is initially disabled provides a clearer rollback path and leaves the existing access unchanged.

If acceptance testing fails, disable the new rule or, for an edited rule, restore the previous values and its former position. Then generate both the allowed test flow and a deliberately disallowed test flow again and verify the expected Firewall Rule ID in the Log Viewer. When changing the management path, independent administrative access must remain available throughout the process.

Data counter, review and change record

Reset data transfer count resets the amount of data transferred through a rule. It is not a session or hit counter. In the SFOS 22 help, Sophos documents Unused differently in two places: the help for the rule table states 24 hours without matching traffic, while the Active firewall rules Control Center widget states 12 hours and a daily check. The status is therefore not a reliable deletion criterion. New and Changed each remain for 24 hours from creation or modification, and a rule can have several statuses at the same time. In the SFOS 23 help, both the rule table and the widget state 12 hours for Unused.

The time windows can overlap: a rule created at 10:00 remains New until 10:00 the following day. A change at 11:00 results in Changed until 11:00 the following day; between 11:00 and the next 10:00, the rule carries both statuses. An Unused status identified during the daily check at 12:00 remains until the next check. If the rule is disabled at 13:00, it can be both Changed and Disabled until 13:00 the following day, then only Disabled. These documentation examples replace neither a check of actual usage nor a decision on deletion. Before Reset data transfer count, document the current value: resetting does not restore an earlier counter value and does not change what the rule permits.

Active firewall rules shows rules by type and status, along with matching traffic in bytes over the last 24 hours. The tile distinguishes between WAF (Webserver Protection), User (with users or groups), and Network (without these criteria). Scanned refers to the total number of rules in the chart, not the number of rules scanned for malware. Disabled means configured but switched off; a disabled rule can also be Changed. Hover to check the data volume; click a count or status to open the rule table with the corresponding filter applied.

The Control Center widget is visible to all administrators, regardless of their rights. Its visibility therefore doesn’t prove write access on the actual rule page. Evaluate these indicators together with logs, the rule description and the use case. Reports > Dashboards > Traffic dashboard > Allowed policies also helps analyze transferred data. If an expected rule is missing from the table, first reset the active filter; the SFOS 22 help also restricts group actions in a filtered view.

Regular reviews should check at least:

• Source, Destination and Services;
• remaining Any objects;
• Owner, ticket and expiry date;
• logging and actual use;
• NAT, Web Policy, IPS, TLS Inspection and other security features;
• disabled, temporary and automatically generated rules.

A backup should be available before major changes. Audit Trail Logs and Config Studio show configuration changes. For groups managed through Sophos Fusion, the Firewall Management Task Queue confirms whether the change reached the correct appliance. The Firewall Health Check complements the regular security review.

Typical errors

• The expected rule does not match or Rule ID #0 appears: Check the order, IPv4/IPv6 and all Source, Destination, Service, user and Exclusion criteria.
• The Firewall Rule ID is correct, but the NAT Rule ID or packet path is not: Check the NAT order, routing, SD-WAN and return path.
• The rule matches, but protection is missing or the application fails: Check the license, global activation, logging, Web Policy, QUIC, TLS Inspection, IPS and Traffic Shaping Policy individually.

If the Rule ID, NAT ID or packet path is unexpected, Sophos Firewall rule does not match provides a structured troubleshooting process.