Skip to content
Avanet

Sophos Firewall Rule Not Matching: Check Causes

Sophos Firewall

If a firewall rule is not matching, it is rarely because the firewall is “broken.” Usually, a condition does not fit, a more general rule is above it, NAT changes the view of the traffic, user matching is not fulfilled, or logging is not properly activated.

This checklist helps to proceed systematically instead of randomly tweaking rules.

Orientation

Start with a clear test case before changing rules or security features.

Which Article Fits?

Rule issues quickly overlap with NAT, routing, VPN, Device Access, or security features. For analysis, it should first be clear which level is affected:

This separation is important because a firewall rule does not control every type of access. Local services of the firewall, NAT decisions, routing, and security features have their own checkpoints.

Quick Narrowing

At the beginning, you should not immediately move rules or change objects. First, narrow down where the traffic is lost.

  • Rule counter remains 0: Rule position, zone, source, destination, service, or schedule does not fit
  • Log Viewer shows a different rule: A more general or automatically generated rule is higher up
  • Log Viewer shows nothing: Logging is missing or the traffic does not reach the firewall
  • Packet Capture sees no packet: Problem is before the firewall: client, VLAN, switch, gateway, provider, or cloud security group
  • Packet Capture sees packets but no forward: Firewall rule, NAT, routing, or security feature blocks
  • Packet Capture sees forward but no response: Check return route, target system, NAT, or external firewall

This separation saves time. If the firewall does not see a packet, no change to a firewall rule will help. If the Log Viewer shows a different Rule ID, the order is more important than the affected target rule. If packet flow and Rule ID are correct, the analysis shifts to NAT, return path, or security features.

Define Test Case Clearly

A rule can only be meaningfully tested if the test case is clear. Statements like “Internet doesn’t work” or “VPN doesn’t work” are too broad. For troubleshooting, a specific flow is needed.

Before the test, it should be clear:

  • Source IP: Client 10.10.20.35
  • Source zone: LAN, VPN, DMZ, or custom zone
  • User: Authenticated user or no user matching
  • Destination: Server IP, FQDN, public IP, or WAN object
  • Service: TCP 443, UDP 53, ICMP, custom service
  • Expected rule: Rule name or Rule ID, if known
  • Expected NAT rule: NAT Rule ID or rule name, if NAT is involved
  • Test time: Exact time for Log Viewer and later log files

Then the same test is repeated. If during the analysis the source IP, destination, DNS resolution, or port changes, you are no longer comparing the same case.

Combine Analysis Tools Correctly

Sophos Firewall offers several tools that answer different questions. None of them alone is complete proof.

  • Rule counter: Does the new test traffic fundamentally hit the rule? Does not show why an application still fails
  • Log Viewer: Which Rule ID, NAT Rule ID, action, user, or security function was logged? Depends on logging and session end
  • Policy Tester: Which policy logic would apply for a defined flow? Does not replace real packet flow and does not fully map SD-WAN
  • Packet Capture: Do packets arrive, are they forwarded or dropped? Does not explain every application layer and needs tight filters
  • Service logs: Does a module like Web, IPS, Authentication, or VPN have its own problem? Only useful when the affected service is narrowed down

For a reliable finding, combine at least Log Viewer and a real test. In case of contradictory results, Packet Capture is usually the next step because it shows whether packets actually arrive and continue.

Decision Tree for the First Test

For the first analysis, a short decision tree is often sufficient. It prevents working on rules, NAT, and routing simultaneously right away.

  • Packet Capture sees no packet: Check client, VLAN, switch, gateway, provider, cloud security group, or upstream firewall
  • Packet Capture sees packet, Log Viewer remains empty: Check logging, log type, session end, and appropriate BPF filter
  • Log Viewer shows different Rule ID: Compare rule order, zones, source, destination, service, and schedule
  • Firewall Rule ID matches, NAT Rule ID does not: Check NAT order and Original fields
  • Rule ID and NAT ID match, but no response comes back: Check return route, target system, local firewall on the server, or external block
  • Rule only matches for certain users: Check user matching, group, authentication, and clientless user

This keeps the analysis controlled: First, prove whether the traffic reaches the firewall. Then check which rule and which NAT rule actually apply. Only when these two points are correct does it make sense to search for return path, security features, or application layer.

Understanding Rule Matching

Sophos Firewall processes rules in order. The first suitable rule wins.

First Principle: The First Matching Rule Wins

Sophos Firewall processes firewall rules from top to bottom. As soon as a rule matches, subsequent rules are no longer checked. The same basic principle also applies to NAT rules.

Important:

  • The position in the list determines the evaluation.
  • The Rule ID is only a reference and says nothing about the current order.
  • Rule groups help with the overview but are not their own match logic.
  • A general rule above can completely “swallow” a specific rule below.

If a rule is not matching, check the position first.

Sophos Firewall Firewall rules with marked rule order
The position in the firewall rule list determines the evaluation. The first matching rule wins, not the lowest Rule ID.

Reset Rule Counter

In case of unclear hits, it helps to reset the rule counter.

  1. Open Rules and policies > Firewall rules.
  2. Find the affected rule.
  3. Open the three-dot menu.
  4. Select Reset data transfer count.
  5. Reproduce the traffic.
  6. Check the counter after the test.
Sophos Firewall three-dot menu with Reset data transfer count
Resetting the data transfer count helps to see if the new test traffic really lands on this rule.

If the counter does not increase, the rule is not matching. If it increases but the application still does not work, the problem is more likely with security profiles, NAT, routing, return path, or target system.

Check Matching Fields

A firewall rule only matches if all relevant criteria fit.

  • Source zones: Wrong zone, VLAN is in another zone, VPN traffic comes from VPN
  • Source networks and devices: Wrong object, wrong IP, host group incomplete
  • Destination zones: Wrong destination zone, especially with DNAT or VPN
  • Destination networks: Pre-NAT and post-NAT view confused
  • Services: Port missing, TCP/UDP confused, application uses additional ports
  • Users or groups: User is not authenticated or wrong group
  • Schedule: Schedule does not currently fit
  • Exclusions: Traffic is excluded from the rule and processed further below
Sophos Firewall Firewall rule with Source, Destination and services
A firewall rule only matches if Source zone, Source networks and devices, Destination zones, Destination networks, Services, and Schedule all fit simultaneously.

For web traffic, you should also check if QUIC is active. If browsers send traffic over UDP 443, some web filter and scanning expectations apply differently than with classic HTTPS over TCP.

More on this: Sophos Firewall and the QUIC Protocol.

Do Not Overlook DNS, FQDN, and IPv6

A rule can look correct and still not match if the client reaches a different target than expected. This often happens with FQDN objects, split DNS, CDN services, IPv6, or applications that use multiple targets in parallel.

Before changing rules, you should check:

  • Which IP does the client actually resolve?: DNS cache, split DNS, or another resolver can deliver a different address than expected.
  • Is it IPv4 or IPv6?: IPv4 rules do not match IPv6 traffic. If clients prefer IPv6, the IPv6 side must be checked separately.
  • Is an FQDN host used in the firewall?: The firewall must resolve the FQDN and know the current target IP. CDN or cloud services can deliver multiple changing IPs.
  • Does the application use additional targets?: Login, API, updates, telemetry, or media paths can use different domains and ports than the main application.
  • Does an internal client use the public name of an internal service?: Then split DNS, loopback NAT, or incorrect public resolution are possible causes.

For troubleshooting, it is crucial not only to note the hostname but to compare the actually used target IP in the Log Viewer or Packet Capture. If a rule points to a specific FQDN or host object, but the client uses a different IP, the rule will not match.

For internal name resolutions, clean DNS request routes help. The procedure is described in Set Up DNS Request Routes on Sophos Firewall. If IPv6 is active in the environment, you should also check whether IPv6 is consciously planned and the appropriate policy is in place. Basics on this are in Set Up IPv6 Prefix Delegation on Sophos Firewall.

A common special case is FQDN objects. If clients prefer IPv6, but a rule only uses IPv4 objects or an FQDN host with IPv4 resolution, the actual IPv6 flow will not match. The rule then looks technically correct, but it does not process the traffic that is actually on the wire. In such cases, DNS answer, IP version, and policy should be checked separately.

Traffic to the Firewall Itself Is a Special Case

Not every access to a Sophos Firewall is controlled by normal firewall rules. If the client is to reach the firewall itself, for example, WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS, or SNMP, Device Access and Local service ACL are crucial.

Typical examples:

  • WebAdmin from LAN or WAN: Device Access, Local service ACL, MFA, admin permission
  • VPN Portal or User Portal: Device Access, portal configuration, user permission
  • SSH to the firewall: Device Access, Local service ACL, admin rights, source network
  • SSL VPN or IPsec dial-in: Device Access for the appropriate zone, VPN configuration, authentication
  • DNS to the firewall: Device Access, DNS configuration, request path
  • SNMP to the firewall: Device Access, SNMP configuration, monitoring source

If a firewall rule does not match for such traffic, it is often not a rule error. The traffic ends on the firewall and is treated as a local service. For hardening these services, Secure Sophos Firewall Access: Properly Configure Device Access is the central article. For portals, additionally, Overview of Sophos Portals fits.

Check NAT, DNAT and IDs

For DNAT traffic, firewall rules and NAT rules must be read together.

Read DNAT Correctly

With DNAT, the view in firewall rules is particularly important. As a rule of thumb, remember:

Firewall rules for DNAT traffic use the destination zone after NAT, but the destination IP before NAT.

Example:

  • External client connects to the WAN IP of the firewall.
  • NAT translates to an internal server in the DMZ.
  • The firewall rule uses the destination zone of the internal server, such as DMZ.
  • The destination network remains the public IP or WAN object that the client addressed.

If this combination is wrong, the NAT rule may look correct, but the firewall rule still does not match.

More on this: Publish Server via DNAT on Sophos Firewall.

Check NAT Rules

NAT does not allow traffic. NAT only translates. It always needs an additional matching firewall rule.

Under Rules and policies > NAT rules, you should check:

  • Is the appropriate NAT rule above more general NAT rules?
  • Is the rule active?
  • Do original source, destination, and service match?
  • Do translated source, destination, and service match?
  • Is MASQ or a fixed SNAT IP used?
  • Is there a linked NAT rule that unexpectedly applies?
  • Is there a generic SNAT rule that matches before a more specific rule?

Sophos generally recommends standalone NAT rules for simple environments instead of creating a linked NAT rule per firewall rule.

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

Read Firewall Rule ID and NAT Rule ID Together

When NAT is involved, the question “Which firewall rule applies?” is not enough. A connection can hit the expected firewall Rule ID but still run over a wrong NAT Rule ID. Conversely, a NAT rule can look correct while a more general firewall rule above already processes the traffic.

For the test, you should note in advance:

  • Expected Firewall Rule ID: Shows whether the correct firewall rule allows or blocks the traffic
  • Expected NAT Rule ID: Shows whether the correct SNAT, DNAT, MASQ, or PAT rule translates
  • Actual IDs in Log Viewer: Proves whether the firewall processes the flow as planned
  • IDs in Packet Capture: Helps if the Log Viewer seems incomplete or the return path is unclear

The interpretation is relatively simple but saves a lot of search time:

  • Firewall Rule ID matches, NAT Rule ID is wrong: Check NAT order, Original fields, and more general NAT rules
  • NAT Rule ID matches, Firewall Rule ID is wrong: Check firewall rule order, zones, source, destination, and service
  • Both IDs match, connection still fails: Check return path, target server, security feature, or application
  • No NAT Rule ID visible, although NAT is expected: Recheck test flow, NAT criteria, direction, and logging

It is important not to immediately rebuild both rule sets simultaneously. First, decide whether the problem lies in firewall matching or NAT matching. Only then should you change a specific rule position, object, or field. The more detailed NAT evaluation is in the section Read Firewall Rule ID and NAT Rule ID Correctly.

Check Users, Routing and Security Features

User matching, routing, NAT, logging and security profiles can all affect whether a rule applies.

Check User Matching and Authentication

Rules with user or group matching often look correct but only apply if the firewall can actually assign the user to the traffic at that moment.

To check:

  • Is the user visible in the Log Viewer?
  • Does the traffic come from the expected device or another client?
  • Is the user in the correct firewall group?
  • Does AD SSO, STAS, Captive Portal, RADIUS, or Entra ID SSO work?
  • Does a rule without user matching apply above the planned user rule?
  • Are there clientless users that are treated differently?
  • Is MFA or portal access successful, but the firewall rule for the actual user traffic wrong?

For remote access, you should separate user problems and VPN problems. A user can log in successfully but still not reach an internal application if the VPN pool, firewall rule, NAT, or routing does not fit. For AD basics, Add Active Directory on Sophos Firewall fits, for Entra-based remote access scenarios Microsoft Entra ID SSO for Sophos Connect and VPN Portal. If the user is logged in via Captive Portal with Entra ID SSO, Set Up Microsoft Entra ID SSO for Sophos Firewall Captive Portal fits.

Separate User Login and Rule Matching

A successful login at the VPN Portal, User Portal, Captive Portal, or via Microsoft Entra ID SSO does not yet prove that the planned user rule matches the actual traffic. The login first only confirms authentication. Then the firewall must correctly combine the user, source IP, group, and traffic flow.

For analysis, you should separately check:

  • User logs in, rule counter remains 0: Check VPN pool, source zone, source network, group condition, or rule position
  • User field in Log Viewer is empty: Check STAS, Captive Portal, AD SSO, Entra ID SSO, or clientless user
  • User is visible, but wrong rule applies: Check rule order, group filter, or more general rule above
  • Only VPN users are affected: Check zone VPN, VPN pool, SSL/IPsec configuration, and Sophos Connect profile
  • Only individual users are affected: Compare UPN, email address, imported group, and firewall group

In local AD environments, STAS and Add Active Directory on Sophos Firewall help. In Entra-based setups, depending on the login path, Microsoft Entra ID SSO for Sophos Connect and VPN Portal or Entra ID SSO for Captive Portal should be checked. If many users or clientless users are involved, the Sophos Firewall User-ID Limit may also become relevant.

Check Routing and SD-WAN

If the rule matches but the connection does not work, routing may be the problem.

Check:

  • Is there a suitable default route?
  • Is there a static route?
  • Does an SD-WAN route apply?
  • Is the gateway active?
  • Are there return routes on the target system or in the remote network?
  • Is the return path symmetrical?
  • Does traffic go over VPN, MPLS, or another interface than expected?

Important: The Policy Tester does not fully map SD-WAN routing. It is very helpful for firewall, SSL/TLS, and web policy decisions but does not replace a real packet flow test.

More on this: Adjust Routing Priority on Sophos Firewall.

Enable Logging

Without logs, troubleshooting becomes tedious. Check two places:

  1. In the firewall rule, Log firewall traffic must be enabled.
  2. Under System services > Log settings, the appropriate log type must be enabled locally, for Sophos Central, or for Syslog.

The Log Viewer typically shows firewall sessions when the firewall ends a connection and receives a Destroy event. If an internet connection simply drops, it may be that not every session appears as expected.

Open the Log Viewer at the top right in the WebAdmin console. Useful filters are:

  • Source IP
  • Destination IP
  • Port or service
  • Rule ID
  • Rule name
  • Action
  • User
  • NAT rule ID
Sophos Firewall Log Viewer with Firewall rule ID and NAT rule ID
In the Log Viewer, you can see which Firewall Rule ID and NAT Rule ID processed the traffic. This is often faster than just searching by rule name or IP address.

More on this: Sophos Firewall Troubleshooting: Services and Logs.

Use Packet Capture

If Log Viewer and rule counter are not enough, use Diagnostics > Packet capture.

The most important question is whether the packet arrives, is forwarded, or already gets stuck on the firewall.

Sophos Firewall Packet Capture with BPF Filter, NAT ID, and Rule ID
Packet Capture shows whether packets arrive, which interface they run over, and which NAT ID or Rule ID is visible. The BPF filter keeps the output small and readable.
  • No packet arrives: Problem is before the firewall: client, switch, VLAN, gateway, provider, cloud security group
  • Packet comes in but does not go out: Check firewall rule, NAT, routing, or security feature
  • Packet goes out but no response comes back: Check return route, target system, NAT, or external block
  • Packet is shown with Violation: Policy or security feature blocks
  • Packet shows NAT ID and Rule ID: Compare rule and NAT hits specifically

More on this: Use Packet Capture Tool in WebAdmin.

Do Not Change Multiple Things at Once

With rule problems, it is tempting to adjust position, service, NAT, web policy, and routing simultaneously. This sometimes temporarily solves access but makes the cause difficult to trace later.

Better is a step-by-step approach:

  1. Note the initial state: Rule ID, NAT ID, source, destination, service, time.
  2. Make exactly one change.
  3. Repeat the test with the same source IP and destination.
  4. Compare Log Viewer and Packet Capture again.
  5. Document the result.
  6. Only then check the next change.

For productive rules, it should also be clear whether a change is permanent or only serves as a test rule. Temporary rules should have an owner and an expiration date, otherwise, they often remain in the rule set for years.

Check Security Features Individually

If the rule matches but the application does not work, a protection profile may intervene:

  • Web Policy
  • SSL/TLS inspection rule
  • Decryption Profile
  • IPS Policy
  • Application Control
  • Malware Scan
  • Zero-day protection
  • Security Heartbeat
  • Traffic Shaping

For tests, you cannot disable everything permanently. It is better to briefly check specifically, observe the Log Viewer, and then cleanly fix the cause. For TLS Inspection, the article Roll Out TLS Inspection on Sophos Firewall Step by Step helps.

For productive rules, you should not consider security features as a collective block. It is better to narrow down one module after another:

  • Web category or URL is blocked: Check web policy, category, exception, and Log Viewer
  • Application is misidentified: Check application control and IPS log
  • HTTPS page only loads without inspection: Check SSL/TLS inspection rule, CA distribution, decryption profile, and exceptions
  • Connection breaks with large data: Check MTU/MSS, VPN path, fragmentation, and Packet Capture
  • Hits in IPS or Zero-day Protection: Evaluate signature, policy, target system, and false-positive risk
  • Only individual users affected: Check user matching, security heartbeat, group, and authentication

If a protection profile is removed for a test, the change should be narrowly limited: only the affected source, only the specific target, only for the test period. Then restore the original protection effect or document a targeted exception.

Check Change History

If a rule worked yesterday and no longer works today, do not only check the current rule content. Often an object, rule position, NAT rule, group, service, or Central policy was changed shortly before.

Practical checks:

  • Was the firewall rule itself changed?: Audit Trail, Config Studio, rule description
  • Was a referenced object changed?: Hosts and services, Audit Trail, Config Studio
  • Was the rule position moved?: Firewall rule list, Audit Trail
  • Was a Central policy pushed?: Sophos Central Task Queue and local firewall view
  • Was a NAT rule or SD-WAN route changed?: NAT rules, routing, Audit Trail, Packet Capture

For traceability, Check Sophos Firewall Audit Trail Logs and Use Sophos Firewall Config Studio fit. If the change comes from Sophos Central, also check the Sophos Central Firewall Management Task Queue.

Practical Process and Typical Causes

Most rule-matching problems can be narrowed down quickly with a fixed troubleshooting sequence.

Common Causes

  • Rule counter remains 0: Rule position, source zone, destination zone, or service wrong
  • Log shows different rule: More general rule is above
  • No log visible: Logging not active or traffic does not reach the firewall
  • DNS works, web does not: Check service, web policy, TLS inspection, or QUIC
  • Hostname fits, but target IP is different: Check DNS, FQDN object, split DNS, CDN, or IPv6
  • HTTPS is not scanned: No suitable SSL/TLS inspection rule or CA not distributed
  • DNAT does not work: Firewall rule uses wrong destination zone or wrong destination network
  • VPN traffic does not match: Check zone VPN, route, tunnel interface, or XFRM context
  • Only some users affected: Check user matching, group, SSO, captive portal, or heartbeat

Practical Procedure

  1. Note problem with source IP, destination, port, user, and time.
  2. Check rule position.
  3. Reset rule counter.
  4. Reproduce test.
  5. Filter Log Viewer with source IP and destination IP.
  6. Check NAT rule and routing.
  7. Start Packet Capture with a tight filter.
  8. Only check security profile specifically.
  9. Document change.

For a combined test procedure, see Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture.

Checklist for Rule Troubleshooting

  • Defined specific test case with source, destination, service, user, and time.
  • Checked rule position and reset rule counter for the test.
  • Log Viewer shows the expected Rule ID or a comprehensible other rule.
  • DNS resolution, actual target IP, and IP version were matched with the test case.
  • For DNAT, destination zone after NAT and destination network before NAT are correctly set.
  • NAT Rule ID was checked if NAT is involved.
  • Traffic to the firewall itself was separated from traffic through the firewall.
  • User matching was only evaluated if the user is visible in the Log Viewer.
  • For user rules, login, user assignment, and actual rule decision were evaluated separately.
  • Routing, SD-WAN, gateway, and return path were checked.
  • Packet Capture shows Incoming, Forwarded, Violation, or missing response comprehensibly.
  • Security features were checked individually and not permanently disabled.
  • Test changes are documented, and temporary rules have an owner and expiration date.

FAQ

Why is a Sophos Firewall rule not matching?

Usually, at least one matching criterion does not fit: rule position, source zone, destination zone, source object, target object, service, schedule, user matching, or NAT context. First, check Log Viewer, Rule ID, and Packet Capture.

Why does the Log Viewer show a different rule than expected?

Then a more general rule is probably higher up, or the traffic looks different from the firewall’s perspective than expected. Rule position, zones, NAT, and source/destination fields are then more important than the rule name.

Why is there no log entry visible?

Either Log firewall traffic is not active in the rule, the appropriate log type is disabled, or the traffic does not reach the firewall. Packet Capture helps to distinguish whether the packet arrives at all.

Do firewall rules also apply to WebAdmin, SSH, or VPN Portal?

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

Why does DNAT not work even though the NAT rule is correct?

Often the appropriate firewall rule is incorrectly built. With DNAT, the firewall rule uses the destination zone after NAT but the destination network before NAT. Additionally, NAT order, logging, and return path must fit.

Is the Policy Tester proof of real traffic?

No. The Policy Tester is helpful for policy logic but not a real packet flow test. Routing, SD-WAN, return path, provider behavior, and target systems must be checked with Log Viewer and Packet Capture.

Why does a user rule not match even though the VPN login works?

The VPN login only proves that authentication works. For the firewall rule, source zone, VPN pool, user assignment, group, service, target, and rule position must also fit. In the Log Viewer, it should be checked whether the user is really visible in the affected traffic and which Rule ID processes the flow.

Why does a rule with an FQDN target not match?

Often the client uses a different target IP than expected. Causes are DNS cache, split DNS, CDN addresses, another resolver, or IPv6. In the Log Viewer or Packet Capture, the actually used target IP should be compared with the FQDN or host object of the rule.