Re: NFQUEUE verdicts - adding non-termination

[Patrick McHardy <kaber@trash.net>]

On 12.11.2010 20:54, Stig Thormodsrud wrote:
> On 11/11/2010 02:50 AM, Patrick McHardy wrote:
>> On 11.11.2010 10:01, Andrew Watts wrote:
>>> Hi.
>>>
>>> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4 post is very interesting.
>>>
>>> NF_CONTINUE would provide the NFQUEUE target the added flexibility of, say, partial handling in userspace. A queue-handler could have a set of criteria that, when satisfied, would result in an immediate drop or accept. One could then leave the rest of the packets to find their fate in the chains/rules left to traverse.
>>>
>>> I would be interested in helping to add this verdict if someone will take the lead (assuming a patch hasn't already been written - has it?).
>>
>> There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
>> Queueing happens outside of the ruleset context, so in either case the
>> packet would continue through the network stack directly, not after
>> the NFQUEUE rule.
> 
> I've been interested in this thread since I recently converted our
> version of snort inline to use NFQUEUE instead of QUEUE.  One of driving
> factors was that I needed to have multiple QUEUE targets.  While I was
> doing the work I was hoping there was a verdict like NF_RETURN, so that
> if it passed the snort inspection then I could have another NFQUEUE
> target that would do https domain filtering.  From reading this thread I
> now understand why I can just continue, but I wondering what is that the
> recommended approach for this type of use case?  As it is now, I think I
> would need to have the 2nd NFQUEUE target on a different hook.

Look at my second response to Andrew, you can use NF_REPEAT and some
mark based jumps to do this. You can also return NF_QUEUE from userspace
directly and encode the queue number in the upper 16 bits.