SonicWall Access Rules & NAT Policies — the Gate and the Translator, Together

① Access Rules — the gate that decides whether traffic passes

Access Rules are SonicWall's gate. They decide whether traffic is allowed between two security zones, always written for a zone pair such as LAN→WAN or WAN→DMZ. You pick a source zone and a destination zone, and SonicOS shows just the rules for that pair.

Within a zone pair the rules are evaluated top-down, first match wins: the first rule that matches sets the action and the firewall stops looking — which is why ordering matters. Each rule carries a source and destination address object, a service (port/protocol), an optional schedule and users, and an action: Allow permits, Deny politely refuses with a reset, Discard drops silently. You can also enable security services like DPI and logging on the rule itself.

Default rules ship per zone pair. Trusted-to-untrusted (LAN→WAN) is allowed by default; untrusted-to-trusted (WAN→LAN) is denied by default. You add your own rules above the defaults to change behaviour.

② NAT Policies — the separate table that rewrites addresses

NAT Policies are a completely separate table from access rules. A NAT policy does not allow or deny anything — it translates. Each policy maps an Original source, destination and service to a Translated source, destination and service, scoped by inbound and outbound interface.

The mental model: the access rule is the gate (whether), the NAT policy is the translator (how). They are matched independently for the same packet. A packet can sail through the gate and then have its destination rewritten by a NAT policy, or be translated and still hit a closed gate — the two tables do not know about each other.

The most common NAT policy is already there: the default outbound PAT. It maps your whole LAN subnet (Original source) to the firewall's WAN interface IP (Translated source), so many internal hosts share one public address on the way out.

③ The NAT types — outbound, one-to-one, inbound and loopback

Once you see NAT as 'Original to Translated', the types are just different mappings. Many-to-one PAT (outbound masquerade) is the default: many LAN IPs hidden behind the single WAN IP using ports. One-to-one NAT maps a single internal host to a single dedicated public IP in both directions. One-to-many spreads one internal resource across several public IPs.

The two that matter for publishing a service: inbound NAT translates a public IP/port to an internal server's private IP/port, so the internet can reach an internal service. Loopback (reflexive) NAT lets internal users reach that same published server by its public IP — so staff and outsiders use one address instead of two.

The line to remember

NAT only ever rewrites addresses. None of these types decides whether the traffic is permitted — that is always the access rule's job. Keep that split clean and the rest is just choosing the right mapping.

④ Publishing a server — NAT policy and access rule, together

Here is the whole lesson in one rule: to publish an internal server you need both an inbound NAT policy (public→private translation) and a matching access rule (e.g. WAN→DMZ Allow for the service). One without the other fails. NAT alone rewrites the destination but the gate still denies it; an access rule alone permits traffic that never gets steered to the right host.

The safe way is the Public Server Wizard. It asks what you are publishing and then builds all three pieces together: the address objects, the inbound NAT policy, and the matching access rule — so you cannot forget either half.

The classic failure

The number-one SonicWall ticket: someone hand-builds the NAT policy, skips the WAN→DMZ access rule, and external users time out. SonicOS dutifully translates the public IP to the internal server, then the default WAN→DMZ deny drops it before delivery. The fix is always the same — add the matching access rule (or re-run the Wizard).