Tunnel and Prefilter Rule Components
State (Enabled/Disabled)
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings and errors for that rule.
Position
Rules are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. The first rule that traffic matches is the rule that handles that traffic, regardless of rule type (tunnel vs prefilter).
Action
A rule's action determines how the system handles and logs matching traffic:
-
Fastpath—Exempts matching traffic from all futher inspection and control, including access control, identity requirements, and rate limiting. Fastpathing a tunnel fastpaths all encapsulated connections.
-
Block—Blocks matching traffic without further inspection of any kind. Blocking a tunnel blocks all encapsulated connections.
-
Analyze—Allows traffic to continue to be analyzed by the rest of access control, using inner headers. If passed by access control and any related deep inspection, this traffic may also be rate limited. For tunnel rules, enables rezoning with the Assign Tunnel Zone option.
Direction (Tunnel Rules Only)
A tunnel rule's direction determines how the system source and destination criteria:
-
Match tunnels only from source (unidirectional)—Match source-to-destination traffic only. Matching traffic must originate from one of the specified source interfaces or tunnel endpoints, and leave through one of the destination interfaces or tunnel endpoints.
-
Match tunnels from source and destination (bidirectional)—Match both source-to-destination traffic and destination-to-source traffic. The effect is identical to writing two unidirectional rules, one the mirror of the other.
Prefilter rules are always unidirectional.
Assign Tunnel Zone (Tunnel Rules Only)
In a tunnel rule, assigning a tunnel zone (whether existing or created on the fly), rezones matching tunnels. Rezoning requires the Analyze action.
Rezoning a tunnel allows other configurations—such as access control rules—to recognize all the tunnel's encapsulated connections as belonging together. By using a tunnel's assigned tunnel zone as an interface constraint, you can tailor inspection to its encapsulated connections. For more information, see Tunnel Zones and Prefiltering.
Caution | Exercise caution when assigning tunnel zones. Connections in rezoned tunnels may not match security zone constraints in later evaluation. See Using Tunnel Zones for a brief walkthrough of a tunnel zone implementation, and a discussion of the implications of rezoning without explicitly handling rezoned traffic. |
Conditions
Conditions specify the specific traffic the rule handles. Traffic must match all a rule's conditions to match the rule. Each condition type has its own tab in the rule editor.
You can prefilter traffic using the following outer-header constraints. You must constrain tunnel rules by encapsulation protocol.
-
Interface—Interface Rule Conditions
-
Network (prefilter rule)/Tunnel Endpoints (tunnel rule)—Network Rule Conditions
-
Ports (prefilter rule)/Encapsulation and Ports (tunnel rule)—Port Rule Conditions for Prefilter Rules or Encapsulation Rule Conditions
-
Time Range—Time and Day Rule Conditions
Logging
A rule's logging settings govern the records the system keeps of the traffic it handles.
In tunnel and prefilter rules, you can log fastpathed and blocked traffic (the Fastpath and Block actions). For traffic subject to further analysis (the Analyze action), logging in the prefilter policy is disabled, although matching connections may still be logged by other configurations. Logging is performed on inner flows, not on the encapsulating flow. For more information, see Logging Connections with Tunnel and Prefilter Rules.
Comments
Each time you save changes to a rule you can add comments. For example, you might summarize the overall configuration for the benefit of other users, or note when you change a rule and the reason for the change.
You cannot edit or delete these comments after you save the rule.