Firewall Rule Tutorial

This description is addressed to advanced users only.
Incorrect editing of the firewall rules may cause security risks!

Editing the firewall rules manually allows greater control of what is allowed through the firewall, but is also much more complicated than using the Security Profile pages.

This tutorial will give you some examples of what can be achieved by editing the firewall rules manually.

Firewall rules are parsed line-by-line, top to bottom. If a matching rule is found, the rest of the rules are ignored. Meaning if a matching accept rule has been found, it does not matter if you have a deny rule further down – it is ignored:

dport >= 2000 && dport <= 2010 accept 
dport == 2003 deny

Port 2003 will also be accepted, as the first rule matches 2003, and accepts it. The deny rule is never reached! For the desired functionality, the rules should be entered in reverse order:

dport == 2003 deny 
dport >= 2000 && dport <= 2010 accept

If there is no rule that allows a packet through the firewall, it is stopped by the default “deny all” rule.

The settings on the security profile page is translated into firewall rules that you can see on the firewall rules page. Using “Additional rules” on the security profile page you can add your own hand-written rules to the automatically generated ones.

It is very difficult to get a visual picture of what is going on inside the firewall. Such pictures easily become either too simplified or too complex. Here you see one attempt:

A packet on its way through the firewall will be checked against several rulesets. Usually the incoming super, and incoming user of the receiving interface, and the outgoing user and outgoing super of the transmitting interface. There can also be flows that bypass the user rules, but apply stateful inspection and modifications to the packets.

To get a packet through all the way, we need to make sure it is allowed to pass all the rulesets, and can be routed correctly by the router between the interfaces.

When entering rules manually, follow the way of the first packet through the rulesets to make sure you enter all the needed rules in their correct places.

In example 1 you can see how the checkboxes on the Security Profile pages create firewall rules, and how you can modify them.

In example 2 you can see how to open incoming ports manually, thus allowing data coming from the Internet to get through the firewall.

In example 3 you can see how to open outgoing ports manually, thus allowing your PCs to reach the Internet through the firewall.

In example 4 you can see how to redirect traffic between interfaces.

The firewall rule syntax lists all available rules, with some more examples, and a walk-through of the default “Hi” rules.

The modify action has several arguments. Choosing the correct ones might seem difficult, but there is some simple rule-of-thumbs making the task simpler.

This action creates two flows that are stateful inspected and modified. The modification is static: always the same for all data streams. You enter manually what fields of the packet headers to modify. modify static is mostly used for port redirections – see example 2 for details.

This action also creates two flows that are stateful inspected and modified. But the modification is dynamic: it is different for different data streams. The port number chosen is not hard coded but taken from a pool of available ports. Even though you specify a pool number, currently there is only one pool available: pool 0. Arguments source and destination are similar to sport and dport but they change the IP address too, to the global IP address. modify dynamic is mostly used for allowing applications from the inside to get out through the firewall – see example 3 for details.

This is a special case of the modify action that creates no flows, no stateful inspection, merely modifies packet header fields. It is very seldom used, only in special cases.

Another special case: Creates two flows that are stateful inspected, but performs no modifications on the packets. It is very seldom used, only in special cases.

In the vast majority of cases you should enter your modify rule in one of the user rules of the outside interface.