Fix clab ipv6 forwarding on bridges

[jbemmel]

Fixes #1669

Temporary fix until Containerlab catches up

• Using OVS bridge doesn't have the same issue
• Cleaning up rules is a little cumbersome, as it requires the handle

Note: Verbose debug prints don't work upon 'down' - see other issue

[jbemmel]

Libvirt creates rules with both iifname and oifname, perhaps that would be better?

[ipspace]

We're not going to start playing the security whack-a-mole just because you don't find it convenient to wait for the containerlab fix, particularly considering that:

A) the problem depends on the security setup of the server (considering the same setup works on my server and on a fresh Ubuntu 24.04 Vagrant box)
B) you're the first one reporting it
C) nobody tested this across various Linux distros and I don't think that would be a good investment of anyone's time anyway.

We should document the potential issue in the clab documentation though.

[jbemmel]

That’s fine, I agree and I figured you might feel that way - changing security settings is risky. But I wanted to give you that choice

[ipspace]

I will definitely polish the clab caveats you wrote and merge them. I the meantime, please check:

• Whether you have br_netfilter module loaded (lsmod|grep net)
• What are the sysctl net.bridge settings?

[ipspace]

FWIW, on my server br_netfilter definitely caused #1669. After loading it, IPv6 connectivity immediately stopped working.

Setting sudo sysctl net.bridge.bridge-nf-call-ip6tables=0 "fixed" the problem, but I don't feel comfortable doing more than mentioning it in the caveats. Can you check whether this works for you?

[jbemmel]

FWIW, on my server br_netfilter definitely caused #1669. After loading it, IPv6 connectivity immediately stopped working.

It's loaded on mine by the Docker snap:

jeroen@j:~/Projects/netlab/tests$ cat /etc/modules-load.d/snap.docker.conf
# This file is automatically generated.
arp_tables
br_netfilter
ip6table_filter
iptable_filter
overlay

Setting sudo sysctl net.bridge.bridge-nf-call-ip6tables=0 "fixed" the problem, but I don't feel comfortable doing more than mentioning it in the caveats. Can you check whether this works for you?

jeroen@j:~/Projects/netlab/tests$ cat /proc/sys/net/bridge/bridge-nf-call-ip6tables
1

Setting it to '0' indeed allows IPv6 test validation to succeed

However, there's also individual bridges:

jeroen@j:~/Projects/netlab/tests$ cat /sys/devices/virtual/net/virbr0/bridge/nf_call_ip6tables
0
jeroen@j:~/Projects/netlab/tests$ cat /sys/devices/virtual/net/docker0/bridge/nf_call_ip6tables
0

but these are already 0 also for Netlab created bridges.

[jbemmel]

FWIW, on my server br_netfilter definitely caused #1669. After loading it, IPv6 connectivity immediately stopped working.

It's loaded on mine by the Docker snap:

jeroen@j:~/Projects/netlab/tests$ cat /etc/modules-load.d/snap.docker.conf
# This file is automatically generated.
arp_tables
br_netfilter
ip6table_filter
iptable_filter
overlay

FYI - snap remove docker --purge followed by netlab install containerlab also solves the issue; the br_netfilter module is no longer loaded at startup.

In summary: We could detect the presence of the 'br_netfilter' module and issue a warning about possible ipv6 interference, and we could recommend to try reinstalling Docker using netlab install in case of issues

[ipspace]

Setting it to '0' indeed allows IPv6 test validation to succeed

👍 Now we know what the issue is ;)

However, there's also individual bridges:
but these are already 0 also for Netlab created bridges.

I tried setting those variables, but it seems like they have no effect whatsoever.