Announcement

Collapse
No announcement yet.

Monitoring Cisco PIX/ASA IPsec VPN tunnels

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Final Update hopefully

    Originally posted by mrafi View Post
    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

    Comment


      #17
      Update

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

      Comment


        #18
        Originally posted by darwinaloot View Post
        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 ?

        Comment


          #19
          Update

          Originally posted by mrafi View Post
          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

          Comment


            #20
            Originally posted by darwinaloot View Post
            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...

            Comment


              #21
              Originally posted by mrafi View Post
              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.

              Comment


                #22
                Originally posted by mrafi View Post
                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,
                Attached Files

                Comment


                  #23
                  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?

                  Comment


                    #24
                    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).

                    Code:
                    # 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.

                    Code:
                    # 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:

                    Code:
                    # 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.

                    Comment


                      #25
                      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!

                      Comment


                        #26
                        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!
                        Last edited by darklord20k; 25-01-2018, 05:16.

                        Comment

                        Working...
                        X