Rules

Overview

Ixolate contains a stateful packet filter, which can be used to restrict or allow traffic from and/or to specific networks as well as influence how traffic should be forwarded (see also policy based routing in “`Multiwan </network/multi-wan>`_”).

The rules section shows all policies that apply on your network, grouped by interface.

There are two implementations to choose from:

• Rules [new]: a modern MVC implementation with API support and improved rule management
• Rules: a static PHP page with no API support

The basics

Before creating rules, it’s good to know about some basics which apply to all rules.

States

By default rules are set to stateful (you can change this, but it has consequences), which means that the state of a connection is saved into a local dictionary which will be resolved when the next packet comes in. The consequence of this is that when a state exists, the firewall doesn’t need to process all its rules again to determine the action to apply, which has huge performance advantages.

Another advantage of stateful packet filtering is that you only need to allow traffic in one direction to automatically allow related packets for the same flow back in. Below diagram shows a tcp connection from a client to a server for https traffic, when not using stateful rules, both the client should be permitted to send traffic to the server at port 443 as the server back to the client (usually a port >=1024).

blockdiag {
group {
color = “#eee”; label = “Client [tcp:1024]”; client_req [label=“request”]; client_res [label=“”];

}

group {
color = “#eee”; label = “Firewall”; firewall_req [label=“”]; firewall_res [label=“”];

}

group {
color = “#eee”; label = “Server [tcp:443]”; server_req [label=“”]; server_res [label=“reply”];

} client_req -> firewall_req -> server_req [color=green]; client_res <- firewall_res <- server_res [color=red]; }

The use of states can also improve security particularly in case of tcp type traffic, since packet sequence numbers and timestamps are also checked in order to pass traffic, it’s much harder to spoof traffic.

States can also be quite convenient to find the active top users on your firewall at any time, we added an easy to use “session” browser for this purpose. You can find it under Firewall › Diagnostics › Sessions.

Action

Rules can be set to four different action types:

• Pass –> allow traffic
• Block –> deny traffic and don’t let the client know it has been dropped (which is usually advisable for untrusted networks)
• Reject –> deny traffic and let the client know about it. (only tcp and udp support rejecting packets, which in case of TCP means a RST is returned, for UDP ICMP UNREACHABLE is returned).
• Match –> apply rule options without deciding whether traffic is passed or blocked. This action is available in Firewall › Rules [new] and is commonly used for normalization.

For internal networks it can be practical to use reject, so the client does not have to wait for a time-out when access is not allowed. When receiving packets from untrusted networks, you usually don’t want to communicate back if traffic is not allowed.

Processing order

Firewall rules are processed in sequence per section, first evaluating the Floating rules section followed by all rules which belong to interface groups and finally all interface rules.

Internal (automatic) rules are usually registered first.

blockdiag {
System [label=“System defined”, style = dotted]; Floating [label=“Floating rules”]; Groups [label=“Interface groups”]; Interfaces [label=“Interfaces”]; System -> Floating -> Groups -> Interfaces;

}

Rules can either be set to quick or not set to quick, the default is to use quick. When set to quick, the rule is handled on “first match” basis, which means that the first rule matching the packet will take precedence over rules following in sequence.

When quick is not set, last match wins. This can be useful for rules which define standard behaviour. Our default deny rule uses this property for example (if no rule applies, drop traffic).

Match rules are usually not quick, allowing later rules to make the final pass or block decision. A quick match rule can still be used intentionally when no later rule options should be evaluated.

Since Firewall › Rules [new] and Firewall › Rules implementations exist side by side, there are some additional considerations regarding the processing order of rules.

If a Firewall › Rules [new] 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 or one inverted interface defined, it is a Floating Rule

Processing order:

1. System defined rules at the beginning of the ruleset
2. Firewall › Rules [new] and Firewall › Rules floating rules
3. Firewall › Rules [new] and Firewall › Rules group rules
4. Firewall › Rules [new] single interface rules
5. Firewall › Rules single interface rules
6. System defined rules at the end of the ruleset

Rule sequence

The sequence in which the rules are displayed and processed can be customized per section:

• Select a rule with the checkbox on the left side of the rule.
• Use the arrow button in the action menu on the right side of a rule in order to move selected rules before the rule where the action button is pressed.

While rules in Firewall › Rules are processed implicitly by the order they appear in the configuration file, Firewall › Rules [new] implement a more explicit Sort order.

A Sort order will have this structure: 200000.0000250:

• 200000 The Priority group, 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. A lower sequence number inside the priority group means the priority is higher.

Direction

blockdiag {
source [label=“Source”]; firewall [label=“Firewall”]; destination [label=“Destination”]; source -> firewall [label=“in”] firewall -> destination [label=“out”];

}

Traffic can be matched on in[coming] or out[going] direction, our default is to filter on incoming direction. In which case you would set the policy on the interface where the traffic originates from.

For example, if you want to allow https traffic coming from any host on the internet, you would usually set a policy on the WAN interface allowing port 443 to the host in question.

Implementations

Rules [new]

Rules [new] started out as Firewall Automation with a limited GUI to offer API support, since the static php implementation of Rules lacked automation requirements. Over time, more features have been added, and the GUI has been completely reworked. Long requested features like advanced search functionality, category folders improved performance and better visibility are the result.

You can find it in Firewall › Rules [new] or Firewall › Automation › Filter.

User Interface

Our overview shows all the rules that apply to the selected interface, group or floating section. For every rule, some details are provided and when applicable you can perform actions such as move, edit, copy, delete.

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

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.

Tree button

Group all firewall rules in a tree, based on their category. The groups act like folders, but always honor the sort order and sequence. The group folders are not saved inside the configuration, they are an alternative view based on categories.

Whenever a rule in sequence changes category, a new folder copying the category of the first rule will be created. To move similiar rules into the same folder, change their sequence and category. But keep in mind that the sequence of rules will always be the same as without the tree view.

Inspect button

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

While in inspect mode the search can find IP addresses inside aliases.

Rule statistics are cached. To pull the latest statistics, press the refresh button in the statistics column.

Settings

Organisation

Interface

Filter

Normalization

Normalization options can be applied by Match or Pass rules. See Firewall scrub for details.

Stateful firewall

Rate limiting

Traffic shaping [experimental]

Source Routing

Priority

Internal tagging

Audit

Divert-to

With divert we can integrate additional policy constructs into firewall rules. A rule with “divert-to” can send all packets to a divert socket, on which a service like Ips can listen.

This can provide more fine grained control than intercepting all traffic for inspection. It can improve performance because large flows that do not necessarily need inspection can be excluded.

As an example, go to Services › Intrusion Detection › Administration and set the “Capture mode” to “Divert (IPS)”.

Afterwards, create a firewall rule that matches the traffic that should be inspected and set the “Divert-to” settings in that rule. Matching packets will be diverted to the socket the intrusion detection listens on. After making a decision, the packet will then be forwarded or dropped.

Rules

Rules is the implementation that has been around since day one. Since it consists of static php pages, there is no API support, Over time, it will be replaced by Rules [new] and a Migration assistant can be found in Firewall › Rules › Migration assistant.

User Interface

Our overview shows all the rules that apply to the selected interface (group) or floating section. For every rule some details are provided and when applicable you can perform actions, such as move, edit, copy, delete.

Below you will find some highlights about this screen.

1. Interface name
   The name of the interface is part of the normal menu breadcrumb

2. Category
   If categories are used in the rules, you can select which one you will show here.

3. Toggle inspection
   You can toggle between inspection and rule view here, when in inspection mode, statistics of the rule are shown. (such as packet counters, number of active states, …)

4. Show / hide automatic rules
   Some rules are automatically generated, you can toggle here to show the details. If a magnifying glass is shown you can also browse to its origin (The setting controlling this rule).

5. Automatic rules
   The contents of the automatic rules

6. User rules
   All user defined rules

Settings

Traffic that is flowing through your firewall can be allowed or denied using rules, which define policies. This section of the documentation describe the different settings, grouped by usage.

Organisation

Some settings help to identify rules, without influencing traffic flow.

Basic settings

Below are the settings most commonly used:

Troubleshooting

While building your ruleset things can go wrong, it’s always good to know where to look for signs of an issue. One of the most common mistakes is traffic doesn’t match the rule and/or the order of the rule doesn’t make sense for whatever reason.

With the use of the “inspect” button, one can easily see if a rule is being evaluated and traffic did pass using this rule. It’s also possible to jump directly into the attached states to see if your host is in the list as expected.

Another valuable tool is the live log viewer, in order to use it, make sure to provide your rule with an easy to read description and enable the “log” option.

If your using source routing (policy based routing), debugging can sometimes get a bit more complicated. Since the normal system routing table may not apply, it helps to know which flow the traffic actually followed. The packet capture is a useful tool in that case.

Common issues in this area include return traffic using a different interface than the one it came into, since traffic follows the normal routing table on it’s way out (reply-to issue), or traffic leaving the wrong interface due to overselection (matching internal traffic and forcing a gateway).

Inspecting used netmasks is also a good idea, intending to match a host but providing a subnet is a mistake easily made (e.g. 192.168.1.1/32 vs 192.168.1.1/24 is in reality all of 192.168.1.x).

Last but not least, remember rules are matched in order and the default (inbound) policy is block if nothing else is specified, since we match traffic on inbound, make sure to add rules where traffic originates from (e.g. lan for traffic leaving your network, the return should normally be allowed by state).