[GH-ISSUE #2926] netbird 0.32.0 breaks K3s 1.32.2+k3s1 with flannel due to iptables conflicts #6306

Open
opened 2026-08-05 01:07:42 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @christian-schlichtherle on GitHub (Nov 21, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2926

Describe the problem

We're operating an IoT project where some K3s nodes are placed at customer premises. So we are installing Netbird 0.32.0 on each node first and then install K3s v1.32.2+k3s1 using flannel next. When installing k3s, we are providing flannel-iface=wt0 to tell it to use the Netbird interface for node-to-node communication.

This works great to some extent but there is a problem: When the Netbird service starts, it sets up its iptables rules. Also, flannel sets up its iptables rules. However, there seem to be conflicts in those rules, resulting in communication being broken after every restart of the Netbird service, e.g. when installing an upgrade. As a workaround, I have to restart the k3s(-agent) service after every restart of the Netbird service.

Summing it up, to restart all Netbird services in the cluster, I have to do something like this:

ansible k3s_server -b -m shell --forks 1 -a 'systemctl restart netbird && sleep 3 && systemctl restart k3s'
ansible k3s_agent -b -m shell -a 'systemctl restart netbird && sleep 3 && systemctl restart k3s-agent'

As you can imagine, this is not a sustainable solution, just a hacky workaround.

Is this a known issue? What are my options? Wait for a fix or try another CNI like cilium?

To Reproduce

Steps to reproduce the behavior:

  • Install Netbird on a bunch of nodes
  • Install K3s on the nodes with flannel-iface=wt0
  • Restart the netbird service only and watch the in-cluster communication to break, e.g. you can't kubectl logs <any-pod> anymore.

Expected behavior

Not breaking the in-cluster communication by leaving flannel's iptable rules alone.

Are you using NetBird Cloud?

Yes

NetBird version

0.32.0

NetBird status -dA output:

n/a

Do you face any (non-mobile) client issues?

Yes.

Screenshots

n/a

Additional context

See above.

Originally created by @christian-schlichtherle on GitHub (Nov 21, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2926 **Describe the problem** We're operating an IoT project where some K3s nodes are placed at customer premises. So we are installing Netbird 0.32.0 on each node first and then install K3s v1.32.2+k3s1 using flannel next. When installing k3s, we are providing `flannel-iface=wt0` to tell it to use the Netbird interface for node-to-node communication. This works great to some extent but there is a problem: When the Netbird service starts, it sets up its iptables rules. Also, flannel sets up its iptables rules. However, there seem to be conflicts in those rules, resulting in communication being broken after every restart of the Netbird service, e.g. when installing an upgrade. As a workaround, I have to restart the k3s(-agent) service after every restart of the Netbird service. Summing it up, to restart all Netbird services in the cluster, I have to do something like this: ```shell ansible k3s_server -b -m shell --forks 1 -a 'systemctl restart netbird && sleep 3 && systemctl restart k3s' ansible k3s_agent -b -m shell -a 'systemctl restart netbird && sleep 3 && systemctl restart k3s-agent' ``` As you can imagine, this is not a sustainable solution, just a hacky workaround. Is this a known issue? What are my options? Wait for a fix or try another CNI like cilium? **To Reproduce** Steps to reproduce the behavior: + Install Netbird on a bunch of nodes + Install K3s on the nodes with flannel-iface=wt0 + Restart the netbird service only and watch the in-cluster communication to break, e.g. you can't `kubectl logs <any-pod>` anymore. **Expected behavior** Not breaking the in-cluster communication by leaving flannel's iptable rules alone. **Are you using NetBird Cloud?** Yes **NetBird version** 0.32.0 **NetBird status -dA output:** n/a **Do you face any (non-mobile) client issues?** Yes. **Screenshots** n/a **Additional context** See above.
saavagebueno added the clienttriage-neededk8s labels 2026-08-05 01:07:42 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#6306