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.
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
