Monitoring Cisco PIX/ASA IPsec VPN tunnels

[mrafi]

Final Update hopefully

Sorry dude, i exactly copied you Key but i realized now your script name has different name, corrected the name and now I am having below error.

became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal]

apologies for too many replies, as I have been trying different thing but this below key worked for me.

query_asa_lan2lan.pl["<CISCOPIX IP HERE>","{$SNMP_COMMUNITY}","ASA","get","RX","<YOUR GATEWAY IP HERE>"]

it might be because when we call script in the console we mention IP first and then community string and rest is as it is...anyway I get some value, dont know whether they are correct or not and also need to figure it out why I am not getting the graph.

Thanks for your help dude....darwinaloot

[darwinaloot]

Update

Yeah.. no problem.. do you have the updated query_asa_lan2lan_cisco.pl script?

[mrafi]

Yeah.. no problem.. do you have the updated query_asa_lan2lan_cisco.pl script?

No dude, I have used exactly the same script, not the final one, that dint work for me...do you have updated one ?

[darwinaloot]

Update

No dude, I have used exactly the same script, not the final one, that dint work for me...do you have updated one ?

Yes If I remember it correctly im using the updated script... I uploaded the script so you could also check..

query_asa_lan2lan_cisco.txt

[mrafi]

Yes If I remember it correctly im using the updated script... I uploaded the script so you could also check..

[ATTACH]6737[/ATTACH]

I will try your script as well, but if it is same as the expouser one then it will not work for me because I tried that before...

[mrafi]

I will try your script as well, but if it is same as the expouser one then it will not work for me because I tried that before...

yep I tried your scrip now it is working, I cannot see any difference in the output except that now I understand they key format you pasted earlier is working for your script because you defined the variable in different order.

[zied.bouazizi]

yep I tried your scrip now it is working, I cannot see any difference in the output except that now I understand they key format you pasted earlier is working for your script because you defined the variable in different order.

Hi All,

I would like to thank you first for your precious advices and shared experiences with zabbix.
I ran the last script and it looks working by retrieving data and bandwidth statistics. However, the resulted graph is discontinuous so we can't get a good idea about the ipsec tunnel bandwidth evolution.

Could you please help me to find what would be the issue?

Kind Regards,

[Linwood]

I don't know if this topic is too old but let's see...

I started trying to monitor ASA's and ended up somewhere near this. I started with Rancid however, scanning the cisco configs for defined tunnels, so I would have a list of what I expected and could detect tunnels that were never coming active, and matching this up against the data similar to what's in the script here.

However, in validating that it matches what I see in CLI, I find I am confused by the meaning of some of the tables.

This script from above sees to scan the Phase 1 list (cikeTunRemoteValue) and also the Phase 2 list (cipSecTunIkeTunnelIndex).

But the MIB has this thing in the middle called a cikePeerCorrTable, which is described as having one entry for each active tunnel and linking the phase 1 and phase 2 together. I don't see that the above scripts refer to that.

The reason I ask is that I'm finding two situations which are distinguished by that table, and am not quite sure how to interpret them.

1) The Correlation table may have only 1 tunnel, but there will be two with the same local/remote IP's in the Phase 2 table (i.e. anything with cipSec*). What is the meaning of the unreferenced extra entry? Is it prior data from a recent index change and so should be ignored?

2) The Correlation table may have multiple entries for one local/remote pair, and so similarly the cipSec* values also have multiple entries. I THINK, from just observation, this relates to separate ACL's which are going to represent separate end points, and what should be done with these is add them together to report relative to one Local/Remote IP pair (or conversely if you wanted to do separate endpoint subnet reporting, separate them out, but I do not).

Is this the correct interpretation? How have people using this dealt with the correlation table and reconciling the (otherwise) redundancies in the cipSec* fields?

I THINK the scripts in this thread just add them together all the time, but I'm curious if that's correct for cases when the tunnel in the cipSec* does not appear in the correlation table?

Finally - any else tried reconciling these against Rancid scripts, to find dead tunnels (but obviously ones with redundant routing or you would already know)? It's tedious and my syntax checking so far is very inadequate for the range of setups you can have (notably it does not handle multiple output IP's very well), so was wondering if this wheel has already been invented somewhere?

[Linwood]

I thought perhaps an example will make these comments a bit more clear.

The script below appears to use portions of this table to find the peers (I've obvious redacted some stuff).

# snmpwalk -v2c -cSomeSecret QQQQQQQQQQ  CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1413120 = STRING: 38. XXX.YYY.18
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1466368 = STRING: 50. XXX.YYY.77
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1531904 = STRING: 71. XXX.YYY.146
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1548288 = STRING: 50. XXX.YYY.37
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1556480 = STRING: 50. XXX.YYY.197
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunRemoteValue.1564672 = STRING: 69. XXX.YYY.86

Notice it shows 6 tunnels. That's phase 1.

Here's the actual data for outbound. Notice 7 tunnels.

# snmpwalk -v2c -cSomeSecret QQQQQQQQQQ  CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.352 = Counter64: 5866936627
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.353 = Counter64: 262710686
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.354 = Counter64: 27563120
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.367 = Counter64: 23461309
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.383 = Counter64: 19718614
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.387 = Counter64: 1752756
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.389 = Counter64: 2119089
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcOutOctets.391 = Counter64: 86627

The actual indexes for the above tunnel data comes from here, the correlation table. Notice it has 7 entries, and the flagged lines show where there are two for one peer pair. That pair has two endpoint subnets, which is why I think it comes out like this:

# snmpwalk -v2c -cSomeSecret QQQQQQQQQQ  CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrTable
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."50.XXX.YYY.77".500.367 = INTEGER: 367
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."50.XXX.YYY.37".500.387 = INTEGER: 387
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."69.XXX.YYY.86".500.391 = INTEGER: 391
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."38.XXX.YYY.18".500.352 = INTEGER: 352  <<<< 
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."38.XXX.YYY.18".500.354 = INTEGER: 354  <<<<
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."71.XXX.YYY.146".500.383 = INTEGER: 383
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerCorrIpSecTunIndex.ipAddrPeer."68.XXX.YYY.62".ipAddrPeer."50.XXX.YYY.197".500.389 = INTEGER: 389

Right at this moment I can't find any cases where there are entries in the cipSec* data that are not in the peer correlation table, but I thought I saw some. Maybe I caught it right on a tunnel creation or something.

So my question is one of interpretation -- what I'm doing it using the peer correlation table to find the appropriate indexes (e.g. 352, 354 for the flagged lines) and query those into the cipSec* tables, and add them together. And if any data is at indexes not in the peer correlation table, ignore it.

[mdiorio]

Dredging up this old thread. This is exactly what I was looking for and works perfectly.

Just a few things to note:

You may need to install the Perl Module Switch as it's deprecated in the core.

The shebang in the script needs to end with -X because Switch is deprecated, it will return an error message with the value and mess everything up. The -X ignores the deprecation warning and only returns the value.

Thanks very much for this script!

[darklord20k]

sorry for dig in, I'm beginner for both zabbix and ubuntu,
When I creat items, it appear error permission denied, although i did chown

ls -l /usr/lib/zabbix/externalscripts/query_asa_lan2lan.pl
-rw-r--r-- 1 zabbix zabbix 7912 Th12 19 18:34 /usr/lib/zabbix/externalscripts/query_asa_lan2lan.pl

I don't know how to fix it, please help
Thanks!

[lpossamai]

It works for CentOS 7 and Zabbix Server 3.4 (2018). Check out this Post.

[lpossamai]

Hi all,

Is it possible to use the script to get an Average? Instead of RX and TX?

This is how the graph looks at the moment:


I don't wanna see the sum(total) of bandwidth.. I was hoping to get a better good looking graph ; like this one for example:


Thanks in advance.

Cheers!