On 4/8/25 6:39 PM, Florian Westphal wrote: > Eric Woudstra <ericwouds@xxxxxxxxx> 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?
