Automation 

Index

Automation

The automation component offers API access to firewall and source nat rules.

Partial API access is described in more detail in the firewall API reference manual.

Overview 

The automation filter pages use the MVC framework. This means, the component only has knowledge of rules created within it. Any firewall filter and NAT rules created outside the automation filter pages will not be collected via its API endpoint.

The UI component can be found in Firewall ‣ Automation. This shows a preview of the direction where the current Firewall ‣ Rules pages will be eventually superseded by the automation component.

Automation - Filter 

In Firewall ‣ Automation -> Filter, new firewall rules can be created.

User Interface 

At the top of the page, there are two selectpickers for interfaces and firewall groups and an inspect button.

Interface filter 

Choose an interface to filter the current view. Floating, group and single interfaces can be selected.

If you choose the “LAN” interface, you will be presented with all floating, group and single interface rules that influence packet decisions of the LAN interface.

If you create a new rule while having an interface selected, it will be automatically added to dialog.

Categories filter 

Choose one or multiple categories to filter the current view. This combines with the selection of the interface filter.

Categories can be created in Firewall ‣ Categories and can enable grouping different logic constructs.

If you create a category for mailservers and tag rules with it, you can simply filter for this tag and only see your mailservers.

As with the interface filter, selecting one or multiple tags will add them automatically to a new rule.

Inspect button 

The inspect button will reveal all system defined firewall rules and show rule statistics. It can be enabled at any time to get a complete view of the current active ruleset.

Available rule parameters 

Option	Description
Enabled	Enable this rule
Sort order	The order in which rules are being processed.
Sequence	The order in which rules are being processed. Please note that this is not a unique identifier, the system will automatically recalculate the ruleset when rule positions are changed with the available “Move rule before this rule” button.
Categories	For grouping purposes you may select multiple groups here to organize items.
No XMLRPC Sync	Exclude this item from the HA synchronization process. An already existing item with the same UUID on the synchronization target will not be altered or deleted as long as this is active.
Description	You may enter a description here for your reference (not parsed).

Option	Description
Quick	If a packet matches a rule specifying quick, then that rule is considered the last matching rule and the specified action is taken. When a rule does not have quick enabled, the last matching rule wins.
Action	Choose what to do with packets that match the criteria specified below. Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded.
Allow options	This allows packets with IP options to pass. Otherwise they are blocked by default.
Direction	Direction of the traffic. The default policy is to filter inbound traffic, which sets the policy to the interface originally receiving the traffic.
Version
Protocol
Invert Source	Use this option to invert the sense of the match.
Source
Source Port	Source port number or well known name (imap, imaps, http, https, …), for ranges use a dash
Invert Destination	Use this option to invert the sense of the match.
Destination
Destination Port	Destination port number or well known name (imap, imaps, http, https, …), for ranges use a dash
Log	Log packets that are handled by this rule
TCP flags	Use this to choose TCP flags that must be set this rule to match.
TCP flags [out of]	Use this to choose TCP flags that must be cleared for this rule to match.
Schedule

Option	Description
State type	State tracking mechanism to use, default is full stateful tracking, sloppy ignores sequence numbers, use none for stateless rules.
State policy	Choose how states created by this rule are treated, default (as defined in advanced), floating in which case states are valid on all interfaces or interface bound. Interface bound states are more secure, floating more flexible
State timeout	State Timeout in seconds (TCP only)
Adaptive Timeouts [start]	When the number of state entries exceeds this value, adaptive scaling begins. All timeout values are scaled linearly with factor (adaptive.end - number of states) / (adaptive.end - adaptive.start).
Adaptive Timeouts [end]	When reaching this number of state entries, all timeout values become zero, effectively purging all state entries immediately. This value is used to define the scale factor, it should not actually be reached (set a lower state limit).
Max states	Limits the number of concurrent states the rule may create. When this limit is reached, further packets that would create state are dropped until existing states time out.
Max source nodes	Limits the maximum number of source addresses which can simultaneously have state table entries.
Max source states	Limits the maximum number of simultaneous state entries that a single source address can create with this rule.
Max source connections	Limit the maximum number of simultaneous TCP connections which have completed the 3-way handshake that a single host can make.
Max new connections [c]	Maximum new connections per host, measured over time.
Max new connections [s]	Time interval (seconds) to measure the number of connections
Overload table	Overload table used when max new connections per time interval has been reached. The default virusprot table comes with a default block rule in floating rules, alternatively specify your own table here
NO pfsync	This prevents states created by this rule to be synced with pfsync.

Option	Description
Traffic shaper	Shape packets using the selected pipe or queue in the rule direction.
Traffic shaper [reverse]	Shape packets using the selected pipe or queue in the reverse rule direction.

Option	Description
Gateway	Leave as ‘default’ to use the system routing table. Or choose a gateway to utilize policy based routing.
Disable reply-to	Explicit disable reply-to for this rule
Reply-to	Determines how packets route back in the opposite direction (replies), when set to default, packets on WAN type interfaces reply to their connected gateway on the interface (unless globally disabled). A specific gateway may be chosen as well here. This setting is only relevant in the context of a state, for stateless rules there is no defined opposite direction.

Option	Description
Match priority	Only match packets which have the given queueing priority assigned.
Set priority	Packets matching this rule will be assigned a specific queueing priority. If the packet is transmitted on a vlan(4) interface, the queueing priority will be written as the priority code point in the 802.1Q VLAN header
Set priority [low-delay]	Used in combination with set priority, packets which have a TOS of lowdelay and TCP ACKs with no data payload will be assigned this priority when offered.
Match TOS / DSCP

Option	Description
Set local tag	Packets matching this rule will be tagged with the specified string. The tag acts as an internal marker that can be used to identify these packets later on. This can be used, for example, to provide trust between interfaces and to determine if packets have been processed by translation rules. Tags are “sticky”, meaning that the packet will be tagged even if the rule is not the last matching rule. Further matching rules can replace the tag with a new one but will not remove a previously applied tag. A packet is only ever assigned one tag at a time.
Match local tag	Used to specify that packets must already be tagged with the given tag in order to match the rule.
Evaluations
States
Packets
Bytes
Icons

Sort Order and Sequence 

While rules in Firewall ‣ Rules are processed implicitely by the order they appear in the configuration file, Firewall ‣ Automation filter rules implement a more explicit Sort order.

A Sort order will have this structure: 200000.0000250:

200000 The Prefix, defines the hierarchy the rule belongs to. It can be influenced by the interface in a rule.

.0000250 The Sequence, it defines the exact spot of the rule in context of the interface hierarchy. It can be influenced with the Sequence field inside a rule, or with the Move rule before this rule button.

As example, we create a few different rules:

200000.0000100 (Floating rule)

200000.0000200 (Floating rule)

300000.0000050 (Group rule)

300000.0000060 (Group rule)

400000.0002000 (Interface rule)

400000.0003100 (Interface rule)

When applying the filter, the rules will be processed in this Sort order.

Note

The Sequence does not have to be unique, multiple rules can share the same number. Though what this means is that the filter is not populated as strictly in order as if all rules have a unique sequence.

Tip

When adding a new rule, the Sequence will be automatically populated with a unique number. You can either change this number manually to adjust the exact position of the rule, or use the Move rule before this rule button.

Processing Order 

Since Firewall ‣ Automation and Firewall ‣ Rules component exist side by side, there are some considerations regarding the processing order of rules.

If an Firewall ‣ Automation filter rule has:

a single interface defined, it is an Interface Rule

a group interface defined, it is a Group Rule

any number of interfaces defined, it is a Floating Rule

Processing order:

System defined rules at the beginning of the ruleset

Firewall ‣ Automation and Firewall ‣ Rules floating rules

Firewall ‣ Automation and Firewall ‣ Rules group rules

Firewall ‣ Automation single interface rules

Firewall ‣ Rules single interface rules

System defined rules at the end of the ruleset

Automation - Source NAT 

In Firewall ‣ Automation -> Source NAT, new source NAT rules (also known as Outbound NAT or Masquerading) can be created.

These automation source NAT rules will match before Firewall ‣ NAT defined ones.

Option	Description
Invert Interface	Use all but selected interfaces
Interface