Hello
We would like to monitor users on our Cisco ASA VPN, more specifically, the length of time their session is connected for.
I know it is possible to monitor the number of connections, if they are offline etc, but I have not found anything that can report on the session time of VPN users.
I believe there is a way to query this via cmdlets from putty etc - my question is, is there a way to query this via PRTG, in a similar fashion to the EXE/XML sensors - in essence, can we remote call a query to output a value that PRTG can then read and report on?
If so how would the best way to go about this be?
Article Comments
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:
| crasSessionDuration | 1.3.6.1.4.1.9.9.392.1.3.21.1.6 |
| Counter32 | The number of seconds elapsed since this session was established. |
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]
Nov, 2018 - Permalink
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):
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
Nov, 2018 - Permalink