[Bug 1305] Rules in first chain same hook ignored if second chain has policy drop

bugzilla-daemon at netfilter.org bugzilla-daemon at netfilter.org
Thu Jan 21 02:44:00 CET 2021


https://bugzilla.netfilter.org/show_bug.cgi?id=1305

--- Comment #10 from Marcos de Oliveira <markinholiveira at gmail.com> ---
(In reply to Timo Weingärtner from comment #8)
> You can have this quick-accept and delayed-drop behaviour if you create only
> one base chain and branch off to other chains from there (the same worked
> with classic iptables):
> 
> table inet filter {
>   chain forward {
>     type filter hook forward priority filter
>     ct state established accept
>     iifname "internal" accept
>     iifname "world" tcp dport ssh jump ssh-in
>     iifname "world" tcp dport https jump https-in
>     # this could be policy, but I like to make it explicit:
>     drop
>   }
>   chain ssh-in {
>     ip6 daddr 2001:db8::2a accept
>     ip6 daddr 2001:db8::539 accept
>     ip daddr 192.0.2.42 accept
>   }
>   chain https-in {
>     ip6 daddr 2001:db8::1267 accept
>   }
> }
> 
> If you want to carry complex decisions made earlier to other base chains you
> can use a mark.
> 
> Maybe I misunderstand your goal or use case? Why do you want to have
> separate base chains if you do not want them to independently drop a packet?

It would be much more convenient if we could use nftables priorities... There
are many tools that use iptables/nftables for managing nat/routing, like LXD,
docker, libvirt. If we could accept packets early in the packet processing, we
could have the flexibility to accept a packet and not care if other chains have
a policy of drop. Also, nftables and iptables would coexist easier, as we could
create a chain of lower priority than iptables's and still have policy of DROP
in iptables INPUT chain for example. It would be more clean also, less jumps
between chains.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20210121/56af85de/attachment.html>


More information about the netfilter-buglog mailing list