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

NAT is one of the Sophos Firewall topics that quickly becomes confusing in practice. The terms sound similar, the rule editor uses Original and Translated, and Log Viewer may show different addresses depending on where one looks.

This article explains the main NAT types, shows common real-world use cases and walks through a DNAT example with the matching Firewall Rule.

NAT translates, it does not allow

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

⚠️ A NAT rule does not allow traffic. It only translates addresses or ports. Traffic through the firewall always also needs a matching Firewall Rule.

Typical NAT scenarios:

• Internal clients use the public WAN IP to access the internet.
• An internal server is published through a public IP.
• A public port is translated to a different internal port.
• Overlapping networks are translated for VPN connections.
• Internal clients access an internal server through its public DNS name.

The main NAT types

As a mental model: NAT does not answer “Is this traffic allowed?” It answers “How should the address or port look while the packet is handled?”

Reading Original and Translated correctly

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

When troubleshooting, first write down what the packet looks like before NAT. Then define what the firewall should turn it into.

Practical examples: When to use what?

SNAT: Source NAT

SNAT changes the source address. The classic case is outbound internet access from the LAN. Clients keep their private IP addresses internally, but externally the firewall WAN address or another defined public IP is used.

Typical SNAT rule for LAN to WAN:

For simple environments, one 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.

Sophos Firewall includes a default SNAT rule with MASQ in the base configuration. If this rule is not needed, disabling it is usually cleaner than deleting it. When a WAN interface is created or updated, the default rule may otherwise reappear.

Pitfall: 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 may use the XFRM IP as translated source. In Packet Capture or tcpdump, the WAN IP may appear in the outer header and the XFRM IP in the inner context.

DNAT: Destination NAT

DNAT changes the destination address. It is used, for example, to publish an internal server through a public IP or public port. Incoming traffic to the WAN address is translated to the internal server.

Typical DNAT rule:

For public services, NAT is only one part of the design. Logging, IPS, source restrictions, Geo-IP logic and the patch level of the target server should be checked immediately. A detailed step-by-step guide is available in Publish a server with DNAT on Sophos Firewall.

PAT: Port Address Translation

PAT changes the service or port. On Sophos Firewall, this is configured with Translated service (PAT).

Example:

The external client connects to a public port, while internally another port is used.

Important: The protocol must match. TCP can be translated to TCP, UDP to UDP. TCP to UDP is not a valid port forwarding design.

Practical example: Publish Synology with DNAT

In this example, a service should be reachable through a public WAN IP. Externally, the service Synology_5555 is used. Internally, the server listens on HTTPS. The NAT rule therefore translates the public destination address to the internal server and the public service to the internal service.

The example is deliberately technical. Management interfaces such as NAS, RDP, SSH or WebAdmin should only be exposed directly when it is truly necessary. In many cases, VPN or ZTNA is the better solution.

DNAT rule field by field

Matching Firewall Rule for the DNAT rule

A DNAT rule is not enough. A Firewall Rule must also allow the traffic.

For DNAT, it is important to understand that the Firewall Rule is evaluated in the DNAT context. Destination zone and destination network often feel unintuitive at first.

If global users must connect and Source networks and devices cannot be restricted sensibly, harden the rule in other ways: open only required ports, enable IPS, enable logging, keep the target system current and use MFA, VPN or ZTNA where possible.

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

Loopback Rule: Internal access through the public DNS name

A Loopback Rule is required when internal clients should reach an internal server through 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, traffic from the LAN goes to the firewall public IP and must be sent 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 no hairpin NAT is required. If split DNS is not possible, a Loopback Rule can be useful.

With the Server Access Assistant, Sophos Firewall can create loopback rules automatically. This only works under certain conditions, for example when the WAN interface is used as the public IP and external sources are defined broadly enough. For manual rules, loopback should be planned deliberately and tested afterwards.

Reflexive Rule: Mirror outbound traffic from the server

A Reflexive Rule is an automatically created SNAT rule for a DNAT rule. It can be useful when the published server should appear outbound with a specific public IP.

Important: A normal reply to an incoming DNAT connection usually does not need a separate Reflexive Rule. Stateful firewalling ensures that reply packets belong to the existing connection.

Only enable Reflexive Rules when their purpose is clear. In environments with multiple WAN IPs, multiple DNAT rules or multiple servers, an additional SNAT rule can otherwise create behaviour that is hard to trace.

⚠️ If a DNAT rule is changed later, automatically created Loopback or Reflexive Rules are not always updated in the way one might expect. Related rules should be checked after changes.

Server Access Assistant or manual NAT rule?

The Server Access Assistant can automatically create DNAT, loopback, reflexive and Firewall Rules. This is useful when a service must be published quickly.

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

• It is clear which rule does what.
• Source restrictions are maintained intentionally in the Firewall Rule.
• The NAT rule stays cleaner.
• Rule position and logging are set deliberately.
• Later changes are less surprising.

The assistant is helpful, but it 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 and appears in the NAT rule table.

This sounds practical, but has limitations:

• Most matching criteria come from the Firewall Rule.
• Only certain NAT fields can be changed in the NAT rule.
• A more general NAT rule above it can still match first.
• Many Linked NAT Rules quickly make the NAT table hard to read.

For new and simple configurations, a standalone NAT rule under Rules and policies > NAT rules is usually easier to understand. Linked NAT Rules are mainly useful in migration scenarios or very specific exceptions.

Load balancing and health check with DNAT

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

Available methods:

If the firewall should detect whether a target server is available, Health check must be enabled. Without Health Check, the firewall considers servers available even if they do not respond.

NAT order

Sophos processes NAT rules from top to bottom. The first matching rule wins. Later NAT rules are not evaluated for that packet.

Recommendation:

• Specific DNAT rules near the top
• Specific SNAT rules above general MASQ rules
• Position the default SNAT rule deliberately
• Review Linked NAT Rules regularly
• Remove or disable old migration rules when they are no longer needed

Check NAT and Firewall Rule together

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

Working traffic needs:

1. routing to the firewall
2. a matching NAT rule if translation is required
3. a matching Firewall Rule
4. a correct return path
5. matching Security Profiles
6. no upstream blocking, such as provider router, cloud Security Group or target firewall

For DNAT, also remember: Firewall Rules for DNAT traffic use the destination zone after NAT, but the destination network before NAT. This exact point is critical in many troubleshooting cases.

Troubleshooting

For NAT problems, use this order:

1. Open Log viewer and filter by Source IP, Destination IP and service.
2. Check which Firewall Rule ID and NAT Rule ID are shown.
3. Check the NAT rule position.
4. Check the Firewall Rule position.
5. Use Diagnostics > Packet capture to verify whether packets arrive and leave again.
6. For deeper analysis, check nat_rule.log, firewall_rule.log and fwlog.log.
7. For VPN or XFRM contexts, also check charon.log, strongswan.log and xfrmi.log.

If the NAT rule still does not match, Firewall rule not matching: check order, matching and logs and Use Packet Capture in WebAdmin help narrow it down. Relevant service names and log files are covered in Sophos Firewall Troubleshooting: Services and logs. For support cases, logs can be exported with Save Sophos Firewall logs for support and analysis.

Further information

• Sophos Firewall - Add a NAT rule
• Sophos Firewall - Add a DNAT rule with server access assistant
• Sophos Firewall - Create DNAT and firewall rules for internal servers
• Sophos Firewall - Create an SNAT rule