Skip to content
Avanet

Understand and safely configure Sophos Firewall rules

Sophos Firewall

Firewall rules are at the heart of the Sophos Firewall. These rules determine which traffic between zones, networks, users and services is allowed or blocked and which protection functions 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

Sophos Firewall Add firewall rule with all options from rule status to security features
Sophos Firewall - Add firewall rule: The rule is configured from top to bottom and is later evaluated based on the rule order.

The rule mask is divided into several areas: header area, source, destination, Services, user reference, NAT link and security features. In practice, it is important not to see the mask as a collection of individual hooks. A rule only works properly if the source, destination, service, sequence, logging and the activated protection functions match.

Before creating it, it should also be clear whether it is an IPv4 or IPv6 rule. The rule view is selected accordingly in the WebAdmin. In dual-stack environments, IPv4 and IPv6 must be intentionally planned and tested separately; a functioning IPv4 rule does not automatically prove that IPv6 is equally secured.

Quick navigation

Which network policy article fits?

Firewall rules, NAT, WAF, VLANs and routing are closely intertwined in the Sophos Firewall. It is therefore important for admins to first choose the right topic:

This separation prevents typical troubleshooting. A NAT rule does not allow traffic, a firewall rule does not translate an address, and a WAF rule is not the same as regular DNAT port forwarding.

What firewall rules control and what they don’t

Firewall rules control traffic that flows through the firewall. But these rules are not the only control point in SFOS. A lot of troubleshooting occurs because you are looking for a behavior in the firewall rule list, even though another area is responsible.

  • Traffic between zones, networks, users and services: Firewall rules. This is where it is decided whether through traffic is allowed, rejected or checked with security features.
  • WebAdmin, User Portal, VPN Portal, SSH, DNS or SNMP to the firewall itself: Device Access and Local Service ACL. Local firewall services are not treated like normal LAN-to-WAN or WAN-to-DMZ traffic.
  • Address or port translation: NAT rules. NAT translates traffic but does not automatically allow it.
  • Route selection, return route, SD-WAN and VPN paths: Routing, SD-WAN, Route Precedence and VPN configuration. A suitable firewall rule does not prove a working way back.
  • Web Categories, URL Groups and Web Policy: Web filtering and Web Policy. The firewall rule integrates the policy, but the actual web logic lies in the web policy.
  • HTTPS decryption: SSL/TLS inspection rules and CA distribution. Scan HTTP and decrypted HTTPS only scans traffic that is already decrypted.
  • User Identity: Authentication, STAS, Captive Portal, Entra ID SSO or RADIUS. A user rule only matches if the firewall can assign the user to the traffic.

For management and portal services, Device Access and Local Service ACL is the central article. If a rule matches but the connection still fails, Sophos Firewall Rule does not work: Check causes and Test firewall rule with Log Viewer, Policy Test and Packet Capture will help. Particularly with mixed IPv4/IPv6 networks, you should also check whether an application via IPv6 bypasses a stricter IPv4 rule. If IPv6 is not actively used, the IPv6 strategy should still be consciously documented: deactivate, block, regulate properly or introduce it in a controlled manner.

Basic principle and sequence

Firewall rules control traffic between zones and networks. Rules allow, reject or block traffic and can apply additional security features.

Sophos Firewall checks firewall rules from top to bottom. As soon as a rule matches, subsequent firewall rules are no longer checked. What is important is not only what is in a rule, but also where it is in the list of rules.

A rule only fits if all relevant criteria apply at the same time:

  • Source zone: Yes. LAN.
  • Source networks and devices: Yes. net_LAN_Clients.
  • Schedule: Yes. All the time.
  • Destination zone: Yes. WAN.
  • Destination networks: Yes. Any or an FQDN Host.
  • Services: Yes. HTTP, HTTPS, DNS.
  • User Matching: Only if activated. AD group Internet-Users.
  • Exclusions: If set, the rule can be skipped. Exclude backup server.

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

Plan rule base before creating

A single firewall rule can be created quickly. What is more difficult is a rule base that is still understandable, testable and secure after two years. Therefore, before introducing new rules, you should first clarify which security zone, group and operating logic the rule belongs to.

Helpful guiding questions:

  • What kind of traffic should really be allowed?: Note source, destination and Services before creating.
  • Does the traffic belong in its own zone?: Consciously separate servers, clients, guests, management, VPN and DMZ.
  • Is there already a specific rule?: Check existing rules instead of creating a second similar rule.
  • Is NAT involved?: Plan firewall rules and NAT rules together, but do not mix them up.
  • How will it be checked later?: Activate logging and define specific test traffic.
  • Is the release temporary?: Document the expiry date or ticket in the description.

For clean zones and interfaces, Sophos Firewall Configure zones and interfaces fits first. If an existing rule does not work, the checklist Sophos Firewall Rule does not work: Check causes will help.

⚠️ A wide Any rule is often convenient, but rarely a good final configuration. It can help in the short term for tests. It should then be replaced or removed again by specific sources, destinations and services.

Cleanly separate rule types

A good rule base visibly separates different risks from one another. The most common error is not a single incorrect option, but a blanket rule that covers clients, servers, VPN, guests and management at the same time. This works quickly in the beginning, but later becomes difficult to test and difficult to harden.

  • Client Internet: Typical Source: Client networks; Typical target: WAN; What to pay attention to?: Web Policy, Application Control, IPS, TLS Inspection, QUIC, Logging.
  • Server Internet: Typical Source: Server networks; Typical target: defined update, backup or cloud targets; What to pay attention to?: tighter than client rules, often without user reference.
  • Guest-WLAN: Typical Source: Guest Zone; Typical target: WAN; What to pay attention to?: no conscious control of internal targets, bandwidth and DNS.
  • Management: Typical Source: Admin Networks; Typical target: Firewall, servers, switches, hypervisors; What to pay attention to?: do not mix with normal client rules.
  • VPN Remote Access: Typical Source: VPN or own remote access zone; Typical target: internal target zones; What to pay attention to?: only required targets and services, logging in the introductory phase.
  • Site to Site: Typical Source: local and remote VPN zones or XFRM zones; Typical target: Partner or location networks; What to pay attention to?: Check routing, NAT, return path and logging together.
  • Published System: Typical Source: WAN or defined sources; Typical target: DMZ or server zone; What to pay attention to?: DNAT/WAF, IPS, logging, patch level and source limiting.
  • Temporary access: Typical Source: defined support or project source; Typical target: narrow target; What to pay attention to?: Document ticket, expiry date, owner and dismantling.

If two connections have different owners, protection functions or review cycles, separate rules are usually cleaner. If only an additional service is required for the same professional purpose, an existing rule can be expanded.

Fictitious practical example

As an example, a clean client rule is created:

Target: Clients from the internal LAN are allowed to access the Internet. Web filter, Application Control, IPS and logging should be active. Servers, guests and management networks get their own rules and are not mixed with this client rule.

  • Rule name: LAN_to_WAN_Clients. Clear name with source and destination.
  • Description: Internet Access für Client-Netz, erstellt für Standard-Client-Traffic. Later you will know why the rule exists.
  • Rule position: Under specific block and server rules. Specific rules should come into effect first.
  • Rule group: Internet Access. Better overview.
  • Action: Accept. Traffic is allowed.
  • Log firewall traffic: Enabled. Troubleshooting the Log Viewer.
  • Source zones: LAN. Traffic comes from the LAN zone.
  • Source networks and devices: net_LAN_Clients. Not all LAN networks, just clients.
  • During scheduled time: All the time. Internet access should be permanent.
  • Destination zones: WAN. Target is the Internet.
  • Destination networks: Any. Mostly practical for client internet.
  • Services: HTTP, HTTPS, DNS, NTP. Only required basic services.
  • Web policy: Default Workplace Policy. Control web access based on categories.
  • Block QUIC protocol: Enabled. Web filtering and scanning remain effective.
  • IPS: Client Policy. Exploit protection for outbound client traffic.
  • App control: Client Application Policy. Block unwanted apps.
  • Shape traffic: Optional. Only if bandwidth is required.
  • DSCP marking: Empty. Only necessary if downstream devices evaluate DSCP.

This example is deliberately not a Any free ticket. In practice, client networks, server networks, guest networks, VoIP and management should be considered separately. For the first productive test, this example should include a short test case: defined client, specific target address, expected Rule ID, expected NAT Rule ID and a look into Log Viewer or Central/Syslog. Without this approval step, it remains unclear whether the rule actually processes the expected connection.

Header area: Status, Name, Action and Logging

Rule status

Rule status activates or deactivates the rule.

A new rule is usually active. For prepared rules you can deactivate the status and only activate the rule later. Deactivated rules should be checked regularly so that no old test or migration rules remain in the configuration.

Practical example: A new rule for a server is prepared but is only activated in the maintenance window.

Rule name

The name should immediately make it 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 like Rule1, Test, Allow or Internet are less helpful because you can no longer tell what task the rule has.

Description

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

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

Example:

Internet Access für Client-Netz 10.10.10.0/24. Webfilter und IPS aktiv. Angefordert durch IT, geprüft am 10.06.2026.

How to use this field properly and document firewall rules in a comprehensible manner is described in more detail in the article Sophos Firewall sensibly documenting rules.

Rule position

Rule position specifies where the new rule will be inserted.

  • Top: Only for very specific rules, block rules or tests.
  • Bottom: Often useful for new standard rules.
  • Above rule: If a rule specifically has to take effect before an existing rule.
  • Below rule: If a rule should specifically follow an existing rule.

Basic rule: specific before general. A rule for an individual server or a specific application is usually higher up than a general Internet rule.

Rule group

Rule group is an organizational grouping. The group itself is not a security boundary or its own policy engine. The firewall continues to check each rule from top to bottom.

Examples of useful groups include:

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

In small environments, None may be sufficient. In larger environments, clear grouping is worthwhile early on, otherwise the rule base quickly becomes confusing.

Action

Action determines what happens to matching traffic.

  • Accept: Traffic is allowed. Normal Allow Rules.
  • Drop: Traffic is silently discarded. Block rules where the client should not receive a response.
  • Reject: Traffic is rejected and the client receives a response. Troubleshooting or internal block rules.
  • Protect with web server protection: WAF protection is applied. Webserver Protection, not for normal LAN-to-WAN rules.

For normal client or server rules you usually use Accept. For block rules, Drop is quieter, Reject is often more pleasant for troubleshooting.

Log firewall traffic

Log firewall traffic should almost always be activated for important rules.

Without logging, important information will be missing later in the Log viewer. Many troubleshooting cases fail not because of the rule itself, but because there was no logging and it is not possible to see which rule actually applied.

Important: The firewall typically logs firewall sessions when a connection is terminated and a Destroy event occurs. Not every connection appears at the exact moment the client starts it.

In order for logs to be visible locally, in Sophos Central or via Syslog, System services > Log settings must also be configured appropriately. For longer storage, Sophos Central Firewall Reporting or a Syslog server makes sense. More on this: Enable Central Firewall Reporting and Send Sophos Firewall Syslog securely to SIEM.

For productive rules, logging should not just be seen as a troubleshooting hook. It is also the basis for reviews: Is the rule still used, which sources do they apply to, which goals are really addressed and whether a rule is too broad.

Source, Zone and Schedule

In the Source area you define where the traffic comes from.

Source zones

Source zones is the zone where the traffic comes from.

Examples:

  • LAN for internal client networks
  • VPN for remote access users
  • DMZ for server networks
  • Guest for guests-WLAN
  • WAN for incoming internet traffic

Practical example: LAN is selected for an Internet rule from clients to the Internet. For a DNAT rule from external to an internal server, WAN is usually used as the source zone in the associated firewall rule.

Source networks and devices

Source networks and devices narrows down the source more precisely.

Possible objects are, for example:

  • individual hosts
  • Networks
  • IP ranges
  • Host groups
  • FQDN hosts
  • Country objects

For starters, Any seems comfortable, but is often too wide. A specific client network, a host group or a clearly named network object is better.

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

During scheduled time

During scheduled time determines when the rule applies.

Typical values:

  • All the time
  • Working hours
  • Maintenance window
  • temporary releases

Schedules are helpful if access should only be permitted at certain times. When troubleshooting, you always have to check whether the firewall time, time zone and schedule are really correct.

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

Destination and services

In the Destination and services area you define where the traffic is allowed 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 targets
  • VPN for remote users or site-to-site routes

Practical example: WAN is used for client internet traffic. Server or DMZ can be used for clients to access an internal server if these zones are created accordingly.

Destination networks

Destination networks narrows down the target more precisely. For client internet rules, Any is often a viable start. For servers, management networks or VPN access, targets should be limited significantly more.

Examples:

  • Any for general internet access
  • FQDN host like updates.vendor.com
  • Host object of an internal server
  • Network object of a remote station via VPN
  • Country object for Geo-IP rules

Practical example: A backup server may only go to the manufacturer’s cloud backup destinations, not to 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
  • own Services like Synology_5555

Services should be chosen as narrowly as possible. Any only makes sense if all protocols really have to be allowed or if you consciously work with other controls.

Practical example: For normal web clients, a group with HTTP, HTTPS, DNS and NTP is often sufficient. Only the actually published service is permitted for server access from the Internet.

Match known users

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

This makes sense if:

  • Web policies should apply per AD group
  • Reporting should be user-related
  • different user groups get different internet rights
  • MFA, Captive Portal or SSO are already properly set up

Stumbling block: If authentication doesn’t work properly, the rule may not match. Then the traffic drops 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.

If user matching is used, there should not be a broad fallback rule that allows the same traffic without user reference. Otherwise the user rule appears clean, but unknown users still end up with the general rule. When accepted, the Log Viewer should therefore show the user, group and Rule ID.

Add exclusion

With Add exclusion traffic can be excluded from a rule. The firewall only skips this rule if all exclusion criteria set 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 filters. However, a specific update server should run its own rule with other security features. Then you can exclude this server from the general rule.

Exclusions are powerful, but they make rules harder to read. If a rule contains many exceptions, a separate specific rule is often more understandable.

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.

This sounds convenient for beginners, but in practice independent NAT rules are usually clearer. If a generic NAT rule already covers the same traffic, you should not create an additional linked NAT rule.

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 correctly. Important: NAT does not allow traffic by itself. NAT translates addresses or ports. The appropriate firewall rule still decides whether traffic is allowed.

More on this: Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

In the Web filtering area, web policy, malware scan and web filter behavior are configured.

Web policy

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

Practical example: A web policy is used for clients that blocks malware, phishing, adult content and risky categories, but allows business applications.

If no web policy is set, category-based web filtering will not take place via this option.

How to plan categories, URL groups, web policies and instant alerts together is described in Sophos Firewall Using web categories and instant alerts.

Apply web category-based traffic shaping

This option applies traffic shaping based on web categories. It only makes sense if appropriate traffic shaping rules or web category policies are used.

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

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 be left enabled in many environments. Browsers then usually fall back to normal HTTPS over TCP, which is easier to control and check.

More about this: Sophos Firewall Block QUIC and HTTP/3 correctly.

Scan HTTP and decrypted HTTPS

This option scans HTTP and already decrypted HTTPS for malware.

Important: This option does not automatically decrypt HTTPS. In order for HTTPS to really be checked, appropriate 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 check downloaded files in decrypted HTTPS traffic.

More on this: Roll out TLS Inspection to Sophos Firewall gradually.

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 that want to check downloads from the Internet.

The function requires a suitable license and can lead to delays depending on the file type and policy.

Scan FTP for malware

This option scans FTP traffic for malware. It is only relevant if FTP is actually used and the matching Services is usually permitted.

FTP has become less common in modern environments, but it still occurs in legacy systems, machine controls or older update mechanisms.

Use web proxy instead of DPI engine

Sophos Firewall can check web traffic via DPI engine or via Web Proxy.

For modern setups, DPI is usually the better default choice because it can handle HTTP and SSL/TLS traffic on all ports. The web proxy is still useful if special proxy functions are required, for example SafeSearch enforcement, YouTube restrictions, Google app domain restrictions, 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 if Use web proxy instead of DPI engine is activated and HTTPS is to be decrypted in proxy mode.

In DPI mode, HTTPS decryption is not controlled here, but rather via 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:

  • Set minimum status for source devices
  • Block clients without heartbeat
  • Set minimum status for target devices
  • Block requests to destinations without a heartbeat

This is strong, but only makes sense if Sophos Endpoint, Sophos Central and Security Heartbeat are properly set up.

Practical example: Clients with red Security Heartbeat are no longer allowed to access servers or no longer have Internet access.

For a first client rule, you should not activate heartbeat blindly, otherwise you may block devices that cannot send a heartbeat at all.

Other security features

Identify and control applications (App control)

An application filter policy is selected via Identify and control applications (App control).

This allows applications to be recognized and controlled, for example:

  • Team Viewer
  • Gate
  • Messengers
  • Streaming
  • Cloud storage
  • Remote control tools

Application Control requires a suitable license. In practice, this feature is included in the Sophos Firewall bundles with Web Protection, for example Standard Protection, Xstream Protection or Epic Protection.

TLS Inspection is often crucial for application detection in encrypted traffic. Without decryption, depending on the service, the firewall only sees host names, SNI, certificate information or IPs and not the complete content.

The custom process for filters, rule binding, logs and false positive checking is available in Sophos Firewall Setting up and testing Application Control.

Apply application-based traffic shaping policy

This option applies traffic shaping defined in the Application Policy or Application Object.

Practical example: Microsoft Teams should be recognized and prioritized with a specific traffic shaping policy. Then the appropriate Application Control policy must be selected and the application-based traffic shaping policy must be applied.

If you already set an explicit traffic shaping policy in the Shape traffic field, it should be clearly documented which policy should take precedence and why.

Detect and prevent exploits (IPS)

An IPS policy is selected under Detect and prevent exploits (IPS).

IPS checks traffic for known attack patterns and exploits. A different policy is used for client traffic to the Internet than for 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 disrupt VoIP

IPS shouldn’t just be activated everywhere with the harshest policy. An IPS policy that is too broad or incorrect can break legitimate traffic or create unnecessary load.

The dedicated article Sophos Firewall Set up IPS and safely test it explains global activation, license status, policy selection, logging and false positive analysis in more detail.

Shape traffic

With Shape traffic a traffic shaping policy can be applied directly to the rule. This is relevant for:

  • VoIP
  • Online meetings
  • Backup traffic
  • Guest WLAN
  • slow WAN routes

Practical example: Guest WLAN gets a limit policy so that it doesn’t crowd out business traffic.

More about this: Configure Application Traffic Shaping on Sophos Firewall.

DSCP marking

DSCP marking marks packets for quality of service on downstream network devices.

This only makes sense if switches, routers or WAN devices also evaluate these DSCP values. The Sophos Firewall can mark, but the rest of the network must treat these marks consistently.

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

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence uses Sophos NDR Threat Intelligence to additionally assess 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 base rule, but it can be a valuable addition in more highly monitored networks.

Scan email content

The Scan email content area concerns email protocols.

Possible options:

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

If you activate protocols there, the appropriate standard ports must also be included in the Services of the rule or added via Add ports.

This area is often not relevant for normal web client rules. You should plan it consciously for mail servers or client mail traffic.

Practical example: An internal mail server is allowed to send SMTP externally. A separate server rule is then created, logging is activated and email scanning is checked to match the mail architecture.

Check after saving

After saving, you should test the rule and not just assume that everything works correctly.

To check:

  1. Is the rule in the correct position?
  2. Is Log firewall traffic active?
  3. When the rules changed, was the hit counter reset or a clear new test created?
  4. Does the rule match in the Log viewer?
  5. Does the expected firewall Rule ID appear?
  6. Does the desired NAT rule apply?
  7. Does DNS work?
  8. Are web filters, IPS, Application Control and TLS Inspection applied as expected?
  9. Are there any unexpected drops or SSL/TLS errors?

The article Testing the firewall rule with Log Viewer, Policy Test and Packet Capture helps for a clean check.

When making productive changes, a small before-and-after comparison makes sense:

  • Backup or restore point exists: Dismantling remains possible if the rule produces side effects.
  • Audit trail or change ticket noted: later it will be clear who made the change and when.
  • Test case defined beforehand: Success is not only judged by feeling.
  • Only one change per test: Cause and effect remain comprehensible.
  • Log Viewer or central logs checked: the real Rule ID and NAT ID are visible.
  • Dismantling decision documented: temporary test rules do not remain permanently active.

For multiple firewalls or centrally managed groups, you should also check whether the change has arrived on the correct appliance or group. For Sophos Central, the Firewall Management Task Queue helps; local changes can be traced with Audit Trail Logs.

Regular operation and review

A firewall rule is not ready just because it has been saved. Good rules have a clear purpose, are logged, are testable and can be checked again later. Especially in mature environments, many risks arise not from a single incorrect rule, but from old exceptions, rules that are too broad or rules without an owner.

A simple routine is worthwhile for regular reviews:

  • Will the rule still be made?: Unused rules can often be disabled and removed later.
  • Is the source still correct?: Client networks, server networks and VPN areas change over time.
  • Is Any still justified?: Broad sources, goals or Services should be deliberately documented.
  • Is logging active and useful?: Without logs, subsequent analyzes and audits are significantly weaker.
  • Do NAT, web filter, IPS and TLS Inspection still fit?: Security features may work differently after upgrades, app changes or certificate changes.
  • Is there an expiration date?: Otherwise, temporary project or support rules remain permanently active.

For critical rules, you should also document who is technically responsible. This is particularly important for published services, VPN rules, management access, service provider shares and rules with Any at Services or destination.

New rule, change or deactivate existing rule?

Not every new request immediately needs a new firewall rule. Too many similar rules make the list confusing, but rules that are too summarized quickly become too broad. A simple decision helps before saving something in the WebAdmin:

  • Same source, same destination, same purpose, just one additional service: Extend existing rule. The rule remains technically coherent and easier to test.
  • Same networks, but different protection requirements, different logging or different owner: Create your own rule. Web filters, IPS, TLS Inspection, NDR or logging can be checked separately.
  • Temporary service provider or support access: Create your own temporary rule. Owner, ticket, expiration date and test window remain clearly visible.
  • Servers, guests, VoIP, IoT or management are affected: Check your own rule or zone. Different risks should not disappear in one client internet rule.
  • A rule is unclear or old: First deactivate and observe. Direct deletion takes away the ability to check hits, logs and dependencies in a controlled manner.
  • A rule is certainly superfluous after a review: Remove after backup and documentation. The set of rules becomes smaller without breaking blindly functioning dependencies.

For normal operational changes, this process is robust:

  1. Note the purpose, owner, ticket and expected traffic.
  2. Check existing rules for the same source, destination, service and Rule group.
  3. Decide whether an existing rule is extended or your own rule is cleaner.
  4. For productive changes, plan backup, audit trail and test case.
  5. After saving Log Viewer, Rule ID, check NAT decision and affected security features.

If the decision fails primarily due to a lack of documentation, Sophos Firewall rules should be meaningfully documented should be followed up first. If it is unclear whether an existing rule is still needed, a controlled test with Test firewall rule with Log Viewer, Policy Test and Packet Capture helps.

Arrange hit counters correctly

Hit counters help with cleanup, but are not complete proof. A rarely used emergency rule can still be important. Conversely, a broad rule can have many hits even though it allows too much.

For reviews you should always combine hit counters with Log Viewer, rule description and actual use case. If a rule is unclear, it should not be deleted immediately. A controlled process is better: clarify the purpose, activate logging, define test windows, inform stakeholders and only then deactivate or remove it.

Make changes traceable

A backup should be available before major rule changes. Audit Trail and Config Studio then help to check differences in a comprehensible manner. The practical process is in Sophos Firewall Check Audit Trail Logs and Sophos Firewall Use Config Studio.

If many rules are adjusted, you should not only compare the configuration, but also run real test cases. A rule can be syntactically correct and still allow incorrect traffic, use the wrong NAT path, or disrupt an application through IPS, web filtering, or TLS Inspection.

Typical errors

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

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

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

Services are too wide: Any allows significantly more than necessary. Specific Services or service groups are better.

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

IPv6 was forgotten: IPv4 is properly regulated, but IPv6 runs on other rules or remains open unconsciously.

Rule group is certainly confused: A rule group only improves the overview. A rule group is not its own security boundary and does not change the evaluation logic.

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

Web filter does not work: No web policy set, wrong user, wrong source zone or QUIC not blocked.

User matching does not work: Authentication, AD SSO, captive portal or user mapping do not work properly.

NAT missing: The firewall rule allows traffic, but SNAT/MASQ does not fit.

Security feature does not match traffic: An incorrect IPS policy, proxy option or email scanning option can break legitimate traffic. If after these points it remains unclear why traffic is running differently than expected, you should carry out further structured testing with Log Viewer, Policy tester and Packet Capture. The appropriate procedure is in Test firewall rule with Log Viewer, Policy Test and Packet Capture.

FAQ

In what order does Sophos Firewall check the firewall rules?

Sophos Firewall checks rules from top to bottom. The first matching rule wins. Therefore, specific rules, block rules and special cases must come before general rules.

Should you use Any in Sophos firewall rules?

Any can be handy for testing or very general internet rules, but should be deliberately justified. For servers, management, VPN, service provider access and critical networks, concrete sources, targets and Services are significantly better.

Do you need your own Sophos firewall rules for IPv6?

Yes. IPv4 and IPv6 rules are treated separately. In dual-stack environments, IPv6 should be deliberately allowed, blocked or introduced in a controlled manner. Otherwise, a properly hardened IPv4 rule base can be circumvented by ignored IPv6 traffic.

Why can't I see a permitted connection in the log viewer?

Often Log firewall traffic is usually not active or the appropriate log type is not activated for local logs, Sophos Central or Syslog under System services > Log settings. In addition, some sessions only appear as a log entry when the connection ends.

Does a firewall rule replace a NAT rule?

No. The firewall rule decides whether traffic is allowed or blocked. NAT translates addresses or ports. For Internet access, DNAT and VPN, the firewall rule and NAT rule must match.

Do firewall rules also control WebAdmin, SSH or VPN Portal?

Not like normal through traffic. Access to local firewall services is mainly controlled via Device Access and Local Service ACL. Normal firewall rules are responsible for traffic through the firewall.

How do you cleanly test a Sophos Firewall rule?

First define a concrete test case: source, target, service, expected rule and expected NAT decision. Then use Log Viewer, Policy tester and if necessary Packet Capture. For complex cases you should reset hit counters or use a clear test window.

Should unclear firewall rules be deleted immediately?

No. Unclear productive rules should first be documented, logged and deactivated in a controlled manner. Only when the purpose, owner, hits and logs have been checked does removal make sense.