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 ?
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.
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...
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
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
PCNSE
NSE
StrongSwan
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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
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
PCNSE
NSE
StrongSwan
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.
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 |
---|---|
1528 | |
1020 | |
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.