There is a relevant exception to the normal policy order. Policies with VIPs don’t appear to behave the same way. Traffic that is handled by VIPs is processed through the associated policy before the traffic is checked against other policies in the usual top down order.

This only appears inconsistent the policy order rule because when handling the traffic, firewall policies are not the first thing checked. VIP translations are checked first, and if there is more than one VIP that the traffic fits, it is handled in the top down order that is followed by policies. If the traffic is not claimed by a policy in the VIP translation phase, it is checked against the routing rules. If it passes the routing checks, the traffic is allowed to be controlled by the polices.

This processing of traffic targeted a VIPs only applies if there is a policy that included the VIP and the traffic matches all of the criteria checks. There is no need to worry about creating VIPs that are not controlled by a policy.

There are security implications associated with this behavior. Administrators could assume that a policy will process traffic before it drops down to a policy with a VIP in it. This can allow traffic to pass through the firewall into a part of the network that it was not intended for, if it was to be allowed in at all. The way to prevent traffic being incorrectly allowed through a policy containing a VIP is to have that policy be more restrictive or to have a separate policy containing the same VIP deny the traffic earlier in the sequence.

 

As proof of the behavior, look at the following traffic analysis of a packet sent to a VIP. You will see that the packet is translated even before it is allowed to pass through the firewall by a policy.