Thank you for the response. The filtering rules for the other applications come with their own prerouting, forwarding, input rules. It makes the whole thing less readable as well putting rules intended for forwarding into prerouting. Everything is still in the same table, so right now it's analogous to how it would be done in iptables with jumps to the chain that have the rules pertaining to these other applications (so chains without any type or policy). I'd really like to use nftables' ability to have many tables, separating cleanly rules for different applications so one can include or exclude a specific range of rules if it's not to be used. For this to be possible however, there seems to be the need for a new verdict or a verdict parameter to accept. Something like 'accept break' or 'accept final' to stop any further rule evaluation and making this the final decision. This way chains with lower priorities can force accept specific packets without them being reevaluated by chains with higher priorities. I think this way one can have multiple tables treating different use cases. Philipp Richter On Tue, 29 Jan 2019 at 11:42, Arturo Borrero Gonzalez <arturo@xxxxxxxxxxxxx> wrote: > > On 1/22/19 11:47 AM, Philipp Richter wrote: > > Hello, > > > > I have a question concerning the priority of chains as described here > > https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority > > > > If a lower priority chain accepts a packet it will still traverse the > > later priority chains. I wanted to cleanly separate tables for docker > > and/or libvirt, so packets that are accepted by those special lower > > priority tables shouldn't be reevaluated by the main chains. > > Is there a good way to achieve such clean separation using different > > tables ? One way I'd see is maybe marking the accepted packets and > > adding rules to the top of the chains that match that mark and accept > > those packets. But this looks like making this more complex than it > > needs to be if I can achieve the same thing by having the docker, > > libvirt chains in the main table (which is the case right now). > > Is there any better way ? > > > > You could try using different hooks, i.e, prerouting/filter and > forward/filter. > > If you drop a packet in prerouting/filter it won't show up again in > forward/filter. > > table ip t { > chain p { > type filter hook prerouting priority 0; policy accept; > } > > chain f { > type filter hook forward priority 0; policy accept; > } > }
