Unable to discover SNMP Fortinet Firewall Device (Forti Analyzer)

[Naushad1]

Hi All,

I'm currently facing an issue with ServiceNow Discovery for Fortinet Firewall Device. While the discovery process is working until classified however CI is not getting created.

At first, after running Discovery, I was getting "Active, couldn't classify".  When I dug into the payload, I could see that the OIDs are actually being pulled. Now, after creating a new SNMP Classification and adding the oids, the APs are being classified but no CI is being created. Even after discovery has finished it remains in the stage "identifying".

At Discovery Log getting error "Failed Exploring CI Pattern, Pattern name: Next Generation Fortinet Network Firewall, To Check Pattern Log Press Here"

 Identification Engine: Discovery status is FAILURE, Identification sections in pattern failed: section: discover, error: Failed to establish SNMP connection to host XXXXXXX Check that host is accessible and correct credentials are defined..

We have verified the credentials and able to connect the device using mid server.

I am missing anything?

What I've Done So Far:

1. SNMP Classification: I've created a new SNMP classification on the "Fortinet Firewall Device" table under Fortinet Firewall classifier and added the OID based on their sysObjectID.

[bigfissy]

Hi @Naushad1 ,

Why have you created a new SNMP classification? You do not need to do that. Existing OOB SNMP classification is sufficient already. All you need do is ensure the OOB SNMP classification - "Fortinet Firewall" has all the "SNMP OID Classifications" 

Afterwards, test your SNMP credentials and then run discovery.

N/B: Ensure the following applications are up to date 

• Discovery and Service Mapping Patterns
• CMDB CI Class Models

 N/B: Let me know if that helps and Please mark as helpful if it does 🙂 

[AJ-TechTrek]

Hi @Naushad1 ,

Yes, you’re on the right track with custom SNMP Classification for Fortinet, but the issue you’re describing (classified → stuck in “identifying” → no CI created) usually points to a gap between classification, identification, and credential verification. Let me break it down and give you a clear checklist

Root Cause Possibilities will be below -

1. SNMP Classification works, but Identification Rule is missing/incomplete.
* Classification only says “this is a Fortinet Firewall” → but CMDB Identification Engine still needs rules to match or create the CI in the CMDB.
* If no proper identifier (serial number, sysName, sysOID, etc.) is mapped, the CI will stay in Identifying and fail.

2. SNMP Connectivity in Discovery Pattern.
* Even though classification pulls OIDs, the pattern step may be trying to query other OIDs (like serial number, firmware, or interface table) and failing → which causes the Failed to establish SNMP connection error in logs.
* Sometimes MID Server SNMP timeout or firewall ACLs block access to deeper OIDs.

3. Classifier vs. Pattern mismatch.
* If you created a new SNMP Classifier but did not link it properly to the “Fortinet Firewall” pattern/CI type, Discovery will classify but not execute the correct pattern → no CI created.

Solution Steps which might helps you -

1. Validate SNMP Classifier
* Go to Discovery → SNMP Classifiers.
* Open your custom Fortinet classifier.
* Ensure:
* sysObjectID OID (e.g., 1.3.6.1.4.1.12356.*) is mapped correctly.
* Discovery Behavior → points to the Fortinet Firewall Device CI class (cmdb_ci_net_fortinet_firewall or your custom subclass).
* Classifier active = true.

2. Check Identification Rule
* Navigate to CMDB → Identification Rules.
* Find the rule for Fortinet Firewall Device.
* Ensure it has at least one unique identifier like:
* serial_number
* or sysName + manufacturer.
* If Fortinet doesn’t return serial via SNMP, add an identifier based on sysName + IP.
Without a proper Identification Rule, Discovery will never create/update the CI.

3. Debug Pattern Log
* In the Discovery Log → click “To Check Pattern Log” (from your screenshot).
* See which SNMP step is failing.
* If it fails at sysDescr, serial, or interface walk → you may need to:
* Extend the pattern to use the correct Fortinet OIDs.
* Verify SNMP v2/v3 credentials (community string, auth, priv).
* Adjust MID Server SNMP timeout (some firewalls are slow to respond).

4. Test SNMP Outside ServiceNow
* From the MID Server host, run:
snmpwalk -v2c -c <community> <device_ip> 1.3.6.1.2.1.1
* Confirms if MID can really walk SNMP system OIDs.
* If only sysObjectID works but deeper OIDs fail → network ACL/firewall issue.

5. Map OIDs in the Pattern
* Open the Next Generation Fortinet Firewall pattern in Discovery Patterns.
* Add/adjust steps to collect:
* sysObjectID
* sysName
* serialNumber OID → Fortinet usually uses 1.3.6.1.4.1.12356.101.4.4.1.1.3 (depends on model).
* Make sure the results map into serial_number or name field in CMDB.

6. Final Fallback
* If Fortinet’s native SNMP is limited:
* Use SSH Pattern (FortiOS CLI commands like get system status) instead.
* Or build a Custom Pattern Extension for Fortinet.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[Sohail Khilji]

Hi @Naushad1 ,

can you please share your pattern error screenshot