agent-to-server connections

Started by Tursiops, April 06, 2017, 01:06:01 AM

Previous topic - Next topic

Tursiops

Hi,

This little line in the Changelog got me all excited: "Experimental agent-to-server connections (agent tunnels)"
But how do I experiment with these experimental connections? :D

Cheers

Victor Kirhenshtein


Tursiops

Hi Victor,

I've been trying to get this to work, but it appears I'm getting something wrong with the certificates, leading to tunnels not working from the moment I bind them.

After setting up a CA on the NetXMS server, I configured NetXMS as per the Wiki article.
When a node connects, I see an unbound tunnel. I bind it and see the following in the logs:
[DEBUG] IssueCertificate: new certificate request (CN override: <NODE GUID>)
[DEBUG] IssueCertificate: new certificate issued successfully
[DEBUG] [TUN-1] Certificate issued

After that, the tunnel disappears and the client logs just keep telling me the TLS handshake is failing, and the server logs give me "verification error 20 (unable to get local issuer certificate)" and "verification error 2 (unable to get issuer certificate)". I translate that as "I don't trust your intermediate/CA cert, go away".
Next I installed the CA and Intermediate cert on the actual node, but that did not make any difference.
The certificate chain on the NetXMS server verifies ok and the server is not complaining about the certificates at startup either, but confirms they loaded ok.
Not sure if I am missing something with the certificate setup?

And another question, is there a way to "unbind" tunnels I setup for testing?
Once I bind them, I can neither see the tunnels as "Bound" or "Unbound" and cannot find a way to remove that link in the Console or in the database. Short of wiping the nodes and re-adding them, how do I remove those node<->tunnel links?

I also can't see where the client certificates are actually stored on the node?

Cheers

Tursiops

Hi again,

I went through some of the code and think I have a better understanding on how nodes are bound to tunnels now.
Posting some of this information here in case it might be helpful to others (even though my tunnels still are not working due to TLS handshake problems).

The agent connects without a certificate and the server generates one for the agent. The certificate contains the agent's GUID as common name. So whenever it connects afterwards, the server knows which node it's talking to, so there is no need to store any node<->tunnel reference in the database. Which means all I need to do to "start fresh" is to delete the certificate, which by default (on Windows) is stored in %localappdata%\nxagentd\certificates. So for the standard Windows agent which is running as Local System that would be C:\Windows\System32\config\systemprofile\AppData\Local\nxagentd\certificates. Delete the certificates and the tunnel will show up as unbound on the server again.

That basically answered my last two questions. It just doesn't tell me why the TLS handshake is failing.  :-\

Cheers

Tursiops

Hi again,

Hope this thread helps other people who might want to try the new experiemental agent->server connection functionality.

After spending some more time on this, I guess it all depends on how you set up your CA.
I used the following guide: https://jamielinux.com/docs/openssl-certificate-authority/index.html
Now, that's where I managed to become confused between the Wiki article and the above guide.

The NetXMS Wiki says to link to the CA certificate and a combined Server certificate/key.
The latter is presumably meant to sign additional certificates, but my server certificate was not authorised to do that.
Instead, I had to put my Intermediate CA certificate and key in as "ServerCertificate" and now the tunnels are up, bound and showing in NetXMS.


What's still not working for me is actual data collection:
- Status polls return unknown status, configuration polls don't run due to node unreachable.
- DCIs all show <ERROR>
- The only exception is a full configuration poll, which happily detects the agent.

I wasn't quite sure if this was Zone related, so I moved the nodes in question into the Default zone "just in case", but it made no difference.
The communication IP is set to 0.0.0.0 as per Wiki.

Not sure what else I might possibly be missing at this stage?

Cheers

Tursiops

Ok, found the final issue.

Using 0.0.0.0 as the agent IP did not work.
Using the systems actual IP address once the tunnel was bound did work.

Victor Kirhenshtein

Hi,

it's strange that 0.0.0.0 is not working - it did on my system. Are you sure that after you set system IP server uses tunnel istead of direct connection? Also, in 2.1-RC1 that just released we have added tunnel manager in the GUI, so you can see active tunnels and bind/unbind them from UI.

Best regards,
Victor

Tursiops

Hi Victor,

The node in question was (and is) completely unreachable to the server, unless the tunnel was working.
Inbound active server->agent connections are being rejected by the firewall in that network.

Cheers

StanHubble

Hi,

I have finally got agent-to-server connections working in version 2.1.1 (same certificate issues as Tursiops).

I created the nodes with the 0.0.0.0 address and bound the agents to the nodes and they connected, but any status or dci polls returned "<error>". 

Once I entered the external ip of the tunnel into the node everything started working.  I have about 45 of these sites set up this way and some of them have dhcp connections to their isp's so I don't know yet if a change of ip on the tunnel will break it.

Would it be possible to put some indication on the object details screen (capabilities or general grid) that a tunnel is connected and maybe its ip or id? ( assuming we have to go back to the 0.0.0.0 address )

thx

ditonet

Hi,
I'm trying to run agent-to-server connection, but log says:
Cannot load server certificate from C:\NetXMS\Certs\NetXMS_Server.crt (error:0906D06C:PEM routines:PEM_read_bio:no start line)
NetXMS runs on Windows Server 2008 R2
Any ideas?

Regards, Grzegorz.

Victor Kirhenshtein

Hi,

most likely certificate format is wrong. Server expects it to be in PEM format.

Best regards,
Victor

ditonet

Hi Victor,

Certificate is in PEM format.
I found solution of this problem.
The certificate file consists of two parts: certificate and private key, e.g.:
-----BEGIN RSA PRIVATE KEY-----
xxx
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
yyy
-----END CERTIFICATE-----

Problem occurs when private key part is first and certificate part is second.
When certificate part is first, everything is fine.

Regards, Grzegorz.