We are trying to connect an Icinga for Windows Agent with an ICINGA MASTER.
During the configuration we discovered that the SAtellite cannot communicate with master.
Our network people anser us with this Info:
Following the tests carried out, it emerges that since there is a PAT and not a 1:1 NAT (between MASTER and SATELLITE), it is possible to establish a communication only if this starts from the MASTER. I will try to explain myself better if I try to perform a ping or a telnt start from MASTER this then manages to respond correctly towards the ICINGA Satellite, because the session has already been created by the latter, however if the session is created from SATELLITE towards the ICINGA MASTER the session is not created and the FW drops the connection because that PAT IP is shared with all customers and therefore the FW doesn’t know who you are trying to communicate with by dropping the communication.
For this reason the solution would be to review the application logic by trying to have the ICINGA MASTER machine establish the session in order to keep the session up.
Due to this explanation how can I connect the MASTER with satellite and make the monitoring (Icinga for Windows) works fine ?
Is there a procedure to connect a MASTER (starting configuration from master) with a SATELLITE (icinga for windows) ?
If you only have the connection information in the masters zone.conf then the satellite will not try to connect. The relationship/parent of the satellite still needs to be in the satellites zones.conf or it will not accept the connection.
Sorry… But is not clear to me if there is a way to make my architecture works.
Can you explain better, please?
have a look at this post: Connection direction vs configuration mode - #4 by dnsmichi
So if you omit, in the zones.conf on the satellite, the host variable in the endpoint of the master node, it will stop trying to establish the connection.
Hi Dominik, i was reading the thread you attached, but i don’t understand if in that way is possible to install icinga agent on the client without the requisite that the client have to establish a connection starting from his side.
There is the mentioned config file zones.conf and in there the nodes of the cluster are declared.
if no host = Address is stated for the endpoint, the agent with this zones.conf will not try to connect to this cluster node. If the other cluster node has a host = address in his zones.conf for the fist node then it will try to initiate the connection. If both have the host of the other node, the connection can be established faster if no problems like the one of the OP are present.
Unfortunately I’m not sure to have understood what is the right procedure to configure the IGINGA FOR WINDOWS Agent on this scenario.
We can only start the configuration from MASTRR NODE (traffic is allowed only when start from master to satellite and not viceversa)
Can you details the steps to configure the SATELLITE ?
Just don’t put any
host = address statements of the master endpoints into the
zones.conf files of the satellites.
This will stop the satellites from initiating connections to the master nodes.
Follow this part of the docs: Distributed Monitoring - Icinga 2
In the step where the parent endpoint (your master) is added don’t activate “Connect to this endpoint” and instead enable the TCP listener
Then save the Icinga2 public CA certificate of the master to this file on the agent
To generate said file run the following command on your master
icinga2 pki save-cert \
--trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
--host <your master fqdn here>
On the agent you should have a key and csr file under ``C:\ProgramData\icinga2\var\lib\icinga2\certs` with the agent endpoint name.
Copy those to the master and run
icinga2 pki sign-csr --csr icinga2-agent.localdomain.csr --cert icinga2-agent.localdomain.crt
to sign the CSR and create your cert.
Then copy the cert back to the agent, restart the service and check both logs (master and agent) if the connection is correctly established
The mentioned settings for the zones.conf files by @rivad are also necessary.
PS: Just for the sake of completeness and for future use of the correct terminology:
Icinga on a windows host is always (and only) an agent. On a Linux host it can be a master, a satellite or an agent.
Agents only check themselves while masters and satellites are also able to check other hosts.
I have performed these 2 command (on master):
icinga2 pki new-cert --cn SATELLITE --key SATELLITE.key --csr SATELLITE.csr
icinga2 pki sign-csr --csr SATELLITE.csr --cert SATELLITE
Where SATELLITE.key and SATELLITE.csr was generated on CLIENT\SATELLITE and moved to master
The commands generate 2 files (on master):
that I moved on CLIENT\SATELLITE (C:\ProgramData\icinga2\var\lib\icinga2\certs)
restarted the agent…
But Still I have error:
Remote Icinga instance ‘SATELLITE’ is not connected to ‘icinga2-master.locale’
This would be the self-signed cert the agent deploys on installation.
Try using the key and create a CSR on your master:
icinga2 pki new-cert --cn icinga2-master1.localdomain
(replace with naming for your agent)
And then try the steps mentioned above
I solved changhing the configuration regarding the CA when Installing the AGENT.
probably I was wront when ASK me for a ca.crt “PATH” I Insert the folder path - instead of the ca.crt FILE PATH.
THIS Solve my “sign” master-client problem.
NOw I have another problem but I will open another POST.