Hrm, I think I'm calling it a day (or a night). Couldn't figure out yet why on this #Proxmox server a Linux bridge wouldn't forward #Multicast Router Discovery (#MRD) messages generated via @troglobit's mrdisc. While sending to ff02::6a via ICMPv6 echo request or UDP works just fine...
Disabling multicast snooping on the bridge does not help either. Nor does "ebtables -I FORWARD -p IPv6 --ip6-destination ff02::6a -j ACCEPT".
Likely sth. with the #ip6tables with nf-call-ip6tables enabled...
Most current Linux distributions (2021) have bridge firewalling enabled by default. Particularly in Ubuntu, since 21.04, this has been known to cause a fair amount of head scratching! This blog post shows only how to rectify the problem using the sysctl command. Another blog post may venture into managing bridge firewall rules with either the traditional ebtables command, or the new nft suite. Example: $ sudo ebtables -L Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 0, policy: ACCEPT Bridge chain: OUTPUT, entries: 0, policy: ACCEPT $ sudo nft list tables bridge $ Fixing the Problem The relevant kernel bridge settings can be seen with the following command:
@troglobit this confirms that it's nf-call-ip6tables indeed: "ip6tables -I FORWARD -p 0 -m physdev --physdev-is-bridged -j ACCEPT" -> then it works.
I have the feeling that this iptables-in-bridge code hook is one of the most misunderstood/misused firewall "feature" in Linux... people often miss that this then applies to all firewall rules... ideally it would only apply to rules with physdev options...
Now need to check the exact rule and need to file a bug report at #Proxmox, I guess.
@troglobit and I think I've seen other weirdnesses with it in the past, too. I think the physdev-in/out was not reset properly when using veth between two bridges. And have had issues with conntrack and this feature, too, I think. ebtables is the way cleaner, less hacky alternative...
I'm not sure if I can just deactivate the nf-call-ip6tables hook. Will need to check what #Proxmox intends to do with it, or if I would break something else if I did that.
@troglobit also another downside is the performance penalty this creates on all traffic. Even if it's not matching, all bridged traffic will still be parsed / the skb pulled into the IP headers at least. And is evaluated for conntrack.
Maybe #nftables / nft does it all in a cleaner way. But still need to try it properly and get accustomed to it :-).
@troglobit also it's this rule which breaks it on Proxmox: "-A PVEFW-FORWARD -m conntrack --ctstate INVALID -j DROP". Which is called right at the start from the FORWARD chain.
My guess is that #MRD would need entries here: https://elixir.bootlin.com/linux/v6.7.8/source/net/netfilter/nf_conntrack_proto_icmpv6.c#L57
Kernel rebuild and VM testing in progress.
@T_X glad I could be of any help. I usually turn it off completely, but there are some acceleration features available that I've yet to look into in detail.
It's some sort of conntrack when routing between VLAN interfaces on top of a bridge, it can learn that it can accelerate a flow by just rewriting the VLAN tag and source IP, basically. Was a friend who told me about it. (We use the bridge on top of a switchcore, so VLAN filtering in combination.)
T_X
Joachim Wiberg