snmp exporter and index queries

Forum|Forum|5 years ago
February 3, 2021
1 reply
13657 views

Hi Everyone,

Has anyone succeeded in monitoring VPN using snmp_exporter/prometheus ? I am trying to query fgVpnTunTable(.1.3.6.1.4.1.12356.101.12.2.2) but it does fail with error like this...

800 error(s) occurred: * collected metric "fgVpnTunEntLocGwyIp" { label:<name:"fgVpnTunEntIndex" value:"140" > label:<name:"fgVpnTunEntLocGwyIp" value:"208.94.108.2" > gauge:<value:1 > } was collected before with the same name and label values * collected metric "fgVpnTunEntSelectorDstEndIp" { label:<name:"fgVpnTunEntIndex" value:"134" > label:<name:"fgVpnTunEntSelectorDstEndIp" value:"10.248.32.255" > gauge:<value:1 > } was collected before with the same name and label values * collected metric "fgVpnTunEntSelectorSrcBeginIp" { label:<name:"fgVpnTunEntIndex" value:"24" > label:<name:"fgVpnTunEntSelectorSrcBeginIp" value:"192.168.147.0" > gauge:<value:1 > } was collected before with the same name and label values * collected metric "fgVpnTunEntInOctets" { label:<name:"fgVpnTunEntIndex" value:"136" > counter:<value:1.9405667848e+10 > } was collected before with the same name and label values * collected metric "fgVpnTunEntTimeout" { label:<name:"fgVpnTunEntIndex" value:"171" > gauge:<value:41053 > } was collected before with the same name and label values * collected metric "fgVpnTunEntLocGwyIp" { label:<name:"fgVpnTunEntIndex" value:"136" > label:<name:"fgVpnTunEntLocGwyIp" value:"208.94.108.2" > gauge:<value:1 > } was collected before with the same name and label values

After digging a bit more I found that it look like the fgVpnTunEntIndex (1.3.6.1.4.1.12356.101.12.2.2.1.1) isn't returned by the Fortigate. I have open a case with them and they say the followging

"as per current design (6.2.3 and above) for SNMP query for VPN tunnel list, the phase1 serial and phase2 serial both are used to be indexes for VPN Tunnel list. So the original fgVpnTunEntIndex is NOT used now"
The fgVpnTunEntIndex became meaningless (just for MIB compatibility). And also, any index of the table should be defined as "not-accessible"."

So I am now confused on how I can query a VPN status or bandwitdh if I can't refer to an index. As per they say and my understanding the only value

sw2090

SuperUser

Our nagios/icinga based monitoring uses the nagios check_fortigate plugin which uses these oids to check vpn status. However we only have ipsec. Works fine for these.

# VPN OIDs # XXX to be checked my $oid_ActiveSSL = ".1.3.6.1.4.1.12356.101.12.2.3.1.2.1"; # Location of Fortinet firewall SSL VPN Tunnel connection count my $oid_ActiveSSLTunnel = ".1.3.6.1.4.1.12356.101.12.2.3.1.6.1"; # Location of Fortinet firewall SSL VPN Tunnel connection count my $oid_ipsectuntableroot = ".1.3.6.1.4.1.12356.101.12.2.2.1"; # Table of IPSec VPN tunnels my $oidf_tunstatus = ".20"; # Location of a tunnel's connection status my $oidf_tunndx = ".1"; # Location of a tunnel's index... my $oidf_tunname = ".3"; # Location of a tunnel's name...

paulinsterAuthor

Visitor III

Well those are exactly the oid that I querying...

But if I run an snmpwalk againt the index oid.. I am getting oid not found...

$ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.1 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.1 = No Such Instance currently exists at this OID

If I run it again the tunstatus and tunname does return result, but I am getting the result that include the phase1 interface index + phase2 interface index..

For example...

$ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.52 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.53 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.54 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.55 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.56 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.57 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.58 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.59 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.61 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.63 = STRING: "REMOTE_OFFICEA" $ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.3 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.52 = STRING: "REMOTE_OFFICEA_P1" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.53 = STRING: "REMOTE_OFFICEA_P2" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.54 = STRING: "REMOTE_OFFICEA_P3" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.55 = STRING: "REMOTE_OFFICEA_P4" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.56 = STRING: "REMOTE_OFFICEA_P5" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.57 = STRING: "REMOTE_OFFICEA_P6" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.58 = STRING: "REMOTE_OFFICEA_P7" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.59 = STRING: "REMOTE_OFFICEA_P8" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.61 = STRING: "REMOTE_OFFICEA_P9" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.63 = STRING: "REMOTE_OFFICEA_P10" $ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.20 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.52 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.53 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.54 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.55 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.56 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.57 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.58 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.59 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.61 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.63 = INTEGER: 1

As per the ticket I have open with them, look like Fortinet has completely change the way they returned snmp data...

sw2090

SuperUser

.1.3.6.1.4.1.12356.101.12.2.2.1.1 seems indeed not to exist.

howewver my nagios starts with .1.3.6.1.4.1.123456.101.12.2.2.1.

If I do an snmpwalk on one of my FGT that starts at this it runs through showing my all my ipsecs etc.

Sign up

Login with SSO

Login to the community

Login with SSO