Policy Ordering Overview
By default, new policies go to the end of a policy lookup list. Therefore, it is possible for one policy to eclipse or overshadow another policy. The order of configured policies is significant in how the device handles traffic. Policy look up is performed in the order that policies are configured. The first policy that matches the traffic is used. If a specific policy is listed after a general policy, it is highly probable that the specific policy will not be used.
For example, if you have two policies configured for the same source zone, destination zone, source IP address, and destination IP address, but one policy has permit-all and one has permit-mail, the policy with permit-mail would never be matched if it is listed after the policy with permit-all.
Because policies execute in the order of their appearance, you must be aware of the following:
Policy order is important.
Newly created policies go to the end of the policy list.
You can change the order of policies.
The last policy in the policy list is the default policy, which has the default action of denying all traffic.
Reordering a Policy
You can correct policy overshadowing by simply reversing the order of the policies, putting the more specific one first.
Policy ordering is extremely important in Virtual Private Networks (VPN) environments. Listing a VPN or encryption policy first ensures that VPN traffic reaches the encryption policy, not a general permit policy.
The S. No. (sequence number) column on the Zone Policy page allows you to reorder the policies:
Use the S. No. column to type a number to change the policy order.
Drag and drop a selected policy from one location to another.
The sequence number changes as you drag the policy or manually type a new sequence number. The sequence numbers of all the policies below the newly moved policy also change.
The drag and drop feature is disabled if you have filtered the policy list.
Order of Precedence for Policy Matches
For policy matches, it is important to understand how the firewall evaluates policies. Juniper calls a security policy context the policy that is within the same source-destination zone pair. For instance, all policies within source zone trust and destination zone untrust are in the same context . Figure 1 shows the order in which policies are looked up.
In terms of context precedence, SRX Series devices support the following order of precedence:
Match intrazone policies: The initial packet in an unknown session is evaluated to determine if the source and destination zones are the same. This occurs if both the ingress and egress interfaces are in the same zone. This context match has the highest precedence and is matched first.
Match interzone policies: If the session does not match an intrazone context or policy, then the next policy is for a source zone and destination zone context. If the context matches, then the policies within that context are evaluated for a match. Interzone policies are only evaluated if there is no matching intrazone policy match.
Global policies: If there is no policy match for either intrazone or interzone policies, then the next policy match is the global policy. A global policy matches any zone context, but it has the same match criteria for the policies as any other security policy (for example, source IP address, destination address, services, user object, and so forth). It is the last policy set that is evaluated after intrazone and interzone policies.
Default action: this action is taken if there is no match on intrazone, interzone, or global policies.