Understand and configure Sophos Firewall Rules

Firewall Rules are the core of Sophos Firewall. They decide which traffic between zones, networks, users and services is allowed or blocked, and which protection features are applied.

This article explains a Sophos Firewall Rule from top to bottom: order, groups, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR and email scanning.

The menu path is:

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

Quick navigation

• Basic principle and order
• Practical example
• Header area: status, name, action and logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Check after saving
• Common mistakes

Basic principle and order

Firewall Rules control traffic between zones and networks. They allow, drop or block traffic and can apply additional Security Features.

Sophos Firewall checks Firewall Rules from top to bottom. As soon as a rule matches, the following Firewall Rules are no longer checked. It is therefore not only important what is configured in a rule, but also where it sits in the rule list.

A rule only matches if all relevant criteria match at the same time:

The first matching rule wins. If a general LAN_to_WAN_Any rule is above a more specific LAN_to_WAN_Restricted rule, the specific rule is never reached.

Practical example

This example creates a clean client rule:

Goal: Clients from the internal LAN are allowed to access the internet. Web filtering, Application Control, IPS and logging should be enabled. Servers, guests and management networks get their own rules and are not mixed into this client rule.

This example is deliberately not an Any free pass. In practice, client networks, server networks, guest Wi-Fi, VoIP and management should be considered separately.

Header area: status, name, action and logging

Rule status

Rule status enables or disables the rule.

A new rule is normally active. Prepared rules can be disabled and enabled later. Disabled rules should be reviewed regularly so that old test or migration rules do not remain in the configuration.

Practical example: A new rule for a server is prepared, but only enabled during the maintenance window.

Rule name

The name should immediately make clear what the rule does.

Good names:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Names such as Rule1, Test, Allow or Internet are less helpful because the purpose of the rule is no longer clear later.

Description

The description is important for operations, support and audits. It should say:

• why the rule exists
• who requested the rule
• which restrictions were set deliberately
• whether there is a ticket, project or expiry date

Example:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

How to use this field cleanly and document Firewall Rules in a traceable way is described in more detail in How to document a Sophos Firewall Rule easily.

Rule position

Rule position defines where the new rule is inserted.

Basic rule: specific before general. A rule for a single server or a specific application is usually placed above a general internet rule.

Rule group

Rule group is an organisational grouping. The group itself is not a security boundary and not a separate policy engine. The firewall still checks the individual rules from top to bottom.

Useful groups include:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

In small environments, None may be enough. In larger environments, clear grouping is worth doing early because the rule base quickly becomes difficult to read.

Action

Action defines what happens to matching traffic.

For normal client or server rules, Accept is usually used. For block rules, Drop is quieter, while Reject is often easier during troubleshooting.

Log firewall traffic

Log firewall traffic should almost always be enabled on important rules.

Without logging, important information is missing later in Log viewer. Many troubleshooting cases fail not because of the rule itself, but because logging was not enabled and it is not visible which rule actually matched.

Important: The firewall typically logs Firewall sessions when a connection ends and a Destroy event is created. Not every connection therefore appears exactly when the client starts it.

For logs to be visible locally, in Sophos Central or through syslog, System services > Log settings must also be configured correctly. For longer retention, Sophos Central Firewall Reporting or a syslog server is useful. More information: Enable Central Firewall Reporting.

Source

The Source section defines where the traffic comes from.

Source zones

Source zones is the zone from which the traffic originates.

Examples:

• LAN for internal client networks
• VPN for Remote Access users
• DMZ for server networks
• Guest for guest Wi-Fi
• WAN for inbound internet traffic

Practical example: For an internet rule from clients to the internet, LAN is selected. For a DNAT rule from outside to an internal server, the corresponding Firewall Rule usually uses WAN as the Source zone.

Source networks and devices

Source networks and devices narrows down the source.

Possible objects include:

• individual hosts
• networks
• IP ranges
• host groups
• FQDN Hosts
• country objects

At first, Any looks convenient, but it is often too broad. A concrete client network, a host group or a clearly named network object is better.

Practical example: Instead of Any as the source, use net_LAN_Clients. Servers, printers, guests and management devices get their own rules.

During scheduled time

During scheduled time defines when the rule applies.

Typical values:

• All the time
• working hours
• maintenance windows
• temporary access

Schedules are useful when access should only be allowed at certain times. During troubleshooting, always check whether the firewall time, time zone and schedule really match.

Practical example: External maintenance access to a server is only allowed during a defined maintenance window.

Destination and services

The Destination and services section defines where traffic may go and which ports or protocols are allowed.

Destination zones

Destination zones is the target zone.

Examples:

• WAN for internet access
• DMZ for servers in a DMZ
• LAN for internal destinations
• VPN for remote users or Site-to-Site tunnels

Practical example: For client internet traffic, use WAN. For client access to an internal server, Server or DMZ can be used if these zones exist.

Destination networks

Destination networks narrows down the destination.

For client internet rules, Any is often a practical starting point. For servers, management networks or VPN access, destinations should be limited much more strongly.

Examples:

• Any for general internet access
• FQDN Host such as updates.vendor.com
• host object of an internal server
• network object of a remote VPN site
• country object for Geo-IP rules

Practical example: A backup server may only access the vendor’s cloud backup destinations, not Any.

Services

Services are protocol and port definitions.

Examples:

• HTTP for TCP 80
• HTTPS for TCP 443
• DNS for TCP/UDP 53
• NTP for UDP 123
• custom services such as Synology_5555

Services should be as narrow as possible. Any only makes sense if all protocols really must be allowed or if other controls are used deliberately.

Practical example: For normal web clients, a group with HTTP, HTTPS, DNS and NTP is often enough. For server access from the internet, only the actually published service is allowed.

Match known users

With Match known users, user identity becomes part of the matching. The rule then no longer applies only to IP addresses, but to known users or groups.

This is useful when:

• Web Policies should apply per AD group
• reporting should be user-based
• different user groups need different internet permissions
• MFA, Captive Portal or SSO are already configured cleanly

Pitfall: If authentication does not work cleanly, the rule may not match. Traffic then falls through to a more general rule below or is dropped by the drop-all rule.

For initial tests, it is often better to start without User Matching and add user criteria later.

Add exclusion

With Add exclusion, traffic can be excluded from a rule. The firewall skips this rule only if all configured exclusion criteria match, and then checks the next rule.

Exclusions can include Source zones, Source networks and devices, Destination zones, Destination networks and Services.

Practical example: A general client internet rule uses web filtering. A specific update server should use a separate rule with different Security Features. That server can be excluded from the general rule.

Exclusions are powerful, but they make rules harder to read. If a rule has many exceptions, a separate specific rule is often easier to understand.

Create linked NAT rule

With Create linked NAT rule, a Source NAT rule can be created directly from the Firewall Rule. This Linked NAT Rule then appears in the NAT rule table.

For beginners this sounds convenient, but in practice standalone NAT rules are usually clearer. If a generic NAT rule already covers the same traffic cleanly, no additional Linked NAT Rule should be created.

For a normal client-to-internet rule, the default SNAT rule with MASQ is usually sufficient, as long as it is active and fits the rule base.

Important: NAT does not allow traffic by itself. NAT translates addresses or ports. Whether traffic is allowed is still decided by the matching Firewall Rule.

More information: Understand NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

The Web filtering section configures Web Policy, malware scanning and web filtering behaviour.

Web policy

Web policy controls web access using categories, users, groups, URL groups and rules.

Practical example: Clients use a Web Policy that blocks malware, phishing, adult content and risky categories, while allowing business applications.

If no Web Policy is set, no category-based web filtering is applied through this option.

Apply web category-based traffic shaping

This option applies Traffic Shaping based on web categories. It is only useful when matching Traffic Shaping rules or web category policies are used.

Practical example: Streaming categories are limited, while business applications remain prioritised.

Block QUIC protocol

QUIC uses UDP 80 and UDP 443. Many browsers use QUIC for Google services and other modern web applications.

If web filtering or malware scanning for web traffic is important, Block QUIC protocol should remain enabled in many environments. Browsers usually fall back to normal HTTPS over TCP, which is easier to control and inspect.

Scan HTTP and decrypted HTTPS

This option scans HTTP and already decrypted HTTPS for malware.

Important: This option does not automatically decrypt HTTPS. To really inspect HTTPS, matching SSL/TLS inspection rules are required under Rules and policies > SSL/TLS inspection rules.

Practical example: If TLS Inspection is active for LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS can scan downloaded files in decrypted HTTPS traffic.

More information: Roll out TLS Inspection on Sophos Firewall step by step.

Use Zero-day protection

Use Zero-day protection sends suspicious downloads to Sophos Zero-Day Protection for further analysis. This is useful for client and server rules where downloads from the internet should be checked.

The function requires a suitable licence and may cause delays depending on file type and policy.

Scan FTP for malware

This option scans FTP traffic for malware. It is only relevant when FTP is actually used and the matching services are allowed in the rule.

FTP is less common in modern environments, but still appears with legacy systems, machine controls or older update mechanisms.

Use web proxy instead of DPI engine

Sophos Firewall can inspect web traffic through the DPI engine or through the Web Proxy.

For modern setups, DPI is usually the better default because HTTP and SSL/TLS traffic can be processed on all ports. The Web Proxy is still useful when specific proxy functions are needed, such as SafeSearch enforcement, YouTube restrictions, Google app domain restriction, Pharming Protection, Web Cache or Parent Proxy.

If Use web proxy instead of DPI engine is not enabled, the rule works in DPI mode.

Decrypt HTTPS during web proxy filtering

This option belongs to Web Proxy mode. It is only relevant when Use web proxy instead of DPI engine is enabled and HTTPS should be decrypted in proxy mode.

In DPI mode, HTTPS decryption is not controlled here, but through SSL/TLS inspection rules.

Synchronized Security Heartbeat

With Configure Synchronized Security Heartbeat, the Sophos Endpoint status can be included in the Firewall Rule.

Typical options:

• define minimum status for source devices
• block clients without Heartbeat
• define minimum status for destination devices
• block requests to destinations without Heartbeat

This is powerful, but only useful when Sophos Endpoint, Sophos Central and Security Heartbeat are configured cleanly.

Practical example: Clients with a red Security Heartbeat can no longer access servers or no longer receive internet access.

For a first client rule, Heartbeat should not be enabled blindly, otherwise devices that cannot send a Heartbeat may be blocked.

Other security features

Identify and control applications (App control)

With Identify and control applications (App control), an Application Filter Policy is selected.

This can detect and control applications such as:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control requires a suitable licence. In practice, this function is included in Sophos Firewall bundles with Web Protection, such as Standard Protection, Xstream Protection or Epic Protection.

For application detection in encrypted traffic, TLS Inspection is often essential. Without decryption, depending on the service, the firewall only sees hostnames, SNI, certificate information or IPs, and not the full content.

Apply application-based traffic shaping policy

This option applies Traffic Shaping defined in the Application Policy or on the Application Object.

Practical example: Microsoft Teams should be detected and prioritised with a specific Traffic Shaping policy. The matching Application Control Policy must be selected and the application-based traffic shaping policy must be applied.

If an explicit Traffic Shaping Policy is already set in Shape traffic, it should be clearly documented which policy should take precedence and why.

Detect and prevent exploits (IPS)

Under Detect and prevent exploits (IPS), an IPS Policy is selected.

IPS checks traffic for known attack patterns and exploits. Client traffic to the internet uses a different policy than server traffic or published services.

Practical examples:

• client rule LAN_to_WAN: client or LAN-to-WAN IPS policy
• DNAT rule to web server: server or web server IPS policy
• VoIP rule: test carefully because aggressive IPS profiles can disturb VoIP

IPS should not simply be enabled everywhere with the strictest policy. A policy that is too broad or wrong can break legitimate traffic or create unnecessary load.

Shape traffic

With Shape traffic, a Traffic Shaping Policy can be applied directly to the rule.

This is relevant for:

• VoIP
• video conferences
• backup traffic
• guest Wi-Fi
• slow WAN links

Practical example: Guest Wi-Fi receives a limit policy so that it does not displace business traffic.

More information: Configure Application Traffic Shaping on Sophos Firewall.

DSCP marking

DSCP marking marks packets for Quality of Service on downstream network devices.

This is only useful if switches, routers or WAN devices also evaluate these DSCP values. Sophos Firewall can mark packets, but the rest of the network must treat these markings consistently.

Practical example: VoIP traffic receives a DSCP marking so that switches and WAN routers prioritise this traffic.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence uses Sophos NDR Threat Intelligence for additional evaluation of network traffic.

This option is only useful if the environment uses the required Sophos Central and NDR components. In many environments it is not the first option for a basic rule, but it can be a valuable addition in more heavily monitored networks.

Scan email content

The Scan email content section applies to email protocols.

Possible options:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

If protocols are enabled here, the matching standard ports must also be included in the rule’s Services or added through Add ports.

For normal web client rules, this section is often not relevant. For mail servers or client mail traffic, it should be planned deliberately.

Practical example: An internal mail server may send SMTP externally. A separate server rule is created, logging is enabled and email scanning is checked according to the mail architecture.

Check after saving

After saving, the rule should be tested instead of assuming that everything works correctly.

Check:

1. Is the rule in the correct position?
2. Is Log firewall traffic enabled?
3. Does the rule match in Log viewer?
4. Is the expected Firewall Rule ID shown?
5. Does the expected NAT rule apply?
6. Does DNS work?
7. Are web filtering, IPS, Application Control and TLS Inspection applied as expected?
8. Are there unexpected drops or SSL/TLS errors?

For clean testing, see Test Firewall Rules with Log Viewer, Policy Test and Packet Capture.

Common mistakes

The rule is too far down: A more general rule above it matches the traffic first.

Source is too broad: Any may work, but it makes rules unclear and increases the attack surface.

Destination is too broad: Servers or management networks should rarely be allowed to access the internet with Any.

Services are too broad: Any allows far more than necessary. Concrete services or service groups are better.

Logging is not enabled: The most important information is then missing in Log Viewer.

HTTPS is not scanned: Scan HTTP and decrypted HTTPS is enabled, but there is no matching SSL/TLS inspection rule or no decryption.

Web filtering does not apply: No Web Policy is set, the wrong user is matched, the Source zone is wrong or QUIC is not blocked.

User Matching does not apply: Authentication, AD SSO, Captive Portal or user mapping does not work cleanly.

NAT is missing: The Firewall Rule allows traffic, but SNAT/MASQ does not match.

Security Feature does not fit the traffic: A wrong IPS Policy, proxy option or email scanning option can break legitimate traffic.