Skip to content
Avanet

Publish a Server with DNAT on Sophos Firewall

Sophos Firewall

With DNAT, you publish an internal server through a public IP address or a public port. Sophos Firewall then forwards incoming traffic to the internal destination server. Typical examples are web servers, reverse proxies, VPN gateways or other services in a DMZ.

This guide shows what to check before and after creating a DNAT rule and how to secure the published service as tightly as possible.

Requirements

  • Public IP address or WAN interface
  • Internal server with a fixed IP address
  • Known service and port, for example TCP 443
  • Matching firewall rule
  • Optional: IPS, Web Server Protection or reverse proxy depending on the service

⚠️ DNAT publishes an internal service to the outside. Every published service increases the attack surface. Publish only what is really necessary and restrict source, port and destination as tightly as possible.

Clarify beforehand

Before creating the rule, answer these questions:

  • Which public IP or WAN interface is used?
  • Which external port should be reachable?
  • To which internal IP address is traffic forwarded?
  • Does the port stay the same or is it translated?
  • Should access be allowed from everywhere or only from defined source networks?
  • Does Source NAT or Reflexive NAT need to be considered?
  • Is a loopback rule required for internal clients that use the public FQDN?
  • Is only one internal server published or are several servers used with load balancing?
  • Is there already a rule using the same port?
  • Is Sophos Firewall directly connected to the internet or behind a provider router?
  • Do additional rules need to be opened in a cloud security group?

These details help prevent later conflicts with existing NAT or firewall rules.

If the firewall is behind a router

DNAT also works if Sophos Firewall does not own the public IP address directly but is behind a NAT router from the provider.

In this case, two forwards are required:

  1. On the provider router, the public port is forwarded to the WAN IP of Sophos Firewall.
  2. On Sophos Firewall, the port is forwarded to the internal server using DNAT.

Many provider routers offer classic port forwards or a function such as Exposed Host or DMZ Host. With an exposed-host function, many or all incoming ports are often forwarded to the firewall. This can be practical, but it must be secured deliberately because the actual control then sits entirely on Sophos Firewall.

If no fixed public IP address is available, DynDNS can be used. Sophos Firewall can configure Dynamic DNS so that a DNS name always points to the current public IP. The important point remains: the port forward on the provider router must point to Sophos Firewall.

The same principle applies in cloud environments. In Azure, the DNAT rule on Sophos Firewall alone is not enough. The matching Inbound rules must also be opened in the Network Security Group, otherwise the traffic never reaches the firewall.

Create a DNAT rule

A typical DNAT example:

  • Original source: Any or defined source networks
  • Original destination: WAN IP or WAN interface
  • Original service: HTTPS
  • Translated destination: internal server
  • Translated service: unchanged or internal target port

Procedure:

  1. Open Rules and policies.
  2. Go to NAT rules.
  3. Create a new NAT rule.
  4. Define Original Source, Destination and Service.
  5. Set Translated Destination to the internal server.
  6. Optionally set Translated Service.
  7. Save and enable the rule.

If only a few external source IP addresses need access, Original Source should not be Any, but restricted to those sources.

Sophos Firewall - DNAT rule with public IP, external port and internal target server
Sophos Firewall - Rules and policies > NAT rules > DNAT

Understand Original and Translated correctly

In NAT rules, the difference between Original and Translated is important.

  • Original source / destination / service describes the traffic as it arrives at Sophos Firewall.
  • Translated source / destination / service describes the traffic as it leaves Sophos Firewall again after translation.

For an inbound DNAT rule, this means:

  • Original destination is the public IP or WAN address of the firewall.
  • Original service is the external port the client connects to.
  • Translated destination (DNAT) is the internal server.
  • Translated service (PAT) is the internal port on the target server, if the port should be translated.
  • Translated source (SNAT) usually remains Original for normal DNAT rules.

Sophos describes the fields in the official guide Add a NAT rule.

Port forwarding and PAT

Port forwarding is technically a service translation. On Sophos Firewall, Translated service (PAT) is used for this.

Example:

  • External: TCP 20120
  • Internal: TCP 22

The external client connects to port 20120, but Sophos Firewall forwards internally to SSH port 22. This can be useful, but it does not replace access restrictions. Changing the external port may reduce background noise a little, but it does not make a service secure.

Important: The protocol must remain the same. TCP can be translated to another TCP port, UDP to another UDP port. TCP to UDP is not a valid port translation.

If HTTPS is published, also check whether there are conflicts with WebAdmin or User Portal on Sophos Firewall. By default, the admin console uses HTTPS port 4444, while User Portal uses HTTPS port 443. If there is overlap, the firewall’s own ports or the published services must be separated cleanly.

Loopback, Reflexive and Linked NAT Rules

Sophos uses several NAT options that are easy to confuse:

  • Loopback rule: Helps when internal clients need to reach an internal server through the public IP or public DNS name.
  • Reflexive rule: Creates a mirrored SNAT rule for a DNAT rule so that return traffic or certain reverse directions are translated correctly.
  • Linked NAT rule: Is created from a firewall rule and is a linked SNAT rule. It is not the same as an inbound DNAT rule for a published server.

For classic server publishing, a standalone DNAT rule plus a matching firewall rule is usually the clearest approach. Linked NAT Rules can be useful when a firewall rule directly needs a specific SNAT translation. For general environments, however, Sophos recommends keeping NAT rules as independent and simple as possible instead of creating unnecessarily many linked NAT rules per firewall rule.

Load balancing and Health Check

If several internal servers are published behind a public IP address, DNAT can also be used for load balancing or failover.

Possible methods include:

  • Round robin
  • First alive
  • Random
  • Sticky IP
  • One-to-one

If the firewall should detect whether a target server is available, a Health check must be configured. Without a Health Check, the firewall may forward traffic to a server that is not reachable.

Check the firewall rule

A NAT rule alone does not automatically allow the traffic. A matching firewall rule is also required.

The firewall rule should define:

  • Source zone: usually WAN
  • Source network: as restricted as possible
  • Destination zone: zone of the internal server, for example DMZ
  • Destination network: internal server
  • Services: only required ports
  • Security profiles: depending on the service, IPS, Malware Scan or Web Policy
  • Logging: enabled

Without a matching firewall rule, traffic is dropped despite DNAT.

Sophos Firewall - firewall rule matching the DNAT rule with restricted source networks
Sophos Firewall - firewall rule matching the DNAT rule

Rule order also matters for NAT rules. Sophos checks NAT rules from top to bottom and uses the first matching rule. A rule that is too general above the specific DNAT rule can therefore prevent the specific rule from being applied.

Restrict access as tightly as possible

Not every published service must be reachable from the entire internet. Where possible, restrict access.

Useful restrictions:

  • Allow only individual source IP addresses.
  • Allow only known FQDN hosts if the remote side uses dynamic IPs.
  • Allow only specific countries.
  • Explicitly block specific countries.
  • Allow access only through VPN.
  • Use a ZTNA solution instead of direct publishing.

For administrative services such as SSH, RDP or internal admin portals, DNAT is usually not the best solution. If access does not have to be public, VPN or ZTNA is almost always the better choice.

Further information:

Improve security

For published services, check:

  • Is the server fully patched?
  • Is there a WAF or reverse proxy option?
  • Is IPS enabled on the firewall rule?
  • Are only required ports open?
  • Is the service logged?
  • Are Geo-IP, Threat Feed or source IP restrictions in place?
  • Is MFA possible if the service is a portal?

For web applications, Web Server Protection can be useful instead of pure DNAT.

Bots and Threat Feeds

Public ports such as HTTP, HTTPS, SSH or RDP are permanently targeted by bots. As soon as a port is reachable from the internet, you often see connection attempts, scans, login attempts or exploit traffic very quickly in Log Viewer.

This does not automatically mean that the server is compromised. It does show, however, that the service is part of the public attack surface. We therefore recommend protecting published services additionally with IPS, logging, tight sources and Third-Party Threat Feeds.

Threat Feeds continuously provide the firewall with current indicators of compromise, such as malicious IP addresses or domains. This lets the firewall block known attackers, botnets or scanners before they reach the published service.

More on this: Sophos Firewall Threat Feeds

Test

After creating the DNAT rule:

  • Test from an external network, not from the same LAN
  • Check a port scan against the public IP
  • Check Log Viewer for NAT and firewall events
  • Check the server logs
  • Verify whether the client sees the expected source IP

If testing from the internal LAN to the public IP is required, Hairpin NAT or an internal DNS solution may also be needed.

Troubleshooting

Common mistakes:

  • Firewall rule is missing
  • Wrong WAN IP selected
  • Port forward on the provider router is missing
  • Azure Network Security Group blocks the port
  • Service is not running internally
  • Server gateway does not point to Sophos Firewall
  • NAT rule is below another rule that matches first
  • Port is already used by another service
  • Loopback is missing when internal clients use the public FQDN
  • Health Check is missing or incorrect when load balancing is used
  • Test is done from the internal network instead of externally

For DNAT problems, Log Viewer is the most important starting point. It shows whether traffic arrives, which rule matches and whether it is allowed or dropped.

Recommendation

DNAT rules should be reviewed regularly. Old forwards are a typical security risk. Good documentation includes purpose, target server, external ports, responsible person, expiry date and last review.