> On 25 Sep 2015, at 09:46, Michael Friedrich <michael.friedr...@netways.de> > wrote: > >> >> 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.
https://github.com/Icinga/icinga2/commit/6555e42d43fb999576f46489fb929a835aef9c7b Kind regards, Michael > > 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 -- 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
