Re: NFQUEUE verdicts - adding non-termination

[Stig Thormodsrud <stig@vyatta.com>]

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.

stig