VPN monitoring

Hi Kris,  Depending on your requirements, the Cisco IPSec Tunnel- and WatchGuard IPSec Tunnels- datasources (or clones of, for specific hosts) could both be adjusted to make discovered instances persistent, and also to then alert on no data, i.e. when a tunnel dropped and data ceased reporting.  Equally it is possible to set an alert if, for example, the count of IP Sec Tunnels (in the CiscoASA datasource) decreases.  Note, neither of these would not be able to differentiate between a deliberate disconnection and an alert-worthy drop.  If you wish to explore this in more detail, please feel free to start a chat with an engineer and we can run through the options with you.

Thanks Anthony,  I have got these already and had alerts setup for them, however it would only report if a tunnel drops and would not tell me which one so i removed the alert as we really need to know which tunnel.

For me it I would need this to be done for Sonicwall firewalls. In talks with LM rep I was told this is being worked on for Sonicwall but have not heard anything further of when it would be done.

I monitor a lot of VPN tunnels as well. I find there is not a lot of point in monitoring a VPN router/firewall as it may be able to tell you if its up, but not the quality of the link (e.g packet loss). You really need to ping something at the other end to tell if the VPN is up and reliable.  There are a couple of options
1: get a Cisco device and configure IP SLAs to ping the other end. SLAs give all sorts of information on the quality of the link (jitter, latency etc). LM discovers and monitors SLAs.
2: again ping something at the other end of the VPN (say a printer) and alert when this is down.

But I don't like this for the following reasons: it implies the printer is down when in fact its the VPN.  It is also a waste of monitor licenses. If I want LM to monitor 1 firewall that terminates 20 VPNs I have to pay for 20 licenses.  And if you group your monitors according you end up having your network people monitoring printers.  The logic should be that the ability to ping the printer and get the RTT, packet loss is not a function of the printer, but of the VPN, and the VPN is a function of the router/firewall  So what LogicMonitor needs to be able to do (and something that Intellipool Keseya does already) is on the firewall/router object provide the ability to list some alternative IP addresses. It would then be the job of the collector to ping each of those IPs, and if they fail or drop packets, put that firewall/router device into alert.

@Simon you could use the multiping datasource to monitor these and only need one collector and one device added to monitor the endpoints of your VPN for packet quality.

Suggestions:  If the 'tunnels' DataSource doesn't meet your needs, here's an option.  I call it 'mesh ping'  It works by using a property called 'ping.targets' on a group of your collectors. It has a comma delimited list of displaynames and IP addresses. Basically each collector pings a device on the other end of the VPN.

Below is the short script that builds the list of ping targets (known as 'Active Discovery'.

ip_a = hostProps.get("ping.targets");
//ip_a = "google@8.8.8.8,gateway@10.36.17.1,self@10.36.17.250"
ip_b = ip_a.split(',');

for ( i = 0; i < ip_b.length; i++) {
  def (name,ip) = ip_b.split('@');
  println ip+"##"+name+"@"+ip;
}