Basics

Rules are configured by the user to categorize and act upon traffic. For example, firewall uses rules to determine whether to block or pass traffic. Bandwidth Application control uses rules to determine how to prioritize a session.

Rules are evaluated in order from top to bottom against sessions (not packets!). If a rule matches then the action from that rule is performed and no more rules are evaluated. If no matching rule is found the behavior is defined by the application, which is usually doing nothing.

This is similar to other firewalls. Arista rules are quick rules which means the first match is always used. Unlike some other firewalls, Arista evaluates against sessions, not packets. 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.

Rule Anatomy

The enable checkbox determines if the rule is evaluated. If the enable checkbox is not checked, the rule is simply skipped.

The description is for the user to document what the rule does. It is highly suggested to give the rule a meaningful name. Trying to troubleshoot a set of rules all named "[no description]" can be extremely difficult.

The set of conditions is the description of the traffic that should match the rule. If all of the conditions are true for the given session then the rules matches. This is discussed in more details in the next section.

The action or set of actions configures what action is performed if the rule matches. This is dependent on the application. For example, in firewall it determines whether to block or pass the session and additionally if it should be flagged.

Conditions

Conditions define which sessions will match the rule. If and only if all of the conditions match, the rule is considered a match. Conditions can also be inverted by selecting "is NOT" in the dropdown, effectively inverting when it matches. Destination Port "is NOT" "80" matches on all ports except port 80.

Lets take a simple example: We want to block TCP traffic to port 80 on a server. There is a web service running on that server that you don't want to allow access to. 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. So in this example will will add:

• Protocol is TCP
• Destination Address is 1.2.3.4 (The IP address of the server)
• Destination Port is 80

Finally, set the action to block and flag, and click Done and Apply. Since all conditions must be true this rule will block TCP traffic to 1.2.3.4 port 80 only and nothing else.

There are many conditions available to carefully define precise sets of traffic. The following table defines the list of conditions.

Order

As discussed above, the order of rules is very important. Often users want to do very complex tasks that can be difficult or impossible with a single rule. In these cases, multiple rules is useful. For example, assume you want to use Firewall to block all traffic to a server (1.2.3.4) except port 80 traffic or from the admin IP (192.168.1.100) to RDP (port 3389).

Doing this in one rule would be difficult (actually impossible in this case), but it is quite easy using several rules: First, create a rule to just block all traffic to the server IP, 1.2.3.4. Above that rule create a rule that passes all traffic from the admin IP, 192.168.1.100, to the server IP where Destination Port == "3389", and another rule that passes all traffic to 1.2.3.4 with Destination Port == "80." This set of three rules does exactly what we describe above and effects no other traffic.

Common Mistakes

This is a list of common mistakes to avoid.

• Conditions must ALL match
  In order for a rule to match, ALL conditions must match. In some cases you may want to add a rule that just passes all traffic to and from an IP. Users sometimes will create a pass rule with two conditions:

  • Destination Address is "1.2.3.4"
  • Source Address is "1.2.3.4"

  This rule will never match anything because it will only match traffic where the destination address is 1.2.3.4 AND the source address is 1.2.3.4 (a session destined to itself). If you want to match when the destination address is 1.2.3.4 OR the source address is 1.2.3.4, then you must create two separate rules, one for the destination address and one for the source address.

• Rule Order

  Occasionally, you will add a rule and not understand why it is not working as intended. Often we find that there was a rule above that was matching the session before the desired rule. For example, just adding a rule to the bottom often isn't sufficient, you must find the appropriate place in your ruleset to place the new rule.

  To do so simply logically evaluate the rules in your head starting at the top to find the appropriate place for your rule. Also use the event log to run several tests to see how the session was handled in the event log and adjust your ruleset accordingly.