Re: netfilter: br_netfilter:NS packet was incorrectly matched by the nftables rule

Florian Westphal <[email protected]>
Newsgroups gmane.linux.network.bridge,gmane.linux.network,gmane.linux.kernel,gmane.comp.security.firewalls.netfilter.devel
Message-ID <[email protected]>
gaoxingwang <[email protected]> wrote:
> Hello,everyone:
> In my test case, the container (with net.bridge.bridge-nf-call-ip6tables=1 set) attempts
> to ping the host's IPv6 address through a bridged network. Simultaneously, tcpdump is used to monitor
> the bridge, and it is observed that the ping fails.
> 
> The direct cause of the ping failure is that the NS packet matches the "ct state invalid drop"
> rule in nftables and is therefore discarded.
> 
> The commit 751de2012eafa4d46d80 introduced a modification to bridge traffic handling. When the bridge
> is in promiscuous mode, it resets the conntrack state of the packets. 
> >	if (promisc) {
> >		nf_reset_ct(skb);
> >		return NF_ACCEPT;
> >	}
> IPv6 NS packets are untracked by default.When an IPv6 NS packet passes through the bridge and the bridge
> is in promiscuous mode, the conntrack state of the packet is reset. If there is a firewall rule
> such as "ct state invalid drop," the IPv6 NS packet will be deemed invalid and dropped, leading to
> a ping failure issue.
> 
> Is this a bug, or is there an issue with my analysis? 

net.bridge.bridge-nf-call-ip6tables and bridge conntrack are
incompatible.

Either use ipv6 conntrack with net.bridge.bridge-nf-call-ip6tables or
disable net.bridge.bridge-nf-call-ip6tables.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.