On 4/8/25 6:39 PM, Florian Westphal wrote:
> Eric Woudstra <ericwo...@gmail.com> wrote:
>> This adds the capability to conntrack 802.1ad, QinQ, PPPoE and PPPoE-in-Q
>> packets that are passing a bridge.
>
> Conntrack is l2 agnostic, so this either requires distinct
> ip addresses in the vlans/pppoe tunneled traffic or users
> need to configure connection tracking zones manually to
> ensure there are no collisions or traffic merges (i.e.,
> packet x from PPPoE won't be merged with frag from a vlan).
>
> Actually reading nf_ct_br_defrag4/6 it seems existing
> code already has this bug :/
>
> I currently don't see a fix for this problem.
> Can't add L2 addresses to conntrack since those aren't
> unique accross vlans/tunnels and they can change anyway
> even mid-stream, we can't add ifindexes into the mix
> as we'd miss all reply traffic, can't use the vlan tag
> since it can be vlan-in-vlan etc.
>
> So likely, we have to live with this.
>
> Maybe refuse to track (i.e. ACCEPT) vlan/8021ad qinq, etc.
> traffic if the skb has no template with a zone attached to it?
>
> This would at least push 'address collisions' into the
> 'incorrect ruleset configuration' domain.
Thanks for the input. I will look in to it and see if I can also add it
to the test script.
The thing is, single vlan (802.1Q) can be conntracked without setting up
a zone. I've only added Q-in-Q, AD and PPPoE-in-Q. Since single Q (L2)
can be conntracked, I thought the same will apply to other L2 tags.
So would single Q also need this restriction added in your opinion?
