Icinga2 Windows Agent behind One-Direction Firewall (Agent never access Master)

Hi there,

currently I have 2 types of setups:

Small customers who are not connected to our network environment with dynamic IPs - I Monitor those via Icinga2 Agent and those agents are connecting to our Icinga2 Master server through internet connection.

Large customers where we have a site2site VPN connection to each of them. The VPN connection is only one way so we can connect to the customers network but the customer has absolutely no access to our environment. Currently I monitor those customers with NRPE / NSClient++.

Now I’m planning to replace the NRPE / NSClient++ with the Icinga2 Agent because of performance, flexibility and stability reasons. I tried to configure an Icinga2 Windows Agent but It always tries to contact the Master Server for the certificate lookup. Is there anyway on how to implement the Icinga2 agent in this network setup automatically?

I’ve written a powershell deployment which configures the Icinga2 agent and contacts the master automatically which works well, But I’m trying to avoid internet traffic when I already have VPN connections setup. Currently the only correct solution I can think of now is to let customers reach my Icinga2 Server on 5665.

Do you have any other idea for an automatic deployment of the Icinga2 agent in this VPN scenario?

Thank you!

The graphical setup wizard doesn’t allow for connection less setups this time. You can use the node wizard on the Windows CMD shell in order to go for such an asynchronous setup step.

Here is my setup and how I manage to make it works :

The connection initiation between master and client can only be made in the direction Master–>Client (it’s like that because of network rules and configuration). So I can’t use the automatic certificate generation.

So what I did is to create the certificates and config files on the master and then copy them manually on the client. So this is not an automatic way but it’s the only way I manage to do it easily.

regards

With 2.8, you can.

  • Ensure the master is running

  • Generate a ticket for the client on the master

  • Run node wizard on the client

  • Don’t give it any connection details

  • Paste the ticket from the master

  • Read about the warning at the end, and manually copy the ca.crt file from the master to the clients certs/ directory

  • Edit the master’s zones.conf, add the Client endpoint and its connection details (host, port)

  • Restart the master

  • Restart the client

  • Wait until the master connects to the client, it will then receive a signing request and returns a signed certificate with the given ticket.

That’s basically what happens in the docs too.

I tried with the following commandline:

icinga2.exe node setup --master_host "myMasterName" --endpoint "myMasterName,1.2.3.4,5665" --accept-config --accept-commands --ticket "ticketid" --trustedcert "C:\path\cert.crt" --cn "myhostname" --zone "myzonename"

but it always tries to contact the master and results to this error:

information/cli: Requesting certificate with ticket 'xxxxxx'.
information/cli: Verifying parent host connection information: host 'myMasterName', port '5665'.
information/cli: Verifying trusted certificate file 'C:\Icinga2\public.crt'.
information/cli: Using the following CN (defaults to FQDN): 'myhostname'.
information/base: Writing private key to 'C:\ProgramData\icinga2\var/lib/icinga2/certs//myhostname.key'.
information/base: Writing X509 certificate to 'C:\ProgramData\icinga2\var/lib/icinga2/certs//myhostname.crt'.
information/cli: Requesting a signed certificate from the parent Icinga node.
critical/TcpSocket: getaddrinfo() failed with error code 11001, "Der angegebene Host ist unbekannt. "
critical/cli: Cannot connect to host 'myMasterName' on port '5665'
critical/cli: Failed to fetch signed certificate from parent Icinga node 'myMasterName, 5665'. Please try again.

i had a similar problem with one-way VPN and certs. what i do is creating the cert on the master, then push it to the client - my scriptpart on master:

icinga2 pki new-cert --cn $nodename --csr $nodename.csr --key $nodename.key
icinga2 pki sign-csr --csr $nodename.csr --cert $nodename.crt

this creates and signs the node cert. then i push key and crt file to the client and include the servers ca.crt. the csr file is not necessary (i remove it after signing).
this is basically what dnsmichi suggests above. i don’t execute the wizard on client node cause creating and copy of the cert-stuff is done by an ansible playbook. this playbook copies the cert files to /var/lib/icinga2/certs

hope this helps.
cheers joka

I was talking about the node wizard, not node setup.

Can you point me to the documentation on how to use the icinga2 node wizard command?
I cant find out which command I need to use to install it that way. Thank you!

The one from Linux, https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#clientsatellite-setup-on-linux which also is implemented in the icinga2.exe on Windows.

I just found out that I can use it in interactive mode - I did the following:

PS C:\Program Files\ICINGA2\sbin> .\icinga2.exe node wizard
Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Please specify if this is a satellite/client setup ('n' installs a master setup) [Y/n]: y

Starting the Client/Satellite setup routine...

Please specify the common name (CN) [HOSTNAME.fq.dn]: hostname.fq.dn


Please specify the parent endpoint(s) (master or satellite) where this node should connect to:

Master/Satellite Common Name (CN from your master/satellite node): master.fq.dn

Do you want to establish a connection to the parent node from this node? [Y/n]: n

Connection setup skipped. Please configure your parent node to
connect to this node by setting the 'host' attribute for the node Endpoint object.

Add more master/satellite endpoints? [y/N]: n

No connection to the parent node was specified.

Please copy the public CA certificate from your master/satellite
into 'C:\ProgramData\icinga2\var/lib/icinga2/certs//ca.crt' before starting Icinga 2.

Found public CA certificate in 'C:\ProgramData\icinga2\var/lib/icinga2/certs//ca.crt'.
Please verify that it is the same as on your master/satellite.

Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:

Accept config from parent node? [y/N]: y
Accept commands from parent node? [y/N]: y

Reconfiguring Icinga...
Disabling feature notification. Make sure to restart Icinga 2 for these changes to take effect.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.

Done.

Now restart your Icinga 2 daemon to finish the installation!

I restarted the Icinga2 Service but I get this in the logs:

[2018-02-15 10:34:21 +0100] information/ApiListener: New client connection for identity 'master.fq.dn' from [::ffff:192.168.0.2]:52458 (certificate validation failed: code 19: self signed certificate in certificate chain)
[2018-02-15 10:34:33 +0100] warning/JsonRpcConnection: API client disconnected for identity 'master.fq.dn'

But the certificate I used was definitly the correct certificate, I used the same file to automate hundrets of hosts installations where access to the master was possible.

Is there anything I did wrong?
Is it possible to use the icinga2 node wizard in a non-interactive mode?

Thank you in advance.

Did you copy the ca.crt file from your master node prior to restarting the service? The wizard tells you exactly that.

Yes I copied the file just before all the steps above

Did the log tell to send a certificate signing request to the parent node? Furthermore please add the involved versions from both the master and the client.

The Master and Client are both 8.1.
It did not tell me to send a certificate request to the parent node.

Is there a signing request file in %ProgramData%\var\lib\icinga2\certificate-requests?

No, its empty. But I do have hostname.crt and hostname.key in the icinga2/certs folder.

Hm, no clue. Is it reproducible with a fresh Windows test VM?

I reproduced the issue on a blank Windows 2012R2 VM.

In the log I can still see:

information/ApiListener: New client connection for identity 'master.fq.dn' from [::ffff:1.2.3.4]:45750 (certificate validation failed: code 19: self signed certificate in certificate chain)

The certs are in place, no signing request exists.

Any ideas on how to troubleshoot this better? Thank you.

Sounds like a bug to me, especially since that mode wasn’t part of the initial design requirement and as such likely slipped longer tests.

Please collect all your findings and create a new issue on GitHub.