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. Cheers, Ben.
... View more
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. Summary: 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. Ben.
... View more