Creating a Firewall Rule is a very simple and easy process (see Adding a Firewall Rule for an example). This article however, will discuss the fundamental basics of what requirements are needed in order to understand how a Firewall rule is generated, and in turn, how it works. 


A Firewall Rule can be generated in any Group on Sonar. Any Group with a Firewall rule that is not in a System Group, is classified as a Group Firewall Rule. This means, any Group Firewall Rule can only be utilised by people who are a member of that group. Any Firewall rule created in the System Group is applied to all users, no matter which Group they are a member of. These are Global Firewall Rules. In every Group, you can create a Firewall rule in Rules -> Access.


There are 2 things that are required when creating a Firewall Rule in Sonar. 

  • Network Objects
  • Rule Object

A network object is something that represents an IP or a Range of IP's. whether it be a Private or Public IP addresses. These objects are essential in determining what your Firewall Rules are affecting. Each Network objects also have an Inbound and Outbound NAT (Network Address Translation) properties. These are required when you need these particular objects to talk out to the internet. If your Firewall Rule destination is somewhere outside your network, an Outbound NAT Property is required to translate the private address into a public address. (see Adding a Network Object for more information)

 If the destination of your Firewall Rule is inside your network, you need an Inbound NAT property to translate public addresses into private. 


Continuing on from the previous topic on using Inbound and Outbound NAT properties, choosing which one to use can also be a bit confusing as well.


  • None - When you do not require an outbound NAT property to be set on a particular Object. Used for Internal Firewall rules. 
  • PAT (Port Address Translation) - PAT is automatic translation out to the internet. It's when you do not care how the translation is done. This is the more commonly used. 
  • SNAT (Source Network Address Translation) - SNAT is used when you want to specify a particular address you want traffic to be seen as on the internet. A great example is Mail Servers. A Mail Server must be seen out on the internet as the same IP as it's MX Record. For this, we use a SNAT to ensure that the Mail Server uses the correct Public IP when publishing to the internet. 


  • None - When you do not require an Inbound NAT property to be set. This is usually the default for most objects. 
  • DNAT (Destination Network Address Translation) - Similar to an SNAT in some ways, except you're specifying the Public Address you want outside traffic to come in on, to be port forwarded to your internal server.


Aside from the Network Objects, Rule Objects are just as important when creating a Firewall Rule. They determine what ports to allow the traffic through on, whether it be on a single port, or multiple ports (see: Adding Rule Objects for more information). Multiple Rule Objects can be added to one Firewall Rule in order to open up several ports of different protocols.


With the knowledge of Firewall Rules and what is required, you should have a better understanding now of what is needed when creating a Firewall Rule for Groups. If you go to a Group or the System Group and under Rules -> Access, click "Add New" to create a new Rule, you will see several fields which should be fairly self-explanatory.

  • Sources - Where the traffic for the Rule is originating from. 
  • Destinations - Where the traffic for the Rule is going to. 
  • Rules - What ports you want to open up for the Rule, for example, HTTP and HTTPS traffic (80 and 443).

If your Network objects contain any Inbound or Outbound NAT Properties, when you click "OK" to apply the rule, Sonar will ask you if you would like to "Auto Generate Translation Rules". If your Rule is traversing the internet, then you want to select "Yes" for this to auto-generate any NAT rules in the NAT Table.