On 2015-05-03 6:55 pm, Tim Dunphy wrote:
It's listening on both IPv6 and IPv4. Specifically, why is that a problem?
The central problem seems to be that the monitoring host can't hit nrpe on port 5666 UDP.
[root@monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H puppet.mydomain.com CHECK_NRPE: Socket timeout after 10 seconds.
It is listening on the puppet host on port 5666
[root@puppet:~] #lsof -i :5666 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xinetd 2915 root 5u IPv6 24493 0t0 TCP *:nrpe (LISTEN)
And the firewall is allowing that port:
[root@puppet:~] #firewall-cmd --list-ports 5666/udp
But if I check the port using nmap
[root@monitor1:~] #nmap -p 5666 puppet.mydomain.com
Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-03 22:51 UTC Nmap scan report for puppet.jokefire.com (216.120.250.140) Host is up (0.012s latency). PORT STATE SERVICE 5666/tcp filtered nrpe
That port is closed despite the port being allowed on the firewall.
So I thought that the problem was that xinetd was listening to port 5666 only on tcp v6. And when the monitoring host hits the puppet host using tcp v4 it can't because only tcp v6 is active on that port.
You mention that it's listening on both tcp v4 and v6. But I only see v6 in that output. How are you determining that
It's a problem because the port does not appear to be open from the monitoring host:
[root@monitor1:~] #nmap -p 5666 puppet.mydomain.com
Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-03 22:33 UTC Nmap scan report for puppet.jokefire.com (216.120.250.140) Host is up (0.011s latency). PORT STATE SERVICE 5666/tcp filtered nrpe
I see that there's been quite a bit of discussion on this issue, already, but I don't believe I've seen anyone note/mention this:
The above does not indicate that the port is closed...the above indicates that the port is open but is being filtered by your firewall rules.
You might want to also check your firewall rules to ensure that port 5666 is allowing connections from the client system(s) in question.