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
Open up Ports
- 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.
Friendly Service Group Name – Add Group
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: 18.104.22.168:DSM services 92109.synology.me -> needs to resolve DNS ping 92109.synology.me (They’re default rules to ping the WAN Interface) (resolves WAN IP) port 5002 —> 192.168.1.97 diskstation.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 22.214.171.124 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.