Most engineers think…
Most people who learned the old Sophos XG model picture the NAT as something you tick on the firewall rule itself — set the masquerade, done. On current Sophos Firewall that mental model quietly breaks things.
Since SFOS 18 the product splits the job into two separate tables: a firewall rule table that answers 'is this traffic allowed?' and a NAT rule table that answers 'how is the address translated?'. They are evaluated independently. A firewall rule can still carry a convenient linked NAT rule for quick source NAT, but DNAT for publishing a server now lives in its own table — and a NAT rule on its own never allows traffic. Understanding that split is exactly what makes server publishing work the first time and what most Sophos interviews probe.
① The firewall rule table & rule groups — top-down, first match
The firewall rule table is an ordered list evaluated top-down, first match wins. The first rule whose conditions match the traffic sets the action — Accept, Drop or Reject — so rule order matters. You can organise related rules into Rule Groups, which are just ordered containers that keep a long policy readable; they do not change the first-match behaviour.
Each rule matches on source and destination zones (LAN, WAN, DMZ, VPN), networks, services (ports and protocols) and a schedule, then applies security profiles — web filtering, application control and IPS — to the allowed traffic, with per-rule logging. Crucially, a rule can be identity-based: it matches on the authenticated user or group, not just an IP. The two rule types are the everyday User / Network rule and the Business Application rule wizard for publishing servers.
Because matching is top-down, first-match, a broad Accept or Drop placed too high can shadow the specific rule below it. Keep specific rules above general ones, and use Rule Groups to keep that order visible. In an interview, always say 'top-down, first match wins' before anything else.
How does Sophos Firewall decide which firewall rule applies to a packet?
② The SFOS 18+ split — firewall rules vs NAT rules
Here is the single most important change, and the one interviews love. In older Sophos XG firmware, the NAT (masquerade) was set on the firewall rule. From SFOS 18 onwards the two are separated into their own tables: the firewall rule table decides whether traffic is allowed; the NAT rule table decides how the address is translated. They are evaluated independently, and the NAT rule table is also top-down.
Linked vs standalone NAT
A firewall rule can still have a linked NAT rule attached for quick source NAT — convenient, but behind the scenes it is still a separate NAT object. The alternative is a standalone NAT rule you create directly in the NAT table, which is what you use for DNAT and full NAT. The practical takeaway: allowing traffic and translating its address are now two different decisions you configure in two different places.
Top-down, first-match rule that decides if traffic is allowed — by zone, network, service, schedule, user identity and security profiles. Action: Accept, Drop or Reject.
A separate rule in its own table that only translates addresses — SNAT/MASQ, DNAT, full NAT or loopback. It never allows traffic on its own.
Source NAT for outbound traffic — rewrites the internal source to the WAN interface IP. The default MASQ rule gives LAN hosts internet access.
Destination NAT for inbound traffic — rewrites the destination so external users reach an internal server. The core of server publishing.
On SFOS 18+ that only gets you a linked NAT rule for quick source NAT. For publishing a server you create a separate DNAT rule in the NAT table — and you still need a firewall rule to allow it. Treat 'allow it' and 'translate it' as two separate decisions.
What is the key change in SFOS 18 and later compared with old XG?
③ NAT types — SNAT/MASQ, DNAT, full NAT and loopback
The NAT rule table holds four shapes you must be able to name. SNAT (source NAT) / MASQ (masquerade) handles outbound traffic — it rewrites the internal source to the WAN interface IP so LAN hosts can reach the internet. DNAT (destination NAT) handles inbound traffic — it rewrites the destination so external users reach an internal server (server publishing / port forwarding). Full NAT translates both source and destination in one rule.
A loopback (reflexive) rule lets internal users reach a published server by its public address from inside the LAN — without it, that traffic fails because it never leaves to the WAN. Sophos ships a default network rule and a default SNAT/MASQ rule so outbound internet works out of the box; you add DNAT, full-NAT and loopback rules as the network grows. Like firewall rules, NAT rule order is top-down.
LAN hosts need to reach the internet. Which NAT rule handles that?
④ Publishing a server with DNAT — and the pitfall everyone hits
To publish an internal server you create a DNAT rule (directly, or through the Business Application rule wizard, which can also layer WAF reverse-proxy protection on top). But here is the trap that bites almost everyone migrating from old XG: a DNAT rule only translates the address — it does not allow the traffic. You still need a firewall rule that accepts the inbound session from WAN to the server, or the (now-translated) packet hits the default drop.
Don't forget reflexive access
Once it works from outside, internal staff often still can't reach the public URL. That is the loopback case: add a loopback NAT rule so internal users can reach the published server by its public address. When something breaks, read the firewall log to see which rule the session hit and the NAT log to confirm the translation — the answer is in the logs, not a guess.
Sneha at Truvelo Logistics, Hyderabad faces this
She publishes the internal web server (10.10.5.20) to the internet with a new DNAT rule on the Sophos Firewall, but external customers get connection timeouts — nothing reaches the server.
On SFOS 18+ the DNAT rule only translates the destination address; it does not allow the traffic. There is no firewall rule permitting WAN to the DMZ server, so the translated packet hits the default drop.
The NAT rule is correct, but Firewall rules has no Accept rule from WAN to the server. The firewall log shows the inbound packets landing on the default drop rule, while the NAT log shows the DNAT translation happening.
Rules and policies ▸ NAT rules (confirm DNAT) + Firewall rules + Monitor & analyze ▸ Log viewerAdd a firewall rule (User/Network rule, or the Business Application wizard) that accepts WAN to the DMZ server on the published service, keep the DNAT rule, and order both above any broad drop.
Re-test from outside — the site loads; the firewall log shows the session hitting the new Accept rule and the NAT log shows the DNAT translation. Add a loopback rule so internal staff can reach the public URL too.
When a published server won't respond, open the firewall log to see which rule the inbound session actually hit (often the default drop) and the NAT log to confirm the translation. That single read tells you whether you are missing the allow rule or the NAT rule — no guessing.
▶ Watch a request reach a published web server
How an inbound request to a DNAT'd server is allowed, translated and answered. Press Play for the healthy path, then Break it to see the classic failure.
You create a DNAT rule to publish a web server but external users get timeouts. What is the most likely cause?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: on SFOS 18+, why isn't a DNAT rule enough to publish a server? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- SFOS
- Sophos Firewall OS — the operating system on Sophos Firewall appliances (v18 and later, current in 2026), successor to the older XG firmware.
- Firewall rule table
- The ordered, top-down, first-match list of rules that decides whether traffic is accepted, dropped or rejected.
- Rule Group
- An ordered container that groups related firewall rules for clarity and bulk management; it does not change first-match semantics.
- User / Network rule
- The everyday firewall rule type controlling traffic by zone, network, service, schedule, user identity and security profiles.
- Business Application rule
- A wizard-driven firewall rule for publishing internal servers via DNAT, optionally protected by WAF.
- NAT rule
- A rule in the separate NAT table (SFOS 18+) that translates addresses — SNAT/MASQ, DNAT, full NAT or loopback. It never allows traffic on its own.
- SNAT / MASQ
- Source NAT (masquerade) — rewrites outbound source addresses to the WAN interface IP. The default MASQ rule provides internet access.
- DNAT
- Destination NAT — rewrites the destination so external users reach an internal server (server publishing / port forwarding).
- Full NAT
- A NAT rule that translates both the source and destination addresses in one rule.
- Loopback / reflexive rule
- A NAT rule that lets internal users reach a published server using its public address from inside the LAN.
📚 Sources
- Sophos — Sophos Firewall: Add and manage firewall rules (rule types, action, zones, profiles). docs.sophos.com
- Sophos — Sophos Firewall: Rules and policies and rule groups. docs.sophos.com
- Sophos — Sophos Firewall: NAT rules — SNAT, DNAT, full NAT and loopback. docs.sophos.com
- Sophos Community — What's new in SFOS 18: NAT separated from firewall rules. community.sophos.com
- Sophos — Sophos Firewall: Business application rules and WAF protection. docs.sophos.com
- Sophos — Sophos Firewall: Linked NAT rules and the default MASQ rule. docs.sophos.com
What's next?
Got rules and NAT straight? Next, see how Sophos Firewall and Sophos endpoints share health over the Security Heartbeat — Synchronized Security — to automatically isolate a compromised host the moment it turns red.