Policy allowing ping/snmp not performing as expected

[lance.wright]

I have a policy which allows icmp / ping / snmp-base / snmpv1 / snmpv2 however when I review the logs the traffic which matches this policy is being caught in a lower policy that is more general (and we are trying to get rid of). Someone told me that because icmp/ping are layer 3 and snmp is layer 7 that they cannot share a policy. I didn't believe him until I saw these results. Please say this is not the case. Any ideas?

[apasupulati]

Hello,

I dont think that's the case. Can you make sure the only difference in the rules are the applications? Despite that, the rules must have the same source/destination zones, source/destination IP's (if any), users, URL category and the service ports configured. Also, try clearing any old sessions for this app traffic that could be matching the generic rule.

Can you post a screenshot of the traffic log and both the rules if the issue still remains or contact support, so we can help troubleshoot the issue for you.

Thank you,

Aditi

[mikand]

That sounds odd because what you do in the GUI as ruleset will be compiled and optimized by the mgmtplane before loaded into the dataplane when you click commit.

What matters is that the execution is top-down first-match so for some reason your icmp echo request didnt match all columns.

Verify that you use the proper srczone and dstzone as a start.

As a troubleshoot (if possible) you can make this rule wider and then step by step narrow it down.

For example start by just:

srczone: X

dstzone: Y

appid: ping

options: log on session start, log on session end

then send a ping from a host in srczone to a host in dstzone and watch the trafficlog.

If this matched then add srcip/dstip to your config like so:

srczone: X

srcip: xrange/xcidr

dstzone: Y

dstip: yrange/ycidr

appid: ping

options: log on session start, log on session end

and redo the test until you have added all options needed (IPS, AV etc).

Other things to verify is that you have the routing properly setup, not only on the srczone side including the PA itself but also at the dstzone so the response will be sent the proper way in return.

You can also login to the PA device with ssh/cli and run the test-command to virtually construct a packet and see which rule will be hit (page 449 in PAN-OS_4.1_CLI_Reference_Guide.pdf) before you start with the manual troubleshooting of altering the ruleset above.

[lance.wright]

Here is a screenshot of the two rules. Rule #1 is above Rule #2. I am trying to get rid of Rule #2 (as it is obviously too general. Let me know if you have any questions about the rules specifically. Thanks for looking this over.

[apasupulati]

Hey Lance,

So what does the traffic log matching Rule 2 show? May be the destination address is not in the Address group configured for Rule 1, therefore its matching Rule 2? Click on the magnifying glass, on the first column of the traffic log and take a screenshot of the log details. We can look if the session details are different and hence not matching the first rule.

Thank you,

Aditi

[Batman]

We are seeing the same issue. Specifically with ICMP custom apps. (breaking down the ICMP types). The traffic is app ID'ed properly but falls to a lower rule and does not get matched higher where it should. We do not notice this on a simple configuration on a PA500. But with a 5060, multiple vsys, etc we do. I wonder if you have gotten an answer to this. We are working with support to figure out the issue also. What setup do you have where you see this issue? Thanks

update 2/15/13 - worked with support and a bug has been identified in 4.1.10. The custom application is identified properly but when it runs the the security policy the custom app id is part of a different vsys. the current vsys +1. So basically, packet comes in vsys10, identified as an app id in vsys10, then when it comes to policy match it is the app id of the same app (shared) but in vsys11 thus does not match.

bug is being officially being documented and hopefully fixes soon.