> On 24 Sep 2015, at 23:24, Eric Zounes <eric.zou...@puppetlabs.com> wrote: > > So I just discovered the problem I was having. It won't relay checks back to > the parent node correctly because the A record pointing at the static NAT > address is different than the one pointing at the internal address. I'll file > a bug report.
The issue is different to that - https://dev.icinga.org/issues/10216 There’s a naming convention for endpoint name, client certification common name (CN) and the NodeName for each node. That was initially written for the cluster docs though it applies for remote clients too. I’ll update the docs while making the bi-directional understanding issue a bit more clear. Kind regards, Michael > > On Thu, Sep 24, 2015 at 2:02 PM, Eric Zounes <eric.zou...@puppetlabs.com> > wrote: > Hey everyone, > > I had some questions around the client -> parent node communication between > two Icinga2 agents. The documentation here: > http://docs.icinga.org/icinga2/snapshot/doc/module/icinga2/chapter/icinga2-client > states the following: > > "Icinga 2 master, satellite and client instances communicate using the > default tcp port 5665. The communication is bi-directional and the first node > opening the connection "wins" if there are both connection ways enabled in > your firewall policies." > > Does this mean that both firewall policies are required? If I have a scenario > where there is a satellite node relaying results from a client to the master > zone, is it enough to have the master connect to the satellite to get these > results? > > The reason I'm asking is because I have a situation where I have a client and > master separated by a firewall. I have to NAT connections established by the > client to reach the master node. I can verify the connection from both the > master -> client and client-> master. However, checks executed by the client > are stuck in a pending state. The master's "cluster-zone" check for the > client is succesful. When I enable debug logging on the client, I can see the > check results are being relayed to the master correctly, but the state is > never updated. > > Has anyone else encountered anything like this? I two other zones separated > by a firewall policy and they work just fine. The only difference here is > that the connections are NAT'd. > > -Eric > > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users -- Michael Friedrich, DI (FH) Senior Developer NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 GF: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | michael.friedr...@netways.de ** OSBConf 2015 - September - osbconf.org ** ** OSMC 2015 - November - netways.de/osmc ** _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
