Discovery - Palo Alto firewall Credential Validation Issue SNMP V3

[Santiago Urzua]

Hello everyone,

I am currently troubleshooting a ServiceNow Discovery issue with Palo Alto firewalls using SNMPv3 credentials and would appreciate any guidance from others who have worked on something similar.

One important limitation in my case is that I am copying the exact SNMPv3 credential details provided by the Palo Alto/network team, but I do not have direct access to the Palo Alto platform/device configuration to verify how SNMPv3 is actually configured on the firewall side. Because of that, I am trying to determine whether the issue is on the ServiceNow side, a mismatch in the provided credential details, or something specific in the Palo Alto configuration.

We are attempting to validate and use SNMPv3 credentials for Palo Alto firewall discovery, but the results have been inconsistent. In some cases, the target appears reachable, but credential validation fails with errors indicating that no valid credentials could be found. 

I am trying to determine whether the issue is primarily related to:

• SNMPv3 credential configuration in ServiceNow
• Palo Alto SNMPv3 configuration on the device
• Supported auth/privacy protocol combinations

Thank you in advance for any help.

[DanielJ43996773]

Hello @Santiago Urzua how are you?

This is a classic SNMPv3 Discovery scenario where the issue can sit on either side, and without access to the Palo Alto config you’ll need to validate it indirectly.

Based on what you described, reachable but credential validation fails, the problem is very likely not network connectivity, but one of the following:

1) SNMPv3 parameter mismatch (most common root cause)

With SNMPv3, everything must match exactly between ServiceNow and the device:

Username
Security level (noAuthNoPriv / authNoPriv / authPriv)
Authentication protocol (MD5 / SHA / SHA-256 depending on support)
Authentication password
Privacy protocol (DES / AES / AES-256)
Privacy password
Context name (often overlooked — Palo Alto may require it)

Even a small mismatch (especially auth/priv protocol) will result in:

“No valid credentials found”

What to confirm with the network team

Ask them explicitly for:

SNMPv3 security level
Auth protocol (SHA vs SHA-256 — very common mismatch)
Privacy protocol (AES vs AES-256)
Whether a context name is configured

2) Palo Alto SNMPv3 specifics

Palo Alto firewalls can be a bit stricter than other vendors:

Some versions require AES-128 only (not AES-256)
Some configurations enforce specific engine ID behavior
SNMP views may restrict OIDs (can cause partial or failed validation)

Even if credentials are correct:

If the SNMP view does not allow required OIDs, Discovery can fail validation

3) ServiceNow credential configuration

Double-check in ServiceNow:

Credential type: SNMPv3
Correct port (161)
Timeout/retries not too low
MID Server properly assigned and Validated

Also validate using:

Discovery → Credentials → Test Credential
Or run a Quick Discovery against the IP

4) Key troubleshooting step (very important)

Since you don’t have device access, this is your best move:

Test SNMPv3 outside ServiceNow (from MID Server)

Run from the MID Server:

snmpwalk -v3 -l authPriv -u <user> -a <auth_protocol> -A <auth_pass> -x <priv_protocol> -X <priv_pass> <ip>

If this fails:
→ problem is NOT ServiceNow, it’s credential/config mismatch

If this works:
→ problem is inside ServiceNow configuration

5) MID Server logs (don’t skip this)

Check:

agent.log
discovery.log

You’ll often see more precise errors like:

unsupported security level
authentication failure
timeout vs auth failure (important distinction)

6) Quick diagnostic summary
Symptom Likely Cause
Reachable but “no valid credentials” SNMPv3 mismatch
Timeout Network / firewall / SNMP not enabled
Partial discovery SNMP view restriction
Works in snmpwalk but not in SN Credential config in SN

Given your constraint (no Palo Alto access), focus on:

Validating SNMPv3 via snmpwalk from MID Server
Confirming exact auth/priv protocol combination
Checking if a context name is required
Reviewing MID logs for deeper error detail

If this solution worked for you, please mark it as Accepted Solution, give it a like, and thank you for your time!
Dan.

[Tanushree Maiti]

Hi @Santiago Urzua 

Check this KB for your query . 

KB1574489 Not able to discover Palo Alto firewall devices via schedules or quick discovery some time... 

Resolution

1. Add the below probe parameter for SNMP-Classify probe,
   • "request_interval"
2. Add "request_interval" probe parameter and set the property to 1000ms. Default is 400ms.
3. This will fix intermittent discovery issue of Palo Alto firewall devices.