SNMP CHANGE --- Bug ID/Enhancements 764679

[Marco-66]

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

[AEK]

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.

[Marco-66]

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

[AEK]

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.

[Marco-66]

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

[Marco-66]

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

[AEK]

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)

[AlexC-FTNT]

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>

[Marco-66]

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

[AlexC-FTNT]

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 :)