We're running a Kubernetes cluster on Rocky Linux 10.2 virtual machines, with the FortiEDR Linux Collector installed directly on each host. When FortiEDR Communication Control was switched from Simulation to Prevention, the entire cluster became unavailable. Returning the policy to Simulation restored normal operation.
Our DevOps engineer reviewed the required external connections, and we allowed the relevant traffic. However, we still couldn't find any new Communication Control events or denied connections in the FortiEDR console. The affected nodes showed this kernel message:
`Failed to initialize the IGMP autojoin socket (err -1)`
The Collector version is 6.2.0.1350. We also checked the FortiEDR Events and Communication Control logs, but there were no entries indicating that traffic had been blocked.
The cluster is managed with Kubespray. Has anyone seen FortiEDR Communication Control interfere with Kubernetes networking, multicast, CNI overlay traffic, etcd communication, or control-plane virtual IPs? I'd appreciate suggestions for isolating the issue safely, since I'm not a Kubernetes specialist.
3 Answers
An empty event log doesn’t necessarily prove that nothing was filtered; some kernel-level interference may happen below the event layer. A safer test would be to enable Prevention on one isolated node, capture traffic during a short test window, and compare CNI overlay, etcd peer, kubelet, and container-runtime behavior. Similar incidents with other endpoint agents have involved kernel hooks temporarily freezing containerd or kubelet, especially during node bootstrap. In one case, the anti-malware component was the only module that reproduced the problem, so testing FortiEDR components separately may help narrow it down.
Kernel-level filtering can interfere with multicast or raw sockets even when the security console doesn’t show an explicit block. The IGMP autojoin error is worth investigating in that context. Check whether FortiEDR supports exclusions for multicast, raw sockets, or the specific CNI traffic patterns before enabling Prevention across the cluster.
Is a control-plane virtual IP provided by something like keepalived or kube-vip? The IGMP message could indicate that the VIP mechanism or related multicast traffic stopped working, rather than ordinary pod traffic being denied. It would be useful to identify the CNI, kernel version, and whether the control-plane VIP failed at the same time.
Our DevOps team confirmed that the cluster is managed with Kubespray. We tested with the agent active but still haven’t found a clear Communication Control anomaly. The vendor’s technical support team is investigating the case, but the root cause is still unknown.