I sat down scratching my head… that ntp client was syncing perfectly in unicast, and didn't create any association once configured in multicast. "Dah, the same old problem", I told to myself, "it's not getting the packets, setting a multicast route will fix it".

So I prepared the usual debugging set: one window running tcpdump 'dst port ntp', one window on the client running watch ntpq -c pe -c as, another one with tail -f /var/log/syslog | grep ntp and a free shell window. To my surprise, as soon as I fired up tcpdump, multicast ntp packets showed up. "What the…?!" I said. …Now, this was strange, anyway I set the multicast route as a good measure. And nothing changed. "Maybe it's the host firewall that's stopping ntp packets… wait, no, tcpdump wouldn't detect them in that case. So… maybe it's blocking IGMP… nah, how would I get those multicast packets then?"

Needless to say, a check in iptables logs showed that none of those packets was being blocked as expected. For another good measure I disabled the host firewall and restarted ntpd. And, of course, nothing changed.

"If I am getting the packets and ntpd doesn't sync, then it's refusing the packets, or it's not authenticating them. Let's check. A-ha! See, wrong ownerships for the keys. chown root:root ntp.keys… Now it will work."

It didn't. "Sh*t! Let's check the restrict rules! This is really pissing me off!". Changed the restrict options, then gave unrestricted access from the whole subnet, then from the whole internet… nothing, no association. "But why?"…

"Ok, let's stop and take a deep breath… I'll go through this damn config line by line and compare it with a working one"… and here it comes! "Whaaaaaat?!?! broadcastclient instead of multicastclient??? Oh, no! no!". But it's a "yes", and setting it to multicastclient obviously fixed it.

So, the moral of the story is: each time you face a strange problem and start thinking about complicated solutions, try to say to yourself: no, it must be simpler than this.