Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Marco-66
New Contributor II

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

11 REPLIES 11
AEK
SuperUser
SuperUser

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.

AEK
AEK
Marco-66
New Contributor II

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
SuperUser
SuperUser

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.

AEK
AEK
Marco-66
New Contributor II

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
New Contributor II

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)

AEK
AEK
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>


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
Marco-66
New Contributor II

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


- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors