NetXMS Support Forum

The value NetXMS returns is correct. Your system does not have 6GB of free memory, it has 1.4GB.
It is using 2.1GB for applications and 4.5GB for Cache. Adding that up means the system is using 6.6GB of RAM, which leaves 1.4GB free (which is shown on the graph, the returned value is not "near zero").

You are confusing free memory with available memory. Memory used for caching is "available", but it is not "free".
Available memory is a different DCI: System.Memory.Physical.Available and it would have returned a value of 5.9GB at that time, which also matches your Task Manager screenshot.

Are you literally trying to poll "Net.Interface.BytesIn(*)"? If so, that won't work.
You need to specify the interface's index.

Two ways of doing that: Create the DCI manually by going into the Interfaces tab, right-clicking on the inter face and selecting Create Data Collection Items.
The more common and more scaleable approach is to use Instance Discovery. An older post with a recent update with screenshots (scroll to the end): https://www.netxms.org/forum/configuration/templates-instance-discovery/
There are quite a few questions & answers forum surrounding instance discovery. I therefore recommend going through the documentation and forums first.

Changing the community name on a node inside NetXMS does not require a restart.
However, adding "EnableSNMPProxy = yes" into an agent's configuration does.

Without an actual screenshot of what you are seeing it's a bit hard to tell, but I'm guessing those were created by instance discovery. The {instance} DCI was assigned as part of the template, but the ones generated on the node based on that {instance} DCI as part of instance discovery aren't part of the template, they'll show your node name instead.

Just in case someone else looks at this thread looking for runtimeFlags for nodes in 3.0:
https://www.netxms.org/documentation/nxsl-3.0/#node-flags

Now my problem is that I do not actually see an "unreachable" flag in that list... 

Is there a list of version 3 runtime flags?
We happen to be using the unreachable one for templates, so I'll need to do some updates.

Version 2 can be found here: https://wiki.netxms.org/wiki/NXSL:Node:runtimeFlags

That's a standard OID for CPU usage (more precise for "CPU Idle").

The unsupported alert means that you have a DCI on your node that tries to query the above OID and NetXMS isn't getting a response back.
That could be because:
- the device really doesn't support that OID
- the device is currently unreachable but NetXMS hasn't worked that out yet
- the device is having a temporary issue dealing with the request
- some SNMP packet(s) got lost in transit
If it's a temporary issue, the DCI should at some point change back to supported.

At our end, we simply disabled the event processing policy for unsupported DCIs as we are making heavy use of templates and some devices not supporting some DCI happens often enough to make unsupported DCI events a nuisance that drowns out other alerts. It really depends on your setup though.

Event processed per minute, are you transforming that into a per-second average or is that literally 500 events per minute that are being processed?
If it's the latter, while it sure looks like your system is hitting a ceiling, it wouldn't be a lot of events to process.
As I mentioned, ours is handling ~220 events per second.
A recent test I ran as part of a question on Telegram showed that our system could handle ~4500 events per second.

In addition to finding what's causing the daily event spikes (the occasional 1,000,000,000+ event spikes on your monthly graph are obviously roll-overs of some sort which you might want to filter out or cap the y-value on the graph), maybe have a look at the NetXMS server disk I/O, CPU and RAM.

I believe you could put that last script as auto-bind rule onto the containers themselves, as these are checked on a configuration poll.
However, depending on how often your configuration poll runs, neither will provide you a very "live" view of what's down.
Adding the BindObject code directly into Hook::StatusPoll might work better for that?

In regards to having the state in a node's Object Overview, you can create a PushDCI (you can check if it exists as part of the status script and if not, create it), then push the current state into it. That DCI could be displayed on the Object Overview page. Here's the downside: I am not sure if it is possible to perform this last step via NXSL, but using the Java API, e.g. via a cronjob to set this field on relevant DCIs once a day or similar should work via https://www.netxms.org/documentation/javadoc/latest/org/netxms/client/datacollection/DataCollectionItem.html#setShowInObjectOverview-boolean-
I'm not a developer and haven't ventured past NXSL, so I can't provide an actual script for this.

Are you monitoring "Server.TotalEventsProcessed" on your server (DCI)?
It could help identify sudden spikes in events giving you a place to start looking, e.g. does this always happen at the same time? Or after roughly the same time period?
What is the server doing at that time (other than piling up events)? Are there resource issues? Is the housekeeper running? Are there database locks?

For comparison, our system is currently handling 220 events per seconds on average without any issues. We're running 60 EPPs some with somewhat complex filter scripts, but I believe your number is more than double that?
Are you using "Stop event processing" to stop processing EPPs after a matching policy? Without it every event will be checked against all policies. Unless your events match a whole range of policies this shouldn't have a massive impact, but throwing it out there anyway.

From what I recall the VPN Connector is a manual "helper" for linking networks connected via VPN on maps.
You can configure a VPN Connector on a firewall/router each link them. Automated maps will then honour that link, so your maps will show both sides. Otherwise the map would stop at each firewall/router.
It is not a tool to monitor or establish VPNs.

Regarding the tunnel status being integer values, the SNMP MIB file will likely contain a "translation" for the integer value. This is a weak point in NetXMS' MIB Browser: it will show the description of an OID, but not the "SYNTAX INTEGER" part which in most cases is required for translation of such integer values (most vendors don't put that information into the description). An example might be more helpful here (this is not for any VPN Tunnel, just an example of how a MIB file looks and what NetXMS shows):
       hpicfSensorStatus OBJECT-TYPE
           SYNTAX     INTEGER {
                          unknown(1),
                          bad(2),
                          warning(3),
                          good(4),
                          notPresent(5)
                      }
           MAX-ACCESS read-only
           STATUS     current
           DESCRIPTION
                   "Actual status indicated by the sensor."
           ::= { hpicfSensorEntry 4 }

In the above, NetXMS will show you hpicfSensorStatus as translated name for the OID. It will also show you the "Actual status indicated by the sensor." in the description. But it will not show you the unknown, bad, warning, good, notPresent information and their numerical representation. In other words, you'll have to go through the MIB for your firewall to locate these details to run a transform into a string (if you want it to show a string.... integers do have the advantage that you can graph them and quickly see when things changed over time).
For transforms on a table DCI, the following post will probably be helpful as well: https://www.netxms.org/forum/configuration/transformations-scripts-for-table-dci/

An alternative to a table would be to use Instance Discovery. There should be a number of forum posts with examples on how to configure this if you want to give it a go.

Depending on what exactly you're trying to do, it could be enough to do a ping test across the VPN (Phase 2 established means the ping should pass through).
If you want to know the actual state of the IPSec VPN and your firewalls allow for it, you may be able to pull actual tunnel information via SNMP.
The devices might also send Syslog messages or SNMP traps whenever a tunnel drops or is established.

The first should be pretty straightforward using the Ping subagent: https://www.netxms.org/documentation/adminguide/icmp-ping.html (That and probably some searching on the forum on how to properly configure/use this as it comes up every now and then. We're not using it so I can't provide guidance.)
The other options would depend heavily on the devices you are using and the details would be specific to them. For some firewalls they may not be possible at all.

Just to summarise my test utilsing TCP Proxy within an Object Tool to connect to switches and routers in remote, private networks using SSH: it works - in NetXMS 3.0.

You could make it work in version 2, but my goal was to call an external PowerShell script that automates populating all the variables required to use the TCP Proxy as well as start a Putty session for the connection. And in version 2, I cannot use a script macro inside the Object Tool. That's a feature that's available in 3.0. The above setup did require adding the proxy JAR file, Putty and PowerShell script into a (sub-)directory of the local Management Console. That also means it doesn't work via Web Console.
The whole approach may be a bit Rube Goldberg-style, but it works. Looking forward to the full release of 3.0 when I can unleash this onto our users.

Note: We're not running 3.0 in production, only on a test system.

That was it. My bad, should've read the initial instructions properly...

Thanks

I just tried to use nxtcpproxy from within an object tool.

From what I can tell, it is starting up and listening. But whenever it tries to establish the proxy session to the device at the other end, it just doesn't happen. Tried using SSH and https. Both don't connect (or more precise, they "unexpectedly" close the connection right away). IP and remote port are correct. Command output (see screenshot) shows it found the correct proxy to use for the connection.

Running the Java command from the command line rather than via Object Tool, I get additional output when I try to connect through the tunnel:
org.netxms.client.NXCException: Access denied
        at org.netxms.client.NXCSession.waitForRCC(NXCSession.java:1696)
        at org.netxms.client.NXCSession.waitForRCC(NXCSession.java:1665)
        at org.netxms.client.NXCSession.setupTcpProxy(NXCSession.java:10485)
        at org.netxms.tcpproxy.TcpProxyApp.run(TcpProxyApp.java:80)
        at org.netxms.tcpproxy.TcpProxyApp.main(TcpProxyApp.java:119)
I thought that'd be an obvious case of missing permissions, but the user has permission to initiate TCP proxy sessions.
In fact, the user has pretty much every permission short of being an integration account (for the sake of it, I gave that permission as well, but it made no difference).

Is that really a NetXMS permission problem or some Java Security thing?