[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