SNMP v3 Traps Being Classified Incorrectly as snmpv3 instead of snmp-traps and Subsequently Denied

Showing results for 
Show  only  | Search instead for 
Did you mean: 

SNMP v3 Traps Being Classified Incorrectly as snmpv3 instead of snmp-traps and Subsequently Denied

L0 Member

Hi all, 


I've run into an issue with our NGFW denying SNMPv3 trap messages passing through the firewall. I've worked around the issue by creating a policy referencing the snmpv3 app-id and a custom service of udp-162.



  • The snmp-trap app-id expects to see traffic destined to UDP port 162. So far, so good.
  • SNMP traps generated in our environment are generated as SNMP v3 (encrypted) traps, not the more common SNMP v2 (clear text).
  • When the traps pass through our NGFW heading to our trap manager the firewall matches the traffic to the snmpv3 app-id rather than the snmp-trap app-id.
  • The snmpv3 app-id is configured to expect traffic with a destination of UDP port 161 (eg. snmpwalk requests, etc).
  • Our SNMP v3 traps were subsequently being dropped by the firewall, given they are traps with a destination port of UDP/162.

Has anyone else run into this and raised a request to update the snmp-trap app-id (or create and snmpv3-trap app-id) with Palo support?


Just wanting to check before I kick off that process. As I said above, I've solved the problem for the moment but SNMP v3 traps seems like something the Palo should natively support, given v3 has been around for a while.




L6 Presenter

Check the Palo Alto known issues for your version and addressed issues for newer version than yours by searching for SNMP:



From what I see in the Palo Alto app center when I search for SNMP there is no app-id for snmpv3-traps, so the snmp-trap id should match v2 or v3. If it is not a bug with your palo alto PANOS version and you have updated the "Applications and Threats Content Updates" database by using dynamic updates to the latest version then palo alto needs to fix this as this is well known application and you don't have write your own custom app-id and signature for it or use the Application Override.





L0 Member

Hi Ben,


I'm having the same issue. Checked the Fixed and Known issues, nothing for SNMP. Did you find a solution other than the workaround for an app override?




Hi Glenn,


Unfortunately I've had no more time to do the data collection exercise required by Palo to justify an app ID update. My workaround, which wasn't an app override, has been working successfully though, so it solved my immediate problem.


I created a policy that has an app-id of snmpv3 plus a service of udp/162. This allows the v3 traps to pass through the firewall. You just have to be conscious of placing the policy above any other that might match snmpv3 without the added service.




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!