I have worked with a handful of firewalls in my time. I have worked with the likes of WatchGuard, FortiNet, Sonicwall, Cisco, and a few others. Up until tonight, I thought that they all had their advantages and disadvantages as well as having their own way of doing things. I have extensive experience with WatchGuard devices. I have found that they make life very easy when it comes to firewall implementation and maintenance. Creating rules in their firewall is very simple and straightforward. Unlike some brands, when you define a NAT rule, in the WatchGuard, it assumes that the source port is randomized and only deals with the destination port in its definitions. Cisco typically handles things this way as well. Now, crack open the configuration on the Fortinet and you will be staring down the barrel of the source port question. This is still fairly easy to tackle and can be handled most of the time with defining source ports 1-65536.
Let me step you through a inbound server connection on HTTP, HTTPS, and terminal services on the Firebox. I can create a custom policy type that defines TCP ports 80, 443, and 3389 then apply it to a new rule or I can just as easily define three rules using the pre-configured policies types. Once the type has been chosen, I pick my source and my destination. In my destination I can define that it is a NAT and pick which external interface, combination of interfaces, or IP address will answer this on the external and then choose my internal IP address of the server responding to these requests. Did I mention I can also remap what port it sends to the answering server? There! I have made a rule that tells what, where from, and where to in one easy clean rule.
Now let’s try this on the Sonicwall. I am going to create a service group of the same three inbound server types. I can then create a firewall rule allowing traffic from WAN to pass to LAN using that service rule. Wait, where did I tell it what IP to answer on and what IP to send that to?? That’s done in Network, under address objects. I can define my alternate external IP address and the IP of my internal server. Now I can define the rule….right? Wrong. There is no place in the firewall rule to do this! To do this, you have to go under NAT policies and define it there. So now I can pick my external object, internal object, and service group and define the rule. Does it work? NO!!!!!! I haven’t yet defined the response! So now I have to define a NAT rule for the server to respond to that request. You can’t just assume that??? To Sonicwall’s benefit, they have something built in that takes the guess work out of all this. They have a wizard that creates all this for you.
To tell you how ridiculous this process really is. If I want to create a custom RDP rule in WatchGuard to map port 3388 to an internal server. I have to create the custom policy and then the rule using that policy. Two locations. when I create the same rule in the Sonicwall, I have to define the service. Start the wizard, give it everything it needs, and boom! Done. What did it do? It created ANOTHER service by the name I defined in the wizard, created a network object by the same name, created a firewall rule by the same name, and created 3 NAT policies! This is just clutter in the rule set that will eventually slow down the device in general. Not to mention how slow it makes troubleshooting when you go to look at the rules to see what is there and what it is supposed to be doing.
My take on Sonicwall is that while they are a strong company that obviously makes a good product, otherwise they would be out of business, their way of thinking is completely overkill in most areas and brain dead stupid in other places. I would say they are like having a car with a gas powered engine that has a rocket-fuel powered air conditioner that only works if you have the radio on the right station and you don’t sit in the driver seat.
If you bring me a Sonicwall to setup for you, don’t be surprised when I start getting a strange twitch in my eye.