Score:0

Check_mk agent listening on ipv6, how to change to ipv4

gb flag

Hi I am new to check_mk and not very good in linux server configuration at all, so thanks for your patience.

I installed check_mk under debian via gdebi (systemd not xinetd - and used default configuration so far) and also deployed several agents already. That worked good on most machines. but on machines, where ipv6 is deaktivated for security reasons, it does not work. (https://security.stackexchange.com/questions/181949/how-would-disabling-ipv6-make-a-server-any-more-secure seems to be not the worst idea)

checking netstat -npa | grep 6556 showed me its tcp6 listening.

tcp6       0      0 :::6556                 :::*                    LISTEN      1/init

When I check telnet localhost 6556 I get the agent output (the same when I run check_mk_agent).

And check_mk dashboard tells me it can ping that server. So it is there.

What are my chances to fix that problem without activating ipv6?

Thanks :)

Brandon Xavier avatar
us flag
What exactly is the problem? Given that telnet seems to work locally, have you checked your firewall?
gb flag
The exact problem is, that i cannot change checkmk to work with ipv4 and so looking for hepl how to do that. Yes i checked my firewall, which drops ipv6.
Brandon Xavier avatar
us flag
Start by doing `telnet 127.0.0.1 6556` and reporting back if that worked. That should definitively tell us if ipv4 is working on not (localhost may resolve to EITHER ipv4 or ipv6). If that worked, try 'telnet ip.of.problem.machine 6556' from the check_mk host. If that didn't work, then run 'netstat -anp | grep 6556` on the problem machine WHILE the telnet is trying from the check_mk host and post those results.
gb flag
thanks brandon for the debug help!!
Score:1
cn flag

On Linux, the v6 sockets are dual stack by default, but this is platform specific behavior. Of course applications can still do AF_INET sockets, and would have to if v6 is not in the kernel. Beware, without v6 some apps may no longer work in their default configurations.

but on machines, where ipv6 is deaktivated for security reasons, it does not work.

Do not disable IPv6 completely on a host. You already broke a thing, and pretending it does not exist is not secure. Avoid adding to technical debt.

Instead, leave IPv6 enabled on hosts and manage your network. Just to name some basics, RA guard and other first hop security, firewall rules, and manage A or AAAA records in DNS. An IPv6 implementation is not required, but actually securing a network requires knowledge of both.

gb flag
Thanks for your reply. Anyways: Can you still try to answer my questions? Or give a solution? I did not disable ipv6 but it is already. I don't even know how to do that. What is AF_INET? What is RA?
John Mahowald avatar
cn flag
My answer is to re-enable IPv6 in the network stack on hosts. But since you are not, please edit your question to add how exactly you have configured check_mk_agent to listen on this port. They document xinetd or systemd options, which are quite different software.
gb flag
Updated - and after unsuccessful research switching ipv6 on now :D ...
gb flag
Now back to ipv4 thanks to the solution in my answer. thanks again for trying.
Score:0
gb flag

I was now able to switch to ipv4.

I followed the instructions in the manual installation here:

https://docs.checkmk.com/latest/de/agent_linux.html (2.5) - which was not obvious for me, as the gdebi installation worked without any errors.

Then I configured xinetd to change the ceckmk socket to listen on ipv4 in the configfile /etc/xinetd.d/check-mk-agent.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.