Configure Port Forwarding to an Internal Server on a SonicWall

Before you run this

This guide publishes one internal server on one port to the internet through a SonicWall. You will create an address object for the server, pick or create a service (port) object, add an inbound NAT policy that rewrites the destination to the internal host, and add a WAN→LAN access rule that permits the traffic. Both pieces are required: the NAT policy alone forwards nothing without the matching access rule.

• Privileges: you need an administrator login to the SonicWall management UI (the built-in admin account or an account with full config rights). Everything here is done in the web GUI on SonicOS 7.0 / 7.1 (TZ and NSa series). Older SonicOS 6.5 has the same concepts but different menu names.
• This opens a hole in your firewall. You are deliberately allowing unsolicited inbound traffic from the entire internet to an internal host. Scope the service and source as tightly as you can, and never publish RDP, SMB, or a database port raw to Any — put it behind a VPN or restrict the source.
• Keep a second way in. Before you touch anything, confirm you have out-of-band access: the physical console port (SonicWall ships a serial/RJ-45 console cable) or LAN-side management from inside. A wrong access rule or NAT can break management or production traffic.
• Back up first. Go to Device > Settings > Firmware and Settings, create a local backup and export the settings file to your workstation. SonicOS has no timed commit or auto-rollback — changes are live the moment you click Accept/Save. Your rollback path is re-importing that exported settings file (same page, Import Settings), which reboots the unit.
• Do this in a maintenance window, and test against a lab unit or a throwaway service before publishing anything production-critical. Read each rule back before you save it.

I'll use these placeholders throughout — substitute your own:

• Internal server IP: 192.168.10.50 (on your LAN)
• WAN interface: X1
• LAN interface: X0
• Public service: HTTPS / TCP 443 (SonicOS ships this as a built-in service object)

Step 1 — Create an address object for the internal server

Object > Match Objects > Addresses, then Add.

• Name: srv-web-internal (something you'll recognise later)
• Zone Assignment: LAN
• Type: Host
• IP Address: 192.168.10.50

Save. If the server sits in a DMZ zone instead of LAN, set the zone to match where it actually lives — this matters for the access rule direction later.

Step 2 — Confirm or create the service object

Object > Match Objects > Services. For standard ports, SonicOS already has the object — HTTPS (TCP 443), HTTP (TCP 80), and so on. Use the built-in one.

Only create a custom service if you're forwarding a non-standard port or doing port translation (public 8443 → internal 443). To add one, click Add:

• Name: custom-tcp-8443
• Protocol: TCP(6)
• Port Range: start and end both 8443

Step 3 — Add the inbound NAT policy

Policy > Rules and Policies > NAT Rules, then Add. This is the rule that rewrites the public destination to your internal host.

For a straight forward of HTTPS to the server:

Field	Value
Original Source	Any (or a restricted source group — see below)
Translated Source	Original
Original Destination	your WAN interface IP object (e.g. X1 IP) — or a Public Address Object if you're using a secondary public IP
Translated Destination	srv-web-internal
Original Service	HTTPS
Translated Service	Original (use a different service object only if translating the port)
Inbound Interface	X1
Outbound Interface	Any

Leave it Enabled and save.

A note on Original Destination: if you have a single WAN IP, use the object that represents your WAN interface address. SonicOS auto-creates an interface IP object per interface. If your public IP is a static one not bound to an interface, create a Host address object in the WAN zone for it first and use that here. Don't guess the object name — check it under Object > Match Objects > Addresses and filter by the WAN zone.

If you're translating the port (public 8443 → internal 443), set Original Service to your custom-tcp-8443 object and Translated Service to HTTPS.

Step 4 — Add the WAN→LAN access rule

The NAT policy tells the firewall where to send the packet; the access rule tells it whether it's allowed. Both must exist.

Policy > Rules and Policies > Access Rules, then Add.

• From: WAN
• To: LAN (or DMZ if the server is there — match Step 1's zone)
• Source Port / Zone: Any
• Service: HTTPS
• Source: Any (see the tightening note below)
• Destination: srv-web-internal — the private address object, not the WAN IP. In SonicOS the access rule is evaluated against the post-NAT (internal) destination.
• Action: Allow

Save. Order generally doesn't need adjusting for a single new allow rule, but confirm no broader deny above it would shadow it.

Tighten the source where you can

If only known networks should reach this service, don't leave Source as Any. Create an address object or group for the permitted public IPs and set both the NAT policy's Original Source and the access rule's Source to that group. This is the single most valuable thing you can do here for anything more sensitive than a public website.

The wizard alternative

SonicOS 7 includes a Public Server Wizard (reachable from the Quick Configuration / wizards area) that creates the address object, service, NAT policy, and access rule in one pass. It's fine and produces the same objects. I prefer the manual path above because you see exactly what each object is and can name them consistently, which makes cleanup and auditing far easier later.

Verify it worked

1. From outside the network (a phone on cellular, or a remote host — not from inside your LAN, where hairpin/NAT-loopback behaviour differs), connect to your public IP on the published port: https://<your-public-ip> or curl -vk https://<your-public-ip>.
2. On the SonicWall, watch Monitor > Logs > System Logs (or the connection monitor under Monitor > Connections) and confirm you see the connection hitting the NAT policy and being allowed, not dropped.
3. On the NAT Rules and Access Rules pages, SonicOS shows a hit/packet counter per rule — confirm the counters increment when you test.
4. Confirm the internal server itself is listening and its own host firewall permits the source — a dropped connection at the SonicWall logs differently from one that reaches the server and is refused there.

If it fails: check the log for a dropped entry. A drop with no matching allow means the access rule is wrong (zone or destination object); a connection that never appears means the NAT policy's Original Destination or interface is wrong.

How to undo it

Because SonicOS applies changes immediately, undo is manual and in reverse order:

1. Policy > Rules and Policies > Access Rules — delete the WAN→LAN rule you added.
2. Policy > Rules and Policies > NAT Rules — delete the inbound NAT policy.
3. Object > Match Objects > Services / Addresses — delete any custom service and address objects you created (address objects still referenced elsewhere won't delete until the references are gone).

If anything is unclear or you want to roll the whole change back at once, restore the settings file you exported in Before you run this via Device > Settings > Firmware and Settings > Import Settings — note this reboots the appliance and reverts all config to that snapshot.

For exact field definitions and any option your firmware build renames, see SonicWall's own SonicOS 7 Policies / NAT administration guide on the SonicWall documentation site rather than trusting a screenshot from a different version.