Sophos Firewall Rule Not Matching: Check Causes

When a Sophos Firewall rule does not match, the first response should not be to move rules or expand objects. First, reproduce and observe a single data flow: Does the packet arrive, which Firewall Rule ID and NAT Rule ID process it, is it forwarded, and does a response return?

This usually reveals that a condition differs from what was expected, a more general rule above matches, or the problem occurs only after the rule decision. The firewall itself is the cause far less often than an imprecisely defined test.

Quick decision: If a correctly started and filtered Packet Capture shows no packet, first check the client, VLAN, gateway, or upstream path. A different Rule ID points to order and matching. If the Rule ID and NAT ID are correct, continue the analysis with routing, the return path, the destination system, or a security module.

Fast Track: Follow a Specific Flow

Six steps are sufficient for the initial isolation:

1. Define the test flow: Note the Source IP, Source zone, user, destination, protocol, port, and time.
2. Prove arrival: Start Packet Capture with a narrow capture filter and trigger the same flow.
3. Check the Firewall Rule ID: Compare it with the expected rule in Log Viewer or Packet Capture.
4. Check the NAT Rule ID: If NAT is involved, verify the actual NAT rule and its translation.
5. Check forwarding and response: Look for Forwarded, the outgoing interface, and return packets.
6. Only then go deeper: Investigate routing, SD-WAN, user matching, TLS Inspection, IPS, Web Policy, or the destination system.

This process keeps the layers separate. A firewall rule decides access and protection functions, NAT translates addresses or ports, routing selects the onward path, and the destination system must know the return path. If all layers are changed at once, the symptom may disappear, but the cause remains unclear.

If the test targets WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP, or another service on the firewall itself, the same rules as for transit traffic do not apply. In this case, the diagnostic path leads directly to Administration > Device access and the Local Service ACL.

Define a Reproducible Test Case

A statement such as “the internet does not work” or “the VPN rule does not match” is too broad. A useful test case looks like this, for example:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com or deliberately no user matching
• Destination: app.example.net, currently resolving to 203.0.113.20
• Service: TCP 443
• Expected firewall rule: LAN-App-HTTPS, Rule ID 37
• Expected NAT rule: NAT Rule ID 12 or explicitly no NAT rule
• Test time: 2026-08-08 10:15:00

The IP addresses, IDs, names, and time are example values and must be replaced with values from the actual environment. The format is what matters: the source, destination IP, port, and user remain the same during the diagnosis. If DNS resolution, client, or application changes in between, the same flow is no longer being compared.

Interpret the Initial Observations

• An active Packet Capture shows no packet despite a matching filter: First check the capture status, filter, and buffer. If they are correct, the cause is probably before the firewall, for example at the client, VLAN, switch, gateway, provider, or cloud Security Group.
• Log Viewer shows a different Rule ID: A more general, automatically generated, or otherwise matching rule is evaluated first.
• Firewall Rule ID is correct, NAT Rule ID is not: Check NAT order and the original source, destination, and service.
• Rule ID and NAT ID are correct, but no Forwarded is visible: Check the rule action, Reason, routing, or a security module.
• Forwarded is visible, but no response arrives: Check the return route, destination system, local server firewall, or external block.
• Only certain users are affected: Check authentication and user matching for the actual data flow separately.

The detailed combined process is described in Testing a Firewall Rule with Log Viewer, Policy Tester, and Packet Capture. This article focuses on explaining an unexpected rule match.

Check Rule Order and Matching

A firewall rule only matches when all relevant criteria fit and no earlier rule has already processed the same traffic.

The First Matching Rule Wins

Sophos Firewall evaluates rules from top to bottom and stops at the first matching rule. The position in the list is therefore decisive; the Rule ID is only a fixed identifier and does not correspond to the position.

Also note the following:

• A general rule above can completely shadow a specific rule below it.
• Rule Groups improve the overview but do not create their own matching logic. The rules they contain are evaluated.
• Automatically generated rules, for example for MTA, IPsec, or hotspots, can be inserted at the top and checked first.
• An active filter in the rule table can hide relevant rules. Use Reset filter before the analysis.
• The immutable default drop rule has Rule ID 0, is at the end, and has no regular usage counter. Table filters do not apply to it.

For a complete review of basic rule logic, see Understanding and Configuring Sophos Firewall Rules Correctly.

Read All Matching Criteria Together

A rule that looks correct can fail because of a single field:

• Source zones: The client comes from another zone, such as VPN instead of LAN, or the VLAN is assigned differently.
• Source networks and devices: The IP object, host group, or subnet does not contain the actual Source IP.
• Destination zones: The destination zone is wrong, especially with DNAT, VPN, or routed networks.
• Destination networks: The IP address actually contacted does not match the object, or the pre- and post-NAT views were confused.
• Services: The port is missing, TCP and UDP were mixed up, or the application opens additional connections.
• Users or groups: The firewall cannot map the user to the Source IP, or the imported group does not match.
• Schedule: The schedule is not active at the test time.
• Exclusions: The flow is excluded from the rule and then checked against subsequent rules.

For web traffic, the protocol is also part of the test. Browsers can use QUIC over UDP 443, while the expected rule or web inspection only covers classic HTTPS over TCP 443. Controlling QUIC on Sophos Firewall explains the effects.

Reset Transferred Data in a Controlled Manner

The Reset data transfer count menu item can help during testing but is often misinterpreted. It resets the volume of data transferred through the rule; it is not a session or hit counter.

1. Open Rules and policies > Firewall rules.
2. Find the affected rule and open the three-dot menu.
3. Select Reset data transfer count.
4. Trigger the defined test flow again.
5. Evaluate the data volume, Rule ID, and Packet Capture together.

If the value increases after the controlled test, this indicates traffic transferred through this rule. If it remains unchanged, that alone does not prove that the rule has never matched. For a reliable conclusion, check the actual Rule ID in Log Viewer and the packet path in Packet Capture. This data counter is not available for the default drop rule ID 0 anyway.

Read Log Viewer, Policy Tester, and Packet Capture Correctly

The tools answer different questions:

• Log Viewer: Which logged session, rule, NAT rule, action, and user were detected?
• Policy Tester: Which policy logic would match the entered values?
• Packet Capture: Which packets actually arrive, how does the firewall process them, and do they leave again?

None of the tools completely replaces the others. If the simulation and the actual packet flow contradict each other, log and packet data from the reproducible test carry more weight.

Log Viewer: Actual Rule ID and NAT Rule ID

Log firewall traffic must be enabled in the firewall rule. In addition, the appropriate log type for local display, Sophos Central, or syslog must be enabled under System services > Log settings.

Filters for the following fields are useful for the test:

• Source IP and Destination IP
• Port or service
• Rule ID and Rule name
• NAT rule ID
• Action and User
• the noted test time

A missing entry is not yet proof that the firewall saw nothing. Firewall sessions are logged, among other times, when the connection ends with a Destroy event. If a connection terminates abruptly, the expected entry may therefore be missing or appear later. Packet Capture then provides the more direct finding. The relevant services and log files are described in Sophos Firewall Troubleshooting: Services and Logs.

Policy Tester: Policy Logic Without Actual Packet Flow

Under Diagnostics > Tools > Policy tester, deliberately set the URL, user, time, Source IP, and Source zone. The protocol and port should be clear from the complete URL, for example https://app.example.net:8443/. Without a protocol, the tool tests HTTP; for HTTPS, port 443 is used by default, and a different port must be specified in the URL.

Policy Tester is useful but has clear limitations:

• It does not generate an actual packet flow and checks neither the destination system nor the return path.
• The results do not reflect SD-WAN routes.
• Rules with MAC addresses under Source networks and devices cannot be matched.
• Provider, switch, gateway, and packet loss problems remain invisible.

⚠️ On SFOS 22.0 GA Build 411, NC-177587 and NC-176083 could cause incorrect Policy Tester results. Traffic appeared blocked or matched through the wrong rule even though it flowed correctly in practice. MR1 Build 490 contains the documented fixes. If results conflict, first check the firmware version, Log Viewer, and Packet Capture before changing production rules.

Packet Capture: Check the Actual Packet Path

Under Diagnostics > Packet capture, first set a narrow BPF capture filter, for example for the Source IP, Destination IP, and port of the test flow. Then enable Trace On, clear the list, and trigger exactly the defined flow.

An empty Packet Capture is only meaningful when these requirements are met:

1. Trace On is active.
2. The BPF capture filter matches the actual destination and does not hide the flow.
3. The buffer has not already overwritten the relevant test traffic. Without Wrap capture buffer once full, recording stops when the 2048 KB buffer is full and continues after Clear. With the wrap option enabled, recording continues and overwrites the oldest packets.

An additional Display Filter does not change what was recorded but can hide existing entries. Therefore, check the capture filter and Display Filter separately.

The status values mean:

• Incoming: The packet was received on an interface.
• Forwarded: The firewall forwards the packet through an outgoing interface.
• Consumed: The packet is intended for the firewall itself or is used by it.
• Generated: The firewall generated the packet itself.
• Violation: A policy violation causes the drop; the Reason field explains the cause in more detail.

Always read Rule ID, NAT ID, Reason, and the incoming and outgoing interfaces together. Consumed and Generated are regular results and not automatically errors.

⚠️ On SFOS 22.0 MR1 Build 490, NC-178387 can show drops by default rule ID 0 only as Incoming. The expected Violation Firewall entry and the entry in drppkt are missing even though the firewall continues to drop the flow. For this affected version, Policy Tester or a deliberately placed, logged drop rule at the end of the custom rule list can help. The current Known Issues entry does not specify a fixed version.

A detailed capture process is described in Using Packet Capture in Sophos Firewall WebAdmin. Analyzing Dropped Packets on Sophos Firewall covers drops and a controlled final rule.

Check NAT, DNAT, Routing, and the Return Path

NAT does not allow traffic. It translates addresses or ports for traffic that a firewall rule permits. Therefore, the Firewall Rule ID and NAT Rule ID must match separately.

Evaluate Firewall Rule ID and NAT Rule ID Together

• Firewall Rule ID is correct, NAT Rule ID is wrong: Check NAT order, the Original fields, and more general NAT rules.
• NAT Rule ID is correct, Firewall Rule ID is wrong: Compare firewall order, zones, source, destination, service, and schedule.
• Both IDs are correct, but the connection fails: Check routing, return path, destination server, security module, or application.
• No NAT Rule ID is visible although NAT is expected: Check the direction, inbound/outbound interface, and the original criteria of the NAT rule.

Under Rules and policies > NAT rules, the first matching rule also wins. A general SNAT or MASQ rule can therefore shadow a specific rule below it. Linked NAT Rules are also only considered for traffic that matches their associated firewall rule; an earlier standalone NAT rule can still match first.

Understanding NAT on Sophos Firewall explains the complete ID logic.

Understand DNAT from the Pre- and Post-NAT View

An important rule of thumb applies to inbound DNAT traffic:

The firewall rule uses the destination zone after NAT, but the Destination Network uses the address originally contacted before NAT.

Example of port forwarding:

• The external client connects to 198.51.100.10 on TCP 8888.
• The NAT rule translates to server 10.10.50.20 in the DMZ zone and TCP 4444.
• In the NAT rule, TCP 8888 is the Original service, and TCP 4444 is the Translated service (PAT).
• The firewall rule uses WAN as the Source zone, DMZ as the Destination zone, and 198.51.100.10 as the Destination network.
• In the official Sophos PAT example, the associated firewall rule contains both the original and translated service.

The external test continues to target port 8888; the internal server receives the connection on port 4444. If only one of the two ports is considered, the rule can quickly appear correct even though service matching and translation do not fit together. A complete publication is described in Publishing a Server with DNAT on Sophos Firewall.

Establish a New Connection After NAT Changes

Sophos Firewall evaluates a NAT rule only for the first packet of a connection. Existing sessions continue to use the previous translation even if the NAT rule has since been changed.

After correcting NAT, establish a new connection: stop the current test, close the existing browser or application session, and start the flow again. A reload within the same TCP session does not reliably prove the new NAT configuration.

Investigate Routing Only After Confirming the Match

If the Rule ID and NAT Rule ID are correct and Packet Capture shows Forwarded, rule matching has been proven in principle. Then check:

• appropriate static route or default route
• SD-WAN route and active gateway
• actual outgoing interface
• route on the destination system and in remote networks
• symmetric return path through VPN, MPLS, or WAN
• local firewall on the destination server

Policy Tester does not reflect SD-WAN. The Gateway ID, interface, and packet path are decisive for the actual decision. Adjusting Routing Priority on Sophos Firewall explains the order of static, SD-WAN, and VPN routes.

Special Cases After the Initial Finding

Only after the basic flow has been classified is it useful to investigate local services, users, name resolution, or security modules in more depth.

Traffic to the Firewall Itself: Device Access Instead of a Firewall Rule

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS, and SNMP terminate on the firewall. Packet Capture can therefore show the status Consumed. Access is controlled under Administration > Device access and with Local Service ACL Exception Rules, not with a normal transit rule.

Check the zone, trusted source network, allowed service, user authorization, and MFA. Securing Sophos Firewall Device Access and Local Service ACL explains the security-relevant interaction; Overview of Sophos Firewall Portals classifies the different web interfaces.

Separate User Login and User Matching

A successful login to VPN Portal, User Portal, Captive Portal, or through Entra ID SSO initially confirms authentication only. For the planned user rule to match, the firewall must also map the user to the actual data flow and its Source IP.

Typical findings:

• The User field in Log Viewer is empty: Check STAS, AD SSO, Captive Portal, Entra ID SSO, or Clientless User. For a fixed device IP, set up and test Clientless Users shows the assignment, including the check in Live Users and the negative test.
• The user is visible, but another rule matches: Compare the rule position, group condition, or a more general rule above.
• Only VPN users are affected: Check the VPN zone, VPN pool, Source network, and group matching.
• Only individual users are affected: Compare the UPN, email address, imported directory group, and Sophos Firewall group.

For local AD environments, see Setting Up STAS on Sophos Firewall and Adding Active Directory to Sophos Firewall. Depending on the Entra login path, see Entra ID SSO for Sophos Connect and VPN Portal or Entra ID SSO for Captive Portal. With very many detected users or Clientless Users, the Sophos Firewall User ID Limit may also be relevant.

Check DNS, FQDN, CDN, and IPv6

For rule matching, the destination IP actually used is what counts, not just the entered hostname. DNS cache, Split DNS, CDN services, another resolver, additional API destinations, or IPv6 can direct the flow to another address.

The firewall resolves regular FQDN Hosts itself and updates the mapping based on the DNS TTL. Wildcard FQDNs work differently: the firewall learns IP addresses of matching subdomains from observed DNS responses. If the client uses an external resolver, its UDP DNS traffic on port 53 must pass through the firewall. If the firewall cannot see the relevant response, the subdomain IP may be missing from the wildcard object and the rule may not match even though the name looks correct.

In addition, FQDN Hosts do not support IPv6 resolution. Before expanding an object, compare the DNS response, destination IP, and IP version with Log Viewer or Packet Capture. Details on TTL, wildcards, and learning behavior are described in FQDN Hosts and Wildcard FQDNs on Sophos Firewall. For internal resolution, see DNS Request Routes; an active IPv6 environment needs its own matching rules and a deliberate IPv6 Concept.

Distinguish Security Modules and Traffic Shaping

If the Firewall Rule ID, NAT Rule ID, and routing are correct, a module assigned to the rule can affect the application:

• Web Policy and Application Control
• SSL/TLS inspection rule and Decryption Profile
• IPS Policy and Malware Scan
• Zero-Day Protection
• Security Heartbeat

Only one module is isolated for the specific flow and a short test period at a time. An exception remains limited to the source, destination, and service; afterward, restore the original protection or document the required exception. For HTTPS problems, see the controlled TLS Inspection Rollout.

Traffic Shaping, by contrast, is a QoS function. It guarantees, prioritizes, or limits bandwidth and can therefore cause low throughput, packet loss during congestion, or timeouts. This is not the same as the access decision Drop or Reject. For an actual block, check the Packet Capture status, Reason, and the responsible security module. For large transfers or VPN connections, include MTU and MSS in the analysis.

Test and Document Changes in a Controlled Manner

For rule problems, change only one variable per test:

1. Note the initial state with source, destination, service, user, time, Rule ID, and NAT ID.
2. Change exactly one rule position, object, service, or module.
3. For NAT, establish a new connection; otherwise, trigger the same test flow again.
4. Compare Log Viewer and Packet Capture with the same filters.
5. Document success or failure, and only then check the next change.

Temporary allow, drop, or exception rules receive a meaningful name, an owner, and an expiration date. Otherwise, a short-term diagnostic aid can quickly remain permanently in the rule set.

If the connection still worked yesterday, the most recent configuration changes should also be checked. Audit Trail Logs show who changed rules or objects. Config Studio helps compare larger configurations. If the change came from Sophos Central, also check the Central Firewall Task Queue.

Checklist for Rule Troubleshooting

• A specific test flow with source, destination, service, user, and time has been defined.
• It has been determined whether the traffic is transit traffic or a local firewall service.
• Rule position, automatic rules, and hidden table filters have been checked.
• All matching fields have been compared with the actual flow.
• Data volume has only been used as an indication, not as a hit counter.
• Log Viewer shows the actual Firewall Rule ID and, if applicable, NAT Rule ID.
• The Policy Tester result has been compared with the firmware version and actual packet data.
• Packet Capture is running with a matching capture filter and available buffer space.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason, and interfaces have been interpreted correctly.
• For DNAT, the destination zone after NAT, Destination Network before NAT, and both PAT services have been checked.
• A new connection has been established after NAT changes.
• The DNS response, destination IP, FQDN learning behavior, and IP version have been checked.
• User login and user matching for the data flow have been checked separately.
• Routing, SD-WAN, gateway, and return path have only been investigated after confirming the rule match.
• Security modules have been checked individually and Traffic Shaping as QoS.
• Every change has been documented; test rules have an owner and an expiration date.

FAQ