Matches if value matches the Destination/Server Address of the session. This column is there purely as a warning that users in these cases must be aware of when conditions might deliver false negatives. If all of these methods fail then it is entirely possible that the hostname of a server is "foo" but Untangle has not been able to determine this and as such a Client Hostname is "foo" condition will not match. Hostname is determined through many ways, including DNS and DHCP. Other conditions, like Client Hostname, only match if the hostname for the client hostname is known. For example, some conditions, like Destination Port, are always known and thus matching on Destination Port is 100% reliable. Reliability - The Reliability is a "reliability" of that condition.As such they are not available in rules that are evaluated at session creation time, like Firewall and Captive Portal. These type conditions are 'deep session' conditions because they are not able to be evaluated at session creation time, only after some data flows. Other conditions, like Application Control: Application, are only known after the session is created and some data flows and Application Control is able to identify the application. Some conditions, like Destination Address, are always known and can always be used to match. Availability - The Availability is the availability of that matcher at various times.If editing through the UI, some conditions have custom editors to help you craft conditions, others are just a text field. Syntax - The accepted Syntax of the condition.The following Table defines the list of conditions. There are many conditions available to carefully define precise sets of traffic. Since all conditions must be true this rule will block TCP traffic to 1.2.3.4 port 80 only and nothing else. Destination Address is 1.2.3.4 (The IP address of the server)įinally, set the action to block and flag, and click "Done" and "Apply".First, create a rule and check the enable checkbox and give it a reasonably descriptive name like "blocking TCP port 80 to serverX." Now you will need to add some conditions that match only the traffic you want to block. There is a web service running on that server that you don't want to allow access to. Lets take a simple example: We want to block TCP traffic to port 80 on a server. Destination Port "is NOT" "80" matches on all ports except port 80. If and only if all of the conditions match, the rule is considered a match.Ĭonditions can also be inverted by selecting "is NOT" in the dropdown, effectively inverting when it matches. For example, in Firewall it determines whether to block or pass the session and additionally if it should be flagged.Ĭonditions define which sessions will match the rule.
The action or set of actions configures what action is performed if the rule matches. This is discussed in more details in the next section. If all of the conditions are true for the given session then the rules matches. The set of conditions is the description of the traffic that should match the rule. Trying to troubleshoot a set of rules all named "" can be extremely difficult. It is highly suggested to give the rule a meaningful name. The description is for the user to document what the rule does.
If the enable checkbox is not checked, the rule is simply skipped. The enable checkbox determines if the rule is evaluated. This means that the "Source Address" will be the initiator of the session and the "Destination Address" will be the server address the client is connecting to, and the same is true for "Source Port" and "Destination Port." Unlike some other firewalls, Untangle evaluates against sessions, not packets. Untangle rules are "quick" rules which means the first match is always used. If no matching rule is found the behavior is defined by the application, which is usually doing nothing. If a rule matches then the action from that rule is performed and no more rules are evaluated. Rules are evaluated in order from top to bottom against sessions (not packets!).
Bandwidth Control uses rules to determine how to prioritize a session. For example, Firewall uses rules to determine whether to block or pass traffic. Rules are configured by the user to categorize and act upon traffic.
All of these rules essentially share the same logic. Many applications use rules like Firewall, Captive Portal, Application Control, Bandwidth Control, etc. This documentation describes how rules work and gives some basic examples and some common mistakes to avoid. Rules are very powerful, but can sometimes be difficult to configure. Rules are used frequently in Untangle and many other firewalls.