Sonicwall Port Forwarding is used in small and large businesses everywhere. We broke down the topic a further so you are not scratching your head over it.
How to Enable Port Forwarding
The illustration below features the older Sonicwall port forwarding interface. Please go to “manage”, “objects” in the left pane, and “service objects” if you are in the new Sonicwall port forwarding interface. Note: The illustration to the right, demonstrates really bad naming for troubleshooting port forwarding issues in the future. Please see the section below called “Friendly Service Names – Add Service” for understanding best practice naming techniques.
- Add Service
- Add All services into “Service Group”
- Add Address Object
- Add Inbound NAT
- Add Outbound NAT
- Add Access Rules – WAN to LAN
Friendly Service Names – Add Service
Some IT support label DSM_WebDAV, “Port 5005-5006” That’s fine but labeling “DSM_webDAV” is probably more helpful for everyone else trying to figure out what the heck you did. We jotted down our port forwarding game plan in a notepad before implementing the Sonicwall port forwarding. I suggest you do the same.
Friendly Service Group Name – Add Group
The illustration below features the older Sonicwall port forwarding interface. Please go to “manage”, “objects” in the left pane, and “service objects” if you are in the new Sonicwall port forwarding interface. You will see two tabs once you click “service objects”
- Service Objects
- Service Groups
- Please create friendly object names. See new Sonicwall GUI below.
Legacy GUI illustrated here.
Friendly Object Names – Add Address Object
Some support teams label by IP address in the “name” field. I suggest adding the name of the server you are providing access to.
Add Inbound NAT
Be default, the Sonicwall does not do port forwarding NATing. You have to enable it for the interface.
Add Outbound NAT
Best practice is to enable this for port forwarding.
WAN to LAN Access Rules
By default, the SonicWALL security appliance’s stateful packet inspection allows all communication from the LAN to the Internet. However, we have to add a rule for port forwarding WAN to LAN access. This is the last step required for enabling port forwarding of the above DSM services unless you don’t have an internal DNS server.
Hair Pin or Loopback NAT – No Internal DNS Server
“Hair pin” is for configuring access to a server behind the SonicWall from the LAN / DMZ using Public IP addresses. Basically, the DSM services that my LAN hosts do not work if my PC is pointed to an external IP and port. There’s a very convoluted Sonicwall KB article to read up on the topic more. We included an illustration to follow and break down the “hair pin” further below.
Hair Pin NAT Policy
New Hairpin or loopback rule or policy. This rule is neccessary if you don’t host your own internal DNS. THe routing table does not understand by default to send back internally because it thinks it an outside or external IP or service. THat’s why we enable Hairpin NAT.
(Source) LAN: 192.168.1.0/24 (PC) >> (Destination) WAN-X1 IP: 74.88.x.x:DSM services mysynology.synology.me -> needs to resolve DNS ping mysynology.synology.me (They’re default rules to ping the WAN Interface) (resolves WAN IP) port 5002 —> 192.168.1.97 mysynology.synology.me:5002
By default, my PC can hit the external WAN inteface but the Sonicwall will deny DSM (5002) services. It will be dropped.
Implement a NAT policy to trigger Destination IP 74.88.x.x and Port 5002 to work
74.x.x.x >>> 192.168.1.97 : original (DSM services)
No Outgoing Ports are not blocked by default
It’s important to understand what Sonicwall allows in and out. There are no outgoing ports that are blocked by default on the Sonicwall. Ie email delivery for SMTP relay. By default, all outgoing port services are not blocked by Sonicwall. Restart your device if it is not delivering messages after a Sonicwall replacement.
Traffic to LAN Blocked
The following behaviors are defined by the “Default” stateful inspection packet access rule enabled in the SonicWALL security appliance:
|•||Allow all sessions originating from the LAN, WLAN to the WAN, or DMZ (except when the destination WAN IP address is the WAN interface of the SonicWALL appliance itself)|
|•||Allow all sessions originating from the DMZ to the WAN.|
|•||Deny all sessions originating from the WAN to the DMZ.|
|•||Deny all sessions originating from the WAN and DMZ to the LAN or WLAN.|
NAT – Many to One NAT
***Need to talk public to private IP
This is the most common NAT policy on a SonicWall, and allows you to translate a group of addresses into a single address. Most of the time, this means that you’re taking an internal “private” IP subnet and translating all outgoing requests into the IP address of the SonicWall’s WAN port, such that the destination sees the request as coming from the IP address of the SonicWall’s WAN port, and not from the internal private IP address. View more info on the NAT topic here.
Sonicwall Port Forwarding Summary
Open up Ports