When committing a configuration, a warning may appear that one rule "shadows" another rule.
Rule 'rule1' shadows 'rule2'
Configuration committed successfully
A shadow rule warning generally indicates a more broad rule matching the criteria is configured above a more specific rule.
See this example:
No traffic will ever match the second rule, which specifically allows web-browsing, because all applications have already been allowed by the first rule.
The shadow rule can also appear if there are unresolved FQDNs. If FQDN objects are configured make sure they are resolved from CLI by using this command:
>request system fqdn show
Unresolved FQDNs in Security Policy Result in Shadow Policy Warning During Commit
Your example contradicts an assumption I had about policies...
I was sure that a policy have to be defined between 2 zones and it is not possible to define a policy between specific interfaces as you did ,see def of rule2. UI seems to block this feature by allowing me to choose only zones and not interfaces.
Am I missing something? Or was your example only to illustrate meaning of shadowed rules?
My example was to illustrate shadow rules, not cause confusion! Thanks to your comment, I've changed the example.
I have a couple PBF rules that I'm using for ISP failover that will require rule shadowing to be allowed. I configured the first rule with a monitor that will disable the rule if the nexthop ip is unreachable. The next rule down will forward to the secondary ISP. Is there a way that I can allow rule shadowing?
If you have are using DUAL ISP for redundancy, you can implement using a single PBF rule.
The Piimary route for the traffic will use the PBF which will forward the trafic to Primary ISP (say ISP 1). This rule will be monitoring the next hop. If this fails, there is a fail-over condition in place which will route the traffic through device's routing table.
The Routing table will have a default route out through the secondary ISP (say ISP2) as a back up.
If you want to go through the set up here is the document:-
I have NAT Rules setup to route incoming requests by FQDN to a specific internal Server. I have 2 websites on the same server with different FQDN. I had this rule setup previously during a demo, but now I am receiving the "shadow rule" warning. Is this normal behavior? and will the routing for the second website still work?
if ip addresses will hit the second rule it should work.There are some wrong logic on shadow rule messages.Especially for pbf.
Yes it seems that the shadow rule detection can't sort out the difference between "more borad" rules and "equally broad rules" when using PBF for ISP failover. No need to use the routing table for ISP failover when because it doesn't support link state detection with wait time whereas PBF does. Would be nice if they could improve the shadow detection but everything still works so not a big deal.
I have two nearly identical PBF rules. One is configured for next hop monitoring and will of course disable if the next hop is unavailble. The very next rule is identical, except I've configured it for "no-pbf" action instead of forwarding. The primary reason for this is to make sure traffic gets pushed to the VR if the first rule is not matched. When committed it warns me I have a shadow rule issue. Unless the first rule is disabled I'm assuming my commits will always show this. Is that correct? Also, I have a default route (for ISP fail-over), and to ensure my traffic in questions doesn't match the default rule (because destination for default is 0.0.0.0/0) I've negated the destination IPs of my first PBF rule, but this traffic still matches on the default, hence the reason I created the second PBF no-pbf rule. Any thoughts or suggestions?
That second rule is redundant, if your first rule gets disabled by a failed monitor, traffic will automatically default to the VR (this is why the rule is 'disabled' upon failed monitor)
a more typical use for the no-pbf policy is to add a rule in front of a 'subnet' pbf that would excempt for example 1 ip from the subnet listed in the latter (no-pbf 22.214.171.124 , pbf 126.96.36.199/24)
in your current setup, you will always get the message during commit
could you add a screenshot or something to help explain the second part of your question? the default gateway will likely only start being used once the PBF policy gets disabled by a failed monitor (depending how you configured your policy) so it may be completely normal for all your sessions to hit your pbf, until the monitor fails
Hi Reaper, thanks for the reply. Will the traffic automatically default to the VR because the rule is disabled, or will it continue to try to match against existing rules until none match, then onto the VR? That is how I understood it. The way I was understanding my scenario was the rule was being disabled, and the traffic matched against a following rule, the default rule. That's the reason I through in "pbf#2" for testing, to make sure it didn't match on that default rule, which I'm not sure why it is anyway. Sorry for all the "white out" in the attached picture. I hope it still shows my setup well enough to understand.
don't worry about the white space! :)
lookups will go through all the rules before defaulting to the VirtualRouter
having a catch-all pbf rule is an interesting approach :)
In your case it makes sense to have the no-pbf rule, but do you really need a catch-all pbf policy if you know that anything not hitting pbf will default to the VR anyway
It may help creating your pbf rules from an inclusion perspective: if it needs to be routed differently, create a rule as specific as possible, anything not necessarily needing a pbf policy: VR
A typical deployment is to use the default route on the VR for all critical traffic, and then have pbf policies to redirect less important connections over a backup/DSL link via pbf. when the DSL isp fails, pbf policies will be disabled and everything defaults to the default route, all critical apps already use the VR