Cisco VPN: User Session Time Monitoring

There might be a chance to get this - but it will involve some effort.

The Cisco ASA VPN sensor indeed shows you the amount of users connected - in theory that might be a single SNMP query and single response from the ASA (did not look it up in detail).

What you want is the duration of a sessions - and now it becomes complicated.

You might have 40 users connected to your ASA - so do you now want to report the top time you are able to find or what exactly?

In theory let us say you have a license for 500 users - PRTG allows up to 50 channels per sensor - well - the time alone won't help so you need additional values ... since there are IPs involved that you could only report as a text-string what narrows it down to 1 per sensor but in theory abusing the warning and error fields per channel you might be able to bypass this...

So - assume we set the error message in the channel as the IP found in the ASA - so if the session time is more then 24 hours you get the IP as an error message - you still end up with 100 sensor a 50 channels - just to cover all possible VPN connections.

Why? Simply because if you look at this MIB file you will quickly find that a big part will be in the OID 1.3.6.1.4.1.9.9.392.1.3 - possibly even the session time hidden somewhere (likely as a tick-count (Linux/Unix) or a seconds value) but you will have changing and extremely variable OID paths due to the way it works. You still would need to cover all possible connections and the results back to PRTG would highly vary.

On top - you would need to find a way to do the SNMP queries - likely in PowerShell and probably with this free module (as of what I read it is free):

• powershellgallery.com: Proxx.SNMP

Cause you will need to act dynamically on it.

Even just to find out the longest session - you will need to include a script technique to read through the current connections and determine the oldest session/connection - assuming that Cisco provides you that per SNMP (likely - but did not test it out).

All of this is quite a bit of effort - it sure is possible - but having a ASA here myself I still wonder what good it would do me to know this. Theoretically I could abuse SYSLOG for it or the logging and later determine such information - if not directly in clear-text reported - simply due to database queries looking for connect and disconnect information - assuming your logging is reported to a database system. We talk about big-data here - while PRTG can process and help you here - it is not a database where you can do syslog research.

If you are worried about the time the users are connected - there are a few configuration values on the ASA that might help to prevent this.. though, I have users that are connected many days - due to them having a home office with of course company provided equipment (nothing else is allowed to use the VPN) where I really don't care if they are connected for a whole month - it actually allows some other automatic stuff to run on their systems - likely pushed out software or various other scheduled maintenance tasks.

Sorry for the long response and not providing you a solution - I don't see any benefit in putting so much effort in it - but I know it might be possible if you dig a bit deeper in to the provided links.

Regards

Florian Rossmark
www.it-admins.com

Florian is right. The data does indeed appear to be available in the crasSessionTable(1.3.6.1.4.1.9.9.392.1.3.21). More specifically:

However, this is a multi-indexed table, index by Username and Session:

   crasSessionEntry OBJECT-TYPE
      SYNTAX CrasSessionEntry
      MAX-ACCESS not-accessible
      STATUS current
      DESCRIPTION
            "Each entry contains the attributes, statistics and
             status of an active session."
      INDEX { crasUsername,
              crasSessionIndex}
      ::= { crasSessionTable 1}

This makes a lot of sense, because a single user might have multiple sessions. But it makes interacting with the SNMP Data considerably more complex. PRTG wise (if you tried monitoring this with the SNMP Custom Table sensor you'd get one sensor per user and session. And sensors would go down as soon as session is closed. In other words, not very practical.

And as an exe/script, this would be difficult to do because channels in PRTG lack the dimensions for this. Let's say you did a custom-exe script advanced sensor, with the top 10 active sessions. Since channel names are static, you'd run into issues if you used the username as channel name. If you simply named the channel "Top 1" you'd see what the connection time for the user is but not the user name. This would have to be part of the sensor's message, something like Top1 = John, Top2 = Tom, Top3 = Mr. X and so forth. The problem then would be, it's not very pretty and you wouldn't be able to correctly graph this, since PRTG would only record the duration of the top sessions, but with no permanent association to a user (because the sensor's message isn't stored, only numerical values(since they can be easily stored and graphed).

Ps.: Thank you @Florian for the hint about Proxx.SNMP - Works like a charm!

PS C:\WINDOWS\system32> $a = Invoke-SnmpWalk -IpAddress $b.IPAddress -Oid 1.3.6.1.2.1.25.2.3
PS C:\WINDOWS\system32> $a

Node        OID                      Type        Value
----        ---                      ----        -----
10.49.13.49 1.3.6.1.2.1.25.2.3.1.1.1 Integer32   1
10.49.13.49 1.3.6.1.2.1.25.2.3.1.1.2 Integer32   2
10.49.13.49 1.3.6.1.2.1.25.2.3.1.1.3 Integer32   3
10.49.13.49 1.3.6.1.2.1.25.2.3.1.1.4 Integer32   4
10.49.13.49 1.3.6.1.2.1.25.2.3.1.1.5 Integer32   5
10.49.13.49 1.3.6.1.2.1.25.2.3.1.2.1 ObjectId    1.3.6.1.2.1.25.2.1.5
10.49.13.49 1.3.6.1.2.1.25.2.3.1.2.2 ObjectId    1.3.6.1.2.1.25.2.1.4
10.49.13.49 1.3.6.1.2.1.25.2.3.1.2.3 ObjectId    1.3.6.1.2.1.25.2.1.4
10.49.13.49 1.3.6.1.2.1.25.2.3.1.2.4 ObjectId    1.3.6.1.2.1.25.2.1.3
10.49.13.49 1.3.6.1.2.1.25.2.3.1.2.5 ObjectId    1.3.6.1.2.1.25.2.1.2
10.49.13.49 1.3.6.1.2.1.25.2.3.1.3.1 OctetString A:\
10.49.13.49 1.3.6.1.2.1.25.2.3.1.3.2 OctetString C:\ Label:  Serial Number 6292b832
10.49.13.49 1.3.6.1.2.1.25.2.3.1.3.3 OctetString D:\ Label:New Volume  Serial Number 2af34479
10.49.13.49 1.3.6.1.2.1.25.2.3.1.3.4 OctetString Virtual Memory
10.49.13.49 1.3.6.1.2.1.25.2.3.1.3.5 OctetString Physical Memory
10.49.13.49 1.3.6.1.2.1.25.2.3.1.4.1 Integer32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.4.2 Integer32   4096
10.49.13.49 1.3.6.1.2.1.25.2.3.1.4.3 Integer32   4096
10.49.13.49 1.3.6.1.2.1.25.2.3.1.4.4 Integer32   65536
10.49.13.49 1.3.6.1.2.1.25.2.3.1.4.5 Integer32   65536
10.49.13.49 1.3.6.1.2.1.25.2.3.1.5.1 Integer32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.5.2 Integer32   20881407
10.49.13.49 1.3.6.1.2.1.25.2.3.1.5.3 Integer32   2620671
10.49.13.49 1.3.6.1.2.1.25.2.3.1.5.4 Integer32   35591
10.49.13.49 1.3.6.1.2.1.25.2.3.1.5.5 Integer32   24568
10.49.13.49 1.3.6.1.2.1.25.2.3.1.6.1 Integer32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.6.2 Integer32   17009151
10.49.13.49 1.3.6.1.2.1.25.2.3.1.6.3 Integer32   11099
10.49.13.49 1.3.6.1.2.1.25.2.3.1.6.4 Integer32   22970
10.49.13.49 1.3.6.1.2.1.25.2.3.1.6.5 Integer32   14278
10.49.13.49 1.3.6.1.2.1.25.2.3.1.7.1 Counter32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.7.2 Counter32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.7.3 Counter32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.7.4 Counter32   0
10.49.13.49 1.3.6.1.2.1.25.2.3.1.7.5 Counter32   0

Best Regards,
Luciano Lingnau [Paessler Support]