Manually opening Ports to allow (Webserver, FTP, Email, Terminal Service, etc.) from Internet to a server behind the SonicWALL in SonicOS Enhanced involves the following steps:

Step 1: Creating the necessary Address Objects
Step 2: Defining the appropriate NAT Policies (Inbound, Outbound and Loopback)
Step 3: Creating the necessary WAN > Zone Access Rules for public access
Recommendation: Use the Public Server Wizard to quickly configure your SonicWALL to provide public access to an internal server. The Public Server Wizard is the most ambitious and functional wizard developed to date. It simplifies the complex process of creating a publicly and internally accessible server resource by automating above mentioned steps.
Alert: The SonicWALL security appliance can be managed using HTTP (Port 80) or HTTPS (443) and a Web browser. Both HTTP and HTTPS are enabled by default. If you are using the SonicWALL WAN IPaddress for HTTP or HTTPS port forwarding to a server, then the default Management port must be changed to another unused port number (e.g. 8080, 444, 4443, etc.). You can change this underthe System > Administration page.
The following example covers allowing HTTP (webserver) service from the Internet to a server on the LAN with private IP address as  Once the configuration is complete, Internet users can access the HTTP (webserver) service behind the SonicWALL UTM appliance through the WAN (Public) IP address 
 In this example we have chosen to demonstrate using HTTP service, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).
Step 1: Creating the necessary Address Objects
1. Select Network > Address Objects.
2. Click the Add a new address object button and create two address objects one for Server IP on LAN and another for Public IP of the server: 
3. Click the OK button to complete creation of the new address objects.
Step 2: Defining the appropriate NAT Policies
1. Select Network > NAT Policies.
2. Click the Add a new NAT Policy button and chose the following settings from the drop-down menu:
Understanding how to use NAT policies starts with the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester’s IP address, the protocol information of the requestor, and the destination’s IP address. The NAT Policies engine in SonicOS Enhanced can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.
Note: Create a reflective policy: When you check this box, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy window is automatically created.
3. Click the Add button.
4.  Upon completion under Network > Nat Policies tab the above Inbound and Outbond NAT policies will be created. 
Loopback Policy:
If you wish to access this server from other internal zones using the Public IP address consider creating a Loopback NAT Policy else go to next step:
Original Source: Firewalled Subnets 
Translated Source: Mywebserver Public
Original Destination: Mywebserver Public
Translated Destination: Mywebserver Private
Original Service: HTTP
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any
Comment: Loopback policy
Enable NAT Policy: Checked
Create a reflexive policy: unchecked
Step 3: Creating Firewall Access Rules
1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3. Click Add a new entry and create the rule by entering the following into the fields:
Caution: The ability to define network access rules is a very powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.
4. Under the Advanced tab, you can leave the “Inactivity Timeout in Minutes” at 15 minutes. Some protocols, such as Telnet, FTP, SSH, VNC and RDP can take advantage of longer timeouts where increased values like 30 or 60 minutes can be tried with caution in those cases. Longer timeout values will not help at all for HTTP or HTTPS.
5: Click OK.