Monitor Cisco ASA Site to Site VPN with MRTG


Look for these lines in the output:

SNMPv2-SMI::enterprises. = Hex-STRING: D4 DB 3F CE
SNMPv2-SMI::enterprises. = Hex-STRING: 94 09 ED C4

SNMPv2-SMI::enterprises. = Hex-STRING: D4 DB 3F CE

SNMPv2-SMI::enterprises. = Hex-STRING: D4 DB 3F CE

SNMPv2-SMI::enterprises. = Hex-STRING: 94 09 ED C4

SNMPv2-SMI::enterprises. = Hex-STRING: 51 AE 81 5C

The first line that contains the red is the string identifying the VPN connection that we want to track; you may need some guess work and trial and error to find the correct one.

Here there is also something to note, when there are multiple site to site VPNs or remote access VPNs, this script will attempt to return two or more IDs, which then means the script won’t work correctly, to sort this you need to add the number “4” that refer to the correct site to site VPN to the end of the SNMPWalk command, shown in green below. This will ensure that the correct VPN is monitored and the script doesn’t return an error as it tries to return two IDs at the same time. If you leave the “4” off the end it will match anything with the same hex string, which may include other tunnels you don’t want included.

Create a file called in the /usr/sbin directory with the following contents:

# snmpwalk -v 1 -c communitystring

We were looking at how to monitor traffic going from our internal network to our cloud network as we conducted a cloud computing pilot. We found that cloud computing was far to expensive for us because our internal in-house IT offering is so cheap, i.e. to provide the same resources from the cloud we’d be doubling the cost of in-house IT, of course our in-house IT doesn’t have the same uptime ability, but those in the ivory tower don’t care about that its the cost that counts and as long as IT works when they want it to they are not too bothered with 99.99999% availablility.

Anyway, off topic…..I wanted to know the kind of traffic that would be making its way to our cloud environment so we’d have an idea of the bandwidth usage, of course this is fairly well documented for MRTG with switches internally, and routers and firewalls. What seems to be more difficult is how to do this with VPN tunnels. Because although a site to site VPN is probably going to be quite static, it by its nature is dynamic, and might re-key and drop and come back up so any monitoring of it needs to follow its changes.

CITATION: So heres a way to do it. I’m building very heavily on the work done by this chap: i’m basically using his work as a starting point. So standing on the shoulders of giants so to speak. And because the amount of documentation about how to do this is so small and hard to find i’m repeating it here.

This solution assumes you are using MRTG on Linux (any flavour, i’m using Ubuntu) and you are running a Cisco ASA 5520 with ASA-IOS 9.0(2) and ASDM 7.1(2) on it monitoring with SNMP and i’m assuming you know how to do this SNMP setup already. The below configuration is working for that.

One thing to note is that when the tunnel drops or rekeys all the previous data is lost in MRTG, i’ve yet to find out why this is happening.

Firstly you need to identify the firewall running the VPN, in our case this is the firewall.


## Parses out the correct tunnel entry to monitor for the VPN

## Technique:



CLD=`snmpwalk -v 1 -c o4kl4nds .4 | grep " D4 DB 3F CE " | awk -F'.' '{print $10}' | awk '{print $1}'`

echo VPN ID: $CLD

snmpget -v1 -c o4kl4nds $CLD | awk '{print $4}' > /temp/cld.txt

snmpget -v1 -c o4kl4nds $CLD | awk '{print $4}' >> /temp/cld.txt

You should try to run the snmpwalk command outside of the script to see the result you get is correct, and also the snmpget ones too, you should find that you get an output of the VPN ID from the first, and from the snmpget command the statistic for the current bytes on the interface.

There are two snmpget commands, because you are querying input and output from the interface (the green and the blue on the graph), you can check these independantly.

Set the file to be executable with:

 # chmod 777

Now edit the crontab with:

# crontab -e

And make it look like:

# m h   dom mon dow    command

*/5 * * * * /usr/sbin/

*/5 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/firewalls.cfg

This script basically connects to the firewall, queries the statistics for the VPN tunnel, then saves them into the /temp/cld.txt file ready for MRTG to scoop up into its statistics file and generate the graphs.

Add to the file smf-firewalls.cfg that is within the /etc/mrtg/ directory the following lines, at the end of the file. Notice that the “target” (or input) is the temporary file /temp/cld.txt which will contain the statistics of the VPN connection at that time.

### Interface 4 >> Descr: 'CLOUD Site to Site VPN' | Name: 'DMZ' | Ip: '148.x.x.x'###

Target[148.x.x.x]: `cat /temp/cld.txt`
SetEnv[148.x.x.x]: MRTG_INT_IP="148.x.x.x" MRTG_INT_DESCR="Adaptive-Security-Appliance-'DMZ'-interface"
MaxBytes[148.x.x.x]: 13107200
Title[148.x.x.x]: Traffic Analysis for site to site VPN to CLOUD
PageTop[148.x.x.x]: <h1>Traffic Analysis for site to site VPN to CLOUD</h1>

                <div id="sysdetails">
                                        <td>Site to Site VPN to CLOUD</td>


                                        <td>Site to Site VPN to CLOUD</td>

                                        <td>IPSec VPN Tunnel</td>

                                         <td>IPSec VPN Tunne</td>

                                        <td>Max Speed:</td>
                                        <td>100.0 Mbits/s</td>


Now sit back and wait to see if it adds the statistics, alternatively run the commands in this order to force it creating a sample of the firewalls stats….

# indexmaker /etc/mrtg/firewalls.cfg --output /var/www/mrtg/firewalls/firewalls.html

This will now run the script to collect the statistics every 5 minutes, then it will run the MRTG script to update those statistics from the contents of the /temp/cld.txt file.

Now regenerate the indexmaker:

# /usr/sbin/

# env LANG=C /usr/bin/mrtg /etc/mrtg/firewalls.cfg

Leave a Reply

Your email address will not be published.