SNMP monitoring VPN tunnels

[dirkdigs]

Has anyone successfully setup PRTG to monitor IKE VPN tunnels on a FortiGate by importing the Fortinet MIB files ad extracting the relevant OID's ?

[Jirka1]

Hello,

It´s simple. You don't have to import anything. Just configure SNMP and scan the interface. IPsec tunnel is a standard intreface for monitoring.

Jirka

[Jurie]

Hi 

Also want to know the same thing...

I have managed to configure PRTG to connect to my local Fortinet APC by importing the Fortinet MIB files ad extracting the relevant OID's but I cant get it to work on a remote site via VPN. I have checked the remote FW and APC and SNMP is configured corerctly SNMP is allowed on the FW interface and IPv4 policy, I can ping and access the FW and APC from my network but cant get SNMP to connect...

[Dominik]

Hi guys,

sorry for opening this thread again.

But monitoring the interfaces doesn't mean you monitor the IPSec tunnel. The tunnel interfaces just goes down in case the complete tunnel goes down. In the moment one (or multiple) SA of a tunnel goes down your PRTG wouldn't recognize anything. But the impact could be as critical as if the complete tunnel goes down.

So you need to monitor the SAs too.

With PRTG there is a way to monitor the SAs with the OID 1.3.6.1.4.1.12356.101.12.2.2.1.20 but in my eyes that's a very unattractive way because you have to use a formular sensor or a custon snmp sensor, that scales up very fast.

Do you know any other ways? Kind regards,

Dominik

[emnoc]

This has came up in past post but your best bet is to review the mib-tree and then find out what you want to monitor.

https://forum.fortinet.com/tm.aspx?m=111059

You have many options from up/down and in/outOctets for vpn interface or any interfaces as far as that goes.

Ken Felix

[sw2090]

you could use .1.3.6.1.4.1.12356.101.12.2.2.1.2 to get an index and the descriptive Phase1 name for your tunnels

and then use the index on the output of .1.3.6.1.4.1.12356.101.12.2.2.1.20 to get the corresponding status for the tunnel. This will give you an integer with 1 for down and 2 for up.

Of course as said this can only state if a tunnel is down or up and not if one side (or SA) went down.

As far as I am concerned that don't matter because we use DPD with our S2S IPSec Tunnels and DPD will take the tunnel down if the other side does not respond anymore.

[Dominik]

Hi sw2090,

true, this would be an option. But we would still not solve the problem, as you already mentioned, that we won't see if only one SA of a tunnel went down. But that's a case in my eyes you have to cover with a monitoring system. One SA down can impact a lot in a customer environment.

A way would be to monitor every single SA with the table OID 1.3.6.1.4.1.12356.101.12.2.2 but let's be honest: that isn't a suitable solution.

In my opinion there isn't a perfect solution for monitoring IPSec VPN including SAs. Regardless if it's Fortinet or anyone else.

I'll try to use the possiblitys of the advanced sensors of PRTG to get this to a suitable solution. How is your way to monitor this case with your monitoring solutions?

Kind regards,

Dominik

[emnoc]

I think your over complicating things, if your goal is to monitor layer3 over a SA , just monitor a host that's reachable from over that SA? In every org where we had hub-spoke vpn we had a general rule that allow monitoring from the snmp-nms-host to  key items and in fact this same snmp-host monitor core-it stuff over the vpn. So if the vpn goes down, or a core item become unreachable we knew the tunnel was down.

As mention b4 you can run the snmp-mib & ipsec details or use let's say a nagios check similar to { check_fortigate.pl } and monitor what oid it probes. That will show you how it monitors and the snmpget against the name oids. The check above counts active tunnels and you can customize an alert if X doesn't eq Y and alert. 

YMMV  but you have many options from checking a layer3 resource reachable over the tunnel, ospf/bgp state over the tunnel, or the proper oid for the tunnel, if it's an interface vpn, you can also alert if recv pkts falls below vaule of XYZ in the last 5minutes 

Follow the KISS rule  ( Keep It Simple & Straight ) in your approach and you should be golden.

Ken Felix

[abatie]

In our case, the monitoring system is not in a place to make a connectivity check.  We need to check the state of a phase 2 tunnel that keeps going down within an ipsec tunnel.