Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT

NAT is one of the topics on the Sophos Firewall that quickly becomes confusing in practice. The terms sound similar, the rule mask works with Original and Translated, and in the Log Viewer you see different addresses than expected depending on the location.

This article explains the most important NAT types, shows typical practical cases and describes a DNAT example with a suitable firewall rule.

The most important practical point is: NAT must be considered together with firewall rule, routing, return path and logging. Many NAT problems arise not from the translation itself, but from incorrect rule order, a misunderstood Original destination, missing logging or tests from the wrong network.

Orientation

Before building a NAT rule, it should first be clear which problem is really being solved. NAT translates addresses or ports, but does not replace firewall clearance and clean routing design.

Which NAT item fits?

NAT quickly overlaps with firewall rules, routing, WAF, VPN and Packet Capture. Depending on the task, this basic article is not always the best way to start:

• Understand NAT, SNAT, DNAT, MASQ, PAT, loopback and reflexive rules: This article.
• Publish an internal server via port forwarding: Publish server via DNAT on Sophos Firewall.
• Publish an HTTP or HTTPS application publicly: Sophos Firewall WAF: publish web server securely.
• Classify firewall rules and NAT together: Understand and configure Sophos Firewall rules securely.
• Test an individual connection with logs and Packet Capture: Test firewall rule with Log Viewer, Policy Test and Packet Capture.
• Check NAT for IPsec, XFRM, SD-WAN or overlapping networks: Sophos Firewall IPsec VPN troubleshooting.
• Analyse drops, Violation, Rule ID or NAT Rule ID: Analyse Sophos Firewall dropped packets.

This keeps troubleshooting tighter: first clarify whether it’s about translation, release, routing, web server protection or packet flow. After that, only the affected layer should be changed.

NAT is translation, not release

Network Address Translation changes addresses or ports of a packet as it passes through the Sophos Firewall. However, NAT does not alone decide whether traffic is allowed.

⚠️ A NAT rule does not allow traffic. The rule only translates addresses or ports. A suitable firewall rule is also always required for traffic through the firewall.

Typical NAT cases:

• Internal clients access the Internet via the public WAN-IP.
• An internal server is published via a public IP.
• A public port is translated to another internal port.
• Overlapping networks are translated for VPN connections.
• Internal clients access an internal server via the public DNS name.

Quick decision: NAT or no NAT?

Many NAT errors arise because NAT is used as the default solution, even though routing or a firewall rule would be sufficient. Before each new NAT rule, you should first decide whether an address or a port really needs to be changed.

• Client from the LAN should access the Internet normally: A general SNAT or MASQ rule is usually sufficient.
• Internal server should be accessible from the Internet: Use DNAT or for HTTP/HTTPS check WAF first.
• A different port should be used externally than internally: Plan DNAT with PAT and add the appropriate firewall rule.
• Internal users access the same public FQDN: Check split DNS first, use loopback NAT only if necessary.
• Local and remote VPN networks are clear: Usually don’t use NAT, but build routing and firewall rules cleanly.
• VPN networks overlap or the remote station requires a specific source: Use targeted SNAT or DNAT with documented replacement network.
• Only one firewall rule should be allowed or restricted: Do not build NAT. Adjust the firewall rule.

If the answer to “What should be translated?” is not clear, a NAT rule should not be created. Then first check the packet flow, destination address, return path and Log Viewer. Especially for internal VLANs, site-to-site VPNs without overlapping networks and routed server networks, no NAT is often the cleaner solution.

Understand NAT basics

The rule mask becomes much easier if you first differentiate between original traffic and translated traffic. It will then be clearer whether the source, destination or service needs to be changed.

The main NAT species

• SNAT: Translates the source IP. Typically when internal clients or servers are supposed to access the Internet with a specific public IP.
• MASQ: Translates the source IP to the IP of the outgoing interface. This is the standard case for LAN to WAN.
• DNAT: Translates the destination IP. This makes an internal server accessible via a public IP.
• PAT: Translates port or service. This means that an external port points to another internal port.
• Loopback NAT: Allows internal access via public IP or public FQDN. Internal clients use the same DNS name as external users.
• Reflexive Rule: Creates a reflective source NAT rule. This allows a published server to appear to outgoing traffic with an appropriate public identity.

As a mental model it helps: NAT does not answer the question “Is this traffic allowed?”, but rather “What should the address or port look like on the way?”

Read the original and translated correctly

In NAT rules, Original describes the traffic as it arrives at the Sophos Firewall. Translated describes it after translation.

• Original source: Source address before NAT.
• Translated source (SNAT): Source address to NAT.
• Original destination: Target address before NAT.
• Translated destination (DNAT): Target address after NAT.
• Original service: Service or port before NAT.
• Interfaces and VPNs: Any is often correct for inbound and outbound interfaces in DNAT or VPN scenarios because VPN tunnels are not always handled like normal physical interfaces.
• Translated service (PAT): Service or port to NAT.

If there are errors, you should first note what the package looks like before NAT. Then you define what the firewall should do with it.

Schedule NAT before change

Before making a NAT change, you should not only look at the NAT rule itself. The entire packet flow is crucial: Where does the packet arrive, which firewall rule allows the traffic, which NAT rule translates it, where does the response go and how is the result checked?

These points should be clear before the change:

• Package before NAT: Source, Destination and Service must match the Original side of the NAT rule.
• Package according to NAT: Translated source, Translated destination and Translated service must be set deliberately.
• Permitting firewall rule: NAT does not allow traffic. Without a suitable firewall rule, the translation remains ineffective.
• More general NAT rules: The first matching NAT rule wins. A broad SNAT or MASQ rule can obscure more specific rules.
• Return path: Many NAT problems are actually routing, return path or destination system problems.
• Test Method: Log Viewer, Rule ID, NAT Rule ID and Packet Capture should be prepared before testing.

Understanding and safely configuring Sophos Firewall rules helps you find the right firewall rule. If it is unclear whether the rule applies at all, Sophos Firewall Rule does not apply: Check causes is the better troubleshooting start.

Practical examples: When do you use what?

• Clients from the LAN should access the Internet: MASQ or SNAT. Example: 10.10.10.80 goes outside with the WAN-IP firewall.
• Internal web server should be accessible from external: DNAT. Example: The public WAN-IP points to 172.16.16.10.
• A different port is used externally than internally: PAT. Example: External TCP 5555, internal TCP 443.
• Internal users use the same FQDN as external users: Loopback NAT. Example: service.example.com points to the same service internally and externally.
• Published server should appear outgoing with specific public IP: SNAT or Reflexive Rule. Example: A mail server sends with defined public IP.
• VPN networks overlap: SNAT or DNAT. Example: Site A sees Site B via a translated network.
• Internal traffic should remain unchanged: No NAT. Routing and firewall rules are sufficient.

Not all traffic needs NAT. Between internal VLANs, over site-to-site VPNs without overlapping networks or to directly routed networks, NAT is often even harmful because logs, remote stations and target systems lose the real source IP. Good NAT planning therefore first decides whether translation needs to be done at all.

NAT species in practice

The following NAT types solve different tasks. In productive environments, one should consciously select which translation is necessary instead of using NAT as a general workaround for routing problems.

SNAT: Source NAT

SNAT changes the source address. The classic case is outgoing Internet access from the LAN. The clients internally retain their internal IP addresses, but the public address of the firewall or a defined public IP appears externally.

Typical SNAT rule for LAN to WAN:

• Original source: internal LAN or server network.
• Translated source (SNAT): MASQ or fixed public IP.
• Original destination: Any.
• Translated destination (DNAT): Original.
• Original service: Any or defined Services.
• Translated service (PAT): Original.
• Inbound interface: internal interface or Any.
• Outbound interface: WAN interface. For simple environments, a generic SNAT rule is often clearer than many individual linked NAT rules.

MASQ: Masquerading

MASQ is a convenient SNAT variant. By default, MASQ translates the source address to the IP address of the outgoing interface. For normal internet access this is usually the WAN-IP.

In the basic configuration, the Sophos Firewall has a default SNAT rule with MASQ. If you don’t want to use this rule, deactivating is usually cleaner than deleting. Otherwise, the default rule may reappear when creating or updating a WAN interface.

Stumbling block: With route-based VPNs, MASQ may look different than expected. If local and remote subnets are set to Any or dual IP configurations are used, the firewall can use the XFRM-IP as the translated source. In Packet Capture or tcpdump you can then see the WAN-IP in the outer header and the XFRM-IP in the inner context. Other stumbling blocks apply to policy-based IPsec. If translated traffic needs to be assigned to a specific IPsec tunnel, IPsec Routes and the Outbound interface setting in SNAT rules can be critical. The process is in IPsec Create route on Sophos Firewall.

NAT on VPN, SD-WAN and overlapping networks

NAT quickly becomes more complex in VPN and SD-WAN environments than simple LAN to WAN traffic. The most important principle remains the same: First, the expected path must be clear. You then decide whether NAT is necessary.

Typical scenarios:

• Site-to-site VPN with unique networks: Mostly no NAT, but clean firewall rules and routing.
• Site-to-site VPN with overlapping networks: Targeted SNAT or DNAT rule with documented backup network.
• Route-based VPN with XFRM and SD-WAN: Check XFRM interface, route, SD-WAN route and NAT together.
• Policy-based IPsec with translated traffic: Check IPsec route and SNAT rule with matching Outbound interface.
• Remote Access VPN to internal networks: Normally no NAT, unless a target system expects a specific source.

For overlapping networks, NAT should not be improvised. Both sides need to know which real network is behind which translated network. Otherwise, individual tests work, but applications, DNS, logging or access rules become difficult to understand later. If a VPN tunnel is green but no useful traffic is flowing, NAT is only one of several possible causes. IPsec status, route lookup, firewall rule, SD-WAN route and Packet Capture should then be checked in parallel. For a structured process, use Sophos Firewall IPsec VPN troubleshooting, SD-WAN routing for Reply Packets and System Traffic and check MTU and MSS on Sophos Firewall for VPN problems.

DNAT: Destination NAT

DNAT changes the destination address. For example, you can publish an internal server via a public IP or a public port. Incoming traffic to the WAN address is translated to the internal server.

Typical DNAT rule:

• Original source: Any or defined source IP networks.
• Original destination: WAN-IP or WAN host object.
• Original service: external service, for example HTTPS or Synology_5555.
• Translated destination (DNAT): internal server.
• Translated service (PAT): Original or internal destination port.
• Translated source (SNAT): mostly Original.
• Inbound interface: Any or WAN interface.
• Outbound interface: mostly Any at DNAT.

For public services, you should not only build NAT, but also immediately check the logging, IPS, source restrictions, geo-IP logic and patch level of the target server. More detailed step-by-step instructions can be found in the article Publish server to Sophos Firewall via DNAT. For HTTP and HTTPS applications, you should also check whether a Sophos Firewall WAF is a better fit than pure DNAT. DNAT is a port forwarding. WAF can include hostnames, certificates, paths, web protection profiles and optionally authentication. For simple non-HTTP services, DNAT often remains correct; for publicly accessible web applications, WAF is often a better starting point.

PAT: Port Address Translation

PAT changes the service or port. On the Sophos Firewall, the Translated service (PAT) field is responsible for this.

Example:

• External TCP 5555 to internal TCP 443.
• External TCP 20120 to internal TCP 22.
• External TCP 8443 to internal TCP 443.

The external client connects to a public port, but internally a different port is addressed. Important: The protocol must be correct. TCP can be translated to TCP, UDP to UDP. A translation from TCP to UDP is not clean port forwarding.

DNAT example with firewall rule

The example shows the typical publication of an internal service. What is crucial is that the NAT rule and the firewall rule match.

Practical example: Publish Synology via DNAT

In the example, a service should be accessible via a public WAN-IP. The Synology_5555 service is addressed from the outside. Internally the server listens to HTTPS. So the NAT rule translates the public destination address to the internal server and the public service to the internal service.

DNAT rule field by field

• Rule name: Name clearly, for example DNAT_SYNOLOGY_5555.
• Description: Document why the rule exists and who created it. This will help enormously later.
• Rule position: Specific rules should be placed above general rules.
• Original source: Can be restricted in the NAT rule. In practice, it is often cleaner to maintain the source restriction in the firewall rule so that the same restriction does not have to be maintained twice.
• Original destination: The public destination address before NAT. It is better to use a host object for the WAN-IP than the WAN interface directly. A host object usually remains more stable during interface changes or adjustments.
• Original service: The service or port that can be reached from outside, for example Synology_5555.
• Translated source (SNAT): For classic DNAT rules usually Original. Only change if the internal server should see the firewall as source. But then you lose the real client IP.
• Translated destination (DNAT): The internal server or a list of servers to redirect to.
• Translated service (PAT): The internal service or port to be rewritten to, for example HTTPS. If no port change is necessary, the service remains Original.
• Inbound interface: Interface where traffic comes in. For DNAT often Any or WAN. Any is often required for VPN contexts because VPNs are not treated like normal interfaces.
• Outbound interface: For DNAT usually Any, as the firewall decides on routing and target zone.

Create firewall rule for DNAT rule

A DNAT rule is not enough. In addition, a firewall rule is required that allows traffic.

For DNAT it is important: The firewall rule refers to the traffic in the DNAT context. This seems unusual at the beginning, especially with target zones and target networks.

• Source zones: Mostly WAN when access comes from the Internet.
• Source networks and devices: If possible, not Any if it can be avoided. Better to use countries, individual IPs, networks, FQDN hosts or groups.
• Destination zones: The zone of the internal target, for example SERVER or DMZ, not simply WAN.
• Destination networks: The public destination address or the WAN host object from Original destination.
• Services: The external service from Original service, i.e. the port that clients access from outside.
• Log firewall traffic: Enable for published services. Without logging, the Log Viewer is not helpful with this rule. If global users need access and Source networks and devices cannot be meaningfully restricted, you should still harden the rule: only open required ports, activate IPS, switch on logging, keep the target system up to date and use MFA, VPN or ZTNA if possible.

💡 Publicly accessible services are often scanned very quickly by bots. Sophos Firewall Threat Feeds help block known malicious IPs, domains or URLs early. This doesn’t replace a clean rule, but it significantly reduces unnecessary bot traffic.

Loopback Rule: Access internally via the public DNS name

A Loopback Rule is required if internal clients should reach an internal server via its public IP or public FQDN.

Example:

• Externally, service.example.com points to the public WAN-IP.
• Internally, clients use the same name service.example.com.
• Without loopback, the traffic from the LAN goes to the public IP of the firewall and has to go back to the internal server.

In simple environments, split DNS is often cleaner: Internally service.example.com points directly to the internal server IP. Then there is no need for Hairpin-NAT. If split DNS is not possible, a loopback rule can make sense.

With Server Access Assistant, the Sophos Firewall can automatically create loopback rules. However, this only works under certain conditions, for example if the WAN interface is used as Public IP and external sources are appropriately defined in general. With manual rules, loopback should be planned consciously and then tested.

Reflexive Rule: Mirror outgoing traffic from the server

A Reflexive Rule is an automatically generated SNAT rule for the DNAT rule. This rule can be useful if you want the published server to appear starting with a specific public IP. Important: Normal responses to an incoming DNAT connection usually do not require a separate reflexive rule. Stateful firewalling ensures that the response packets belong to the existing connection.

You should only activate reflexive rules if you understand the purpose. In environments with multiple WAN IPs, multiple DNAT rules, or multiple servers, an additional SNAT rule may otherwise result in behavior that is difficult to understand.

⚠️ Automatically generated Loopback or Reflexive Rules remain independent rules. If the original DNAT rule is later changed or deleted, these derived rules are not automatically updated logically. After every change to the original rule, the related Loopback and Reflexive Rules must be checked manually.

Advanced NAT features

These options are not needed in every environment. They become important when internal clients use the same public name, multiple target servers are involved or NAT rules are created from firewall rules.

Server Access Assistant or manual NAT rule?

Server Access Assistant can automatically create DNAT, loopback, reflexive and firewall rules. This is useful if you want to quickly publish a service.

For productive environments, manual rules are often easier to understand:

• You can see exactly which rule does what.
• Source restrictions are deliberately maintained in the firewall rules.
• The NAT rule remains slimmer.
• Rule position and logging are set cleanly.
• Later changes are less surprising.

The Assistant is helpful, but does not replace understanding the individual rules.

Linked NAT Rules

A Linked NAT Rule is created from a firewall rule. It is a Source NAT rule in the NAT rules table.

That sounds practical, but it has limits:

• Most of the matching criteria come from the firewall rule.
• In the NAT rule you can only adjust certain NAT fields.
• A more general NAT rule above can still match first.
• Many linked NAT rules quickly make the NAT table confusing.

For new, simple configurations, an independent NAT rule in Rules and policies > NAT rules is usually more understandable. Linked NAT Rules are particularly useful in migration scenarios or very targeted special cases.

Load Balancing and Health Check at DNAT

DNAT can do more than simple port forwarding. If several internal servers are stored as Translated destination, the firewall can distribute traffic.

Possible methods:

• Round robin: simple distribution without session persistence.
• First alive: primary server with failover.
• Random: random distribution.
• Sticky IP: same source-destination combination stays on the same server.
• One-to-one: fixed assignment between original and translated destination. If you want the firewall to detect whether a target server is available, Health check must be enabled. Without Health Check, the firewall considers servers to be available even if they do not respond.

NAT order

Sophos processes NAT rules from top to bottom. The first matching rule wins. After that, further NAT rules will no longer be checked.

Recommendation:

• Specific DNAT rules up
• Specific SNAT rules above general MASQ rules
• Position default SNAT rule consciously
• Check Linked NAT Rules regularly
• Remove or deactivate old migration rules if they are no longer needed

A tried and tested order in many environments looks like this:

1. Black hole DNAT or block rules for known unwanted sources, if such rules are used.
2. Very specific DNAT rules for published services.
3. Special SNAT rules for individual servers, partner networks or VPN special cases.
4. Loopback or reflexive rules when they are consciously needed.
5. General SNAT or MASQ rules for normal Internet access.

This is not a hard and fast law, but it is a good test framework. The specific test flow is always crucial. If a broad MASQ rule or an old linked NAT rule is placed above a specific rule, the new rule looks correct but is never reached. When making changes, you should not only check the rule itself, but also the rules directly above and below it.

For public services, a black hole DNAT rule before the productive DNAT rule can be useful if certain bad IP lists or countries are to be intercepted early. The process is described in Sophos Firewall: Block countries and malicious IPs.

NAT safely change and check

NAT changes alter packet flow. That’s why you should treat it like a productive change: prepare, test, log and roll back cleanly if necessary.

Roll out NAT changes safely

NAT changes often affect productive traffic immediately. This is particularly critical for published servers, VPN special cases, multiple WAN-IP addresses, or firewall rules used by external partners. Therefore, NAT should not be treated like a pure object change, but rather like a small change with a test and fallback path.

Before making a productive change, you should briefly note:

• Previous NAT Rule ID and rule name: In the Log Viewer you can then check whether the new rule really applies.
• Expected test flow: Source, Destination, Service and Direction must be clear before saving.
• Dependent firewall rule: NAT and firewall rule must match but be checked separately.
• Fallback path: If there are problems, the new rule can be deactivated and the old rule can be activated again.
• Test window: External services, VPN remote sites or partner access should not be interrupted unnoticed.

When making major changes, we recommend first duplicating existing NAT rules or creating a new specific rule above them instead of directly converting the only working rule. The old rule initially remains deactivated or remains below as a reference. After a successful test, it can be removed or clearly documented.

The rule position is also important: A new specific SNAT or DNAT rule is of no use if a more general rule above already matches the same traffic. Therefore, the change always includes a log viewer test with expected Firewall Rule ID and NAT Rule ID. For externally accessible services, the test should not only be carried out from your own LAN. An internal test for the public FQDN often checks loopback or split DNS, but not real access from the Internet. DNAT acceptance requires at least one external test, for example via mobile communications, an external location or a controlled port test.

Check NAT and firewall rule together

A common thinking error is: “The NAT rule is correct, so it should work.” That’s only half true.

For traffic to work you need:

1. Routing to the firewall
2. appropriate NAT rule if translation is necessary
3. appropriate firewall rule
4. correct return route
5. appropriate security profiles
6. no upstream blocking, for example provider router, cloud security group or target firewall The following also applies to DNAT: Firewall rules for DNAT traffic use the target zone after NAT, but the public target address before NAT as the target network. It is precisely this point that is crucial in many troubleshooting.

Read Firewall Rule ID and NAT Rule ID correctly

In the case of NAT errors, you should not only check whether any log entry exists. What is crucial is whether the log entry matches the expected firewall rule and the expected NAT rule. For this reason, Firewall Rule ID and NAT Rule ID are more helpful than the rule name alone, because names can be changed, chosen similarly or cut off in screenshots.

A short interpretation helps:

• Expected Firewall Rule ID and expected NAT Rule ID visible: The rule matching is basically correct. Then check the return path, target system, security profile and application.
• Expected Firewall Rule ID visible, but incorrect NAT Rule ID: The firewall rule matches, but NAT order or NAT criteria do not match. Check NAT rule position, Original fields and more general NAT rules.
• Other Firewall Rule ID visible: Another firewall rule wins. Check firewall rule order, zones, source, destination and service.
• No NAT Rule ID visible, although NAT is expected: No NAT rule was applied or the wrong log type or flow is being viewed. Check NAT criteria, direction and real test flow.
• No log entry visible: Logging is missing or traffic does not reach the firewall. Check rule logging, provider router, VLAN, Gateway and Packet Capture. Especially with DNAT, a single successful or failed test without an ID comparison is not enough. You should note which IDs are expected, run the test exactly once and then compare Log Viewer and Packet Capture. If the IDs do not match the expectation, the matching and ordering is corrected first, not the target server.

Common NAT errors

When dealing with NAT problems, it is helpful not to rebuild rules immediately. First, one should classify the observed defect.

• No log entries in Log Viewer: Traffic does not reach the firewall, logging is missing or the filter is incorrect. Check provider router, cloud security group, client Gateway, firewall rule logging and filters.
• Log entry without expected NAT Rule ID: The NAT rule does not match or a rule above it wins. Original source, Original destination, check service and NAT order.
• DNAT rule matches, connection still doesn’t work: Firewall rule, destination server, return route or local server firewall blocked. Compare Firewall Rule ID, Packet Capture and server logs.
• Internal access to public FQDN does not work: Split DNS or loopback NAT is missing. Check internal DNS resolution and decide whether split DNS or loopback is cleaner.
• External client sees incorrect source-IP: SNAT or Reflexive Rule changes source unexpectedly. Check Translated source (SNAT) and automatically generated rules.
• VPN traffic uses unexpected source IP: SNAT, XFRM, SD-WAN route or IPsec route do not match. Check route lookup, SD-WAN route, IPsec route and NAT rule position.
• Public port pointing to wrong internal service: PAT or service object is set incorrectly. Compare Original service and Translated service (PAT). This overview does not replace packet flow analysis, but it saves time: It separates problems in front of the firewall, in the NAT logic, in the firewall rule and on the target system.

Acceptance test after NAT changes

After a NAT change, you should not only check whether a single ping or a website works once. The test must match the type of translation.

For SNAT or MASQ:

1. Define test client and target service.
2. Check firewall rule with Log firewall traffic.
3. In the Log Viewer check which Firewall Rule ID and NAT Rule ID are in effect.
4. On the target system or external test service, check which source IP is visible.
5. Test the return path and session behavior on several WAN links.

For DNAT or PAT:

1. Carry out the test from outside your own network, not just from the LAN.
2. Compare public target IP, external port and internal target server.
3. Check Log Viewer Firewall Rule ID and NAT Rule ID.
4. Use Packet Capture to check whether packets arrive and continue to the internal server.
5. Check on the target server whether the local firewall, service and return route are correct.

For VPN-NAT:

1. Check tunnel status and security associations.
2. Define a concrete test flow with source, destination and service.
3. Check NAT rule position and route lookup.
4. Use Packet Capture on both sides if the remote site allows access.
5. Include logs from the application or target system so that not only the firewall side is evaluated.

Especially at remote locations, only one test case should be changed per change. If the firewall rule, NAT, route, SD-WAN and target system are adjusted at the same time, a successful test can hardly be explained later.

Troubleshooting

This order helps with NAT problems:

1. Open Log viewer and filter by Source IP, Destination IP and Service.
2. Check which Firewall Rule ID and NAT Rule ID are displayed.
3. Check NAT control position.
4. Check firewall rule position.
5. Use Diagnostics > Packet capture to check whether packets are arriving and continuing.
6. For deeper analysis, check nat_rule.log, firewall_rule.log and fwlog.log.
7. For VPN or XFRM context, also check charon.log, strongswan.log and xfrmi.log. If the NAT rule still doesn’t work, Firewall rule doesn’t work: check order, matching and logs and Use Packet Capture tool in WebAdmin will help you narrow it down. Which service names and log files are relevant can be found in Sophos Firewall Troubleshooting: Services and Logs. For support cases, you can export the logs with Sophos Firewall Save logs for support and analysis.

NAT Rules Checklist

• NAT rule has a unique name and description.
• Purpose, responsible person and last review are documented.
• Original and Translated fields were tested against a real test flow.
• NAT rule is above more general NAT rules.
• Appropriate firewall rules are in place and logging is active.
• Expected Firewall Rule ID and NAT Rule ID were checked in Log Viewer.
• For DNAT, the target zone is set correctly after NAT and the target network before NAT.
• DNAT was tested externally, not just internal LAN.
• For public services, source restrictions, IPS, WAF alternative and patch level were checked.
• For VPN-NAT, routing, IPsec route, SD-WAN and overlapping networks are documented.
• Loopback or split DNS is a conscious decision.
• Reflexive rules are only active if the outgoing server traffic really needs to be mirrored.
• Old or temporary NAT rules are disabled or removed.

FAQ