Athanasius <netfilter.org@xxxxxxxxx> 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.
