Create Access Rules and NAT Policies on a SonicWall (SonicOS 7)

Before you run this

This guide walks through publishing one internal server to the Internet on a SonicWall running SonicOS 7 (7.0/7.1) — creating the address and service objects, an inbound NAT policy that translates your public IP to the server's private IP, and the access rule that permits the traffic. On a SonicWall the "script" is the vendor's own web GUI, so there is nothing to paste into a shell.

• Privileges: You need a full administrator login to the firewall's management interface (the built-in admin account or an equivalent admin). A read-only or limited operator login cannot save these changes.
• This changes live security policy. A wrong access rule can expose an internal host you did not mean to expose; a wrong NAT policy or a bad interface selection can black-hole production traffic or lock you out of management. Treat it accordingly.
• Test scope first. If you possibly can, try the procedure against a lab appliance or a spare public IP and a throwaway internal host before you touch the production server. Do not build the rule at 3pm on a Friday against your only WAN address.
• Keep an out-of-band path open. Have the console port connected (or a second management path you know works from a different source) before you start, so a mistake in a WAN→LAN rule doesn't leave you with no way back in.
• Back up the running config first. Go to DEVICE | Settings | Firmware and Settings, create a local backup and also Export Configuration to a file on your workstation. This is your rollback.
• Do it in a maintenance window. Rollback path if it goes wrong: import the exported settings file (or restore the local backup) from DEVICE | Settings | Firmware and Settings, or reboot the unit to a saved settings image. Deleting the objects/rules you added, in reverse order, also undoes the change cleanly.

What I'm assuming

• A standalone SonicWall (TZ or NSa series) on SonicOS 7, managed over HTTPS.
• Default zone/interface layout: X0 = LAN, X1 = WAN with a static public IP. Adjust interface names if yours differ.
• The goal: publish an internal web server at 192.168.10.20 on TCP 443 to the Internet, reachable on the firewall's WAN IP.
• Replace every placeholder — the private IP, the WAN IP, ports, and object names — with your own values.

SonicOS 7 also ships a Public Server Wizard (in the wizard menu) that builds the objects, NAT policy, and access rule for a standard published server in one pass. It is a perfectly good option; I'm doing it by hand here so you understand each piece and can edit it later.

Step 1 — Create the address object for the internal server

OBJECT | Match Objects | Addresses, then the Address Objects tab → Add.

• Name: SRV-Web01 (any clear name)
• Zone Assignment: LAN (the zone the server actually lives in — use DMZ if that's where it is)
• Type: Host
• IP Address: 192.168.10.20

Save. If your public service should answer on a secondary WAN IP rather than the firewall's primary WAN IP, create a second host object in the WAN zone for that public address too.

Step 2 — Confirm or create the service object

SonicOS ships common services predefined. For TCP 443 you can use the built-in HTTPS service object as-is.

If you need a non-standard port, go to OBJECT | Match Objects | Services, Service Objects tab → Add, choose protocol TCP/UDP, and set the port(s). Use a Service Group if the server needs several ports so you can reference one object in both the NAT policy and the access rule.

Step 3 — Create the inbound NAT policy

POLICY | Rules and Policies | NAT Policies → Add.

Fill it in as a destination-translation (inbound) policy:

• Original Source: Any
• Translated Source: Original
• Original Destination: the WAN address object clients hit — commonly the built-in WAN Interface IP object, or your secondary-IP host object from Step 1
• Translated Destination: SRV-Web01
• Original Service: HTTPS (the service clients connect to on the outside)
• Translated Service: Original (use a different service object here only if you're translating the port)
• Inbound Interface: X1 (WAN)
• Outbound Interface: X0 (or the interface toward the server)
• Enable: checked

Save. The Original Service / Translated Service fields are exactly where people accidentally do port translation they didn't intend — leave Translated Service as Original unless you specifically want the public port to differ from the internal port.

If internal clients also need to reach this server by its public IP, that requires an additional loopback (reflexive) NAT policy. That's a separate, well-documented pattern — see the SonicOS 7 administration guide section on NAT ("Creating a Loopback NAT Policy") rather than improvising it here.

Step 4 — Create the access rule

The NAT policy only translates addresses; it does not permit the traffic. In SonicOS 7 the firewall implicitly blocks WAN→LAN, so you must add an allow rule.

POLICY | Rules and Policies | Access Rules → Add.

• From: WAN
• To: LAN (or DMZ, matching where the server sits)
• Source Port / Ports: Any
• Service: HTTPS
• Source: Any (tighten to a specific network/geo object if only known sources should reach it)
• Destination: SRV-Web01 — the private address object, not the WAN IP. This is the single most common mistake; the access rule matches the translated (real) destination.
• Action: Allow
• Enable Logging: on, at least while you validate

Save. Restrict the Source wherever you can — an Any→Any allow on a published port is exactly the kind of rule that turns into an incident later.

Step 5 — Verify it worked

• Check the objects and rules exist and are enabled on their respective pages (green/enabled status on the NAT policy and access rule).
• Confirm connections are matching. With logging on the access rule enabled, go to MONITOR | Logs (event log) and generate a test connection from outside; you should see the WAN→LAN allow entries.
• Watch live sessions. SonicOS 7 shows active connections under the monitoring section (the connection/flow table). A successful external request to https://<your-WAN-IP> should appear as a session with the translated destination 192.168.10.20.
• Test from the actual outside. Use a host that is genuinely off-network (a phone on cellular, an external checker) — testing from inside can succeed or fail for reasons unrelated to this rule.

If it doesn't connect, check in this order: the access rule (is it allowing WAN→LAN to the private object?), the NAT policy (right interfaces, translated destination is the host, translated service is Original), then the server itself (is 443 actually listening and is the server's default gateway the firewall?).

Undo / rollback

Because you built this in discrete pieces, remove it cleanly in reverse:

1. Delete or disable the access rule (POLICY | Rules and Policies | Access Rules).
2. Delete or disable the NAT policy (POLICY | Rules and Policies | NAT Policies).
3. Delete the address/service objects you added (they won't delete while a rule still references them, which is a useful safety check).

If anything is wrong and traffic is broken, don't troubleshoot live — restore the configuration you exported in "Before you run this" from DEVICE | Settings | Firmware and Settings. For exact field names on any screen and for the loopback-NAT and Public Server Wizard procedures, consult the official SonicOS 7 Rules and Policies administration guide on SonicWall's documentation site.