I am confused by this answer as we just hit the 50 user limit and we do "not" have 50 concurrent users connected but we do have 50 total uses showing up in our list that have connected since we created this sensor. Why would this sensor count 50 users total over the lifetime of the sensor if it is supposed to only count concurrent connections?

Hello,

Please note that this sensor can monitor up to 50 VPN connections - not up to 50 active users, but up to 50 offline and online users in total. So if the number of users (ever connected users, not just currently connected) exceeds 50, the sensor will show an error.

Best regards

If you have a changing username (like 2 way authenication, username*[code]) it will easy exceed 50 users. Why not have the last 50 users?

Hello,

With new connected users, new channels are created, but it is not possible to delete existing channels, sorry.

This is ridiculous. There are several options here that would make more sense:

1) Only show online users - I couldn't care less if they're offline, only when they're on. This would reduce the number of users in the list.

2) Let me chose how many users is my "max" based on my environment. I only have about 48 sensors and can throw dozens of CPU's and Gig's of memory at the box if performance was an issue. Unless your performance issues are with your database, let me make up my mind about the number of users to see.

This is a critical limitation in your application.

Dear mdiorio,

I do understand your point here. But I am afraid I have to tell you this is still status quo and we will not change this behavior in this direction anytime soon.

PRTG is predominantly designed to monitor numerical values. Furthermore, sensor channels can't be deleted as you would loose the related historic data in the same breath just to name one disadvantage. This would cause further issues.

I'm sorry that I can't offer you a more satisfactory respond.

Best,
Sebastian

I agree with mdiorio in part.

I have an extensive virtualization environment that will likely address any performance issues (I can assign up to 40 cores and 768GB vRAM to any machine). I would like to be able to choose the limits/thresholds myself. I don't mind the helpful warnings in regards to repercussions of doing so, but I do mind the limitations.

I'd like to be able to:

• see all VPN connections, regardless of type (i.e. AnyConnect, IPSEC, etc.);
• see historical and current data;
• designate a sensor as "informational" in order to use if for just that: information
• supress alerts generated by making a sensor informational (which I believe I can do by removing triggers).

Thanks

Dear msmith11950 and everyone interested in the feature request,

We do take your requests seriously and are fully aware that, for some situations, it would be helpful to have more than the pre-defined channel limits.
@msmith11950, your hardware environment is very powerful though, but it's important to know that PRTG's workload does not rely on dozens of gigabyte of RAM and multiple CPU's/Core's only. PRTG internal, hard coded data structure uses so called semaphores to avoid simultaneous access due to too many read and write locks which can cause severe issues.

At the moment there is no solution we can offer, I'm afraid.

Best regard,
Sebastian

Yes, as PRTG is concerned with monitoring numerical values, is there no way to monitor the current number of connected VPN users without creating a channel for each one? I want/need to monitor the count of active connections, something I can see in the ASDM utility, so the value should be available to PRTG.

You could write a custom sensor which puts that information into the sensor status message (up to 2000 characters, no line breaks.) Messages are not part of the historic data, so you would not be able to create reports for this.

According to support The PRTG sensor is limited in channels. Most sensors have a limit of 50 channels. This is a limitation by PRTG's architecture. A VPN with more than 50 users cannot be monitored in a useful way with PRTG. This can also not easily implemented, because of how PRTG works....

Do anyone know if there is another way to monitor number of VPN users ?

Dear ThomasMichaelJohansen,

since there is this limitation with channels, motioning more users would require using more sensors. Since sensors run independently, one would have to use a complex master sensor which creates additional sensors on the fly. With a single sensor, the number of channels is limited.

I need a solution asap. Currently 98% of our users vpning. I have 5 vpn concentrators and I need to monitor that.

Dear stabarz,

the capacity of having only up to 50 channels is documented in the official manual: https://www.paessler.com/manuals/prtg/snmp_cisco_asa_vpn_users_sensor

We understand that even without increased homeoffice use, this can be limiting. The development is informed about the pressing nature regarding this sensor, though the limit is implemented for a reason (preventing overload.)

Well - since we all are in the same boat.. here is a quick work-around. Read the article, please.. but it gives you at least a good idea of how many users are connected to your Cisco ASA.

Hope it helps a few of you.

https://www.it-admins.com/prtg-and-cisco-asa-vpn-monitoring/

Regards Florian Rossmark

The solution above worked for me. It uses CISCO-REMOTE-ACCESS-MONITOR-MIB where you can poll for the number of currently active sessions (crasNumSessions - 1.3.6.1.4.1.9.9.392.1.3.1.0)

I am coming here to voice the same concerns others have.

This sensor was one of the very cool things I showed management, we have the need to track who is in. We are logging that info, and have checked against ISE and other logs in the past but this seemed like a really easy and awesome way to know who was online at any given moment.

I will go poking to see if there is a MIB that will give me user information (I care more about who than the #) but it is pretyy disappointing to see this limitation.

The technical part makes some sense, but I would love to see the sensor delete data for offline users. We would never get to 50 people online at once, but the sensor is useless for companies with more than 50 users.

Thank you very much for your open feedback. I will immediately forward it to the responsible Product Owner in order to find a proper solution for this as soon as possible.

Best regards,
Sven Roggenhofer [Paessler Technical Support]

Exactly this requirement i got yesterday for a customer using brand new Cisco ASA and needs urgently Monitoring for it.

I´v just tested to create "SNMP Custom Cisco ASA VPN Counter" with the OID in article and it looks good.

We have to validate the results, but if this is stable -> "Go for it" and set up this one as Standard sensor.

Benefit: also a report using standard PRTG reporting can be created with graph and data table.

Best regards, Jürgen

I understand the limitations of the sensor, though, agree with the rest of the forum that the number of 50 is unacceptable. Further, the need to delete the sensor, and hence the data, and reports associated with it does not make it as simple as remove and re add.

I believe that Paessler, in this new semi post Covid world is missing an opportunity. That is, an add on application that can run on its own system if required dedicated to this one process, but be accessible for reporting to the main application. If the cost of said parallel application was not overly steep, it is something I would pickup in a heart beat. I too have more than 50 users, and am constantly asked for was xxx online on a certain day. I don’t see this need changing any time soon, if ever.

Hello,

for that scenario, PRTG is not the right tool. With PRTG we focus on more traditional network hardware status monitoring. Other sensor types exist but come with certain limitations.

As for possible new software, doing one thing means other things cannot be done at the same time. We are busy with features which are in high demand for many PRTG users.