Rules Overview in Untangle SD-WAN Router

Summary

Untangle SD-WAN router uses rules in many areas of the configuration. Rules follow a common set of criteria and behavior. This article provides an explanation of rule processing and components in Untangle SD-WAN Router.

Conditions & Syntax

Rule can have a list of conditions. The conditions define what elements match the existing rule upon evaluation. If a rule has no conditions, it always matches. A condition has a type, operator, and a value.

For a complete description of Rule Syntax and Conditions refer to Conditions Syntax in Untangle SD-WAN Router rules.

Rule Execution

Rules determine how to handle network traffic. For example, "Filter" rules determine whether to allow or block a certain type of traffic.

Each rule comprises of

  • a description,
  • zero or more conditions
  • an action to take if all the above conditions match
  • a flag to enable or disable the rule

Rules are evaluated from the top down until a matching rule condition is found. The corresponding action is performed and no further rules are evaluated.

For example, a rule to allow port 80 TCP to pass would look like:

mceclip0.png

This rule can be interpreted as "If the packet has an IP protocol of TCP and a destination of port 80, then allow this packet to pass and cease checking the packet for any more rules."

When evaluating this rule, if the packet is not TCP or it doesn't have a destination port of 80, then this rule does not match and subsequent rules are evaluated.

Rulesets

Rules can be grouped together to form a set of rules to achieve a desired effect. Using the example of filter rules, two very common types of rulesets for filter rules are
* Accept everything and explicitly block some traffic
* Reject all traffic except things explicitly allowed

An example of the "Accept all except certain traffic" ruleset would comprise of two rules as follows:

Rule 1: "If the packet is a TCP packet and has a destination port of 21 then drop"
Rule 2: "Accept all packets"

This simple ruleset drops all TCP port 21 packets, and allows anything else.

Rule 1 just drops the TCP port 21 packets, and for all packets that are not port 21 and TCP, the second rule is evaluated.
Rule 2 has no conditions attached to it, therefore all packets will match it if they get to it. As it has an action of "Allow", all packets that reach it will be allowed.

An example, the "Reject all except certain traffic" ruleset would look like the following:

Rule 1: "If the packet has a connection state of established then allow"
Rule 2: "If the packet is a TCP packet and destination port is 53 then allow"
Rule 3: "If the packet is a UDP packet and destination port is 53 then allow"
Rule 4: "If the packet is a TCP packet and destination port is 80 then allow"
Rule 5: "If the packet is a TCP packet and destination port is 443 then allow"
Rule 6: "Reject all packets"

This ruleset is a bit more complicated.
Rule 1 allows any packets that are part of a session that already exists.
Rule 2-5 allow specific DNS, HTTP, and HTTPS traffic via their standard protocol & ports.
Rule 6 rejects everything else.
A ruleset like this is very restrictive as only traffic that meets rule 1-5 is allowed, and everything else is rejected.

Rule 1 is required for this ruleset because the ruleset is evaluated on every packet. A response packet to an HTTP packet with destination port 80, will have a source port of 80 and a destination port of some very high arbitrary number. This packet would normally be dropped if Rule #1 didn't exist which means even DNS, HTTP, and HTTPS would not work because only the original request would be passed and the response would be blocked.
Rule #1 basically just says to allow the rest of the packets for a session in which we already have allowed the first packet. This is commonly referred to as a "stateful" firewall.

While these examples are quite simple, large rulesets with a variety of rules and conditions can be crafted in a very specific order to achieve the desired effect.

Chains

A list of rules is called a chain. A rule can "jump to" or "go to" another chain to continue evaluation of those rules.

The "jump to" action, jumps evaluation to the specified chain and if execution of that chain finishes without a terminating action, it will return to the jump rule and continue execution.
The "go to" action, jumps evaluation to the specified chain, but it will not return to the original "go to" rule if the chain finishes.

The ruleset in the example above is just one chain - a single list of rules. There are cases where the entire ruleset can be greatly simplified with the use of multiple chains.

Taking another example of a ruleset which allows all traffic, but blocks a certain IP (192.168.1.100) from connecting to HTTPS(443), HTTP(80), and FTP(21). This example would look like:

Rule 1: "If the packet has a client of 192.168.1.100 and is a TCP packet and is destination port of 443 then reject"
Rule 2: "If the packet has a client of 192.168.1.100 and is a TCP packet and is destination port of 80 then reject"
Rule 3: "If the packet has a client of 192.168.1.100 and is a TCP packet and is destination port of 21 then reject"
Rule 4: "Allow all packets"

This example is simple enough, despite there being a lot of repetition of the conditions in the ruleset.
Assuming we needed to block the same ports for another two hosts: 192,168.1.101 and 192.168.1.102.

With the same technique this ruleset would look like:

Rule 1: "If the packet has a client of 192.168.1.100 and is a TCP packet and is destination port of 443 then reject"
Rule 2: "If the packet has a client of 192.168.1.100 and is a TCP packet and is destination port of 80 then reject"
Rule 3: "If the packet has a client of 192.168.1.100 and is a TCP packet and is destination port of 21 then reject"
Rule 4: "If the packet has a client of 192.168.1.101 and is a TCP packet and is destination port of 443 then reject"
Rule 5: "If the packet has a client of 192.168.1.101 and is a TCP packet and is destination port of 80 then reject"
Rule 6: "If the packet has a client of 192.168.1.101 and is a TCP packet and is destination port of 21 then reject"
Rule 7: "If the packet has a client of 192.168.1.102 and is a TCP packet and is destination port of 443 then reject"
Rule 8: "If the packet has a client of 192.168.1.102 and is a TCP packet and is destination port of 80 then reject"
Rule 9: "If the packet has a client of 192.168.1.102 and is a TCP packet and is destination port of 21 then reject"
Rule 10: "Allow all packets"

This ruleset works fine. However there are lot of rules involved which makes it hard to maintain and understand. Furthermore it does not perform optimally as rules take time to evaluate. Having fewer rules is generally better than having more rules to maximize performance.

With chains, we can create a single chain that blocks port 21,80, and 443 and use that chain to simplify and improve the ruleset:

Chain "block-stuff":
Rule 1: "If the packet is a TCP packet and is destination port of 443 then reject"
Rule 2: "If the packet is a TCP packet and is destination port of 80 then reject"
Rule 3: "If the packet is a TCP packet and is destination port of 21 then reject"

Main chain:
Rule 1: "If the packet has a client of 192.168.1.100 then jump to chain block-stuff"
Rule 2: "If the packet has a client of 192.168.1.101 then jump to chain block-stuff"
Rule 3: "If the packet has a client of 192.168.1.102 then jump to chain block-stuff"
Rule 4: "Allow all packets"

This not only simplifies the ruleset, but makes evaluation much quicker.

This example is fairly trivial with an unrealistic use case, but chains can be used in many ways to greatly simplify or speed up ruleset.
Some more common examples might be:

* To evaluate more complex rules only on the first packet of a session.
* To enforce acceptable use network policy (via a chain) for wifi guests only.
* To enforce acceptable use network policy (via a chain) certain times of day.
* To add special exemption lists for specific IPs, users, or groups.

Actions

Rules have an assortment of actions. The type of actions available depends on the goal of the ruleset.
For filter rules the goal is to just block/pass certain packets. As such there are a few basic actions:

* Accept - accepts the packet and stops processing all filter rules immediately
* Reject - rejects the packet immediately and stops processing all filter rules immediately
* Drop - drops the packet immediately and stops processing all filter rules immediately

and 3 more commonly available actions to deal with chains:

* Jump to - jumps execution to the specified chain
* Go to - jumps execution to the specified chain, but does not return
* Return - returns to the calling chain, if currently in the top chain just means "Accept"

The actions available in a given ruleset vary depending on what the rules do.

Follow
Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk