Re: [PATCH] selftests: nft_queue: conntrack expiration requeue

[Florian Westphal <fw@strlen.de>]

Antonio Ojea <aojea@google.com> wrote:
> yeah, sorry, as you say, I meant disabled
> 
> > > state. Setting the conntrack entry timeout to 0 allows to remove the state
> > > and the packet is sent to the queue.
> >
> > But its the same as --delete, entry gets tossed (its timed out) and is
> > re-created from scratch.
> >
> 
> The behavior is not the same as deleting the entry, I tried both and
> only works by setting the timeout, I tried to follow the codepath but
> I'm very unfamiliar with the codebase to understand why delete is
> different from updating with timeout 0.

It should be the same.

Only difference:

ctnetlink delete zaps entry right away, timeout-0 zaps it on the next
(matching) packet or when gc finds the entry (or on next conntrack -L),
whatever comes first.

> > That zaps the entry and re-creates it, all state is lost.
> > Wouldn't it make more sense to bypass based on connmark or ctlabels?
> 
> This simplifies the datapath considerably and avoids the risk of
> having to coordinate marks with other components, but there is also
> some ignorance on my side on how to use all netfilter features
> efficiently.
> 
> The use case I have is to only process the first packet of each
> connection in user space BUT also be able to scan the conntrack table
> to match some connections that despite being established I want to
> reevaluate only once, so I have something like:

> ct state established,related accept
> queue flags bypass to 98

Understood.

> And then I scan the conntrack table, and for each flow I need to
> reevaluate once , I just reset the timeout and it ignores the rule "ct
> state established,related accept" , then if the verdict is accepted it
> keeps skipping the queue.

Yes, but thats because the packet that hits the timed-out flow zaps it
and is 'new' (for tcp_loose=1).

> However, if there is a more elegant way that does not depend on this
> "hack" please let me know
> Can I apply a connmark or ctlabel via netlink in an existing flow?

Yes, bypassing nfqueue was the original use-case that prompted the
connlabel feature.

> If so, how to make it so it only is enqueued once, do I need to mark
> and unmark the flow?

There are several ways to do what you want.

You can add a 'requeue' named set:
   ct id @myset queue ...

and then add/remove from that set to (re)enable via userspace.

Or you can use opt-in (or out, its simpler) via mark or label:
  ct state new ct label set shouldqueue ...
  ct label shouldqueue queue ...

or, without need to set initial state:
  ct label ! "wasqueued" queue ...

... and then use ctnetlink to set the label (or clear it).

Or, set/clear the label from the nfqueue program itself when setting accept
verdict (via nested NFQA_CT + CTA_MARK/LABELS).

Same with connmark, but I know that this might be impossible
due to those being used for policy routing etc.

> > I'm not sure what the test is supposed to assert.
> >
> > That setting timeout via ctnetlink to 0 kicks the entry out of the ct hash?
> 
> The behavior I'd like to assert is if this behavior is just some side
> effect I found or something it will be "stable" , since I'm trying to
> build the firewall on this behavior and if changes it will be very
> disruptive

Setting the timeout to 0 zaps the entry at earliest opportunity,
it will not be "reactivated" on next packet, its just
conntrack --delete with minor random delay.