Document Sophos Firewall rules properly

Firewall rules quickly become confusing. At the beginning, every rule makes sense: a server needs internet access, a service is published, a VPN needs access, or an application needs specific ports. Months later, nobody remembers why the rule exists, who requested it, or whether it is still needed.

The simplest countermeasure is not a large CMDB, but a clean description directly in the Sophos Firewall rule. A few consistent details already help with troubleshooting, audits, clean-up work and handovers.

For the structure of a rule, Understanding and configuring Sophos Firewall rules correctly is the foundation article. After saving a rule, Testing Sophos Firewall rules with Log Viewer and Packet Capture is useful.

Why Rule Documentation Matters

A firewall rule is not only a technical permission. It is an operational decision: who may access what, through which service, with which risk and for which reason?

Without documentation, typical problems appear:

• Old rules remain active because nobody knows their purpose.
• Test rules are never removed.
• Audits take unnecessarily long.
• Incidents take longer because the application owner is unclear.
• Changes are made directly on the firewall but are not documented.
• Rules are not cleaned up because nobody wants to risk side effects.

A good description does not prevent all of these problems, but it noticeably reduces friction in daily operations.

Where To Enter The Description

The Description field is located directly in the firewall rule. Open the rule under:

Rules and policies > Firewall rules

Then edit the relevant rule and maintain the description field.

The field is limited. It should not replace the full technical documentation, but should make the most important operational information visible directly on the firewall. Details can remain in a ticket, wiki, change request or project folder.

What Belongs In A Rule Description

Source, destination, services, NAT and security features are already visible in the rule. The description should therefore not repeat everything, but explain what will otherwise not be obvious later.

Useful details:

• Purpose: Why does the rule exist?
• Application / service: Which application or process needs the rule?
• Owner: Who is responsible for it?
• Ticket / change: Where is the change documented?
• Creator / editor: Who created or changed the rule?
• Date: When was the rule created or last reviewed?
• Review: When should the rule be reviewed or removed?
• Special note: Intentional exception, deviation or risk.

Not every rule needs every field. A standard client rule often needs less. DNAT, VPN, management, partner access or temporary exceptions should be described more precisely.

Combining Name And Description

The rule name should be short and structured. The Description explains the context. There is no single perfect naming scheme for every company. What matters is that an administrator can roughly understand what the rule does by scanning the rule base without opening every rule.

In practice, three approaches work well:

• Source, destination, service: VLAN12_WAN_HTTPS. Good default for client, server and VPN rules.
• Application, source, destination: ERP_VPNUSERS_SRVERP_HTTPS. Useful when the application is more important than the network segment.
• Rule type as prefix: DNAT_WAN_SRVWEB01_HTTPS. Helpful for DNAT, drop rules, temporary rules or special cases.

We often use the pattern SOURCE_DESTINATION_PORT because it stays technical and remains readable months later. The action does not always need to be part of the name, because Sophos Firewall already shows Accept, Drop or Reject in the rule.

Typical examples:

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

Depending on the environment, the scheme can be extended slightly:

• ZONE_SOURCE_DESTINATION_PORT, for example LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, for example ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, for example CHG1842_VPNUSERS_SRVERP_HTTPS

For small environments, a simple pattern is often enough. In larger environments with many VLANs, VPNs, server networks and DNAT rules, a consistent standard becomes much more valuable. Prefixes such as DNAT, DROP or TEMP are useful when they help with quick scanning or indicate a special rule type.

Very generic names should generally be avoided because they are not useful later:

• Rule1
• Test
• Allow
• Internet
• Temp

Compact Example

Example of a production rule:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

If space is limited, the description can be shorter. The purpose, owner and ticket should still be visible:

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

For a temporary rule, the expiry date should be especially clear:

Temp vendor access for migration, Owner IT, CHG-1910, remove after 2026-07-31

What Should Not Be Written In The Description

The Description field should not contain:

• passwords,
• API keys,
• personal data without a reason,
• confidential customer data,
• full access instructions for third parties,
• long external URLs without internal context.

If external providers are involved, an internal contact person, ticket or documentation reference is usually enough. Sensitive details belong in a suitable ticketing or documentation system, not in a firewall rule.

Review And Clean-Up

Rule documentation is only the first step. The important part is reviewing rules regularly.

Practical process:

1. Mark rules without a Description.
2. Check rules with Test, Temp, Allow any or unclear names.
3. Review usage counters and Log Viewer.
4. Find the owner or ticket.
5. Disable rules that are no longer needed, monitor them and remove them later.
6. Document the change.

For every clean-up, Log firewall traffic should be enabled for relevant rules so that Log Viewer shows whether a rule is still used. For tests after changes, use Testing Sophos Firewall rules with Log Viewer and Packet Capture.

Minimum Standard For New Rules

New Sophos Firewall rules should have at least:

• a meaningful name,
• clear source and destination instead of unnecessary Any,
• logging enabled for important rules,
• a Description with purpose, owner and ticket,
• a review date for temporary or risky rules,
• no secrets in the description field,
• a test after saving.

For published servers, Publishing a server with DNAT on Sophos Firewall is also relevant. For NAT fundamentals, see Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

FAQ