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

[bugzilla-daemon at netfilter.org]

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

Brian Pond <brian at pondconsulting.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brian at pondconsulting.net

--- Comment #4 from Brian Pond <brian at pondconsulting.net> ---
Comment on attachment 602
  --> https://bugzilla.netfilter.org/attachment.cgi?id=602
Script demonstrating conflicting base chains.

I am unsure whether this is a "bug" or "working as intended".  But I have
encountered a similar situation as the OP.

Script attached showing how to duplicate.  There are 2 base chains for
filter+output.  
* The first chain allows outbound HTTP/HTTPS.  
* The second chain has a default policy of "drop".  

If you apply these rules, you cannot access the web through your browser.

>From a certain point of view, this seems to contradict documentation. 
Documentation says that "accept" is a terminating statement.  The first chain
is lower priority, so should be evaluated first.  Once the outbound HTTP/HTTPS
is accepted, it should not be re-evaluated by the 2nd chain, and dropped.

What I "think" the documentation should say is this:

1) "If you create 2+ base chains for the same hook, all chains are evaluated."
2) "Accept is a terminating statement, but only within its own base chain."
3) "Drop is a terminating statement globally.  It will override decisions by
other base chains of the same hook."

Whether this is what the maintainers intended or not, I don't know.

My workaround was creating non-base chains, and doing jumps.  I'm kind of
disappointed about that.  I'd hoped to avoid jumps altogether, by creating
multiple base chains of different priorities.  With my final base chain being
"log drop".  This way, if traffic is not explicitly allowed, it is logged and
dropped.

My ruleset is working fine now, but it's not quite-as-clean as I'd hoped.

-- 
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/20200805/3586a7c2/attachment.html>