NetXMS Support Forum

I saw in changelog for 2.2.7 added functionality for "TCP proxy", but I can't find any documentation for that. Can someone point me in the right direction?

Hi,

there is TCP proxy functionality in agent, server, and client API which is something similar to SSH port forwarding. It was intended mostly for integration tools but there is command line tool that can be used for TCP port forwarding. You can build it from source (it is located under src/client/nxtcpproxy) or download from here: https://cloud.netxms.org/index.php/s/zQLdMnFaNu0mwNA

You run it on your workstation like this:

java -jar nxtcpproxy-2.2.15.jar netxms_server_ip netxms_login netxms_password proxy_node_name remote_ip remote_port local_port

On proxy node TCP proxy should be enabled by adding

EnableTCPProxy = yes

to nxagentd.conf file. NetXMS user should have system access right "Initiate TCP proxy sessions".

For example, if I want to connect with SSH to IP address 10.5.3.2 via proxy node "zone-proxy" I can run (assuming NetXMS server IP address is 10.0.0.10)

java -jar nxtcpproxy-2.2.15.jar 10.0.0.10 admin password zone-proxy 10.5.3.2 22 2222

and then connect with SSH client to localhost port 2222.

Best regards,
Victor

If I wanted to use this within Object Tools, is there a variable or other way to push the connected user's NetXMS Server/Login/Password connection details straight through to that command?

I was thinking of something along the lines of right-click on node to start the proxy process, followed by opening a Putty connection through that SSH tunnel.
Though that'd require two local commands and for the sake of usability (nobody would want to run it that way and enter half a dozen variables every time) would need to be wrapped in a script - but NXSL doesn't seem to include ways to run local commands.
Guess the above might work for RDP or for accessing web interfaces internal to a network, too.

An obvious concern would be the ability by an admin to log usernames and passwords. If nxtcpproxy was more integrated that step probably wouldn't be necessary?

Edit: I also just noticed, the proxy node is identified by name, not ID?

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?

Did you add

EnableTCPProxy = yes

to config of proxy agent? Also, server has to be listed as master server on a proxy.

Best regards,
Victor

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

Thanks

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.

And here I was thinking my excessively complicated PowerShell to create a service desk ticket was just me (which it still largely probably is).

Switch management in remote networks is potentially on my horizon, so good to hear that a) somebody else got it working and b) they used PowerShell.

My only hard requirements were SSH (Securecrt or Putty) and Utilization / Packet loss at a Node level and at an interface level. This functionality should deliver the first and I assume that Utilisation and Packet Loss could / should probably be added to the Network template to give me the second. (add .13 .14 .19 and .20 from iftable)

Once v3 is out, will check out what options are now available.