Re: NFQUEUE usage and interaction with later chain rules

[Florian Westphal <fw@strlen.de>]

Athanasius <netfilter.org@miggy.org> wrote:
>   I'm in the middle of trying to implement some firewall bans based on
> GeoIP data.  It seemed that implementing an NFQUEUE userspace helper
> to do the lookups and decision making was the most feasible solution,

For IP matching?  Use ipset or xt_geoip from xtables addons, much
simpler and faster...

> but I have run into some issues.  I can probably work around them,
> but it does make this setup more fragile than I'd like.
> 
>   So, I'd like to ensure I'm properly understanding some things.
> 
>   1. The only practical verdicts the userspace helper can return are
>   ACCEPT or DROP.  Checking through some documentation, examples, and
>   kernel code I've come across 'STOLEN', 'QUEUE' and 'REPEAT', but I
>   cannot find any actual documentation on what these might achieve.

You can accept, drop, queue (pass packet to queue/program), or repeat,
which will make the packet reenter the same ruleset, i.e. its queued
again unless you use mark tricks to avoid that.

STOLEN cannot be used, its kernel internal.

>   2. There appears to be no way to have an NFQUEUE rule act in a manner
>   where the userspace verdict can cause subsequent rules in the chain to
>   be considered.

Yes.

>     I'd specifically like my userspace helper to be able to say 'DROP',
>   but otherwise allow rule evaluation to continue in the chain, rather
>   than blindly accepting all else.

Thats impossible to do.

>     If I could cause rule evaluation to jump to another chain that would
>   also be acceptable, simply placing rules that would normally be later
>   in the current chain into that one.

Same.

> there's no userspace helper listening to the queue... but this literally
> turns the rule into an ACCEPT, rather than passing evaluation to later
> rules.  Presumably the 'fail open' socket option, to not cause all
> packets to be dropped if the queue buffer is filled, has the same issue.
> It's then blind ACCEPT rather than "let later rules look at the packet".

Right.

>   Is any of my understanding in error?  Can I actually implement this
> how I'd prefer, with later rules being evaulated upon some specific
> verdict returned from userspace ?

No.  It would require significant rewrites on the kernel side, nfqueue
would have to be moved from core into xt_NFQUEUE and nft_queue,
respectively, with nftables/xtables specific changes to support what
you want, and such change would also break backwards compatibility.

I don't think this is going to happen.