Sonicwall TZ215 port forwarding quick start

We recently took delivery of a Sonicwall TZ215 firewall. I must say, its quite a nice bit of kit, and some nifty features. There are lots of video tutorials on their website,  and on youtube. I recommend this knowledgebase arcticle as a good starting point if, like me, you prefer to read rather than sit and watch a 15 minute video that tells you one thing.

With firewalls being your front line defence, it’s certainly wise to make sure you learn how they work properly. However, the real-world dictates that sometimes things need to be set up quickly. Port-forwarding, being a pretty basic function of a firewall-router, is one of those things. Its normally straight-forward on your standard DSL/cable modem. The Sonicwall, I guess due to its power and flexibility, is a bit more involved. It does provide a wizard for this, but I think it’s definitely worth seeing what is involved in doing it “long hand”, as it will give you a good insight to how the firewall works as a whole. So here is a quick “how to”:

Assuming you want to forward an incoming port 80 request, to the web server myserver with IP 192.168.1.5 on your internal network

Log on as an administrator to your Sonicwall web UI

Create an address object for myserver

Every host or network that you want to refer to in your NAT or Firewall policies needs to be defined as an “address object”

    • Go to Network > Address Objects
    • Scroll down past Address Groups to Address Objects and click Add
    • Fill in the details of your server, Zone will be LAN and type is Host
Add Address Object
Add Address Object

Create a NAT policy

This is where the magic happens. You are defining how Sonicwall should manipulate incoming (and outgoing packets).  I find it helpful think of the policies in terms of how TCP/IP headers look coming in and going out (src address, src port, dst address, dst port fields)

  • Go to Network > NAT Policies
  • Click Add, fill in the fields:
Add NAT Policy
Add NAT Policy
  • Original Source: the packet is coming from anywhere on the internet, so select Any
  • Translated Source: we don’t want to hide the address of where the request came from, so set to Original
  • Original Destination: the incoming packet will be addressed to one of your internet facing IPs (not your internal IP, as that wouldn’t work!), so set to All WAN IP or Primary WAN IP, as appropriate
  • Translated Destination: you want your Sonicwall to re-write the packet so that your internal server is now the dst address, so set to myserver
  • Original Service: the incoming packet is addressed to port 80, the standard port for HTTP, so select HTTP
  • Translated Service: we want the packet to go to port 80 on myserver so we can leave the port unchanged, so select Original. If your server was listening on a non-standard port, 8080 perhaps, you could set that here
  • Inbound Interface: set this to X1, this the interface connected to the internet (WAN)
  • Outbound Interface: you can leave this as Any, since sonicwall will decide itself which interface that packet needs to go out on, based on its routing tables
  • Enable NAT Policy: have ticked, this is so that you can switch existing policies on and off easily
  • Create a reflexive policy: have unticked – we only need this for one way

Allow the packets through the firewall

We are now set up as far as the port forwarding goes, but we need to actually allow the packets through the firewall for it to be of any use!

  • Go to Firewall > Access Rules
  • Click Add, fill in the fields:
Add Firewall Access Rule
Add Firewall Access Rule
  • Action: we want to Allow the packet in
  • From Zone and To Zone: we are going from the internet, WAN to the private internal network, LAN
  • Service is port 80, HTTP
  • Source: we want to allow everyone in! Any
  • Destination: remember we are talking about how the incoming packet looks, so it’s dst address will be set to one of the WAN IPs, not the internal IP, so choose ALL WAN IP
  • The other fields we can ignore, for our purposes.

That’s it. We’re done!