Policy allowing ping/snmp not performing as expected

Reply
lance.wright
L0 Member

Policy allowing ping/snmp not performing as expected

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?

Tags (3)
apasupulati
L4 Transporter

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
L6 Presenter

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
L0 Member

PA SS1.png

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
L4 Transporter

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
Not applicable

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.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!