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
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.
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...
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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...
.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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
It does also snmpwalk through the whole ipsec tun table fgVpnTunEntry(.1.3.6.1.4.1.12356.101.12.2.2.1), but the problem is that prometheus's snmp_exporter look at the fortigate MIB file and do rely on the index in order to push data within the database. When is push data to the database, it add some labels so when it' try to push/ingest the data, the format will look like this.
fgVpnTunEntStatus{ fgVpnTunEntIndex="x" } my_fgVpnTunEntStatus_value
The same snmp_exporter setup/config look to be working fine on previous version of FortiOS.
paulinster wrote:It does also snmpwalk through the whole ipsec tun table fgVpnTunEntry(.1.3.6.1.4.1.12356.101.12.2.2.1), but the problem is that prometheus's snmp_exporter look at the fortigate MIB file and do rely on the index in order to push data within the database. When is push data to the database, it add some labels so when it' try to push/ingest the data, the format will look like this.
fgVpnTunEntStatus{ fgVpnTunEntIndex="x" } my_fgVpnTunEntStatus_value
The same snmp_exporter setup/config look to be working fine on previous version of FortiOS.
I saw your bug report for the snmpexporter and the replies (https://github.com/prometheus/snmp_exporter/issues/609).
Did you made any progress with TAC?
last comments/update I got from TAC look like they finally acknowledge the issue, however I haven't been able to get further details/informations :(
paulinster wrote:TAC told me that there is going to be an updated MIB with the release of FortiOS 7, "Add fgVpnTunEntPhase2Index as the second index of fgVpnTunTable in MIB file.".last comments/update I got from TAC look like they finally acknowledge the issue, however I haven't been able to get further details/informations :(
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1517 | |
1013 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.