This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About ben_netsol
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About ben_netsol
06-05-2023
2Posts
1Like
0Solutions
Jun 05, 2023Last Visited
User
Activity
User
Profile
Latest posts by ben_netsol
| Subject | Views | Posted |
|---|---|---|
| 3110 | 10-18-2021 05:08 PM | |
| 3540 | 06-08-2021 04:49 PM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 10-18-2021 05:08 PM |
User Badges
Community Statistics
| Member Since | 05-29-2017 08:28 PM |
| Date Last Visited | 06-05-2023 03:41 AM |
| Posts | 2 |
| Total Likes Received | 1 |
10-18-2021
05:08 PM
1 Kudo
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
06-08-2021
04:49 PM
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
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
06-05-2023
03:41 AM
|
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks