[Bug 1128] ip6_tables connmark or connlabel never matches

bugzilla-daemon at netfilter.org bugzilla-daemon at netfilter.org
Fri Mar 10 09:08:43 CET 2017


https://bugzilla.netfilter.org/show_bug.cgi?id=1128

--- Comment #2 from Florian Westphal <fw at strlen.de> ---
(In reply to Jim Carter from comment #1)
> Created attachment 498 [details]
> Test ruleset using connlabel

Thanks, the reproducer works for me.
This is caused by

netfilter: connmark: ignore skbs with magic untracked conntrack objects

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb9c9649a1d0a65a8f94f784aa18252a0dd584c1

but unfortunately that change is/was intentional.

The problem is that in ipv6, mac address <-> ipv6 address resolution is handled
by icmpv6, and netfilters connection tracker intentionally ignores them
(ipv4 uses arp which isn't handled by iptables).

Before the commit, this worked because the mark would be added to the percpu
untracked object.  It never worked for connlabels as the match always contained
the ct_is_untracked() test.

The test works fine when adding

ip6tables -I INPUT -p icmpv6 -m conntrack --ctstate UNTRACKED -j ACCEPT

to pass neigh resolution packets.

I see no way to fix this, reverting is possible of course but has other
side effects, the percpu object is never reset so when doing something like

-m <some condition> -j CONNMARK --set-mark 42
-m connmark --mark 42

... the 2nd rule will match other UNTRACKED packets too.
Resetting the untracked object is possible, but will need more code to avoid
problems when NFQUEUE gets used (so multiple packets can refer to same
untracked
entry).

Furthermore, this would force us to retain the UNTRACKED object, so we won't be
able to remove it as done in this pending patch (not yet applied):

https://patchwork.ozlabs.org/patch/736578/

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170310/4b2fb90c/attachment.html>


More information about the netfilter-buglog mailing list