- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SNMP CHANGE --- Bug ID/Enhancements 764679
Hi all
In this release notes the bug ID 764679 "enhance" the MIB in a way that our NMS system is not able to discovery in the right way the IPs of the Firewall running FortiOS 7.0.14.
How we can bypass this "wrong behaviour" ?
Thanks in advance
Nominate a Forum Post for Knowledge Article Creation
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Marco
When I try snmpwalk on FG 7.0.15 I get this:
$ snmpwalk -O n -v2c -c com1 192.168.2.1 .1.3.6.1.2.1.4.34.1.3
.1.3.6.1.2.1.4.34.1.3.1.4.192.168.1.1.1 = INTEGER: 1
.1.3.6.1.2.1.4.34.1.3.1.4.192.168.2.1.19 = INTEGER: 19
.1.3.6.1.2.1.4.34.1.3.1.4.192.168.3.1.21 = INTEGER: 21
... and so
The output looks fine and like described on the enhancement ID that you shared above.
For example in the first line we can see:
- 1: IP type is IPv4
- 4: is number of bytes (4 bytes)
- 192.168.1.1: is the first IP address
Is it the format that you are looking for?
Do you get something similar?
PS: On my old FG 6.2.15 I don't have the "number of bytes" field in the output.
Created on 06-29-2024 01:45 PM Edited on 06-29-2024 01:47 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi AEK
Thanks for your quick reply.
The problem is precisely the modification made, i.e. the fact that it adds the
type of IP address (type 1 for IPv4, type 2 for IPv6) and the number of octets (four for IPv4, 16 for IPv6)
where in the previous/old FortiOS these new informations are not present, as you pointed out.
This enhancement made a big change without taking into account that this information is also used by NMS like ours which now no longer works properly with Fortinet firewalls.
This change will probably have some positive aspects but certainly not for those who use this information like us who have hundreds of Fortinet Firewalls.
Making these changes without taking into account what this may mean for those who use this data to carry out monitoring is something I have never seen in 35 years of work except to fix bugs.
Is there any configuration parameter in the Firewall to avoid this "improvement"?
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Marco
I'm not from monitoring world so I don't know why they added these fields and can't really know what can be the impact on NMS.
But I think this can be fixed by downloading the two new MIB files from your FortiOS 7.0.14 (Core and FortiGate), and use them to replace the old ones on your NMS.
Besides I don't think there is a config parameter on FG to avoid this improvement.
Hope it helps.
Created on 06-29-2024 02:21 PM Edited on 06-29-2024 02:25 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks again AEK
I don't know if using the new MIB can solve this issue, but the fact remains that we have Firewalls both with this modification and without and I don't think this can be easily resolved.
I'm asking on the OpenNMS Forum which is the NMS we use.
However, there are already other Fortinet customers experiencing the same problem.
I will keep you informed on developments.
Greetings
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Someone else using OpenNMS tried loading the new MIBs but the problem remained unchanged.
In my opinion, everything could be summed up in this question
Before this change, was the information provided by the Fortinet firewalls incorrect? because if this were not the case, and there is no reason to think so, it means that something that worked has been changed, transforming it into something that doesn't work.
I'm doing other checks because I'm starting to think that the change introduced seems to be correct, but not being an "expert" in the SNMP/MIB world, the times are not immediate..
Reference
http://www.net-snmp.org/docs/mibs/ip.html#ipAddressTable
http://www.net-snmp.org/docs/mibs/IP-MIB.txt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing.
So I was wrong when I said that you should reload the new Fortinet MIBs, simply because this is not in Fortinet MIBs but in IP-MIB.
Thanks for the bringing it to my attention.
Now why Fortinet did that? And is this standard or not standard or left to each editor's choice?
Hope some SNMP experienced user can bring some helpful answer.
Besides, I worked on Zabbix like 6 or 7 years ago (on SNMP especially), and if my memory is good I think it was possible to play with SNMP output and extract the information as needed, I mean it should be possible to adapt your NMS to extract the IP even with this change. (Hope my memory still good)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Marco,
Yes, prior to this bug fix, the FortiGate would send an incorrect response to the OID .1.3.6.1.2.1.4.34.1.3.1.4.10.56.242.61.1, which was not as described by the RFC (so it was incorrect). The change implemented was:
When sending response to SNMP request for ipAddressTable, append the IP address type (type 1 for IPv4, type 2 for IPv6) and number of octets (4 for IPv4, 16 for IPv6) in the format 1.3.6.1.2.1.4.34.1.3.<type>.<octet>
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Many Thanks Alex
Just to clarify, there is no need to load any new MIB as the change was introduced to correct a BUG.
We'are checking if this change complies with the MIB, it would seem so but we still don't all agree on this, so before closing the matter, wait for my feedback.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Marco,
The MIB likely needs to be reloaded, because there is a ".4." missing in the middle of the OID that causes this behavior. There is no mention of MIB or reloading it in the bug, because we don't support any 3rd party integrations. That should be handled by the software support team individually.
And about "closing" - this is a forum, man! only you can mark the issue as resolved :)
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -